答案内容由AI生成，仅供参考：
OS启动/重启阶段误报Mngmnt Health告警分析与解决方案
问题描述
在OS启动或重启阶段，系统产生 Mngmnt Health 告警（事件状态为 Asserted），提示“Sensor access degraded or unavailable”，该告警在OS启动完成后自动消除（Deasserted）。此现象虽为临时性事件，但导致装备流程误判系统异常，影响自动化运维稳定性。
环境信息
- 操作系统：Ubuntu 24.04
- 软件版本：OpenUBMC 2509
- 硬件配置：安装华为 300IA2 NPU 卡（64GB）
- 关键实体：
NPU_1Entity_GPUCardThresholdSensor_GPUPower、ThresholdSensor_GPUDeviceTemp 等 NPU 相关传感器
故障现象
-
系统上电后，BMC 日志中出现多条 Mngmnt Health 告警：
Sensor access degraded or unavailable
-
告警时间点集中在 OS 启动初期（BIOS 初始化之后，OS 完全加载之前）。
-
多个告警条目中，Sensor Number 不同，但均对应 Management Subsys Health 类型，事件类型为：
Management Subsys Health #0x03: Sensor access degraded or unavailable
-
告警在 OS 启动完成后约 30–60 秒内自动清除。
根本原因分析
1. Mngmnt Health 告警机制原理
根据知识库信息：
Mngmnt Health 是一种 离散传感器（Discrete Sensor），用于聚合管理子系统的健康状态。- 当任意一个底层传感器出现 扫描异常 或 无法访问 时，会触发该传感器上报“Sensor access degraded or unavailable”事件。
- 触发条件是：某传感器的
ReadingStatus 属性值 非0（即 != 0）。
- 在 IPMI 协议中，
SelData2 和 SelData3 字段用于标识具体是哪个传感器引发了事件。
参考文档：传感器管理常见问题指南
2. 日志分析定位问题传感器
从用户提供的 app.log 和 sensor.log 提取关键信息：
（1）事件日志片段：
{
"SelData2": 171,
"SelData3": 0,
"SensorNumber": 3,
"SelType": 2,
"Description": "Sensor access degraded or unavailable"
}
SelData3 == 0 → 传感器编号 = SelData2 = 171
（2）sensor.log 查找编号 171 的传感器：
[2026-01-28 07:46:33] sensor ThresholdSensor_GPUPower_0101010302 of host 0 is registered, number is 171.
定位到：编号为 171 的传感器是 NPU 卡的功耗传感器（ThresholdSensor_GPUPower）。
3. 上电阶段传感器行为分析
（1）NPU 上电顺序
- BMC → BIOS → OS → 驱动加载完成 → NPU 通信建立 → 温度/功耗数据可读
- 在 OS 启动初期，BMC 尝试轮询 NPU 传感器，但由于：
- NPU 驱动未加载
- PCIe 链路未完全建立
- MCU/FW 未就绪
导致传感器 读值失败
（2）ReadingStatus 异常机制
根据文档《传感器管理常见问题指南》：
若连续传感器的 ReadingStatus 属性值 非0，则视为扫描异常，触发 Mngmnt Health 告警。
在 OS 启动初期，以下情况发生：
ThresholdSensor_GPUPower、ThresholdSensor_GPUDeviceTemp 等传感器因无法获取真实值，其 ReadingStatus 被设为 1（异常）- sensor 模块检测到该状态变更，立即生成 SEL 事件
- 事件类型：
Sensor access degraded or unavailable
- 汇总上报至
Mngmnt Health 传感器
4. 为什么 PowerState 无法用于控制
用户尝试使用 NPUCard.PowerState 来抑制告警：
"PowerState": "U8" // 0: 下电, 1: 上电
但发现：
- 即使 OS 已启动，
PowerState 仍为 0
- 表明 PowerState 依赖于驱动上报，存在延迟
- 早于
PowerState 更新前，已有传感器状态异常
因此无法作为前置条件屏蔽告警。
解决方案建议
推荐方案：引入 传感器防抖延迟机制
思路
在 OS 启动完成前，对 NPU 类传感器设置一个初始化窗口期，在此期间：
- 允许传感器
ReadingStatus 为异常
- 不生成
Sensor access degraded or unavailable 的 SEL 事件
- 或将
Mngmnt Health 的上报延迟至 OS 稳定后
实现方式（基于 openUBMC 架构）
-
监听 OS 启动状态
- 监控
Bios.SystemStartupState 或 OS_Status 信号
- 状态变迁：
BootComplete 或 OS running 为真时，认为初始化完成
-
配置传感器延迟使能
-
在 CSR 配置中为 NPU 传感器添加 InitializationDelay 字段
-
示例：
{
"ThresholdSensor_GPUPower_0101010302": {
"Initialization": 127,
"Capabilities": 232,
"InitializationDelay": "P0DT30S", // 延迟30秒后再启动监控
"AssertMask": 128,
"DeassertMask": 28800,
...
}
}
-
结合 ReadingStatus 过滤逻辑
- 修改
sensor 模块逻辑，在 OS 启动完成前忽略 ReadingStatus == 1 的异常
- 或仅当
ReadingStatus 持续异常超过阈值时间才上报
替代方案：通过 Entity 在位状态控制传感器扫描
参考文档中提到：
传感器扫描状态受其关联 Entity 的 在位状态 和 上电状态 控制。
可优化如下配置：
"ThresholdSensor_GPUPower": {
"EntityId": "<=/Entity_GPUCard.Id>",
"EntityInstance": "<=/Entity_GPUCard.Instance>",
"EnableCondition": "expr($1.PowerState == 1 && $1.Health == 'OK')"
}
- 只有当
Entity_GPUCard 的 PowerState == 1 且健康时，才启用该传感器扫描
- 避免在设备未就绪时强行读取数据
要求：确保 Entity_GPUCard 的 PowerState 能准确反映硬件真实状态。
增强建议：添加日志关联提示
在 Mngmnt Health 告警触发时，自动输出 SelData2 对应的传感器名称（而非仅编号），便于快速识别源头。
可结合脚本实现：
# 解析 SEL 日志，映射编号到传感器名
grep "add sel" sensor.log | grep "Sensor access degraded" | \
awk '{print $NF}' | xargs -I {} grep "number is {}" sensor.log
结论
| 项目 |
内容 |
| 问题本质 |
OS 启动阶段 NPU 传感器未就绪，ReadingStatus 异常，触发 Mngmnt Health 告警 |
| 定位结果 |
告警由 ThresholdSensor_GPUPower（编号171）等 NPU 传感器引发 |
| 根本原因 |
缺乏 初始化等待机制，导致对未就绪传感器误判为故障 |
| 解决方向 |
引入 启动延迟 或 状态依赖条件，避免早期误报 |
| 影响范围 |
所有依赖 OS 驱动通信的 PCIe 扩展卡（如 GPU/NPU/网卡）均可能复现 |
参考资料
建议：将此类启动阶段的瞬态告警纳入“可忽略事件白名单”，并通过 BMC 提供“系统启动中”状态标志，供上层管理系统判断是否应忽略这些临时告警。
相关链接：
- 板卡温度模拟获取失败，Mngmnt Health传感器信息无变化
- 使用ipmitool/web查看传感器事件出现报错的问题
- OS下电后NPU卡传感器的读值
- BMC CPU1 0V9_UNCORE传感器只有Deasserted没有Asserted事件
- CSR配置字典之TemperatureInfo类 | 文档中心 | openUBMC
《传感器管理常见问题指南》
openUBMC 官方文档
