📋 文档信息 ​

📋 变更历史记录 ​

在配置事件告警中，需要保证每次事件触发时具备唯一标识，该标识会通过事件上报机制告知网管侧，网管基于此唯一标识判断事件告警是否已经处理过，如果已经处理过则不再处理，否则进行处理。

事件告警流程图 ​

CSR告警配置 ​

    "[Event_名称]": {
        "EventKeyId":"[事件标识]",
        "Reading" : [告警读值],
        "Condition" : [告警门限值],
        "OperatorId" : [运算符],
        "Hysteresis" : [迟滞量],
        "Enabled" : [事件使能状态，或者称为屏蔽状态]，
        "DescArg1-10" : "[事件的描述参数，用于格式化参数，仅支持字符串格式，最多10个]",
        "Component" : "#/[关联的Component对象]",
        "AdditionalInfo": "[(选配)事件的附加信息]",
        "InvalidReadingIgnore": [(选配)是否忽略无效值,1:开启 0 : 关闭，开启后读值如果等于InvalidReading则忽略],
        "InvalidReading": [(选配) 需要忽略的无效值]
    }

事件对象生成原理 ​

• 生成EventId：根据EventKeyId匹配告警事件对应的EventCode(在redfish接口叫做EventId)

• 生成EventSubJect：根据Event.Component、'--'与Event.AdditionalInfo(可以有多个，也可以没有)生成。Event.AdditionalInfo一般是数字，表示的是DescArg的第几个，如下所示，Event.AdditionalInfo指的是DescArg2，则EventSubJect = Event.Component + '--' + DescArg2 = CpuBoard--BCU1

    "[Event_名称]": {
        "EventKeyId":"[事件标识]",
        "DescArg1" : 3.3V,
        "DescArg2" : "BCU#{Slot}",
        "Component" : "#/Component_CpuBoard",
        "AdditionalInfo": "2",
    }

事件对象 ​

    "Events":[ 
        {
            "EventType":"[事件类型]",
            "EventId":"[事件码]",
            "EventSubject":"[事件主体]",
            "Severity":"[严重等级]",
            "MessageArgs":[
                3.3V,
                BCU1
            ]
        },
        ...
    ]

对象“唯一性”原则 ​

• 每种机型，事件配置通过EventId和EventSubJect(由Event.Component与Event.AdditionalInfo组成)信息组合之后确定唯一性。
• 网管侧拿到事件对象后，根据对象“唯一性”原则，对于EventId和EventSubJect相同的事件对象进行合并。然后在网管侧给用户展示最终的事件。

根据对象“唯一性”原则，在CSR中配置新的事件需要明确EventKeyId、Event.Component、Event.AdditionalInfo是否能够保证产生唯一的事件对象。

还要遵循现网存量告警对象配置“不能变”原则，即现网已经支持的告警，事件对象配置的如下3个信息不能变化：EventKeyId、Event.Component、Event.AdditionalInfo

违背对象“唯一性”原则后修复方法：新的事件配置需要在保证对象“唯一性”原则的同时还要满足现网存量告警对象配置“不能变”原则。满足现网存量告警对象配置“不能变”原则的目的是需要兼容现网旧版本——网管不会主动实时更新告警，对于已经产生的告警也需要BMC产生一个消除告警的信号过去（消除告警也遵循对象“唯一性”原则去匹配）。因此更改事件的配置的时候，要保证能够让旧事件对象的检测结果固定配置为OK（即能够消除网管侧已经产生的告警）；然后新增事件对象，与存量的冲突的事件对象通过AdditionalInfo来区分。