第4章监控工具总览

4、监控工具总览：硬件计数器、软件工具、开源方案、商业方案对比

说实话，做RoCE网络监控这件事，最怕的不是工具不够用，而是工具太多不知道怎么选。我刚开始接触RoCE那会儿，面对一堆计数器、命令行工具、开源软件、商业套件，整个人是懵的。后来踩了不少坑，才慢慢理清楚——不同场景，就得用不同的工具。

这一节，我把常用的监控工具分成了四类：硬件计数器、软件工具、开源方案、商业方案。咱们一个一个来看，我会结合我自己的实战经验，告诉你每个工具适合干什么、不适合干什么。

硬件计数器，说白了就是网卡和交换机芯片内部自带的统计寄存器。它们记录着最原始的数据——比如收发了多少包、丢了多少包、有没有CRC错误、缓存是否溢出。

我个人习惯，排查任何RoCE性能问题，第一步永远是看硬件计数器。为什么？因为它不消耗CPU资源，也不影响业务流量，纯粹是硬件自己默默在记。

关键硬件计数器一览（以Mellanox ConnectX系列为例）

计数器名称	含义	排查方向
`port_rcv_packets`	接收总包数	流量基线
`port_xmit_packets`	发送总包数	流量基线
`port_rcv_errors`	接收错误包数	物理层问题
`excessive_buffer_overrun_errors`	接收缓存溢出	流控或背压问题
`link_down_events`	链路中断次数	物理链路稳定性
`cnp_sent`	发送的CNP报文数	拥塞通知频率
`cnp_received`	接收的CNP报文数	对端拥塞情况

怎么读这些计数器？用 ethtool -S 或者 mlxstat 命令就行。举个例子：

# 查看所有硬件计数器
ethtool -S enp175s0f0np0 | grep -E "cnp|error|drop|overrun"

# 只看CNP相关
ethtool -S enp175s0f0np0 | grep cnp

我的经验： 如果 cnp_sent 和 cnp_received 数值持续增长，说明网络正在频繁发生拥塞。这时候别急着调参数，先看看是不是流量模型有问题。

硬件计数器虽然准，但信息太原始。你想想看，光看一个“丢包数”，你根本不知道是哪个进程丢的、丢的是什么类型的包。这时候就需要软件工具上场了。

我常用的软件工具就这几个：

举个例子，用 ib_write_bw 快速验证两台机器之间的带宽：

# 服务端（192.168.1.10）
ib_write_bw -d mlx5_0 -p 18515

# 客户端
ib_write_bw -d mlx5_0 -p 18515 192.168.1.10

如果测出来的带宽远低于预期（比如40G网卡只跑出10G），那就要怀疑是不是有丢包或者流控问题了。

避坑指南： 我曾经用 perftest 测带宽，发现结果忽高忽低。查了半天，原来是CPU频率缩放（scaling governor）设成了powersave模式。改成performance模式后，带宽立刻稳定了。所以，测性能前记得先检查CPU和PCIe配置。

如果你需要持续监控、告警、可视化，光靠命令行工具肯定不行。这时候开源方案就派上用场了。

我接触过的开源方案主要有这几类：

Prometheus + node_exporter + RDMA exporter：最流行的组合。node_exporter 收集系统指标，RDMA exporter 专门收集网卡计数器。配合 Grafana 做仪表盘，效果不错。
Collectd + RDMA plugin：老牌监控框架，插件丰富，但配置稍复杂。
Netdata：开箱即用，界面漂亮。对RDMA的支持一般，但胜在部署简单。
Elastic Stack (ELK)：适合做日志分析和历史趋势。我会把硬件计数器的数据定期导入ES，然后做异常检测。

下面是我自己搭的一个简易监控架构图：

这个架构图，说白了就是“采集→存储→展示”三层。我建议你从 Prometheus + RDMA exporter 开始，因为社区活跃，遇到问题容易找到答案。

如果你所在的公司预算充足，或者运维团队人手不够，商业方案确实能省不少事。我接触过的商业方案有：

NVIDIA Mellanox UFM (Unified Fabric Manager)：专门针对Mellanox网络的监控管理平台。能自动发现拓扑、实时监控、历史回溯、甚至做拥塞控制策略下发。功能很全，但价格不便宜。
SolarWinds Network Performance Monitor：通用网络监控工具，对RoCE的支持一般，但胜在界面友好。
VMware vRealize Network Insight：如果你用VMware虚拟化，这个工具能帮你看到虚拟机到物理网卡的完整路径。
HPE OneView / Dell OpenManage：服务器厂商自带的监控工具，对自家网卡支持好，但跨厂商兼容性差。

我的建议： 如果网络规模在几十台以内，开源方案完全够用。如果超过100台节点，或者有严格的SLA要求，可以考虑UFM。我在一个200节点的集群上用过UFM，确实方便——拓扑自动发现、一键导出报表、历史数据回溯，这些功能自己搭开源方案要花不少时间。

最后，我整理了一张对比表，方便你快速决策：

维度	硬件计数器	软件工具	开源方案	商业方案
部署难度	无需部署	低	中	低
实时性	极高	高	中	高
历史回溯	不支持	有限	支持	支持
可视化	无	命令行	Grafana等	内置仪表盘
告警能力	无	需脚本	Alertmanager	内置
成本	免费	免费	免费	高
适用场景	快速定位	日常巡检	持续监控	大规模/企业级

我的习惯： 日常巡检用软件工具，出问题时先看硬件计数器，长期监控用开源方案搭一套Prometheus+Grafana。如果公司预算允许，再上一套UFM做兜底。这样既省钱又保险。

好了，这一节的内容就到这里。工具是死的，人是活的。关键不是你会用多少个工具，而是你知道在什么场景下用哪个工具。下一节，咱们会深入一个具体的工具——perftest，看看怎么用它做性能基准测试。