Gathering Network Metrics: iptables and Interface Counters

good explanation for that: network interfaces exist within the context of _network namespaces_. The kernel could probably accumulate metrics about packets and bytes sent and received by a group of processes, but those metrics wouldn't be very useful. You want per-interface metrics (because traffic happening on the local `lo` interface doesn't really count). But since processes in a single cgroup can belong to multiple network namespaces, those metrics would be harder to interpret: multiple network namespaces means multiple `lo` interfaces, potentially multiple `eth0` interfaces, etc.; so this is why there is no easy way to gather network metrics with control groups. Instead you can gather network metrics from other sources. #### iptables iptables (or rather, the netfilter framework for which iptables is just an interface) can do some serious accounting. For instance, you can setup a rule to account for the outbound HTTP traffic on a web server: ```console $ iptables -I OUTPUT -p tcp --sport 80 ``` There is no `-j` or `-g` flag, so the rule just counts matched packets and goes to the following rule. Later, you can check the values of the counters, with: ```console $ iptables -nxvL OUTPUT ``` Technically, `-n` isn't required, but it prevents iptables from doing DNS reverse lookups, which are probably useless in this scenario. Counters include packets and bytes. If you want to setup metrics for container traffic like this, you could execute a `for` loop to add two `iptables` rules per container IP address (one in each direction), in the `FORWARD` chain. This only meters traffic going through the NAT layer; you also need to add traffic going through the userland proxy. Then, you need to check those counters on a regular basis. If you happen to use `collectd`, there is a [nice plugin](https://collectd.org/wiki/index.php/Table_of_Plugins) to automate iptables counters collection. #### Interface-level counters Since each container has a virtual Ethernet interface, you might want to check directly the TX and RX counters of this interface. Each container is associated to a virtual Ethernet interface in your host, with a name like `vethKk8Zqi`. Figuring out which interface corresponds to which container is, unfortunately, difficult. But for now, the best way is to check the metrics _from within the containers_. To accomplish this, you can run an executable from the host environment within the network namespace of a container using **ip-netns magic**. The `ip-netns exec` command allows you to execute any program (present in the host system) within any network namespace visible to the current process. This means that your host can enter the network namespace of your containers, but your containers can't access the host or other peer containers. Containers can interact with their sub-containers, though. The exact format of the command is: ```console $ ip netns exec <nsname> <command...> ``` For example: ```console $ ip netns exec mycontainer netstat -i ``` `ip netns` finds the `mycontainer` container by using namespaces pseudo-files. Each process belongs to one network namespace, one PID namespace, one `mnt` namespace, etc., and those namespaces are materialized under `/proc/<pid>/ns/`. For example, the network namespace of PID 42 is materialized by the pseudo-file `/proc/42/ns/net`. When you run `ip netns exec mycontainer ...`, it expects `/var/run/netns/mycontainer` to be one of those pseudo-files. (Symlinks are accepted.) In other words, to execute a command within the network namespace of a container, we need to:

The section discusses how to gather network metrics for containers, since control groups don't directly expose them. It suggests using iptables for accounting traffic, providing an example of setting up a rule to count outbound HTTP traffic. It also explains how to check interface-level counters by executing commands within the container's network namespace using `ip netns exec`, detailing how this command works and how it leverages namespace pseudo-files.