网管系统告警产生和处理机制
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.254.190 告警类型：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 告警数据处理流程
告警从采集，到入活动库，最后进入历史库，这个过程称为告警的生命周期。采集为始，入历史库为终。从始到终，其数据流程如下图所示：
主动检测告警：设备PING， 端口Polling，性能告警，资SYSLOG TRAP 源告警，拨测告警等 JMS消息活动库 未过滤 告警接收解析翻译 服务 Socket服务 封装告警 未过滤 过滤 告警验证 未通过 各种规则时间窗口处理 过滤 丢弃 预处理 告警风暴处理 原始告警 库 通过 是 否 告警重资源关联 定义 AlarmOperator 流程说明： 1、 收到的所有SYSLOG和TRAP告警都进行记录。
2、 只有SYSLOG和TRAP告警需要经过RULES解析和翻译环节，其它告警来源无此过程。 3、 被RULES过滤掉的SYSLOG和TRAP告警直接丢弃，而非进入历史库，SYSLOG和
TRAP告警在原始库中可以找到（TRAP原始报文默认不入库，如果要入库，需要打开进程参数）。
4、 告警先进行重定义，在进行预处理规则过滤，被预处理过滤的告警，直接进入历史库（也
可以选择直接丢弃），对应的删除类型为“预处理删除”；没有过滤的告警入活动库，同时发布JMS消息。
5、 告警是排队入库的，每次从入库队列中取一定数量的告警依次入库。分为三种情况：
（1） 如果活动库中存在相同的告警事件（告警源和事件相同），则进行告警更新（更
新发生次数和发生时间）；
（2） 如果活动库中不存在相同的告警事件，则插入一条新的活动告警记录； （3） 如果告警为恢复告警，则将活动库中对应的告警事件清除，进入历史库。 6、 活动库的告警被删除后，进入历史库。这里的删除有以下几种情况
（1） 界面手工删除
恢复 历史库 丢弃
(完整版)网管系统告警产生和处理机制
