-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Expose network stats for pods #852
Expose network stats for pods #852
Conversation
5552fce
to
f1bc44b
Compare
If leaky is imported just to get pod infra container name, it's not worth it. I'd just have it be a constant or parameter in this code. |
retest this please |
f1bc44b
to
cf6f29b
Compare
Removed |
Yeah, the problem seems to be unrelated. BTW, we will have to redo this work in heapster-scalability branch. |
@mwielgus Are you targeting the new metrics APIs in the scalability branch? Sorry I've not kept up to speed with it. |
If the new API is delivered on time then yes we will switch, if not we will keep using the old one. |
cf6f29b
to
42d3c59
Compare
Ready for review please. Jenkins GCE e2e is flaky & needs to either disabled or fixed separately to this PR. |
// A model entity can be a Pod, a Container, a Namespace or a Node. | ||
type ExternalEntityListEntry struct { | ||
Name string `json:"name"` | ||
CPUUsage uint64 `json:"cpuUsage"` | ||
MemUsage uint64 `json:"memUsage"` | ||
RxBytes uint64 `json:"rx_bytes"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need network metrics in the model or is it necessary only for monitoring purposes?
The cost for adding metrics to the model is kindda high for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So are you saying it shouldn't be returned by API queries, only passed to sinks? I'd prefer it to be exposed via the REST API & that means using the model, doesn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. Is it required to be exposed via APIs as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Point me to the requirements :) Don't we make it up as we go along? ;)
Honestly, if it's too expensive to store a couple of extra values per pod then I don't mind dropping it from there & just leave it as passed to sinks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd personally prefer exposing this and filesystem stats as well. Its just that the default resource limits in Kube has to change once these metrics are added. So as long as we can go fix the limits, then adding these metrics is OK by me :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK how about I remove from the model for this version & revisit it for @mwielgus' rewritten version?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM. So is monitoring the primary use case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Monitoring & accounting, yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't think of a use for autoscaling on network traffic right now.
44cd513
to
b445c4f
Compare
pod := &sd.data.Pods[podIndex] | ||
// If we find a matching pod then add the container to the pod's containers slice. | ||
if pod.Name == podName && pod.Namespace == podNamespace { | ||
cont.Hostname = pod.Hostname |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, the pod infra container should be hidden inside heapster. That way if we collect metrics from rocket for example, which does not need an infra container, we will not break users of heapster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestions on how to do that? Right now I can't think of one tbh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need stats at the pod level in addition to container level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bit confused by this. We're adding the infra container to the appropriate pod so this is done.
General structure LGTM. Thanks @jimmidyson !! |
b445c4f
to
e412d1a
Compare
Network stats are now only sent to sinks, not retrievable via Heapster API as discussed with @vishh. |
@vishh Please can you let me know what is outstanding for this PR to be merged? |
The only issue with this PR is that of exposing the infra container. I'd prefer adding pod level metrics and exposing network as a pod level metrics. |
This is how's it's been done in |
Ok then. No issues in that case. On Tue, Jan 12, 2016 at 8:00 AM, Jimmi Dyson notifications@github.com
|
Thanks @vishh. Merging. |
Expose network stats for pods
Fixes #368
Dirty: using leaky infra container name, regex for container name to pod mapping, but seems to work OK...
/cc @vishh @akash010 @smarterclayton @simon3z