实现容器内网流量精准监控需打通 docker metrics、cgroups 网络子系统与网络命名空间三层链路：启用 daemon.json 的 metrics-addr 提供基础入口；部署 cadvisor 读取 veth 接口级 rx/tx 字节统计；再通过 prometheus+promql 实现按容器、协议、端口的实时定向分析，而非依赖 docker stats 等伪精准方式。
要实现容器内网流量的精准监控，不能依赖 Docker 守护进程本身直接提供细粒度网络流统计（如按容器、按协议、按端口的实时速率），因为 dockerd 的内置 metrics（如 metrics-addr:9323）只暴露引擎级指标（如容器启停数、镜像拉取量），不包含容器间或容器内部通信的网络字节/包级数据。
真正可行的路径是：以守护进程配置为起点，打通底层网络可观测链路。核心在于启用并整合三类能力——Docker 的 metrics 接口、cgroups 网络子系统暴露、以及容器网络命名空间的可访问性。
✅ 启用 Docker 内置 metrics 接口（基础入口）
这是整个监控体系的第一步，为 Prometheus 等工具提供统一抓取入口：
# 编辑 /etc/docker/daemon.json
{
"metrics-addr": "127.0.0.1:9323",
"experimental": true
}
⚠️ 注意：
metrics-addr默认只监听本地，生产环境如需远程采集，请改用0.0.0.0:9323并配合防火墙策略；该接口本身不输出容器网络流量详情，但它是后续集成 cAdvisor 的前提。
重启生效：
sudo systemctl restart docker
验证是否开启：
curl http://127.0.0.1:9323/metrics | grep -i container
你会看到类似 container_last_seen{...} 这类生命周期指标，但没有 rx/tx 字节数——这正是需要补充的关键缺口。
✅ 配合 cAdvisor 暴露容器级网络 I/O（关键补全）
cAdvisor 是 Google 开发的容器资源监控代理，能自动发现所有容器，并通过 /sys/fs/cgroup/ 和 /proc/net/ 等路径读取真实网络统计（包括 veth 接口的 rx_bytes/tx_bytes）：
-
启动 cAdvisor（推荐容器方式）：
docker run -d \ --name=cadvisor \ --privileged \ --volume=/:/rootfs:ro \ --volume=/var/run:/var/run:ro \ --volume=/sys:/sys:ro \ --volume=/var/lib/docker/:/var/lib/docker:ro \ --publish=8080:8080 \ --detach=true \ --restart=unless-stopped \ gcr.io/cadvisor/cadvisor:v0.49.1
-
访问
http://localhost:8080/metrics，你会看到：container_network_receive_bytes_total{container="myapp",interface="eth0",pod="nginx-5b8f6c7b4d-xyz"} 12345678 container_network_transmit_bytes_total{container="myapp",interface="eth0",pod="nginx-5b8f6c7b4d-xyz"} 87654321
✅ 这些指标来自内核
net_cls.classid+veth设备统计，天然支持容器内网通信（如容器A ↔ 容器B走 docker0 桥接）的收发分离统计，且精确到每个容器、每个接口。
✅ 利用 Prometheus + PromQL 实现“内网流量”定向分析
有了 cAdvisor 数据，即可用 PromQL 提取容器间通信特征。例如：
-
统计某容器发往其他容器的出向流量（即它作为服务端被调用时的响应流量）：
rate(container_network_transmit_bytes_total{interface=~"veth.*",container!="",pod!=""}[1m]) -
过滤仅属于 docker0 桥接网络的流量（排除 host 网络或 macvlan 等）：
rate(container_network_transmit_bytes_total{interface=~"veth.*",container=~".+"}[1m]) * on (container) group_left() kube_pod_info{namespace="default"} 识别高频内网通信对（如 api 容器频繁调用 db 容器）： 结合
container_network_transmit_packets_total与标签pod,namespace，在 Grafana 中用「TopN」面板展示sum by (container, remote_container) (...)（需额外打标或借助 service mesh 注解）。
❌ 不推荐依赖的“伪精准”方式
-
docker stats --no-stream：只返回累计 NetIO 总量（如12MB / 3MB），无法区分方向、无时间窗口、不支持标签筛选，不能用于内网流量归因。 -
netstat -tulnp | grep docker-proxy：只能看到端口映射关系，看不到实际流量大小和流向容器 ID，排查效率低。 - 单纯修改
daemon.json加其他字段（如"log-driver"或"default-ulimits"）：与网络流量监控无关，属日志或资源限制范畴。
✅ 补充：若需更底层控制（如限速+监控联动）
当既要监控又要干预内网流量（例如限制容器 A → 容器 B 的带宽），需进入网络命名空间操作 tc：
PID=$(docker inspect -f '{{.State.Pid}}' myapp)
nsenter -t $PID -n tc qdisc show dev eth0 # 查看当前限速规则
nsenter -t $PID -n cat /sys/class/net/eth0/statistics/rx_bytes # 实时读取
此方式要求容器启动时加
--cap-add=NET_ADMIN，适合有强管控需求的场景，但不属于“守护进程配置”范畴，而是运行时增强。
不复杂但容易忽略：精准监控容器内网流量，本质是打通 Docker metrics（调度层）→ cAdvisor（资源层）→ 内核网络统计（驱动层） 这条链路。守护进程配置只是起点，不是终点。
