传感器温度为32,csr配置门限值为70,产生过温告警

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

问题描述

AC后偶现传感器读值为32,门限值配置为70,但是产生了过温告警

环境信息

  • 操作系统:[如 Ubuntu 24.04]

  • 软件版本:[如 OpenUBMC2509]

  • 硬件配置:[如 CPU、内存等]

重现步骤

  1. [第一步]AC后观察系统事件

  2. 过温告警立马恢复

期望结果

无告警产生

实际结果

无误告警

分析结论

CSR配置:

“ThresholdSensor_M2TransferCardTemp”: {
“AssertMask”: 128,
“DeassertMask”: 28800,
“ReadingMask”: 2056,
“M”: 100,
“RBExp”: 224,
“OwnerId”: 32,
“OwnerLun”: 0,
“EntityId”: “<=/Entity_M2TransferCard.Id”,
“EntityInstance”: “<=/Entity_M2TransferCard.Instance”,
“Initialization”: 127,
“Capabilities”: 104,
“SensorType”: 1,
“ReadingType”: 1,
“SensorName”: “M2 Trans${Slot} Temp”,
“Unit”: 128,
“BaseUnit”: 1,
“Analog”: 1,
“NominalReading”: 25,
“MaximumReading”: 127,
“MinimumReading”: 128,
“UpperNoncritical”: 70,
“PositiveHysteresis”: 2,
“NegativeHysteresis”: 2,
“Reading”: “<=/Scanner_M2TransferCardTemp.Value”,
“ReadingStatus”: “<=/Scanner_M2TransferCardTemp.Status”,
“SensorNumber”: 255
},

“Event_DiskBackplaneOverTempMajor”: {
“Reading”: “<=/Scanner_M2TransferCardTemp.Value |> expr($1 > 255 ? 20 : ($1 >= 128 ? (-(255 - $1 + 1)) : $1))”,
“OperatorId”: 4,
“Enabled”: true,
“DescArg1”: “#/M2TransferCard_1.Name”,
“DescArg3”: “#/Event_DiskBackplaneOverTempMajor.Reading”,
“DescArg4”: “#/ThresholdSensor_M2TransferCardTemp.UpperNoncritical”,
“Component”: “#/Component_M2TransferCard”,
“Condition”: “<=/ThresholdSensor_M2TransferCardTemp.UpperNoncritical”,
“Hysteresis”: “<=/ThresholdSensor_M2TransferCardTemp.PositiveHysteresis”,
“AdditionalInfo” : “1,3,4”
},

[详细总结您对此问题的分析结论]

日志如下:

2026-07-24 08:48:55.098567 event NOTICE: hardware_event.lua(593): Event_DiskBackplaneOverTempMajor_010104|{“type”:“synchronization”,“source”:{“expressions”:[“expr($1 > 255 ? 20 : ($1 >= 128 ? (-(255 - $1 + 1)) : $1))”],“properties”:[{“Service”:“bmc.kepler.hwproxy”,“Property”:“Value”,“Interface”:“bmc.kepler.Scanner”,“Path”:“/bmc/kepler/Scanner/Scanner_M2TransferCardTemp_010104”}]},“value”:[32]}

2026-07-24 08:48:55.221377 event NOTICE: abstract_event.lua(242): [Event_DiskBackplaneOverTempMajor_010104] generate an event [assert] while Reading change to [32].

2026-07-24 08:48:55.320981 event NOTICE: hardware_event.lua(593): Event_DiskBackplaneOverTempMajor_010104|{“type”:“synchronization”,“source”:{“properties”:[{“Service”:“bmc.kepler.sensor”,“Property”:“UpperNoncritical”,“Interface”:“bmc.kepler.Systems.ThresholdSensor”,“Path”:“/bmc/kepler/Systems/1/ThresholdSensors/ThresholdSensor_M2TransferCardTemp_010104”}]},“value”:[70]}
2026-07-24 08:48:55.407938 event NOTICE: abstract_event.lua(242): [Event_DiskBackplaneOverTempMajor_010104] generate an event [deassert] while Condition change to [70].

通过分子日志可以看到产生告警时的读值为32,说明此时的上门限一定低于32;再看恢复时的日志可以看到,事件恢复并不是因为读值变化,而是上门限变为了70,读值低于上门限;因为上门限时配置死的,所以可以推断产生事件时读到的上门限为默认值0而非配置值

而且从传感器对象分发的事件来看,事件产生时传感器对象早已分发:

[2026-07-24 08:48:38] sensor ThresholdSensor_M2TransferCardTemp_010104 of host 0 is registered, number is 6.

求助:为什么事件对象会读到默认的上门限0,如何避免该种情况?

答案内容由AI生成,仅供参考:

解决方案建议

根据提供的最佳实践和配置指南,可通过以下方式避免此类误告警:

方案 具体做法 参考来源
配置 @Default 表达式 为事件的 ConditionReading 引用的属性设置安全默认值,例如在引用路径后添加 @Default(70),确保在属性未正确更新时不使用 0。 Event常见问题指南(ID 5):“请配置@Defalut(仅对同步生效,引用无效)”
优化初始化顺序 调整SR文件中事件对象与传感器对象的注册顺序,确保传感器属性的配置值先于事件对象的首次条件评估完成。 传感器适配指南(ID 8)强调实体与传感器的配置顺序重要性。
增加状态判断 在事件条件中加入对传感器属性有效性的判断,例如检查 ReadingStatus 是否为正常状态,避免在传感器未就绪时触发告警。 Event常见问题指南(ID 5):“建议判断扫描状态”
调整门限值默认行为 如果业务允许,可将 UpperNoncritical 等门限的默认值设为明显不合理的值(如 0xFFFF),使默认值不会误触告警。 CSR配置字典(ID 10)中门限字段均可在CSR中指定初始值。

推荐优先采用配置 @Default 的方法,因为它最直接且影响范围小,仅需修改事件对象的属性引用表达式。


总结

误告警产生的根本原因是事件在传感器属性未正确初始化时读取了默认值 0。通过为引用属性添加默认值表达式、调整初始化顺序或增加有效性判断,可以有效避免此类问题。上述分析均基于所提供的上下文信息(知识图谱、文档块、搜索结果),未引入外部知识。

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

问题原因分析

根据提供的日志与CSR配置,事件 Event_DiskBackplaneOverTempMajor_010104 在产生过温告警时,实际读到的上门限(UpperNoncritical)为默认值 0,而非配置值 70。当传感器读值 32 大于 0 时,条件成立,触发了误告警;随后传感器对象属性正确更新为 70,事件恢复(deassert)。

这种现象的核心原因在于:事件对象在首次条件评估时,引用的 ThresholdSensor_M2TransferCardTemp.UpperNoncritical 属性尚未正确加载(仍为默认值 0),而传感器属性默认值即为 0

关键证据

  • CSR配置字典(搜索结果 ID 10)明确说明 UpperNoncritical 的默认值为 0
  • Event常见问题指南(搜索结果 ID 5)指出:

    “同步的资源树对象未上树或者解析异常,此时解析Event读值失败,会使用默认值 0”
    以及 “同步时,引用对象值未更新,还是默认值,例如Scanner默认值0,还未开始扫描就被读取”

尽管传感器对象已在 08:48:38 注册(见日志),但它的 UpperNoncritical 属性可能因初始化顺序或SR文件加载时序问题,在事件触发前仍处于默认状态。事件对象的 Condition 直接引用了该属性(“Condition”: “<=/ThresholdSensor_M2TransferCardTemp.UpperNoncritical”),当引用值未更新时,事件使用了默认值 0,导致条件误判。


解决方案建议

根据提供的最佳实践和配置指南,可通过以下方式避免此类误告警:

方案 具体做法 参考来源
配置 @Default 表达式 为事件的 ConditionReading 引用的属性设置安全默认值,例如在引用路径后添加 @Default(70),确保在属性未正确更新时不使用 0。 Event常见问题指南(ID 5):“请配置@Defalut(仅对同步生效,引用无效)”
优化初始化顺序 调整SR文件中事件对象与传感器对象的注册顺序,确保传感器属性的配置值先于事件对象的首次条件评估完成。 传感器适配指南(ID 8)强调实体与传感器的配置顺序重要性。
增加状态判断 在事件条件中加入对传感器属性有效性的判断,例如检查 ReadingStatus 是否为正常状态,避免在传感器未就绪时触发告警。 Event常见问题指南(ID 5):“建议判断扫描状态”
调整门限值默认行为 如果业务允许,可将 UpperNoncritical 等门限的默认值设为明显不合理的值(如 0xFFFF),使默认值不会误触告警。 CSR配置字典(ID 10)中门限字段均可在CSR中指定初始值。

推荐优先采用配置 @Default 的方法,因为它最直接且影响范围小,仅需修改事件对象的属性引用表达式。


总结

误告警产生的根本原因是事件在传感器属性未正确初始化时读取了默认值 0。通过为引用属性添加默认值表达式、调整初始化顺序或增加有效性判断,可以有效避免此类问题。上述分析均基于所提供的上下文信息(知识图谱、文档块、搜索结果),未引入外部知识。

大概率是因为 Reading 和 Condition 都是配置的同步语法,且 Reading 先于 Condition 同步到数据,此时 Reading 是真实值 32,而 Condition 还未同步到取的是本属性默认值 0
可尝试配置 @Default 语法,给 Condition 配置不告警的默认值