AI 基础架构跨越多个层，从计算和网络到存储、编排和应用。当性能下降时，识别来源可能很困难，因为在某一层观察到的症状可能源于堆栈中的其他地方。
全栈可观察性策略将这些层中的遥测连接起来，帮助基础设施和运营团队检测问题、找出问题原因并维护可靠的 AI 工作负载。本文将介绍适用于 NVIDIA AI 基础架构的实用可观测性框架，以及如何将其应用于常见的监控和故障排除场景。
假设分布式训练作业的执行时间为三天。GPU 利用率和队列等待时间保持正常。在吞吐量降低 6 小时后，团队发现单个 InfiniBand 链路漂移到更高的误码率的原因。
这是典型的灰色故障。硬件降级，但系统不会将其报告为“停机”。AI 训练遵循批量同步并行 (BSP) 模型。这些紧密合的系统很容易受到掉队者的影响：一个慢秩会阻碍作业。在同步集合通信库 (NCCL) all-reduce 等运算期间，链路级重传输会停止单个秩。然后，吞吐量下降到最慢的秩，另一个秩会阻塞。这是一种级联式失败。
在 AI 工厂中经常会出现这种故障模式。所需的遥测通常已经存在；挑战在于尽早从正确的工具中选择正确的信号，以便采取行动。操作员不需要每个产品的所有指标。他们需要一个决策路径，将组件映射到工具，将工具映射到简洁的警报集，并将该警报集整合到单个分类控制面板中。
这篇文章展示了这一路径。您将学习如何：
- 在选择软件之前，列举必须可观察到的故障域。
- 使用源自 NVIDIA DGX 部署的决策框架，将 AI 基础设施组件映射到遥测工具源。
- 将可观察性框架应用于 InfiniBand 集群。
- 将遥测简化为 top-k 警报集，并在单个分类仪表板中关联信号。
在产品文档中保留详细的目录、协议矩阵和每个工具的支持指南。在这里，您将专注于如何选择可观测性堆栈。NVIDIA DGX 和 NVIDIA HGX 部署共享相同的可观测性表面，即使硬件配置不同 (图 1) ：
识别 AI 工厂故障域
在选择监控软件之前，请列举静默故障会占用 GPU 小时数的领域：
- 平台运行状况：风扇、PSU、BMC、机箱、CPU、内存、本地存储。
- GPU 运行状况和性能：利用率、温度、功耗、XID/ECC 和 NVIDIA NVLink 吞吐量。
- 结构：InfiniBand 或以太网链路完整性、拥塞和交换机/ 线缆运行状况；机架级 NVLink (如有) 。
- 集群和作业：调度、保留、空闲分配的 GPU、队列等待。
- 推理服务：NVIDIA NIM 微服务或类似服务在生产中时的延迟、成功率和缓存行为。
在复杂的系统中，很少能一次性消除覆盖差距。当潜在故障模式在负载下显示时，它们会稍后出现。及早分析这些模式可以缩短发现时间。这种分析有助于防止在负载下再次出现故障。
将 AI 基础设施组件映射到遥测工具
运营团队需要从组件到遥测源的清晰映射。表 1 将 NVIDIA Data Center GPU Manager (DCGM) 、NVIDIA 系统管理 (NVSM) 、NVIDIA Unified Fabric Manager (UFM) 、NVIDIA NetQ、NVIDIA NMX、NVIDIA Base Command Manager (BCM) 和 NVIDIA Run：ai 映射到这些组件。绿色表示完全支持域；黄色表示部分或间接覆盖。使用该框架选择可消除覆盖率差距的最小工具集。
| 组件 | Redfish/ IPMI | DCGM | NVSM | UFM | NetQ | NMX | BCM | Run:ai | NIM |
|---|---|---|---|---|---|---|---|---|---|
| 基础基础架构 | * | * | * | * | * | * | * | * | * |
| 计算节点 | * | * | * | * | * | * | * | * | * |
| GPU | * | * | * | * | * | * | * | * | * |
| 节点互连 | * | * | * | * | * | * | * | * | * |
| 机架级 NVLink | * | * | * | * | * | * | * | * | * |
| 以太网 | * | * | * | * | * | * | * | * | * |
| InfiniBand 网络 | * | * | * | * | * | * | * | * | * |
| 集群管理 | * | * | * | * | * | * | * | * | * |
| 作业和工作负载 | * | * | * | * | * | * | * | * | * |
| AI 推理 | * | * | * | * | * | * | * | * | * |
关键权衡包括：
- 用于 GPU 的 DCGM 与 NVSM 相比：首选 DCGM 用于利用率、功耗、温度、NVLink，以及将 XID/ ECC 导出到 Prometheus。在 DGX 级节点上保留 NVSM 以确保系统运行状况 (驱动、功耗、整体运行状况) 。这些工具在 GPU 指标上重叠；都不能替代平台 BMC 数据。
- UFM 与 NetQ 的比较：按网络类型选择。InfiniBand 使用 UFM。Spectrum 以太网/ RoCE 使用 NetQ。仅当两种结构都存在时部署这两种结构。
- NMX：用于机架级 NVLink。在 DCGM 已涵盖节点互连的经典多节点 NVLink 拓扑上省略。
- BCM：将 BCM 视为聚合器和集群/ 工作平面，而非低级计数器的来源。专用工具仍然负责深度遥测。
- Run：ai 和 NIM：引入工作负载调度公平性或推理 SLO 是首要操作要求的情况。两者都不能取代 DCGM 或网络监控。
一条有用的法则：用最少的工具覆盖每个必需的绿色单元。在没有清晰分类路径的情况下，额外导出会增加噪声，而非可观察性。这种噪音会导致警觉性疲劳。
团队不断添加指标和控制面板，但仍然无法回答损坏的原因。结果是“西瓜指标”：仪表板外部显示绿色，而服务内部出现故障。纠正原则是“尽可能简单，不简单”中所述的原则：保持简单的监控，并删除未使用的信号，而不是将它们累加起来。
将可观察性框架应用于 InfiniBand 集群
考虑使用配备 InfiniBand、BCM 和 Slurm 的 DGX 集群。大多数工作都是训练；推理尚未进入生产阶段。操作要求是一个分诊仪表板和警报，在长达数小时的作业浪费累积之前检测网络和 GPU 运行状况的恶化。
决策过程如下：
- 范围域：平台、GPU、InfiniBand 结构、集群/ 作业。超出初始部署范围：NetQ、NMX、Run:ai、NIM。
- 从框架中选择工具
- 每个节点上的 Redfish/ IPMI，用于风扇、PSU、机箱和 BMC 状态。
- 每个 GPU 节点上的 DCGM，用于利用率、功耗、温度、XID/ ECC 和 NVLink。
- DGX 节点上的 NVSM，用于系统运行状况聚合。
- 用于 InfiniBand 端口运行状况、BER、拥塞和路由的 UFM。
- BCM 作为作业、预订和整合硬件警报的集群聚合器。
- 理论依据：仅 DCGM 就无法实现前言中描述的 BER 回归。这是一个大规模的问题。当跨多个秩同步工作时，端到端吞吐量遵循的是最慢的秩，而非平均组件运行状况。单是 UFM 就会错过 GPU XID 风暴和节点电源故障。仅凭 BCM 无法生成低级计数器。它们共同涵盖了在此环境中浪费 GPU 时间的领域。
- 排除项：在引入以太网、机架级 NVLink 或推理服务之前，跳过 NetQ、NMX 和推理指标。
这为您提供了 IPMI、DCGM、NVSM、UFM 和 BCM 的初始堆栈，并在 Prometheus/ Grafana 中进行了统一。
构建可行的 AI 基础设施警报集
大多数工具都会显示数百个指标。首选与服务水平指标 (SLI) 和服务水平目标 (SLO) 相关联的简短 top-k 集，而不是每个硬件计数器的转储文件。每个警报都应映射到明确的补救措施。UFM Telemetry 可公开数百个字段；从记录的高频遥测字段开始。
要将可观测性框架应用于 InfiniBand 集群，请从以下开始：
- 平台：风扇转速、PSU 状态、关键温度 (
SPD_FAN_*、PWR_*、TEMP_*(通过 Redfish/ IPMI 实现) 。 - 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 馈送相同的 Scrape 模型。这样可以简化初始部署的协议选择，并避免在需要 gNMI 或 SNMP 集成之前引入第二个控制平面。
构建统一的 AI 基础架构分类仪表板
选择工具和 top-k 指标后，构建统一的 AI 基础架构分类仪表板 (图 2) ：
实用架构如下所示：
- 在每个 GPU 节点上安装 IPMI 和 DCGM 导出工具。
- 在触手可及的位置运行 UFM Telemetry；抓取或导出到 Prometheus。
- 保留 BCM 作为集群管理和聚合平面。
- 指向 Prometheus 的 Grafana，获取跨 GPU、节点和网络信号的仪表板和警报。
- 如果 BCM 中尚未提供工作级别的上下文，请添加社区 Slurm 控制面板。
使用两层监控方法。第 1 层为分诊提供高级视图；第 2 层保留检查单个组件所需的细节。第 1 层是首先使用的 Grafana 控制面板：是 GPU、节点或结构中的故障？一旦已知故障域，第 2 层将深入探讨供应商 UI ( UFM Web UI、BCM Base View 和类似工具) 。当第 1 层从一个板上回答分诊问题时，第 2 天的运算速度会更快。第 2 层仍可用于根本原因分析。
定义可观察性接受标准
您已准备好继续：
- 范围内的每个故障域都至少有一个来自框架的全面支持工具。
- 警报与包含所有者和操作的简短 top-k 指标列表绑定。
- GPU、节点和网络信号在一个视图中共享通用的时间轴。
- 其他工具 (以太网、机架级 NVLink、Run:ai、NIM) 仅在需要时才会添加，而非默认添加。
不要通过仪表板的数量来衡量可观察性成熟度。通过信号是否显示故障组件以及在浪费大量计算能力之前的下一个操作来衡量。
扩展 NVIDIA AI 基础架构可观察性堆栈
在初始部署满足 define observability acception 标准后，按以下顺序扩展覆盖范围：
- 使用 DCGM 用户指南 和 GPU 遥测 启用 GPU 遥测。
- 在《NVSM 用户指南》中验证 DGX 系统运行状况路径。
- 使用 UFM Telemetry 或 NetQ 配置网络可视化，具体取决于网络结构。
- 对于集群聚合和操作，请从 Base Command Manager 和 NVIDIA Mission Control (如适用) 开始。
- 对于推理服务，请添加 NVIDIA NIM Operator 可观察性。
使用决策框架来证明每项添加内容的合理性。在运行手册或产品文档中保留详细的指标字典和协议矩阵。将生产警报设置得足够短，以便随时使用。
决策框架优于指标目录。它能让您找到几个精心选择的信号和一个分流板，而不是 50 个无人读取的仪表板。
3 步部署检查清单：
- 建立覆盖范围：为每个范围内的域选择一个全面支持工具 (请参阅表 1) 。
- 集成导出工具：Wire Redfish/ IPMI、DCGM、NVSM、UFM 和 BCM 到 Prometheus，并将 Grafana 指向统一的遥测端点。
- 强制执行所有权：在添加下一个导出工具之前，将每个警报与所有者和剧本操作绑定。
不要通过仪表板的数量来衡量可观察性成熟度。在浪费大量计算能力之前，通过信号是否指明故障组件和下一个行动来衡量它。
