服务器监控如何监控集群节点的网络流量带宽

监控集群网络流量需分层采集、统一聚合、智能基线比对：节点层读取/proc/net/dev；容器层用eBPF或Ingress聚合；集群层通过Prometheus+Grafana实现动态基线告警；AI场景需适配RoCEv2或eBPF专项采集。

要监控集群节点的网络流量带宽，关键在于**分层采集、统一聚合、智能基线比对**。不同规模和架构的集群适用不同方案，但核心逻辑一致：从节点级原始数据出发，叠加拓扑与业务语义，最终形成可告警、可溯源、可调度的带宽视图。

一、节点级实时带宽采集（底层数据源）

每个集群节点的网卡流量统计，优先读取 Linux 内核暴露的 /proc/net/dev 文件。它每秒更新多次，字段固定，含接收/发送字节数、包数、错误数等。脚本或 Agent 可按 1–5 秒间隔轮询，计算 Δbytes/Δt 得到瞬时速率（如 B/s、Mbps）。该方式轻量、无侵入、兼容所有物理/虚拟网卡（eth0、ens3 等），但不支持容器内部 veth 对或 pod 级别细分。

若需进程级归因，可搭配 nethogs（按进程实时显示带宽占用）或 iftop（按连接显示流量），二者均需 root 权限，适合临时排查，不适合长期采集。

二、容器与服务层流量识别（K8s 或微服务环境）

在 Kubernetes 集群中，单纯看宿主机网卡已不够。推荐两种路径：

1. Sidecar + eBPF 方案：用 Cilium 或 Pixie 在内核层捕获 pod 间 TCP/UDP 流量，直接输出源/目的 pod、端口、协议、字节数，延迟低、精度高，且能绕过 iptables 性能瓶颈；
2. Ingress/Nginx 层聚合：启用 nginx-module-vts 模块，在入口网关统一统计各 service 或 upstream 的请求量、响应体大小、状态码，再换算为近似带宽（如平均响应 100KB × 200 QPS ≈ 16 Mbps），适合 HTTP/HTTPS 为主的应用。

三、集群维度统一监控与异常识别

单点数据必须汇聚才有价值。建议采用以下组合：

1. 用 Prometheus 抓取各节点的 node_exporter（含 netdev 指标）、Cilium agent、Nginx-vts 等指标，存储为 time-series；
2. 用 Grafana 建模：例如绘制“各节点 eth0 发送带宽 Top5”面板，叠加 95 分位线与当日基线；
3. 对跨时区集群（如东京+纽约+法兰克福），必须启用 动态基线建模——按本地时间滑动窗口学习流量周期性（如工作日 9–18 点 vs 午夜批处理高峰），避免误报。当法兰克福节点凌晨 3 点突发 80% 带宽占用，系统应自动比对其历史同期曲线，而非套用全局阈值。

四、AI 训练等特殊场景需额外适配

GPU 集群跑 AllReduce 时，流量特征完全不同：大象流、全节点同步突发、固定通信拓扑。此时传统 NetFlow/sFlow 工具可能失效：

1. 若走 RoCEv2 或 InfiniBand，流量绕过 IP 栈，/proc/net/dev 不可见，需依赖交换机的 PFC/ECN 计数器或厂商 SDK（如 NVIDIA DOCA）；
2. 若走 TCP/IP，可用 Hubble（基于 eBPF）可视化 pod 间梯度同步流，标记出 incast 拥塞点；
3. 务必确认采集位置：是在计算节点、TOR 交换机，还是 GPU 直连网卡？位置错，数据就失真。