网管系统告警产生和处理机制.doc

网管系统告警产生和处理机制
1.1.1 告警来源和产生机制
1、 SYSLOG日志（被动接收方式）
通过采集服务器的SYSLOG服务，接收网元发送上来的SYSLOG日志记录。告警采集程序通过rules将SYSLOG日志记录解析为告警记录。一条典型的华为端口DOWN告警解析过程：
Jul 15 19:54:11 133.63.254.190 2008 yaan-DC-R-N40 IFNET/5/UPDOWN:Interface Ethernet1/0/5 Turns into DOWN state
针对上面的告警，通过rules，主要解析出如下内容
告警来源IP：133.63.254190
告警类型：IFNET/5/UPDOWN
告警对象：Ethernet1/0/5
告警原始级别：5
告警描述：Interface Ethernet1/0/5 Turns into DOWN state

2、 Snmp Trap告警（被动接收方式）
告警采集在162端口监听并接收网元发送过来的TRAP通知，通过加载相应MIB里的TRAP定义或者厂家提供的TRAP告警翻译规则，转换为相应的告警记录。举例说明：
10.102.16.2:
TRAP[requestID=0, errorStatus=Success(0), errorIndex=0,
VBS[1.3.6.1.2.1.1.3.0 = 229 days, 12:07:02.00;
1.3.6.1.6.3.1.1.4.1.0 = 1.3.6.1.4.1.3902.1015.1010.1.10.1.17;
1.3.6.1.2.1.2.2.1.1 = 808584704
]]
根据中兴提供的TRAP告警定义：
（1）1.3.6.1.4.1.3902.1015.1010.1.10.1.17代表zxAnEponOnuErroredSymbolPeriodEvent，即ONU错误符号间隔事件，级别是主要。
（2）808584704 代表索引信息，可进一步定位到具体的ONU设备，如F820(0/4/4/5)。解析翻译后的告警如下：
告警来源IP：10.102.16.2
告警类型：zxAnEponOnuErroredSymbolPeriodEvent
告警对象：10.102.16.2
告警级别：4
告警描述：10.102.16.2 F820(0/4/4/5) : ONU错误符号间隔事件

3、 网元状态Polling告警（主动检测方式）
（1）告警产生
采用定期调度（根据设备的重要程度可设定不同的策略）对设备先进行SNMP连接测试，再进行ICMP PING测试：
a、如果SNMP Ping不通，ICMP Ping也不通，发送网元中断告警；如果只有SNMP Ping不通，只发送网元不可管理告警
b、如果SNMP Ping通，不管ICMP Ping通不通，都不发送任何告警
c、如果原来只是SNMP Ping不通，但ICMP Ping也开始不通，再发送一条网元中断告警
说明：网元不可管理和网元中断告警，默认只发送一次，不重复发送（即发生次数为1）。
（2）告警恢复
对于处于网元不可管理或网元中断状态的设备，同时进行SNMP Ping和ICMP Ping跟踪：
a、如果SNMP Ping通，根据设备的告警状态，发送相应的恢复告警，分两种情况：
设备只有网元不可管理告警：发送网元不可管理恢复告警
设备同时有两种告警：同时发送网元不可管理和网元中断的恢复告警
b、如果SNMP Ping仍不通，但ICMP Ping开始通（也就是说原来两者都不通），发送一条网元中断恢复告警。

4、 端口状态Polling告警（主动检测方式）
端口Polling在端口流量采集时进行（检测周期与性能采集周期相同，5min一次）。判断标准：本次端口流量采集采到的端口操作状态跟上次采到的端口状态做对比，如果发生了状态变化则发送告警，即：
如果是up－>down，就发端口DOWN告警；如果是down－>up，就发恢复告警。告警示例：
告警类型：端口状态
告警描述：如：172.28.12.4 GigabitEthernet0/1/13(端口) 端口down
告警级别：严重
说明：端口状态告警，只发送一次，不重复发送（即发生次数为1）。

5、 性能告警（主动检测方式）
告警产生机制：根据性能采集后的数据结果和性能告警设置进行比较，如果满足性能告警设置条件，发送相应的性能告警。
恢复告警：如果发生了“满足性能告警设置条件”－>“不满足性能告警设置条件”的变化，则发送相应的恢复告警。
性能告警分类：
（1）阈值性能告警：通过阈值设置产生的性能告警
（2）基线性能告警：偏离基线时产生的性能告警
（3）梯度性能告警：梯度变化满足一定条件时产生的性能告警
（4）高级性能告警：满足给定的组合条件时产生的性能告警
说明：性能告警，如果满足性能告警设置条件，则每5分钟发送一次，直到告警恢复为至。

6、 其它告警：翻转告警、资源预警、进程告警等（主动检测方式）
（1）翻转告警：根据翻转设置条件，产生的告警，不能自动恢复。告警类型为“翻转告警”。
（2）资源预警：根据资源预警设置条件，判断设备的槽位占有或端口利用率是否超过给定阈值，如果超过，则发送相应的资源预警告警。告警类型为“资源预警”。
（3）采集进程告警：采集进程正常时，能够定时主动发送心跳信息给应用服务器，系统每3分钟检测一次，根据采集进程的心跳信息是否及时更新来判断采集进程是否正常，如果超过设定时间，心跳信息没有更新，则认为进程down，进而产生相应的告警（重复发送）。如果进程启动，心跳信息恢复，则发送恢复告警。告警类型为“网管服务进程”。
1.1.2 告警数据处理流程
告警从采集，到入活动库，最后进入历史库，这个过程称为告警的生命周期。采集为始，入历史库为终。从始到终，其数据流程如下图所示：
恢复
过滤
过滤

未通过
告警重定义
历史库
活动库
丢弃
解析翻译
封装告警
SYSLOG
主动检测告警：设备PING，端口Polling，性能告警，资源告警，拨测告警等

各种规则预处理

是
未过滤
未过滤
告警接收Socket服务
告警验证
时间窗口处理
告警风暴处理
资源关联
通过
否
JMS消息服务
AlarmOperator
TRAP
原始告警库
丢弃

流程说明：
1、 收到的所有SYSLOG和TRAP告警都进行记录。
2、 只有SYSLOG和TRAP告警需要经过RULES解析和翻译环节，其它告警来源无此过程。
3、 被RULES过滤掉的SYSLOG和TRAP告警直接丢弃，而非进入历史库，SYSLOG和TRAP告警在原始库中可以找到（TRAP原始报文默认不入库，如果要入库，需要打开进程参数）。
4、 告警先进行重定义，在进行预处理规则过滤，被预处理过滤的告警，直接进入历史库（也可以选择直接丢弃），对应的删除类型为“预处理删除”；没有过滤的告警入活动库，同时发布JMS消息。
5、 告警是排队入库的，每次从入库队列中取一定数量的告警依次入库。分为三种情况：
（1） 如果活动库中存在相同的告警事件（告警源和事件相同），则进行告警更新（更新发生次数和发生时间）；
（2） 如果活动库中不存在相同的告警事件，则插入一条新的活动告警记录；
（3） 如果告警为恢复告警，则将活动库中对应的告警事件清除，进入历史库。
6、 活动库的告警被删除后，进入历史库。这里的删除有以下几种情况
（1） 界面手工删除
对应的删除类型为“用户手工删除”。
（2） 自动恢复删除
收到恢复告警后，自动与对应的活动告警结对合并，合并后的告警入历史库。合并后的告警，清除时间为恢复告警的发生时间，清除类型为“自动恢复删除”，其余字段保留原告警信息。也就是说，恢复告警是与成对的活动告警合并成一条告警后入历史库。
（3） 告警条件删除
根据在告警设置里设置的定时删除规则，定时删除符合条件的活动告警。对应的删除类型为“告警条件删除”。
（4） 告警过多删除低级告警
当活动库的告警超过设置的容量时，系统自动启动的删除低级别（未定和警告）告警的策略。删除的告警的级别为未定和警告。对应的删除类型为“告警过多删除低级告警”。
5） 成对合并直接入历史库
如果收到的某个告警发生和恢复时间非常接近（1秒左右），入库线程从告警队列里取告警后，发现有这种成对的情况，就不再走活动库而是直接合并入历史库，这种情况下告警删除类型为“成对合并直接入历史库”。
（6） 等价告警剔重
目前仅适用于端口down告警。当上来某条端口down告警时，但活动库中已经存在该端口的其它PORT_DOWN告警，则该端口down告警直接入历史库，删除类型为“等价告警剔重”。

1.1.3 告警关联机制
告警关联机制包括：
（1） 告警结对清除
收到恢复告警后，自动与对应的活动告警结对合并成一条告警，合并后的告警从活动库转入历史库这种情况下告警删除类型为“自动恢复删除”；
（2） 告警压缩合并
收到告警时，自动与活动库中存在的相同告警事件（告警源和事件相同）进行合并，同时更新告警的发生次数和发生时间；
（3） 告警合并直接入历史库
如果收到的某个告警发生和恢复时间非常接近（1秒左右），入库线程从告警队列里取告警后，发现有这种成对的情况，就不再走活动库而是直接合并入历史库，这种情况下告警删除类型为“成对合并直接入历史库”；
（4） 告警同源处理
目前主要用于端口DOWN告警。端口DOWN告警的来源主要有SYSLOG和端口状态Polling两种，尽管告警类型在不同的厂商定义中不尽相同，但反映的是同一告警事件，系统把这些告警类型归属到同一个告警类型组“PORT_DOWN”，同一个告警类型组下的告警，认为是等价的。
为避免由于SYSLOG日志缺失或解析规则不完整造成的端口DOWN告警不准确，系统采用了端口状态Polling作为辅助手段，对端口状态事件进行监控，但与SYSLOG告警进行了关联处理。具体策略：
a、PORT_DOWN告警类型组下的所有告警类型，可以互相清除，即对于同一个端口，某个告警类型的恢复告警，可以清除其它PORT_DOWN告警。
b、上来某条端口down告警时，但活动库中已经存在该端口的其它PORT_DOWN告警，则该端口down告警直接入历史库，删除类型为“等价告警剔重”。
c、当活动库中存在某个端口的PORT_DOWN告警，而端口状态Polling检测到该端口的操作状态为up时，则发送端口状态恢复告警，用于清除该端口的所有PORT_DOWN告警。
目前PORT_DOWN告警类型组包括的告警类型：
告警类型
来源说明
端口状态
端口状态Polling
LINK-3-UPDOWN
SYSLOG
LINEPROTO-5-UPDOWN
SYSLOG
LINK_DOWN
SYSLOG
LINK-SP-3-UPDOWN
SYSLOG
PKT_INFRA-LINK-3-UPDOWN
SYSLOG
PKT_INFRA-LINEPROTO-5-UPDOWN
SYSLOG
IFNET/4/LINK UPDOWN
SYSLOG
PHY/4/PHY_STATUS_UP2DWN
SYSLOG
PKT_INFRA-LINK-5-CHANGED
SYSLOG
L2INF/5/PORT LINK STATUS CHANGE
SYSLOG
……
每个现场的配置有所不同