监控与告警：从指标采集到故障感知

GPU集群的故障自愈能力，前提是“看得见”。如果系统无法及时感知GPU利用率异常、显存耗尽、温度越限或网络抖动，后续的容灾切换与自愈动作就无从谈起。本章围绕监控指标、监控工具链与告警规则设计三个层面，建立一套面向故障自愈的监控体系。

4.1 核心监控指标：四类信号决定集群健康度

GPU集群的监控指标并非越多越好，而是需要围绕“计算资源、硬件健康、存储带宽、通信质量”四个维度收敛。下表列出了故障自愈场景下必须采集的关键指标及其典型阈值参考：

在自愈场景中，显存ECC错误计数与RDMA重传率往往比利用率更能提前暴露隐患。ECC错误从“可纠正”到“不可纠正”通常有数小时到数天的窗口期，是预测性自愈的重要输入。

4.2 监控工具链：Prometheus + Grafana 的落地架构

Prometheus负责指标采集与存储，Grafana负责可视化与告警展示，两者配合DCGM Exporter形成标准方案。核心采集链路如下：

GPU节点 (DCGM Exporter) --> Prometheus (TSDB) --> Alertmanager --> 自愈引擎/通知渠道
        |                                        |
        +-- 网络设备 (SNMP Exporter) ------------+
        +-- 节点层 (node_exporter) --------------+

部署时需注意：DCGM Exporter默认暴露端口为9400，Prometheus通过scrape_configs抓取指标。以下是一个最小可用的采集配置片段：

scrape_configs:
  - job_name: 'dcgm'
    static_configs:
      - targets: ['10.0.0.11:9400', '10.0.0.12:9400']
    metrics_path: '/metrics'
    scrape_interval: 15s
  - job_name: 'node'
    static_configs:
      - targets: ['10.0.0.11:9100', '10.0.0.12:9100']

Grafana侧建议直接导入DCGM官方Dashboard（ID：12239），并针对自愈场景增加三个自定义面板：“异常卡实时列表”（按温度/ECC错误排序）、“通信质量热力图”（按节点对展示RDMA重传率）、“自愈动作时间线”（叠加告警触发与恢复事件）。

4.3 告警规则设计：分级、聚合与抑制

告警规则设计的核心原则是“少而准”。告警数量过多会导致运维麻木，真正故障被淹没。建议采用三级告警体系：

• Critical（紧急）：触发自愈动作。例如GPU温度超过95℃、不可纠正ECC错误出现、RDMA链路中断。此类告警直接调用自愈引擎执行切换或隔离。
• Warning（警告）：需要人工关注。例如显存使用率超过90%、可纠正ECC错误速率上升、功耗异常波动。此类告警进入待观察队列。
• Info（信息）：记录趋势变化。例如利用率波动模式改变、风扇转速调整，用于容量规划与故障预测。

以下是一条典型的温度告警规则（PromQL），注意使用for参数避免瞬时抖动误报：

groups:
  - name: gpu_thermal
    rules:
      - alert: GPUTemperatureCritical
        expr: DCGM_FI_DEV_GPU_TEMP > 95
        for: 2m
        labels:
          severity: critical
          component: gpu
        annotations:
          summary: "GPU {{ $labels.gpu }} 温度超限"
          description: "当前温度 {{ $value }}℃，持续超过2分钟"

告警聚合方面，建议按“节点维度”聚合而非单卡维度。例如一个8卡节点中3张卡同时温度告警，应合并为一条“节点GPU热事件”而非三条独立告警。Prometheus的group_by机制配合Alertmanager的路由树可实现该效果。

4.4 案例：一次显存泄漏引发的自愈联动

某训练集群在持续运行72小时后，出现以下监控序列：

1. 第60小时：Grafana面板显示节点A的GPU 2显存使用率从78%缓慢爬升至85%，ECC可纠正错误计数从0增至12次/小时。
2. 第66小时：显存使用率突破90%阈值，触发Warning告警。自愈引擎评估后判定为“疑似显存泄漏”，但未达到自动隔离条件。
3. 第70小时：GPU 2显存使用率达到97%，同时NCCL通信重传率上升至0.5%。此时触发Critical告警，自愈引擎执行“任务迁移+GPU隔离”动作。
4. 第71小时：训练任务迁移至节点B的空闲GPU，节点A的GPU 2被标记为“待检修”状态，不再接受新任务。

该案例的关键在于：显存使用率趋势斜率比绝对值更有价值。如果仅设置“显存使用率>95%”的静态阈值，在第70小时才感知问题；而通过监控delta(DCGM_FI_DEV_FB_USED[1h])的增长率，可以在第66小时就预判风险。

4.5 常见误区与复盘

误区二：忽略监控系统自身的高可用。Prometheus单点部署时，如果监控节点宕机，整个自愈体系将“失明”。生产环境至少应部署双Prometheus实例，或采用Thanos方案实现长期存储与高可用。

误区三：告警与自愈动作耦合过紧。并非所有Critical告警都应立即触发自愈。例如“温度超过95℃”可能是瞬时负载尖峰导致，直接切换任务反而造成更大扰动。建议在自愈引擎中设置“确认窗口”（如5分钟），窗口内持续满足条件才执行动作。

误区四：只监控GPU不监控网络。在NVLink与RoCE混合组网中，网络抖动对训练效率的影响往往大于GPU本身故障。建议将RDMA重传率、拥塞窗口变化纳入核心监控指标，并设置独立告警通道。

监控体系的建设不是一次性工作，而是随着集群规模与业务模式持续迭代的过程。建议每两周复盘一次告警命中率与误报率，将无效规则下线，将漏报场景补充为新的规则。只有监控指标准确、告警规则收敛、自愈动作可靠，GPU集群才能在故障频发的真实环境中保持稳定运行。