fru对象health属性问题

问题描述

fru对象的health被UpdateHealth方法更新,异常时health属性一直为1,UpdateHealth方法是被哪个组件使用的,如何排查health为1的原因?

/bmc/kepler/Systems/1/Frus/Fru_CpuBoard_010101  bmc.kepler.Systems.Fru
.BoardId
  signature:  q
  value:      65535
  flags:      emits-change
  readonly:   true
.ConnectorGroupId
  signature:  u
  value:      9
  flags:      -
  readonly:   true
.EepStatus
  signature:  y
  value:      0
  flags:      -
  readonly:   true
.FruDataId
  signature:  s
  value:      "FruData_CpuBoard_010101"
  flags:      -
  readonly:   true
.FruId
  signature:  y
  value:      4
  flags:      emits-change
  readonly:   true
.FruName
  signature:  s
  value:      "CpuBoard1"
  flags:      emits-change
  readonly:   true
.GroupPosition
  signature:  s
  value:      "010101"
  flags:      -
  readonly:   true
.Health
  signature:  y
  value:      1
  flags:      emits-change
  readonly:   true
.PcbId
  signature:  y
  value:      1
  flags:      emits-change
  readonly:   true
.PcbVersion
  signature:  s
  value:      ".A"
  flags:      emits-change
  readonly:   true
.PowerState
  signature:  y
  value:      1
  flags:      -
  readonly:   true
.Type
  signature:  y
  value:      36
  flags:      -
  readonly:   true
.UniqueId
  signature:  s
  value:      "00000001020302065624\u0000\u0000\u0000\u0000"
  flags:      -
  readonly:   true

环境信息

  • 软件版本:OpenUBMC2512SP1

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

结论

  • Health=1 表示轻微告警/异常状态;上下文中的健康状态定义是:0:OK,1:轻微告警,2:严重告警,3:紧急告警。
  • UpdateHealth 是用于更新 FRU Health 的方法,定义在 bmc.kepler.Systems.Components / Bmc Kepler Systems Component 接口中,由 FruData 组件提供更新能力。
  • 实际调用入口不在 FruData 内部。在讨论案例中,最终定位为:Event(闭源)组件在 CPU Board 相关告警产生时,修改关联 FRU 的状态,从而导致 Fru_CpuBoard.Health 异常。
  • 代码层还存在内部入口:ImplComponentComponentUpdateHealth 会委托 update_fru_health,而 update_fru_health 是更新 FRU Health 的主要入口之一。
点击此处查看详细分析解答

结论

  • Health=1 表示轻微告警/异常状态;上下文中的健康状态定义是:0:OK,1:轻微告警,2:严重告警,3:紧急告警。
  • UpdateHealth 是用于更新 FRU Health 的方法,定义在 bmc.kepler.Systems.Components / Bmc Kepler Systems Component 接口中,由 FruData 组件提供更新能力。
  • 实际调用入口不在 FruData 内部。在讨论案例中,最终定位为:Event(闭源)组件在 CPU Board 相关告警产生时,修改关联 FRU 的状态,从而导致 Fru_CpuBoard.Health 异常。
  • 代码层还存在内部入口:ImplComponentComponentUpdateHealth 会委托 update_fru_health,而 update_fru_health 是更新 FRU Health 的主要入口之一。

已知的异常触发链

上下文中给出的典型流程是:

  1. Scanner 状态异常
  2. 触发 CpuBrd 过温告警
  3. Component_CpuBoard 状态变为异常
  4. Event(闭源)组件修改关联 FRU 的状态为异常
  5. 触发 Fru_CpuBoard.Health 异常
  6. 最终产生电子标签告警

因此,根因通常在于过温告警的产生,而不是电子标签本身状态异常。
另外,上下文也提到:FRU 对象的 Health 是在关联的 CpuBoard 有告警时变为 1;而 frudata 的 Health 则可能在连续读取 FRU 失败 10 次后被置为 1,这两个 Health 需要区分。

排查建议

1. 先查关联告警和组件状态

重点检查:

  • CPU Board 是否发生过温告警
  • Scanner 是否状态异常
  • Component_CpuBoard 的 Health / 状态是否异常
  • 是否存在电子标签相关告警,例如 CPU Board 电子标签数据获取失败

如果 Fru_CpuBoard.Health=1 与上述告警同时存在,应优先处理过温或 Scanner 异常,而不是只盯着 FRU Health。

2. 检查 EepStatus 和 FRU 读取状态

你给出的对象中:

  • EepStatus=0
  • Health=1

上下文中示例的 EepStatus=1 表示 EEPROM 正常。因此当前 EepStatus=0 建议重点排查:

  • EEPROM / 电子标签读取是否正常
  • FruDataId="FruData_CpuBoard_010101" 对应的 FruData 是否可访问
  • 是否存在 FRU 读取连续失败的情况

3. 检查告警配置引用的是哪个 Health

上下文中明确提到一个配置问题:

  • Event_CpuBoardAccessFRUAlbeFailure 原先配置为引用 Fru_CpuBoard.Health,这是错误的;
  • 应改为引用 FruData_CpuBoard.Health。

因此需要确认:

  • 当前告警配置的 Reading 是否仍错误地引用 Fru_CpuBoard.Health
  • 是否应使用 FruData_CpuBoard.Health
  • 是否因配置引用错误导致告警或异常状态持续

4. 检查两个 Health 是否同时关联

上下文指出:

  • Fru_CpuBoard.Health 与 FruData_CpuBoard.Health 同时关联时,会导致异常状态无法消除、一直不恢复。
  • 同时关联 Fru_CpuBoard.Health 和 Component_CpuBoard 也可能导致异常状态无法清除。

因此建议检查:

  • 是否同时存在 Fru_CpuBoard.Health 和 FruData_CpuBoard.Health 的关联
  • 事件配置是否同时挂接了 Fru_CpuBoard.Health 与 Component_CpuBoard
  • 是否存在“告警源已恢复,但 FRU Health 仍为 1”的关联配置问题

5. 核对 frudata 版本和代码入口

上下文提到:

  • 基于 frudata/1.70.39 的代码没有带上十二月份的相关需求;
  • 该版本中更新 FRU 的入口仍然只有 update_fru_health;
  • 新版本中新增了 FruData_CpuBoard.Health 属性,和原来的 Fru_CpuBoard.Health 不是同一个属性。

因此建议确认当前 OpenUBMC2512SP1 使用的 frudata 版本是否包含该变更,并检查:

  • UpdateHealth
  • ImplComponentComponentUpdateHealth
  • update_fru_health

三者的实际调用链。

6. 日志不足时结合告警链排查

讨论中提到该问题“没有相关日志打印”。这种情况下不能只依赖 UpdateHealth 日志,应结合:

  • 告警事件列表
  • Scanner 状态
  • Component_CpuBoard 状态
  • 电子标签读取结果
  • FRU / FruData 对象属性变化

综合判断 Health=1 是由过温告警链路触发,还是由 FRU 读取失败、告警配置错误或双 Health 关联导致。