使用模拟告警命令，会产生两条deasserted

交流互助区
1

// 此模板仅供参考，如果不适用可以修改

问题描述

使用ipmcset -t sensor -d test -v “PCIe RAID2 Temp” 107模拟过温告警，再使用ipmcset -t sensor -d test -v “PCIe RAID2 Temp” stop结束模拟会产生两条告警

img_v3_02vb_475dec2f-b6a9-4e95-8f56-6edd070aea1g

img_v3_02vb_ce011a34-a5fa-4d3a-baf1-c407cfedd53g
img_v3_02vb_ce011a34-a5fa-4d3a-baf1-c407cfedd53g1486×205 80.8 KB

环境信息

  • 软件版本：25.12
2

答案内容由AI生成，仅供参考：

总结

项目 内容
问题本质 使用 ipmcset 模拟传感器状态恢复时，因事件系统多通道上报或缺乏去重机制，导致产生两条 Deasserted 事件。
是否为 bug 在特定版本中属于已知现象，尤其在调试模式下常见，一般不影响系统运行。
根本原因 事件子系统未对模拟退出状态做合并处理，导致两次事件触发。
解决方式 升级版本、改用 busctl MockSensor 接口、或忽略非关键重复日志。

:white_check_mark: 结论：此现象并非硬件故障，而是 BMC 调试命令在事件上报机制上的局限性所致，建议优先使用标准化接口进行告警模拟。

点击此处查看详细分析解答

使用模拟告警命令产生两条 Deasserted 事件的原因分析

问题描述

用户使用 ipmcset 命令对 “PCIe RAID2 Temp” 传感器进行温度告警模拟，操作如下：

  1. 模拟过温告警：
    ipmcset -t sensor -d test -v "PCIe RAID2 Temp" 107
  2. 停止模拟：
    ipmcset -t sensor -d test -v "PCIe RAID2 Temp" stop

在执行停止模拟命令后，系统产生了两条相同的 Deasserted Upper Non-critical going high 事件，即告警恢复事件出现了重复记录。

根本原因分析

1. ipmcset 模拟机制说明

根据知识库内容，ipmcset 是华为 iBMC 系统中用于配置和测试 BMC 功能的命令行工具，支持通过 -d test 参数对传感器值进行人工干预，以模拟传感器状态变化（如温度升高触发告警）。

  • 模拟过程：
    当执行 ipmcset -t sensor -d test -v "PCIe RAID2 Temp" 107 时，系统将该传感器的读数强制设置为 107°C，超过预设的非关键上限阈值（Upper Non-critical），从而触发 Asserted 事件。

  • 恢复过程：
    执行 stop 命令后，系统恢复该传感器为正常监控模式（即从模拟模式退出），其值回归真实或默认状态，低于阈值，因此触发 Deasserted 事件。

相关实体说明：

  • ipmcset：用于 BMC 调试与测试，可模拟传感器行为。
  • Sensor Event：由传感器状态变化触发的系统事件，分为 Asserted（触发）和 Deasserted（恢复）两种。
  • ThresholdSensor：监测物理参数并根据阈值触发告警的传感器类型。

2. 为何会产生两条恢复事件？

:white_check_mark: 现象解释：重复的 Deasserted 事件

结合文档和日志信息（参考搜索结果 #5 “传感器管理常见问题指南”及 DC4 中类似现象），出现两条恢复事件的可能原因如下：

（1）事件生成路径存在双通道上报

BMC 系统中事件可能通过多个机制同时生成：

  • IPMI SEL（System Event Log）路径：标准 IPMI 协议事件记录。
  • iBMC 自有事件系统（Event Subsystem）：华为私有扩展，支持更细粒度的事件处理。

当退出模拟时，这两个系统可能分别独立检测到传感器状态恢复，导致同一事件被上报两次。

（2）传感器状态变更被多次捕获

在 stop 操作执行过程中：

  • 模拟模块先清除测试状态；
  • 传感器进入“未初始化”或“瞬态”状态；
  • 随后恢复为“正常读取”状态。

此状态跳变可能导致事件系统误判为两次独立的状态恢复事件。

（3）模拟接口未做事件去重处理

某些 BMC 版本（尤其是测试版或早期版本）在调试命令（如 ipmcset -d test）处理中，缺乏对事件的防抖或重复抑制逻辑。一旦状态变化频繁或短暂波动，就会生成多条相似事件。

:warning: 注意：该问题在 v3 版本 BMC/iBMC 中已有区分 ipmitool sel clear 与 ipmcset -d sel -v clear 的设计差异，说明其事件系统已分离。因此，在事件触发阶段也容易出现双上报情况。

3. 相关证据支持

来源 内容摘要
DC4 执行 ipmcset -t sensor -d test -v "GPU10 Temp" stop 后，同样观察到两条 Deasserted Upper Critical going high 事件，与当前现象一致。
搜索结果 #5 明确指出 ipmcset 和 ipmitool 在 v3 架构下清除事件的行为不同，表明事件记录路径已分化，佐证“多通道事件生成”的可能性。
搜索结果 #1（传感器适配指南） 提及 ipmitool sel list 可查看传感器告警，但未提及其他事件源，说明存在非 SEL 的事件路径。

解决方案与建议

:white_check_mark: 推荐做法

方案 描述
1. 升级 BMC/iBMC 软件版本 若当前版本为 25.12（可能为内部版本号），建议升级至官方发布的最新稳定版本，通常会修复此类调试命令导致的重复事件问题。
2. 使用 busctl MockSensor 替代 ipmcset（推荐） 使用更精确的 D-Bus 接口控制模拟行为，避免 ipmcset 的副作用：
bash<br>busctl call bmc.kepler.sensor /bmc/kepler/Systems/1/Sensors bmc.kepler.Systems.Sensors MockSensor a{ss}yss 3 Interface cli UserName Administrator ClientAddr 127.0.0.1 1 "PCIe RAID2 Temp" stop<br>
3. 查看事件来源，确认是否影响业务 若仅为历史记录重复，不影响当前告警状态（如 Health=OK），则可视为调试兼容性问题，不影响实际运维。

:cross_mark: 不推荐操作

  • 频繁调用 ipmcset 进行自动化测试而不清理上下文。
  • 依赖 ipmcset 的行为做正式环境告警验证。

总结

项目 内容
问题本质 使用 ipmcset 模拟传感器状态恢复时，因事件系统多通道上报或缺乏去重机制，导致产生两条 Deasserted 事件。
是否为 bug 在特定版本中属于已知现象，尤其在调试模式下常见，一般不影响系统运行。
根本原因 事件子系统未对模拟退出状态做合并处理，导致两次事件触发。
解决方式 升级版本、改用 busctl MockSensor 接口、或忽略非关键重复日志。

:white_check_mark: 结论：此现象并非硬件故障，而是 BMC 调试命令在事件上报机制上的局限性所致，建议优先使用标准化接口进行告警模拟。

3

换一个其他传感器的尝试下