nvidia-smi不适合承担长期监控
人工执行`nvidia-smi`只能看到瞬时状态，无法回答某次服务变慢前GPU是否降频、显存何时增长、Xid发生在哪个Pod。DCGM Exporter基于DCGM采集数据，并在默认9400端口以Prometheus格式提供`/metrics`。
部署前的兼容性检查
确认GPU、驱动和DCGM在产品支持矩阵内；容器部署还需要NVIDIA Container Toolkit。若DGX等系统已经运行独立`nv-hostengine`，应决定连接现有host engine还是让Exporter使用内嵌实例，避免重复管理。
每个需要监控的GPU节点运行一个Exporter。部署完成先在节点本地验证：
curl --fail http://127.0.0.1:9400/metrics | head -n 30
curl -s http://127.0.0.1:9400/metrics | grep '^DCGM_' | head选择某个指标并不保证硬件一定输出它；GPU型号、驱动、权限和DCGM版本都会影响可用字段。
第一组：容量和负载
最基本的是GPU利用率、显存已用/可用、SM与显存时钟。利用率高不等于服务健康：可能是有效计算，也可能是重试、异常内核或压测。显存长期接近上限也不必立即报警，应结合OOM、请求失败和增长趋势。
第二组：温度、功耗和降频
默认指标包含GPU温度、显存温度、板卡功率和累计能耗等。告警不应简单照搬统一温度，因为不同型号的阈值、风冷/液冷条件和机房进风不同。更有价值的是持续超过该型号基线，并同时出现时钟下降或thermal/power violation。
第三组：错误与链路
Xid、ECC、PCIe吞吐和NVLink状态能够解释任务崩溃或多卡速度下降。新版Exporter提供`DCGM_EXP_XID_ERRORS_*`、健康状态和P2P状态等可选指标，但部分默认配置中是注释项，需要在自定义CSV或YAML中启用并确认字段语义。
自定义collector的每行由字段名、Prometheus类型和帮助文字组成。counter只适合单调累计值；错误地把可下降字段声明为counter会导致错误速率。
Prometheus采集验证
在Prometheus Targets中确认每个GPU节点为UP，并检查标签能关联实例、GPU UUID和业务节点。Kubernetes环境应挂载kubelet pod-resources接口，让指标关联Pod；容器运行时socket权限很高，只在确需映射且有安全隔离时挂载。
创建Grafana面板前先直接查询原始指标，确认单位。例如功率可能是瓦，能耗可能是累计值；温度是摄氏度。不要仅凭指标名字猜测，官方字段定义才是单位和含义的来源。
告警设计示例
- Exporter或Prometheus target持续不可达：监控盲区告警。
- GPU温度持续高于设备基线且时钟下降：散热或风道告警。
- Xid或不可纠正ECC增加：立即关联节点和任务，按错误类型决定隔离。
- 在线服务有队列但GPU长期低利用：数据、调度、CPU或网络瓶颈。
- 显存持续增长且请求量稳定：缓存或进程泄漏调查。
所有阈值加入持续时间，避免启动和模型加载造成瞬时噪声。
必须做一次故障演练
运行可控GPU负载，确认利用率、功耗和温度曲线变化；停止Exporter，确认采集失败告警；重启Exporter，确认target恢复。注意Exporter进程内维护的自有counter可能因重启重置，PromQL需要正确处理counter reset。
最后把告警链接到处置手册：包含节点下线、保存日志、检查Xid、迁移推理流量和训练检查点恢复。只有监控能够触发具体动作，它才不是展示用仪表盘。
