企业官网建设流程全解析

上周五凌晨三点，我被值班手机震醒。客户那边HPC集群跑着跑着，MPI作业突然卡死，所有节点上的ib_write_bw测试都报“connection timed out”。我ssh上去一看，ibstat显示端口状态正常，ibv_devinfo也没报错，但rdma res show看到的QP数量异常——某个节点上活跃QP数从正常的200多飙到了1800，而且大部分处于RTS状态但实际没有数据传输。

这就是典型的“看起来活着，实际上已经死了”的RDMA网络问题。没有监控，你根本不知道QP泄漏、内存注册泄漏、CQ溢出这些慢性杀手什么时候会捅你一刀。今天这篇笔记，就是讲怎么用Prometheus+Grafana这套组合拳，把RDMA网卡的那些“暗病”全部暴露在阳光下。

为什么需要专门监控RDMA

很多人觉得RDMA监控就是看看带宽、看看丢包率。太天真了。RDMA的监控维度跟传统TCP完全不是一个量级——你需要同时盯着网卡硬件层、驱动层、协议栈层、应用层四个维度的指标。

我踩过最深的坑：某次生产环境，MLNX网卡的PCIe带宽利用率到了95%，但ethtool看到的网络带宽才用了30%。查了两天才发现是DMA写内存的路径上，NUMA节点跨了，导致内存带宽成了瓶颈。这种问题，没有细粒度的RDMA指标监控，你连方向都找不到。

监控指标选型：哪些值得盯

先列一份我实际在用的监控清单，不是官方文档里那些“建议监控”的废话，而是真正能救命的指标：

硬件层

• 端口物理状态（Active/Down）—— 这个太基础，但很多人只看ibstat不看历