基础设施监控基础：CPU、内存、磁盘、网络等基础监控指标与工具
在构建AI算力集群的全栈监控体系时，基础设施层是最先需要被“看见”的部分。无论是承载大模型训练的GPU服务器，还是提供参数存储的高速NVMe磁盘阵列，其底层都依赖CPU、内存、磁盘和网络这四大基础资源。本章聚焦于这些资源的监控原理、关键指标、常用工具以及常见误区，为后续理解GPU、RDMA等高级监控打下坚实基础。
核心原理：从“指标采集”到“状态判定”
基础设施监控的本质，是对操作系统内核与硬件设备暴露的计数器（Counter）和状态文件进行周期性采样，再通过阈值或趋势算法判定资源是否健康。Linux系统下，/proc与/sys文件系统是主要数据源。例如，/proc/stat记录CPU时间片，/proc/meminfo反映内存使用，/proc/diskstats提供块设备I/O统计，而网络数据则来自内核网络协议栈的计数器。
监控系统通常采用“拉取”或“推送”模型。Prometheus采用拉取模型，定期从节点上的exporter（如node_exporter）抓取指标；而Telegraf等代理则主动推送数据到时序数据库。无论哪种方式，都需要注意采样周期与指标语义。例如，CPU使用率是“增量除以时间差”计算出的速率，而非瞬时值；磁盘I/O的await指标是平均服务时间，不能与队列长度混为一谈。
iowait高可能意味着I/O饱和，但也可能是CPU等待锁导致的假象。
四大资源核心指标与工具
CPU监控
CPU监控的核心指标包括：user、system、iowait、steal、idle以及负载均值（load average）。对于AI集群，还需关注context switches（上下文切换）和run queue长度，因为频繁的线程切换会显著影响训练性能。
常用工具：top/htop用于实时查看，mpstat -P ALL查看每核使用率，pidstat定位进程级CPU消耗，perf用于剖析CPU缓存命中率与分支预测失败。在集群场景下，node_exporter暴露的node_cpu_seconds_total指标是Prometheus告警的基础。
# 查看CPU运行队列与上下文切换
vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 0 0 8123456 1234 567890 0 0 12 34 1234 5678 8 2 89 1 0其中r列表示运行队列长度，若持续大于CPU核数，则说明CPU饱和。
内存监控
内存监控不能只看free命令的剩余值。Linux会尽量利用空闲内存做页缓存（page cache），因此available才是真正可分配的内存。关键指标包括：total、used、buff/cache、available、swap used以及OOM Killer事件。对于AI训练，还需关注HugePages使用情况，因为大页内存能显著降低TLB miss。
工具方面，free -h快速查看，/proc/meminfo提供详细数据，sar -r记录历史趋势，valgrind或heaptrack用于定位内存泄漏。在Kubernetes环境中，kubelet暴露的container_memory_working_set_bytes是容器内存监控的标准指标。
si（swap in）和so（swap out）持续非零，说明内存已严重超卖，此时应优先排查进程内存占用，而非盲目扩容。
磁盘监控
磁盘监控分为容量与性能两个维度。容量指标包括df -h显示的文件系统使用率、inode使用率；性能指标则包括IOPS（每秒读写次数）、吞吐量（MB/s）、await（平均I/O响应时间）、%util（设备繁忙百分比）以及队列深度。对于AI集群，模型检查点（checkpoint）写入和数据集读取对磁盘性能要求极高。
工具推荐：iostat -x 1查看详细性能，iotop定位进程级I/O，du/ncdu分析空间占用，smartctl检查磁盘健康状态（SMART信息）。在分布式文件系统（如Lustre、GPFS）场景下，还需监控元数据服务器的负载。
# iostat 输出示例
Device r/s w/s rkB/s wkB/s await %util
nvme0n1 120.0 45.0 1024.0 2048.0 2.50 45.0%util接近100%并不一定意味着磁盘饱和，还需结合await判断。若await远高于基准值（如SSD应小于1ms），则说明I/O路径存在瓶颈。
网络监控
网络监控指标包括带宽利用率、吞吐量、丢包率、重传率、TCP连接数以及RTT（往返时延）。在AI集群中，东西向流量（GPU间通信）远大于南北向流量，因此需要特别关注网卡（NIC）的rx/tx字节数、drop和errors计数。对于RDMA网络，还需监控ibstat或perftest提供的链路速率与重传计数。
常用工具：sar -n DEV查看历史流量，nload/bmon实时带宽，ss -s查看TCP连接状态汇总，ethtool -S查看网卡硬件计数器，tcpdump抓包分析。在Kubernetes中，cni插件（如Calico）会暴露container_network_receive_bytes_total等指标。
| 资源 | 核心指标 | 推荐工具 | 告警阈值建议 |
|---|---|---|---|
| CPU | 使用率、运行队列、上下文切换 | top, mpstat, pidstat | 使用率>85%持续5分钟 |
| 内存 | available, swap使用, OOM事件 | free, sar, /proc/meminfo | available<10%总内存 |
| 磁盘 | IOPS, await, %util, 容量 | iostat, iotop, df | %util>80%且await>20ms |
| 网络 | 带宽, 丢包率, 重传率, RTT | sar, nload, ethtool | 丢包率>0.1%或重传率>1% |
方法流程：构建基础监控的标准化步骤
在AI算力集群中部署基础监控，建议遵循以下流程：
- 盘点资源清单：梳理所有物理机/虚拟机的CPU型号、核数、内存大小、磁盘类型（SSD/NVMe/HDD）、网卡速率（25GbE/100GbE/RoCE）。
- 确定采集粒度：默认采集频率为15秒，关键性能指标（如GPU所在节点的网络流量）可缩短至5秒。历史数据保留策略建议：原始数据7天，聚合数据30天。
- 部署采集代理：在每台节点上运行node_exporter（Prometheus生态）或Telegraf，并配置好认证与端口安全。
- 建立告警规则：基于上述表格中的阈值，设置多级告警（Warning/Critical）。注意避免“抖动”告警，可设置持续时间（如持续3个周期）。
- 验证与调优：使用压测工具（如stress-ng、fio、iperf3）人为制造负载，验证监控数据是否准确、告警是否触发。
案例：一次“CPU高但负载低”的排障
某训练集群反馈任务运行缓慢，监控面板显示所有节点CPU使用率均超过90%，但负载均值（load average）仅为2（节点为64核）。初步判断CPU资源充足，但训练速度依旧上不去。
进一步排查发现：mpstat -P ALL显示所有核心的%usr均高，但vmstat中的cs（上下文切换）高达每秒20万次。使用pidstat -w定位到是某个数据加载进程在频繁创建和销毁线程。最终确认是数据预处理代码使用了multiprocessing池，但池大小设置过大，导致线程切换开销远大于计算收益。优化后，CPU使用率降至60%，训练速度反而提升了30%。
误区与复盘
- 误区一：只看平均值。CPU平均使用率低，但可能存在单核打满（如中断处理绑定在CPU0）。应使用
mpstat -P ALL查看每核分布。 - 误区二：忽略内存回收机制。当
kswapd进程持续占用CPU时，说明内存回收压力大，此时free命令显示的available可能仍较高，但性能已下降。 - 误区三：磁盘%util=100%即故障。对于NVMe SSD，%util达到100%可能仍能维持极低延迟；应结合
await和svctm判断。 - 误区四：网络丢包只查物理链路。在Overlay网络（如VXLAN）中，丢包可能发生在宿主机iptables规则或虚拟交换机（Open vSwitch）层面，需检查
drop计数。
基础设施监控是AI集群可观测性的地基。只有准确理解CPU、内存、磁盘、网络四类资源的指标语义，并熟练运用对应的工具链，才能在故障发生时快速定位根因。下一层级的监控——如GPU利用率、显存带宽、RDMA重传——都建立在这些基础能力之上。建议读者在真实环境中反复练习top、iostat、sar的组合使用，形成“指标-现象-根因”的快速映射直觉。