两台相同的设备，CPLD、BMC固件版本一致，检查当前告警时，一台可以看到Inlet Temp的0x12000013告警，一台看不到。
Scanner_Inlet依赖SmcDfxInfo更新。
由于CPLD不支持进风口温度，两台的当前告警应该都可以看到进风口温度的0x12000013告警信息
1 当前告警是否只展示BMC最近一次重启后产生的告警信息？
2 event/sync_property_trace.log日志看到Scanner_Inlet的Status是0，为什么还触发了告警？
3 sensor/sync_property_trace.log没看到Scanner_Inlet的Status更新记录，是否正常？
4 SmcDfxInfo会影响Scanner_Inlet的Status吗？
答案内容由AI生成，仅供参考：
结论：该问题更可能是由于 SmcDfxInfo 对硬件能力判断不一致导致的行为偏差，而非告警机制本身缺陷。建议统一底层数据处理逻辑，并加强状态同步与日志记录完整性。
在两台配置相同的设备（CPLD、BMC固件版本一致）上，检查当前告警时出现不一致现象：
Inlet Temp 的 0x12000013 告警已知 Scanner_Inlet 依赖 SmcDfxInfo 更新，且 CPLD 不支持进风口温度。软件版本为 OpenUBMC2506。
否，当前告警不仅限于BMC最近一次重启后的告警信息。
根据 openUBMC 的设计，告警状态是持久化的。系统通过以下机制维护告警信息：
例外情况：如知识库中文档 #10《Event常见问题指南》提到，若执行了 AC Power Cycle（交流电源循环），某些非持久化告警可能丢失。此外，如果系统配置了"复位时清空"策略，则可能导致告警状态丢失。
因此，两台设备告警显示不一致的原因不太可能是仅展示"最近一次重启后"的告警。
Status=0 表示正常状态，不应触发告警。若此时仍上报告警，则存在异常或配置问题。
可能原因包括：
sync_property_trace.log 显示 Status=0，但告警子系统可能缓存了之前的状态（如 Status=1），导致误报。event/sync_property_trace.log 与其他模块日志存在时间偏差，实际告警发生时 Status 并非 0。建议排查：结合
dump_info<AppDump>sensor_alarm>eo_sel中的日志，查看该告警的具体触发时间与 Status 变更时间是否一致。
不正常。sensor/sync_property_trace.log 应该记录 Scanner_Inlet 的状态更新。
该日志文件用于追踪传感器属性的同步过程。若未记录 Scanner_Inlet 的状态更新，说明：
Scanner_Inlet 依赖 SmcDfxInfo 更新，若 SmcDfxInfo 本身未更新或未成功传递数据，则不会触发状态变更。[register] [Event_xxx] [error_msg: no definition] 或 [error_msg: no component] 类似错误（参见文档 #10）。Scanner_Inlet 所属的 Component 未正确解析或关联。验证方法：使用
busctl tree bmc.kepler检查Scanner_Inlet对应的对象是否存在，并确认其Status属性是否有值。
是的，SmcDfxInfo 直接影响 Scanner_Inlet 的 Status。
从描述“Scanner_Inlet 依赖 SmcDfxInfo 更新”可知：
Scanner_Inlet 是一个虚拟传感器或逻辑事件，其状态由 SmcDfxInfo 提供的数据驱动。SmcDfxInfo 无法获取有效温度数据（例如 CPLD 不支持 Inlet Temp），应设置 Scanner_Inlet.Status = 1（异常）并触发告警。SmcDfxInfo 成功读取到数据（即使为默认值），则 Scanner_Inlet.Status = 0（正常）。因此，两台设备表现不一致的根本原因可能是：
SmcDfxInfo 成功接收到某种“假数据”或默认值，判定为“支持”，状态为 0；0x12000013 告警。注意：这也与期望结果矛盾——既然 CPLD 不支持进风口温度，两台都应触发告警，说明存在兼容性或识别逻辑不一致的问题。
| 问题 | 原因分析 | 解决建议 |
|---|---|---|
| 告警显示不一致 | SmcDfxInfo 数据处理逻辑存在差异或状态同步异常 |
检查 SmcDfxInfo 的数据源是否一致，确认是否有缓存或默认值处理差异 |
| Status=0 却报错 | 状态与告警不一致，可能为状态更新滞后或防抖缺失 | 检查告警策略中是否启用防抖机制，核对事件触发条件 |
| 无 Status 更新日志 | 组件未正确加载或状态未发生变化 | 检查组件注册日志，确认 Scanner_Inlet 是否成功注册 |
SmcDfxInfo 影响 |
是直接影响源 | 统一 SmcDfxInfo 的处理逻辑，确保相同硬件条件下行为一致 |
busctl get-property 查询 Scanner_Inlet 的 Status 和 EventSeverity 实际值；event/sync_property_trace.log 和 sensor/sync_property_trace.log 的时间戳是否同步；/var/log/one_log/event_register.log 确认告警对象是否注册成功；SmcDfxInfo 是否真的未提供 Inlet 温度数据；结论：该问题更可能是由于
SmcDfxInfo对硬件能力判断不一致导致的行为偏差，而非告警机制本身缺陷。建议统一底层数据处理逻辑，并加强状态同步与日志记录完整性。
两台设备app.log中最后一次告警的reading值都是1，时间都在1月份。
2月-3月期间两台设备都经历过多次重启。
event/event.db是持久化的文件吗？两台设备的event/event.db都能看到0x12000013告警内容
看event/sel.txt嘛 event.db就是记录的这个txt
看下历史状态
有没有恢复过
var/log/alarm.log会记录所有注册的对象以及初始告警值
如果预期有告警 实际没有
1月底做过sel清除操作，event/sel.txt和alarm.log看不到Inlet Temp的信息了。
event是Chassis.ChassisAccessInletTempFailure类型，reading值是Scanner_Inlet.Status。
event/sync_property_trace.log可以看到event对象，记录的reading值是0。
直接截完整的图吧
告警的配置
sync log相关内容
event配置
"Event_InletTempFail": {
"EventKeyId": "Chassis.ChassisAccessInletTempFailure",
"Reading": "<=/Scanner_Lm75_Inlet.Status",
"@Default": {
"Reading": 0
},
"Condition": 1,
"OperatorId": 5,
"Enabled": true,
"Component": "#/Component_Chassis",
"LedFaultCode": "A00"
}
event和sensor日志在压缩包里
AppDump.zip (60.2 KB)