3. 故障检测基础：监控指标、日志收集、告警系统、健康检查机制

3.1 故障检测的总体框架与核心原理

大规模GPU集群的故障检测，本质上是一个从“数据采集”到“状态判定”再到“事件输出”的流水线过程。其核心原理可以概括为：通过多维度、多层次的数据采集，将不可直接观测的硬件健康状态与软件运行状态，转换为可量化、可比较的指标与日志，再依据预设的规则或模型进行状态判定，最终形成告警事件驱动后续的诊断与恢复流程。

一个完整的故障检测体系，通常包含四个相互关联的层次：

• 数据采集层：负责从GPU、CPU、内存、NVLink、存储及作业系统中获取原始数据，包括监控指标与日志。
• 数据处理层：对采集到的数据进行清洗、聚合、关联和格式化，去除噪声，提取关键特征。
• 状态判定层：基于阈值、趋势、规则或机器学习模型，判断当前系统是否处于异常状态，并评估异常的严重程度。
• 事件输出层：将判定结果转化为结构化的告警事件，通过告警系统通知运维人员，并触发自动化的健康检查或恢复动作。

这四层结构形成了一个闭环，任何一层的缺失或失效，都可能导致故障“发现不了、定位不准、响应不快”。下图展示了这一基础框架及关键组件间的数据流向：

3.2 核心监控指标与日志收集方法

有效的故障检测依赖于对关键指标的持续观测。对于GPU集群，监控指标必须覆盖从底层硬件到上层作业的完整栈。仅关注GPU利用率（SM Occupancy）是远远不够的，许多故障在早期表现为温度、功耗或链路误码率的微小变化。

下表列出了故障检测中最优先关注的指标类别及其典型代表：

指标类别	关键指标示例	常见故障关联
GPU核心与显存	GPU温度、显存温度、GPU功耗、核心频率、显存频率、ECC错误计数（单比特/多比特）	散热失效、显存损坏、供电不稳定、芯片老化
GPU利用率与活动	SM占用率、显存利用率、PCIe/NVLink吞吐量、GPU计算API调用频率	应用异常卡死、驱动挂起、通信瓶颈
高速互联链路	NVLink/PCIe链路误码率（CRC错误）、重传计数、链路降速状态	线缆松动、连接器氧化、光模块故障
节点与系统级	CPU温度、内存ECC错误、电源冗余状态、风扇转速、Infiniband/RoCE网卡状态	主板故障、电源模块失效、网络分区
作业与运行时	作业退出码、运行时长、CUDA错误日志、NCCL超时或初始化失败	软件bug、驱动不兼容、分布式通信异常

日志收集方面，建议采用结构化日志与集中式收集策略。在GPU节点上，通过dcgm导出指标，通过syslog/journald收集系统日志，同时将Slurm等作业管理器的日志一并纳入采集范围。一个典型的采集配置片段如下：

# 使用dcgm-exporter采集GPU指标，并通过Prometheus抓取
./dcgm-exporter --address=:9400 --metrics-file=/etc/dcgm-exporter/dcp-metrics.csv

# 配置Prometheus抓取任务
scrape_configs:
  - job_name: 'gpu_node'
    static_configs:
      - targets: ['10.0.0.12:9400', '10.0.0.13:9400']
    metrics_path: '/metrics'

3.3 告警系统设计与健康检查机制

告警系统的价值在于将海量数据转化为有限的、可行动的“事件”。设计上应遵循“分级、分渠道、可路由”的原则。例如，将告警分为P0（紧急，节点宕机）、P1（严重，GPU ECC错误激增）、P2（警告，温度超过阈值）等级别。P0/P1级告警通过短信或电话路由至值班长，P2级告警则通过即时通讯工具通知相关团队。

健康检查机制是故障检测的“主动探测”手段，与被动监控互补。它通常分为两类：

• 静态健康检查：定期执行，检查硬件状态。例如通过nvidia-smi -q查询GPU的Health状态，或通过BMC检查电源与风扇状态。
• 动态健康检查：在作业启动前或运行中执行，验证GPU能否实际完成计算与通信任务。例如运行一个简短的CUDA样本程序或NCCL全归约测试，以确认GPU及NVLink通信功能正常。

一个推荐的健康检查流程如下：

1. 作业启动前检查：对分配到的节点执行快速GPU健康检查（如nvidia-smi -pm 1 设置持久模式，并检查ECC错误计数）。
2. 运行中周期性检查：每5分钟采集一次关键指标，并比对动态基线。若发现指标异常，则触发一次轻量级健康检查。
3. 故障后深度检查：当作业异常退出时，自动触发深度健康检查，包括NVLink链路测试与显存压力测试，以快速定位是否为硬件故障。

3.4 案例：一次“幽灵”GPU故障的快速定位

某训练任务在凌晨频繁中断，作业日志中仅显示“NCCL通信超时”，未出现明确的GPU错误。运维人员通过监控系统回溯数据，发现以下线索：

• 在故障发生前10分钟，节点gpu-worker-07上的NVLink CRC错误计数从0突增至每秒200次以上。
• 同时，该节点上GPU1的功耗出现周期性波动，且温度比同节点其他GPU高5℃。
• 系统日志中未发现内核报错，但BMC日志记录了一次“电源电压微降”事件。

基于这些监控数据，运维人员未盲目重启作业，而是立即对gpu-worker-07执行了动态健康检查，重点测试GPU1与GPU2之间的NVLink通信。测试结果确认链路存在大量重传。最终更换该节点GPU1与GPU2间的NVLink连接线缆后，故障消失。此案例表明，多维度的指标关联分析是穿透表面日志、定位物理层故障的关键。

3.5 常见误区与复盘要点