New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Meter bandwidth #43
Comments
|
Well neat, should have assumed that. |
Ah, and
RX bytes:648 (648.0 B) TX bytes:1296 (1.2 KB) The container still has to be up though. |
Now I wish I knew about how the Linux kernel reports this information so we could collect the bandwidth numbers easily. Won't solve the DC problem though... |
Welp, we could use a libpcap wrapper for Go and sum the bytes on the interface. Then if we wanted to expose controls to demarcate IP blocks to ignore we could. Not terrible. |
Actually, even better is gopacket. That's actually what packetbeat uses. |
Yeah, that wasn't too bad to get started. |
👍 Awesome! How should we integrate this? |
We could determine the interface and do the IP sniffing on container creation, all from the API node. There's a big issue with trying to monitor the interface from the API node if we're using Docker swarm though. Kind of making me think we'd need to run our own job on each node. I also have no idea how many CPU cycles or RAM we'd be wasting on monitoring. For now I could integrate it and we roll with it from there, maybe defaulting the monitoring to off. |
We should meter bandwidth in and out.
Bandwidth in should be the sum of:
The last two can be monitored via their network interface. I'm not sure what tools are available other than summing on a
tcpdump
of the interface Docker gives them. The other hard bit is determining what kind of traffic it is. Do we want to regard traffic internal to a data center differently than traffic to the whole web?The text was updated successfully, but these errors were encountered: