nvidia-smi 是定位 GPU 状态的常用入口，但它更像一次查询视图，而不是完整的监控系统。运维人员在告警后登录节点，看到利用率已经恢复为零，并不能说明告警是误报；一个几十秒的任务可能在两次采样之间完成，进程号也可能被系统复用。要回答“哪项业务在什么时间占用了哪张 GPU、是否触发显存或功耗边界、异常后由谁接管”，必须把设备、进程、容器、作业和时间线连接起来。
先定义指标的采样语义
GPU 利用率通常描述采样窗口内设备忙碌的比例，不等同于业务完成度；显存占用反映已分配或在用空间，也不能单独证明计算有效。功耗、温度、时钟和限制原因需要同一时间窗口解释。监控系统应记录采样周期、聚合方式、缺失值处理和时钟来源。若一分钟只保存平均值，十秒的满载尖峰可能被稀释；若只保存最大值，又无法判断持续时间。关键指标至少应保留原始或较细粒度样本一段时间，再生成较长周期汇总。
设备身份不能依赖显示序号
GPU 0、GPU 1 是当前进程看到的枚举，不一定与机箱插槽、宿主机全局序号或容器内部序号一致。重启、设备屏蔽和调度环境都可能改变编号。资产与监控应使用稳定的设备 UUID，并保留 PCI 地址、主机名和物理位置映射。MIG 环境还需要区分物理 GPU、GPU Instance 与 Compute Instance，不能把多个实例的指标简单写回同一张卡。更换硬件时应关闭旧身份、创建新映射，而不是让新设备继承历史故障曲线。
从 PID 追到业务需要多层映射
宿主机看到的 PID、容器命名空间内 PID、Kubernetes Pod、批处理作业号和最终业务租户往往不是同一个标识。采集代理应在进程仍存活时保存命名空间、cgroup、容器和调度标签，因为任务结束后这些上下文可能无法恢复。映射还要遵守权限边界：监控平台可以保存用于运维的技术标识，不应无条件采集命令行中的密钥、用户输入或业务数据。展示层应按角色限制跨租户查询，并记录谁导出了明细。
短任务与异常退出如何留痕
固定周期轮询容易漏掉短任务，可结合调度器事件、容器生命周期和应用侧埋点补足。异常退出时，单靠最后一个利用率样本通常无法判断原因，应同时保留 Xid、ECC、设备状态、驱动日志、作业退出码和节点事件。若任务被调度器强制终止，还要区分资源超限、健康检查、用户取消和节点维护。将所有异常统一标记为“GPU 故障”，会让硬件统计失真，也会掩盖平台策略问题。
监控基线应服务于行动
- 为设备、实例、进程、容器和作业设计稳定且可追溯的标识关系。
- 按指标变化速度选择采样周期，保留峰值、分位数、持续时间和缺失状态。
- 将温度、功耗、时钟、限制原因、显存与业务吞吐放在同一时间轴。
- 通过任务启动、完成、取消和异常演练，确认短生命周期记录不会丢失。
- 为容量、故障和计费分别定义报表，避免一个聚合口径承担所有用途。
命令行快照仍适合现场快速核查，但生产可观测性更需要稳定 API、明确采样和上下文治理。NVML 提供设备管理与监控接口，其字段、返回状态和线程行为应按所用版本核对，官方入口见 NVIDIA Management Library API Reference。如果采用 DCGM 或第三方采集器，也应确认其最终指标语义与 NVML、调度器和业务日志一致。
WeChat
Profile