先给出分工判断
DCGM Health Watch 与 Diagnostics 不应被视为两套可互换的“健康检查”。前者面向运行期间的持续观察：围绕已配置的健康监控项采集状态并报告异常征兆；后者面向受控时段的主动诊断：发起测试以确认节点在当前条件下能否通过相应检查。生产集群的合理做法是把 Health Watch 放在日常监控链路，把 Diagnostics 放在节点准入、故障复核、维护后验收和计划性排障中。任何一项结果都只是运维决策的输入，不能单独替代业务验证。
持续观察解决什么问题
Health Watch 的价值在于时间连续性。节点已承载训练、推理或数据处理任务时，运维人员需要尽早看到可用性、错误、温度、互连或其他受监控维度的变化，并将事件接入告警、工单或调度策略。它更适合回答“运行中是否出现值得介入的信号”，而不是在某一时刻全面证明设备无误。监控项目、支持范围和输出含义应按现场安装版本核对 DCGM Feature Overview，不要把未启用的监控项或缺失的数据误读为健康结论。
主动诊断何时介入
Diagnostics 适合回答“在指定测试条件下，节点是否通过诊断”。典型触发点包括新节点入池、驱逐节点后的复测、硬件维护完成、反复出现健康事件，或需要在排障中缩小范围时。主动测试可能占用设备、改变负载状态或与现有作业相互影响，因此不应在业务高峰期直接对正在服务的节点执行。诊断级别、命令参数、测试限制及不同版本的差异，应以现场版本对应的 DCGM User Guide 为准；涉及硬件、驱动、运行环境和部署方式的限制，也必须在实际节点复核。
两类能力的决策对照
| 决策维度 | Health Watch | Diagnostics |
|---|---|---|
| 主要目的 | 持续发现运行期健康偏离 | 在受控条件下主动检查 |
| 典型时机 | 节点在线并承载常规工作负载时 | 准入、维护窗口、故障复核或下线后 |
| 结果使用 | 告警分级、趋势判断、触发处置 | 准入判定、排障证据、维修后验收 |
| 对业务影响 | 应按监控配置评估开销与告警噪声 | 需预留作业窗口并避免与生产作业竞争 |
| 不能证明的事项 | 不能替代受控诊断及业务验收 | 不能证明端到端模型、网络和存储路径正常 |
节点准入应采用分层门槛
新节点或返修节点不宜因一次诊断通过就立即投入关键队列。较稳妥的流程是：先确认驱动、DCGM 服务、设备可见性和基础配置符合站点基线；在排空状态执行适用的诊断；通过后加入观察池，由 Health Watch 持续记录；最后运行代表性业务验证，再进入正式资源池。代表性业务验证至少应覆盖目标框架或容器能否使用 GPU、调度器能否正确分配资源，以及任务实际依赖的网络和存储访问。这样可将设备层异常、运行时配置异常与业务集成异常分开处理。
作业窗口与隔离策略
当健康告警持续、诊断失败，或结果与业务现象矛盾时，应先阻止新的关键作业进入该节点，再根据调度系统能力执行 cordon、drain、标签降级或资源池迁移。对于已有任务，先评估检查是否会中断训练、损坏中间结果或影响服务，再安排维护窗口。隔离并非永久下线：它的作用是控制影响面，并为复测留出无竞争环境。需要记录触发信号、执行的诊断范围、软件版本、节点配置和复测结果，避免不同批次或不同条件的结果被直接比较。
最常见的误判边界
诊断通过不代表模型、网络和存储业务路径全部正常。一个节点可以在设备诊断中通过，却仍因容器镜像、CUDA 或框架组合、权限配置、调度插件、DNS、网络策略、挂载点、对象存储凭据或数据读取模式而无法完成真实作业。反过来，某个训练任务失败也不能直接归因于 GPU 硬件。遇到这类反例，应保留诊断结果，同时以最小可复现业务任务验证：提交指定镜像和框架版本，申请目标 GPU 资源，读取受控输入，完成小规模计算并写回结果。该验证应在不泄露生产数据的条件下执行。
可执行的闭环与回退路径
- 为节点定义基线和告警分级，将 Health Watch 事件接入值班流程。
- 将主动诊断安排到新机、返修、变更后或故障处置窗口，并确保节点已从受影响队列排空。
- 以诊断结果、持续监控状态和代表性业务验证共同决定准入、观察或隔离。
- 验证指标至少包括：监控项无持续异常、适用诊断通过、调度分配成功、目标网络可达、目标存储读写完成，以及最小任务正常结束。
- 若任一环节失败，保持节点隔离，撤销本次准入或配置变更，恢复至已知可用的版本与配置，再复测并记录差异。
回退时优先恢复调度隔离和已验证的运行基线，而不是通过关闭告警或跳过诊断来消除表面问题。对版本升级、硬件替换和监控项调整，应先在有限节点上验证告警质量与业务路径，再逐步扩大范围。
WeChat
Profile