OCP 相关精细化告警定义缺失

[kunlun_xiongzirui (熊子锐)]

问题描述

0x53000005 OCP 器件温度读取失败

0x53000003 OCP 器件温度过高一般告警

这两个告警在告警手册中有定义，但是在 vpd 的 `event_def.json` 中缺失；

当前社区上存量的 OCP 卡，温度获取失败告警和过温告警，配置的事件主体都是 PCIe 卡的

对应的是：

疑问：为什么 OCP 器件温度读取失败 和 OCP 器件温度过高一般告警 告警没有在 event_def.json 中定义，存量 OCP 卡上的 PCIe 过温和温度获取失败告警，是否应该被整改为 OCP 的？

环境信息

1230 基线

[ubmc_assistant (openUBMC_Assistant)]

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

总结与结论

项目	当前状态	建议改进
事件定义位置	event_def.json 中缺失	补充定义
事件命名规范性	复用PCIeCard通用事件	使用 OCP.* 独立命名空间
多接口一致性	REDFISH/SNMP可能独立定义但源不统一	以 event_def.json 为唯一源
运维可读性	事件含义模糊，无法区分设备类型	实现精准告警区分

结论：当前OCP卡温度相关告警确实应该整改为专用事件，避免继续使用PCIe卡的通用事件主体。此举不仅符合系统设计规范，也将显著提升监控精度和运维效率。建议在后续版本中优先完成该整改任务。

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

OCP相关精细化告警定义缺失问题分析

问题概述

当前OCP（Open Compute Project）卡相关的两个关键告警在vpd/vendor/event_def.json中缺失，但已在告警手册中定义，具体包括：

• 0x53000005 OCP器件温度读取失败
• 0x53000003 OCP器件温度过高一般告警

目前系统中使用的是PCIe卡通用告警事件主体来上报OCP卡的温度异常，这引发了一个关键问题：OCP卡应拥有独立、精细化的告警定义，而非复用PCIe卡的通用事件。

---

当前配置现状

根据提供的信息，现有配置存在以下情况：

温度过高告警配置

"Event_OCPOverTemp": {
    "EventKeyID": "PCIeCard.PCIeCardOverTemp",
    "Condition": "<?>ThresholdSensor_OCPTemp_UpperNonCritical",
    "Hysteresis": "<>ThresholdSensor_PositiveHysteresis",
    "Reading": "<?Scanner_NIC_Lm75_Value | expr($1 >= 255) ? 30 : $1 | expr($1"
}

• 事件标识：使用了PCIeCard.PCIeCardOverTemp
• 实际监控对象：ThresholdSensor_OCPTemp_UpperNonCritical 和 Scanner_NIC_Lm75_Value
• 判断逻辑：当传感器值 ≥ 255 时视为无效，返回30℃默认值

温度读取失败告警配置

"Event_TempFail": {
    "EventKeyId": "PcieCard.PCieCardTempFail",
    "Condition": 1
}

• 事件标识：PcieCard.PCieCardTempFail
• 触发条件：条件恒为真（需结合上下文判断是否与OCP温度传感器状态关联）

---

根本原因分析

1. 事件定义与实现分离

• 所有标准事件应在 vpd/vendor/event_def.json 文件中全局唯一定义。
• 现有OCP专用告警未在此文件中注册，导致：
  • 缺乏统一的事件元数据（Severity、ActionId、Description等）
  • 无法在REDFISH/SNMP等标准化接口中正确暴露
  • 造成事件管理混乱和运维定位困难

对比：PCIeCardOMOverTemp 在 event_def.json、REDFISH 和 SNMP 中均有完整定义，并支持多接口一致性。

2. 通用事件的滥用

系统通过复用 PCIeCard.PCIeCardOverTemp 和 PcieCard.PCIeCardTempFail 事件来实现OCP告警，属于事件泛化误用，其弊端包括：

问题	描述
定位精度低	无法区分是GPU卡、RAID卡还是OCP卡触发的过温事件
影响诊断效率	运维人员难以快速判断故障设备类型
策略不匹配	不同设备对应的处置建议不同（如光模块 vs 电口卡）
影响自动化处理	自动化工具无法基于事件ID准确执行响应流程

---

是否应进行整改？

强烈建议整改为独立的OCP事件

理由如下：

1. 符合精细化监控设计原则

   • 每类硬件设备应有专用事件ID和专属描述
   • 提升事件语义清晰度，便于故障溯源

2. 支持多接口一致性要求

   • 当前仅有部分OCP事件在SNMP或REDFISH中定义，而主配置文件event_def.json缺失，违反了“以event_def为唯一源”的配置规范。
   • 应通过构建阶段自动生成REDFISH/SNMP定义，确保三者一致。

3. 与已有实践保持对齐

   • 已有类似场景如 PCIeCardOMOverTemp 成功实现了独立事件定义：

     {
       "EventName": "PCIeCardOMOverTemp",
       "EventKeyId": "PcieCard.PCIeCardOMOverTemp",
       "EventCode": "0x08000063",
       "SeverityId": 1,
       "ReportChannel": 65535
     }
     

   • 同样地，OCP卡也应拥有如 OCP.OCPOverTemp、OCP.OCPTempFail 的专用事件。

4. 避免“告警漂移”风险

   • 若多个设备共用同一事件ID，在日志或监控平台中容易造成事件源混淆
   • 特别是在多网卡或混合设备场景下，无法准确映射事件到物理设备

---

整改建议方案

1. 在 event_def.json 中新增OCP专用事件

{
  "EventCode": "0x53000005",
  "ReportChannel": 65535,
  "EventType": 0,
  "LifeCycleId": 0,
  "DeassertFlag": 1,
  "EventKeyId": "OCP.OCPTempFail",
  "SeverityId": 1,
  "ActionId": 0,
  "EventName": "OCPTempFail"
},
{
  "EventCode": "0x53000003",
  "ReportChannel": 65535,
  "EventType": 0,
  "LifeCycleId": 0,
  "DeassertFlag": 1,
  "EventKeyId": "OCP.OCPOverTemp",
  "SeverityId": 1,
  "ActionId": 0,
  "EventName": "OCPOverTemp"
}

2. 更新事件绑定逻辑

将原配置从：

"Event_OCPOverTemp": {
    "EventKeyID": "PCIeCard.PCIeCardOverTemp"
}

改为：

"Event_OCPOverTemp": {
    "EventKeyID": "OCP.OCPOverTemp"
}

3. 同步更新多接口定义

• REDFISH：在 ibmcevents.v3_0_0.json 中添加 OCPTempFail 和 OCPOverTemp 的本地化描述
• SNMP：在 HUAWEI-SERVER-iBMC-MIB.mib 中为新事件分配通知OID

4. 维护配套文档一致性

• 同步更新告警手册、维护指南、北向接口文档
• 确保事件码、名称、建议措施一致

---

总结与结论

项目	当前状态	建议改进
事件定义位置	event_def.json 中缺失	补充定义
事件命名规范性	复用PCIeCard通用事件	使用 OCP.* 独立命名空间
多接口一致性	REDFISH/SNMP可能独立定义但源不统一	以 event_def.json 为唯一源
运维可读性	事件含义模糊，无法区分设备类型	实现精准告警区分

结论：当前OCP卡温度相关告警确实应该整改为专用事件，避免继续使用PCIe卡的通用事件主体。此举不仅符合系统设计规范，也将显著提升监控精度和运维效率。建议在后续版本中优先完成该整改任务。

[xushuo25 (xushuo)]

OCP卡的这两个告警已于2026年2月7日支持，最新适配的OCP卡已使用该OCP卡告警码。社区上存量的 OCP 卡后续会通过需求进行统一整改。MR链接：支持ocp卡告警增强-vpd-AtomGit | GitCode