AI 基础设施横跨多个层次，从计算、网络到存储、编排和应用层。当性能出现下降时，由于某一层的症状可能源自栈中的其他位置，定位根因往往并不容易。
全栈可观测性策略将各层遥测数据贯通连接，帮助基础设施与运维团队及时发现问题、隔离根因，并保障 AI 工作负载的稳定运行。本文为英伟达 AI 基础设施提供了一套实用的可观测性框架，并结合常见监控与故障排查场景展示了具体应用方法。
以一个已运行三天的分布式训练任务为例。GPU 利用率和队列等待时间均显示正常。然而在经历六小时的吞吐量下降后，团队最终将根因追溯到一条 InfiniBand 链路出现了持续升高的误码率（BER）。
这是一种典型的"灰色故障"——硬件已经劣化，但系统并不将其标记为"宕机"。AI 训练遵循批量同步并行（BSP）模型，这类紧耦合系统对"慢节点"（straggler）极为敏感：一个慢速 rank 就会拖慢整个任务。在 NCCL all-reduce 等同步集体通信操作中，链路层重传会导致单个 rank 停滞，吞吐量随即降至最慢 rank 的速度，其余 rank 全部阻塞，引发级联故障。
这种故障模式在 AI 工厂中十分常见。所需的遥测数据通常已经存在，难点在于如何在早期从正确的工具中选取正确的信号并及时响应。运维人员不需要从每个产品中获取所有指标，而需要一条清晰的决策路径——将组件映射到工具，将工具映射到简洁的告警集，再将告警集汇入统一的分诊看板。
本文正是为此而来，你将学到如何：
在选型软件之前，梳理必须可观测的故障域；
通过源自英伟达 DGX 部署的决策框架，将 AI 基础设施组件映射到遥测工具；
将可观测性框架应用于 InfiniBand 集群；
将遥测数据缩减为 Top-K 告警集，并在统一的分诊看板中关联信号。
详细的指标目录、协议矩阵和各工具的启用指南请参阅产品文档。本文聚焦于如何选择可观测性技术栈。英伟达 DGX 与英伟达 HGX 部署共享相同的可观测性边界，即使硬件配置存在差异。
第一步：识别故障域
在选择监控软件之前，先梳理那些在无声中消耗 GPU 算时的故障域：
平台健康：风扇、电源、BMC、机箱、CPU、内存、本地存储；
GPU 健康与性能：利用率、温度、功耗、XID/ECC 错误、英伟达 NVLink 吞吐量；
网络互联：InfiniBand 或以太网链路完整性、拥塞、交换机与线缆健康状况，以及机架级 NVLink（如适用）；
集群与作业：调度、资源预留、已分配但空闲的 GPU、队列等待时间；
推理服务：当英伟达 NIM 微服务或类似服务投入生产时，需关注延迟、成功率和缓存行为。
在复杂系统中，覆盖空白往往难以一次性补齐，通常在负载压力下出现潜在故障模式时才会暴露。提前分析这些模式，有助于缩短发现周期，防止同类故障在压力下反复出现。
第二步：将组件映射到工具
运维团队需要从组件到遥测来源的清晰映射。相关框架将英伟达数据中心 GPU 管理器（DCGM）、英伟达系统管理工具（NVSM）、英伟达统一网络管理器（UFM）、英伟达 NetQ、英伟达 NMX、英伟达基础命令管理器（BCM）和英伟达 Run:ai 与各组件进行了对应。绿色表示对该域的完整支持，黄色表示部分或间接覆盖。使用该框架选择能够消除覆盖空白的最小工具集。
主要权衡点如下：
DCGM 与 NVSM 的 GPU 覆盖对比：优先使用 DCGM 导出利用率、功耗、温度、NVLink 和 XID/ECC 数据至 Prometheus；在 DGX 级节点上保留 NVSM 用于系统健康监控（磁盘、电源、整体健康）。两者在 GPU 指标上有所重叠，但均无法替代平台 BMC 数据；
UFM 与 NetQ 的网络覆盖对比：按网络类型选择，InfiniBand 用 UFM，Spectrum 以太网/RoCE 用 NetQ，仅在两种网络并存时才同时部署；
NMX：仅在机架级 NVLink 场景下需要，在 DCGM 已覆盖节点互联的经典多节点 NVLink 拓扑中可省略；
BCM：应作为聚合层和集群/作业管理平面，而非底层计数器的采集来源，深层遥测仍由专项工具负责；
Run:ai 与 NIM：仅在工作负载调度公平性或推理 SLO 成为一类运维需求时才引入，两者均无法替代 DCGM 或网络监控。
一条实用原则：用尽可能少的工具覆盖所有必须的绿色单元格。没有明确分诊路径的额外导出器只会带来噪声，而非可观测性的提升，最终导致告警疲劳。
团队不断累加指标和看板，却仍然无法回答"什么坏了、为什么坏了"。结果就是"西瓜式指标"：看板外表一片绿色，服务内部已经在报错。正确的做法是：保持监控简单，剔除无用信号，而非持续堆砌。
第三步：应用框架——以 InfiniBand 集群为例
以一个配备 InfiniBand、BCM 和 Slurm 的 DGX 集群为例，绝大多数任务是训练作业，推理尚未投入生产。运维目标是建立单一分诊看板和告警体系，在多小时作业损耗积累之前检测出网络和 GPU 健康回归。
决策过程如下：
纳入范围的域：平台、GPU、InfiniBand 网络、集群/作业；初期部署暂不纳入：NetQ、NMX、Run:ai、NIM。
按框架选择工具：
每个节点部署 Redfish/IPMI，监控风扇、电源、机箱和 BMC 状态；
每个 GPU 节点部署 DCGM，监控利用率、功耗、温度、XID/ECC 和 NVLink；
DGX 节点部署 NVSM，用于系统健康聚合；
部署 UFM，监控 InfiniBand 端口健康、BER、拥塞和路由；
使用 BCM 作为集群聚合层，管理作业、资源预留和硬件告警汇总。
选型依据：仅靠 DCGM 无法发现文章开头描述的 BER 回归问题，这是规模尾效应问题——当大量 rank 同步时，端到端吞吐取决于最慢的 rank，而非平均组件健康状况；仅靠 UFM 无法发现 GPU XID 风暴和节点电源故障；仅靠 BCM 则无法生成底层计数器。三者组合，才能覆盖该环境下导致 GPU 算时损耗的关键故障域。
排除项：在以太网、机架级 NVLink 或推理服务引入之前，跳过 NetQ、NMX 和推理指标。
由此得到初始技术栈：IPMI、DCGM、NVSM、UFM 和 BCM，统一接入 Prometheus/Grafana。
第四步：缩减为 Top-K 告警集
大多数工具会暴露数百个指标。优先选择与服务级别指标（SLI）和服务级别目标（SLO）挂钩的精简 Top-K 集合，而非将所有硬件计数器全量导出。每条告警都应对应明确的修复动作。UFM 遥测提供了数百个字段，建议从官方文档中的高频遥测字段开始。
针对 InfiniBand 集群，建议从以下指标入手：
平台：风扇转速、电源状态、关键温度（通过 Redfish/IPMI 采集 SPD_FAN_*、PWR_*、TEMP_*）；
GPU：DCGM_FI_DEV_GPU_UTIL、DCGM_FI_DEV_MEM_COPY_UTIL、DCGM_FI_DEV_POWER_USAGE、DCGM_FI_DEV_XID_ERRORS，以及 NVSM GPU/系统健康状态；
InfiniBand：PortXmitDataExtended、SymbolErrorCounterExtended、Effective_BER、Total_Raw_BER、Chip_Temp；
作业：BCM/Slurm 的运行作业、GPU 预留和等待时间，用于将网络或 GPU 告警与工作负载影响关联。
仅在某次事故证明存在覆盖缺口时才扩展指标集。告警应基于能够映射到具体动作的症状（如节点下线、更换线缆、提交网络工单），而非采集器能够输出的每一个计数器。
在有 Prometheus 导出器的场景下优先使用：DCGM 和 NVSM 均提供 Prometheus 端点；UFM 和 BCM 也可通过导出器或 API 接入同一采集模型。这在初期部署阶段保持了协议选型的简洁性，避免在 gNMI 或 SNMP 集成需求明确之前引入第二个控制平面。
第五步：构建统一分诊看板
工具和 Top-K 指标确定后，构建统一的 AI 基础设施分诊看板，推荐如下架构：
在每个 GPU 节点安装 IPMI 和 DCGM 导出器；
在网络可达的位置运行 UFM 遥测，并导出至 Prometheus；
保留 BCM 作为集群管理和聚合平面；
将 Grafana 指向 Prometheus，构建覆盖 GPU、节点和网络信号的看板与告警；
如果 BCM 中作业级上下文尚不完整，可接入社区版 Slurm 看板。
采用两层监控架构：第一层提供用于快速分诊的高层级视图，第二层保留深入排查所需的细节。第一层是首先打开的 Grafana 看板，用于判断故障在 GPU、节点还是网络；第二层是厂商 UI 深入分析（UFM Web UI、BCM Base View 等），在确认故障域后使用。当第一层能从单一看板回答分诊问题时，日常运维效率将大幅提升；第二层则始终可用于根因分析。
可观测性验收标准
满足以下条件后，即可视为阶段目标达成：
纳入范围的每个故障域都有至少一个完整支持的工具覆盖；
每条告警都绑定了精简的 Top-K 指标列表，并明确责任人和处置动作；
GPU、节点和网络信号在同一视图中共享统一时间轴；
其他工具（以太网、机架级 NVLink、Run:ai、NIM）仅在实际需要时引入，而非默认全量部署。
不要用看板数量衡量可观测性的成熟度，而应以信号能否在大量算力损耗发生之前准确指向故障组件和下一步动作为标准。
扩展路径建议
初始部署满足验收标准后，按以下顺序扩展覆盖：
参考 DCGM 用户指南和 GPU 遥测文档，启用 GPU 遥测；
参考 NVSM 用户指南，验证 DGX 系统健康路径；
根据网络类型，通过 UFM 遥测或 NetQ 配置网络可见性；
集群聚合与运维从 BCM 入手，条件适用时结合英伟达 Mission Control；
推理服务方面，接入英伟达 NIM Operator 可观测性能力。
每次新增工具都应通过决策框架加以论证。详细的指标字典和协议矩阵保留在运维手册或产品文档中，生产告警集应精简到足以支撑值班响应的规模。
决策框架胜过指标目录。它能让你聚焦于少数经过精选的信号和一张分诊看板，而不是五十张没人看的仪表盘。
三步上线检查清单：
建立覆盖：为每个纳入范围的故障域选择一个完整支持的工具（参见组件-工具映射表）；
接入导出器：将 Redfish/IPMI、DCGM、NVSM、UFM 和 BCM 接入 Prometheus，并将 Grafana 指向统一遥测端点；
落实责任：在新增任何导出器之前，为每条告警绑定责任人和处置手册动作。
衡量可观测性成熟度的标准，不是看板数量，而是信号能否在大量算力损耗发生之前，准确指出故障组件和下一步行动。
Q&A
Q1：什么是"灰色故障"，为什么它对 AI 训练影响特别大？
A：灰色故障指硬件已经劣化但系统不将其标记为"宕机"的状态，例如 InfiniBand 链路出现持续升高的误码率。AI 训练采用批量同步并行（BSP）模型，所有 rank 必须在集体通信操作（如 NCCL all-reduce）中同步，一个慢速 rank 就会导致其余所有 rank 阻塞，最终吞吐量降至最慢节点的速度，引发级联故障。因此灰色故障虽然"不报错"，却会在数小时内悄悄消耗大量 GPU 算时。
Q2：DCGM 和 UFM 分别监控什么，能互相替代吗？
A：两者监控范围不同，不能互相替代。DCGM 负责 GPU 层面的指标，包括利用率、功耗、温度、XID/ECC 错误和 NVLink 吞吐量；UFM 负责 InfiniBand 网络层面，包括端口健康、误码率、拥塞和路由状态。若只部署 DCGM，会遗漏链路层误码率导致的吞吐下降；若只部署 UFM，会遗漏 GPU XID 风暴和节点电源故障。两者结合才能覆盖 AI 工厂中主要的 GPU 算时损耗场景。
Q3：如何避免告警过多导致的"告警疲劳"？
A：核心方法是只保留与服务级别指标（SLI）和服务级别目标（SLO）直接挂钩的 Top-K 告警，每条告警必须对应明确的处置动作（如节点下线、更换线缆），而非对每个硬件计数器都设置告警。同时，没有明确分诊路径的额外导出器应该去除而非保留，未使用的信号要主动清理。只有当某次实际事故证明存在覆盖缺口时，才扩展指标集。
