DCGM Field Group 采样验收的核心判断是：字段能按预期出现、采样间隔能被链路稳定承接、标签不会失控、告警基线能解释业务风险，四项必须同测。只验证 exporter 或采集任务显示 up，并不能证明 GPU 监控可用于生产，因为字段缺失、字段语义误读、采样过密和高标签基数都可能让监控系统本身成为瓶颈。
先确认 DCGM 能力边界
DCGM 面向数据中心 GPU 管理，提供健康检查、诊断、策略、统计和字段查询等能力。实施前应先阅读 DCGM User Guide，确认目标主机、驱动、DCGM 版本、GPU 型号、容器运行方式和权限模型与现场一致。不要假设所有字段在所有硬件和版本上都可用；部分字段可能受架构、驱动、虚拟化或运行模式影响，验收表应允许标记“不支持”而不是简单判为故障。
Field Group 要按用途分层
Field Group 的价值在于把需要周期性读取的一组字段组织起来，减少临时拼接带来的混乱。建议按用途拆成基础健康、资源利用、显存、功耗温度、错误与限频原因等组，而不是一次性采全集。基础组用于长期保留和看板，风险组用于告警，诊断组用于短期开启。这样做的好处是字段缺失时能定位影响面，也便于对不同组设置不同采样间隔和保留策略。
采样间隔先从风险倒推
采样间隔不是越短越好。GPU 温度、功耗、利用率和显存占用的变化速度不同，告警需要的时间分辨率也不同。验收时应把 DCGM 读取间隔、exporter 暴露间隔、Prometheus 或其他系统抓取间隔、远端写入延迟放在一张时间链路中核对。若采样 1 秒、抓取 15 秒，很多瞬时字段只会以低频快照进入时序库；若全链路都高频，CPU、网络、存储和查询成本会快速上升。
抓取完整性要逐字段核验
完整性验收应以字段清单为准，而不是以指标总数为准。先列出每个 Field Group 的字段名、业务用途、期望标签、告警使用情况和可接受缺失条件；再在单机、单卡、多卡、空闲、满载和异常注入场景下比对实际输出。可用指标包括字段出现率、连续缺口时长、样本时间戳漂移、抓取失败率、单次抓取耗时和导出端错误日志。字段为 0、空值、缺失和不支持要分开记录，避免把真实空闲误判为采集异常。
标签设计要克制
GPU 监控常见标签包括主机、GPU UUID、设备序号、实例、作业、集群和租户。验收时要明确哪些标签来自稳定资产，哪些来自高频变化的调度上下文。作业 ID、容器 ID、进程 ID 若直接进入长期指标，容易造成高标签基数，进而放大写入、压缩、查询和告警计算压力。生产基线建议保留定位问题所必需的稳定标签，把短生命周期维度放入日志、事件或短保留指标中。
告警基线不要只看阈值
DCGM 的功能范围和字段能力可结合 DCGM Feature Overview 复核，但告警基线仍需按现场负载校准。温度、功耗、显存、ECC 或 XID 相关事件的告警应区分持续异常、瞬时尖峰和数据缺失。建议至少设置三类规则：采集链路不可用、关键字段持续缺失、GPU 状态或错误信号异常。这样即使业务指标沉默，也能知道是 GPU 正常、采集断裂，还是字段在当前环境不可用。
验收步骤可以这样落地
- 冻结版本和拓扑，记录驱动、DCGM、exporter、采集系统、GPU 型号和部署方式。
- 定义 Field Group 清单，标明每个字段的用途、采样间隔、标签和告警关系。
- 在空闲、稳定压力、短时峰值和重启场景下连续运行采集，覆盖至少一个完整调度周期。
- 对比字段出现率、抓取耗时、样本延迟、时序写入量、查询耗时和告警触发结果。
- 复核高频组和高标签组的资源占用，确认监控组件不会挤占业务节点关键资源。
失败边界必须写进结论
验收不通过的典型信号包括：关键字段在目标 GPU 上不可用却被用于强告警；抓取耗时接近或超过抓取间隔；单节点指标基数随作业数线性膨胀；查询一个常用看板就明显拖慢时序库；告警因缺失样本反复抖动。尤其要避免把所有字段、所有 GPU、所有进程、所有作业都以高频写入同一个长期存储。高频采样和高标签基数叠加时，监控系统可能先于业务系统达到瓶颈。
回退路径要可执行
如果验收发现开销过高，优先降低诊断类 Field Group 的频率，缩短高基数指标保留时间，移除不参与告警和排障的标签，并把进程级或作业级明细转到按需采集。若字段缺失来自版本或硬件限制，应调整告警表达式，使用可用字段替代，或将该能力标注为当前环境不适用。回退后需要重新跑完整性、开销和告警三项测试，确认问题不是被隐藏到下游查询或值班流程中。
WeChat
Profile