背景概述在基于昇腾 NPU 的集群运维中，npu_exporter 是核心的监测组件之一。它负责采集 NPU 设备的健康状态、功耗、温度、算力利用率等关键指标，并以 Prometheus 标准格式暴露给监测系统（如 Prometheus + Grafana）。在实际运行过程中，会出现 npu_exporter 采集到的 NPU 卡数指标短暂归零或异常的情况。问题现象在监测平台中，观察到 npu_exporter 获取的服务器 NPU 卡数指标出现短暂异常。具体表现为：监测数据显示服务器 NPU 卡数为 0，但在一分钟后指标自动恢复正常。原因分析为了定位该问题，我们从硬件状态、软件日志及接口调用机制三个维度进行了深入排查。 1. 硬件与基础日志排查首先，排查了 BMC（基板管理控制器）日志及带内系统日志。结果显示： ●BMC 日志中未发生任何硬件告警。 ●带内日志显示 NPU 卡数正常，设备状态均为 OK。 ●故障时间点未见明显的硬件异常记录。 2. npu_exporter 缓存机制分析 npu_exporter 通过调用 dcmi 接口获取 NPU 列表，并维护一个本地缓存队列。其工作流程如下：通过查看 npu_exporter 日志（路径：/var/log/mindx-dl/npu-exporter），执行命令 grep -irn 'update Cache,key is npu-exporter-npu-list'，发现以下关键时序： 1.正常更新：在 17:14:54，npu_exporter正常调用接口更新缓存。 2.预期更新：按照每分钟一次的频率，预期在 17:15:54 进行下一次更新。 3.实际延迟：实际更新发生在 17:16:01，相比预期推迟了约 7 秒。 4.缓存失效：npu_exporter的缓存队列有效期为 65 秒。由于更新延迟，导致在 17:16:00 左右，监测平台请求指标时，缓存队列已因超时被清空，从而返回空数据（NPU 卡数为 0）。 5.自动恢复：当监测平台在 17:17:00 再次请求时，缓存已在 17:16:55 完成更新，因此指标恢复正常。 3. 接口调用延迟根因进一步分析发现，dcmi 接口返回慢是导致缓存更新延迟的直接原因。日志分析显示，dcmi 接口调用延迟往往伴随着业务进程的退出或重启。在 Atlas 900 A3 SuperPod 架构中，每个 Device 仅有一个 Control CPU。当业务进程退出时，Control CPU 负载瞬间升高。由于 dcmi 接口与业务进程共享该 Control CPU 资源，两者发生资源抢占，导致 dcmi 接口响应时间变长，进而影响了 npu_exporter 的缓存更新及时性。解决方案 1. 短期应对该现象属于软件层面的资源竞争导致的监测数据短暂缺失，并非硬件故障。在业务运行期间，若出现此类短暂指标异常，通常无需人工干预，系统会在下一个采集周期自动恢复。 2. 长期优化方案为了提升监测数据的稳定性和鲁棒性，建议升级 npu_exporter 组件至 7.3.0 或更高版本。在该版本中，开源社区对 npu-list 缓存队列的机制进行了优化： ●缓存有效期延长：将缓存队列的总持续时间从 65 秒延长至100 秒。 ●容错能力提升：即使dcmi接口因资源抢占出现轻微延迟（如 40 秒内返回），监测平台在每分钟一次的采集频率下，仍能获取到有效的缓存数据，从而避免指标归零现象。