CN112671560B - 一种高可用的分布式实时告警处理方法及系统 - Google Patents

Abstract

本发明公开了一种高可用的分布式实时告警处理方法及系统，包括采集网元、网管推送的告警事件并将其发送至消息队列；将所述告警事件进行标准格式化处理，转化成相同的数据格式；对所述标准化后的告警事件进行分析，生成最总的可执行的处理规则；利用分布式延时队列统一所有告警的顺序，实现对所述告警事件的处理。对实时告警处理进行分层，将告警接收和告警处理过程分开，将告警的接收能力最大化，能更好的应对瞬间出现的大量告警，使得告警消息被接收而不丢失；采用高吞吐量的分布式持久化消息队列，使告警能够可靠的保存和缓冲。

Description

一种高可用的分布式实时告警处理方法及系统

技术领域

本发明涉及通信网络告警的技术领域，尤其涉及一种高可用的分布式实时告警处理方法及系统。

背景技术

通信网络设备量大，设备间通过物理链路和逻辑链路相连。网络一个设备、板卡、端口和连接线的故障，引发一连串的连锁反应，导致”告警风暴”的产生，给综合告警监控带来了很大的处理压力，如果处理不当将导致告警的丢失，或造成服务器过载导致系统奔溃。同时，综合告警监控需要满足7*24小时不间断的工作方式，这就要求系统不应该存在单点故障，且满足极具伸缩的处理能力。本方案以开源kafka分布式消息队列为基础，实现”风暴告警”的及时接收和缓冲，在此基础上，提供了一个完整的告警事件实时处理架构。该框架利用kafka每天千亿级的消息处理量，PB级的数据处理能力，同时利用队列消费者的线性扩展能力，而根据业务的需要，通过扩展队列及消费者的数量，来满足任意规模的告警监控业务场景。

发明内容

本部分的目的在于概述本发明的实施例的一些方面以及简要介绍一些较佳实施例。在本部分以及本申请的说明书摘要和发明名称中可能会做些简化或省略以避免使本部分、说明书摘要和发明名称的目的模糊，而这种简化或省略不能用于限制本发明的范围。

鉴于上述现有告警采集处理过程存在的问题，提出了本发明。

因此，本发明解决的技术问题是：一旦出现瞬间出现大量的告警事件，可能会导致告警信息的丢失，或导致采集机的系统奔溃；采集机服务器的计算资源没法有效的共享。

为解决上述技术问题，本发明提供如下技术方案：采集网元、网管推送的告警事件并将其发送至消息队列；将所述告警事件进行标准格式化处理，转化成相同的数据格式；对所述标准化后的告警事件进行分析，生成可执行的处理规则；利用分布式延时队列统一所有告警的顺序，实现对所述告警事件的处理。

作为本发明所述的高可用的分布式实时告警处理方法的一种优选方案，其中：所述将告警事件进行标准格式化处理包括，由于不同厂商、不同网管告警格式不同，为保证告警的后续统一处理，需要对告警进行标准化处理，将相同属性采用相同的定义，通用的告警属性包括有所属专业、所属网管、所属厂商、告警网元IP、告警网元名称、告警网元编号、告警板卡、端口及告警级别、告警类型、告警详情描述、发送时间、恢复状态。

作为本发明所述的高可用的分布式实时告警处理方法的一种优选方案，其中：所述对标准化后的告警事件的自动处理规则进行分析包括，所述分析包括对告警与资源的关联关系分析以及根告警分析，所述对告警与资源的关联关系分析为根据从网元、网管中接收的信息，查找资源对象的内部编号，将告警与内部资源对象相联系；所述根告警分析是指分析告警之间的依赖关系，根据告警的产生原因分出根告警和衍生告警，建立完整的告警依赖关系。

作为本发明所述的高可用的分布式实时告警处理方法的一种优选方案，其中：所述采用分布式延时队列统一所有告警的顺序包括，所述分布式延时队列采用时间轮在接收到新的告警时进行延时，在延时期间新告警的到来会根据所述告警依赖关系触发相关告警的关联分析，若所述相关告警为本告警引起，则所述新的告警信息为上级告警，否则为下级衍生告警，在时间t内，所述新的告警没有相应的触发他的上级告警，才会被确认为根告警。

作为本发明所述的高可用的分布式实时告警处理方法的一种优选方案，其中：所述时间轮包括，所述时间轮是一个存储定时任务的环形队列，底层采用数组，所述数组中的每个元素存放一个定时任务列表，所述定时任务列表是一个环形的双向链表，链表中的每一项表示的都是定时任务项，其中封装了真正的定时任务，所述定时任务队列按照延时量进行排序，将最先发生的任务排在队列的前面，使得每次的告警处理判断只对所述上级告警进行处理，降低延时任务的复杂度。

作为本发明所述的高可用的分布式实时告警处理方法的一种优选方案，其中：所述延时队列还包括，有些告警类型的告警发生是独立的，因此可以直接被认定为根告警，在这种情况下，将设置延时设置为0秒，进行立即处理。

作为本发明所述的高可用的分布式实时告警处理系统的一种优选方案，其中：采集接入层用于对接厂商网管、网元的各种告警通知接口，进行告警信息的采集，并将采集到的告警信息传输至分布式消息列队模块；告警标准化模块连接于所述分布式消息列队模块，对所述采集到的告警信息进行标准化处理，将相同属性使用相同的定义，便于进行统一的分析和处理，并将标准化处理后的告警信息再传输至所述分布式消息列队模块；告警分析模块连接于所述分布式消息列队模块，对所述标准化处理后的告警信息进行告警关联分析、类型标准化分析、根告警分析以及告警处理规则分析，将所述告警信息划分为根告警和衍生告警，并对所述各个告警信息的处理规则解析、合并的分析，并将分析传输至所述分布式消息列队模块；告警延时处理模块与所述分布式消息列队模块相连接，对所述告警信息进行衍生告警和根告警的判断，根据所述告警处理规则分析的分析结果进行规则执行；分布式消息列队模块与所述采集接入层、告警标准化模块、告警分析模块和告警延时处理模块相连接，用于传输和存储所述采集接入层、告警标准化模块和告警分析模块之间的信息，以及对所述告警分析模块和告警延时处理模块之间的告警信息进行延时处理，以找出所述根告警。

作为本发明所述的高可用的分布式实时告警处理系统的一种优选方案，其中：所述告警分析模块包括，告警与资源的关联关系分析单元用于建立告警与系统内部资源对象之间的对应关系；告警类型标准化单元连接于所述告警与资源的关联关系分析单元，根据厂商的接口协议对所述告警信息进行告警字段的标准化；根告警分析单元连接于所述告警类型标准化单元，分析所述告警信息之间的依赖关系，划分根源告警和衍生告警；告警处理规则分析单元连接于所述根告警分析单元，用于对告警处理规则进行解析、合并。

作为本发明所述的高可用的分布式实时告警处理系统的一种优选方案，其中：所述分布式消息列队模块包括，消息列队单元与所述采集接入层、告警标准化模块、告警分析模块相连接，用于传输和存储各个模块之间告警信息；消息队列延时模块与所述告警分析模块和告警延时处理模块相连接，所述消息队列延时模块接收所述告警分析模块的新告警信息并进行延时，在延时期间内所述告警延时处理模块进行告警信息是否为根告警的判断，找出所述根告警信息，进行规则处理。

本发明的有益效果：对实时告警处理进行分层，将告警接收和告警处理过程分开，将告警的接收能力最大化，能更好的应对瞬间出现的大量告警，使得告警消息被接收而不丢失；采用高吞吐量的分布式持久化消息队列，使告警能够可靠的保存和缓冲；采用共享消费者组机制，实现了队列任务处理实例的容错和并发，通过最大并发数量的控制，提高了系统处理能力的可伸缩性，同时也限定了服务器资源的申请上限，保证了在大量告警到来时，服务器能够有序的按照一定的处理能力顺序处理，而不会造成系统因资源有限而导致的奔溃。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。其中：

图1为本发明第一个实施例所述的高可用的分布式实时告警处理方法的流程示意图；

图2为本发明第一个实施例所述的高可用的分布式实时告警处理方法分析过程框架图；

图3为本发明第二个实施例所述的高可用的分布式实时告警处理系统的流程示意图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合说明书附图对本发明的具体实施方式做详细的说明，显然所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明的保护的范围。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其他不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施例的限制。

其次，此处所称的“一个实施例”或“实施例”是指可包含于本发明至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例，也不是单独的或选择性的与其他实施例互相排斥的实施例。

本发明结合示意图进行详细描述，在详述本发明实施例时，为便于说明，表示器件结构的剖面图会不依一般比例作局部放大，而且所述示意图只是示例，其在此不应限制本发明保护的范围。此外，在实际制作中应包含长度、宽度及深度的三维空间尺寸。

同时在本发明的描述中，需要说明的是，术语中的“上、下、内和外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一、第二或第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

本发明中除非另有明确的规定和限定，术语“安装、相连、连接”应做广义理解，例如：可以是固定连接、可拆卸连接或一体式连接；同样可以是机械连接、电连接或直接连接，也可以通过中间媒介间接相连，也可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本发明中的具体含义。

实施例1

参照图1～2，为本发明的第一个实施例，该实施例提供了一种高可用的分布式实时告警处理方法，包括：

S1：采集网元、网管推送的告警事件并将其发送至消息队列。其中需要说明的是，

通过与网元、网管对接，适配网元网管的接口协议，接收到网元、网管推送过来的告警事件，将其转换为消息队列可接收的格式，发送到消息队列，不对告警信息进行处理，这样可以使采集接入有极大的吞吐量，确保不会因处理不及时而丢失告警。

进一步的是，采集对接厂商网管、网元的告警通知接口协议、常用的告警通知接口协议有SNMP TRAP、SYSLOG、CORBA EVENT CHANNEL、TCP/IP SOCKET、HTTP/HTTPS、WEBSERVICE等各种接口协议，这些协议主要分两大类被动告警接收协议和主动告警接收协议，被动告警接收协议如SNMP TRAP和SYSLOG协议就是这种情况，主动接收协议的典型例子是CORBA EVENT CHANNEL。

其中被动接收协议需要采集接入层启动相应server服务，将该server的IP地址和接收端口号，配置在网元或网管上，网元网元发生告警时，会自动通过该地址将告警推送过来，采集接入层被动的等待接收告警即可，被动接收方式下，需要采集接入层对外提供一个公开的IP地址和端口号，该IP地址和端口号不会因为服务器硬件故障而失效，所在这种方式下，双机热备的虚拟浮动IP是一个理想的选择,该浮动IP保证了主用服务器出现故障时，备用服务器立即接管该浮动IP，持续的接收实时告警，保证了采集接入的高可用性。

主动接收协议是采集接入层主动发起连接到网元、网管，建立起事件通道，如CORBA的EVENT CHANNEL，这种方式下，网元、网管上无需做设置，采集接入程序启动后根据网元、网管的接口协议，主动发起连接，建立事件通道，在网元、或网管有告警时，通过该通道将告警推动过来，通常该程序只能在几台服务器上运行一个实例，过多的实例将会导致告警的重复接收，为保证主动接收协议的接口程序的正常运行，不会因硬件故障而停止，需要采用双机或多机单实例的运行方式，多机单实例的设计模式，需要群集消息组软件如zookeeper，或jgroups等软件的支持。

S2：将告警事件进行标准格式化处理，转化成相同的数据格式。其中需要说明的是，

将告警事件进行标准格式化处理包括，由于不同厂商、不同网管告警格式不同，为保证告警的后续统一处理，需要对告警进行标准化处理，将相同属性采用相同的定义，通用的告警属性包括有所属专业、所属网管、所属厂商、告警网元IP、告警网元名称、告警网元编号、告警板卡、端口及告警级别、告警类型、告警详情描述、发送时间、恢复状态等属性，专业和网管不同告警可能会有其它属性。

S3：对标准化后的告警事件进行分析，生成可执行的处理规则。其中需要说明的是，

对标准化后的告警事件的自动处理规则进行分析包括，分析包括对告警与资源的关联关系分析以及根告警分析，对告警与资源的关联关系分析为根据从网元、网管中接收的信息，查找资源对象的内部编号，将告警与内部资源对象相联系；根告警分析是指分析告警之间的依赖关系，根据告警的产生原因分出根告警和衍生告警，建立完整的告警依赖关系。

进一步的是，告警分析还包括告警类型标准化以及自动处理规则分析，其中告警类型标准化虑到厂商告警类型种类繁多，和标准告警之间的对应关系需要不断的进行完善，通常有相应的配置界面来进行对应关系的管理,这些配置结果保存在数据库中，而告警标准化只是根据厂商的接口协议进行告警字段的标准化，不需要连接数据库，而且不同厂商、不同网管的标准化处理程序不一致，便于统一的进行类型标准化的处理；告警处理规则分析是对告警处理规则进行解析、合并的过程，为了支持灵活的告警处理规则的不断完善，我们将处理规则的配置抽取出来，通过人工配置界面来实现，随着系统使用，维护人员的经验也通过系统不断的积累，通过手动处理的工作，可以通过处理规则的配置自动实现，处理规则也将越来越多，这些处理规则可能存在重叠的情况，比如自动派单规则，可能在多个匹配的规则中出现，我们不可能对一个告警进行多次派单，只能派发一次，这就需要对处理规则进行解析、合并，告警处理规则是告警人工处理的自动实现，一般会包含人工在操作界面的大部分处理功能，常用的功能有告警自动屏蔽、告警级别重置、告警自动确认、告警短信、邮件通知、自动派单、自动北向接口发送等，告警自动屏蔽、告警级别重置、告警自动确认这些比较明确、与是否根告警无关的处理动作可立即执行。

S4：利用分布式延时队列统一所有告警的顺序，实现对告警事件的处理。其中需要说明的是，

采用分布式延时队列统一所有告警的顺序包括，以网元编号为单位建立partition分区，实现同一网元的告警能够被同一个消费者实例顺序处理，而不出现极端情况下出来，告警及对应的恢复告警因采用不同的线程或服务器处理而操作的时序错乱；分布式延时队列采用时间轮在接收到新的告警时进行延时，在延时期间新告警的到来会根据告警依赖关系触发相关告警的关联分析，若相关告警为本告警引起，则新的告警信息为上级告警，否则为下级衍生告警，在时间t内，新的告警没有相应的触发他的上级告警，才会被确认为根告警。

进一步的是，时间轮是一个存储定时任务的环形队列，底层采用数组，数组中的每个元素存放一个定时任务列表，定时任务列表是一个环形的双向链表，链表中的每一项表示的都是定时任务项，其中封装了真正的定时任务，定时任务队列按照延时量进行排序，将最先发生的任务排在队列的前面，使得每次的告警处理判断只对上级告警进行处理，降低延时任务的复杂度；并且有些告警类型的告警发生是独立的，因此可以直接被认定为根告警，在这种情况下，将设置延时设置为0秒，进行立即处理。

为了更好地对本发明方法中采用的技术效果加以验证说明，本实施例中选择大量告警信息进行测试，以科学论证的手段对比试验结果，以验证本方法所具有的真实效果；

传统方法将告警采集处理过程分布在各个采集机上，在接收到告警时，就立即进行处理，通常是先估算各个网元或网管的告警事件的数据量，来确定采集处理能力，但是一旦瞬间出现大量的告警事件，可能会导致告警信息的丢失，或导致采集机的系统奔溃；采集机服务器的计算资源没法有效的共享。

采用多台采集器、网元、网管设备、告警信息发送设备以及相应的处理器进行测试，对实时告警信息的处理进行模拟，其中分5组不同数量的告警信息，其数量分别为10、50、100、500、1000条，本方法将告警事件发送至消息队列，并进行标准格式化处理，转化成相同的数据格式，对标准化后的告警事件进行分析，生成最总的可执行的处理规则，利用分布式延时队列统一所有告警的顺序，找出根告警，对根告警进行处理，而传统方法针对告警数件的数量确定采集处理的能力，以两种方法的处理时间作为测试标准，其结果如下表1所示：

表1：两种方法测试时间。

告警数量	10	50	100	500	1000
						传统方法	42ms	83ms	146ms	233ms	287ms
本方法	43ms	79ms	126ms	215ms	270ms

可以看出本方法与传统方法在进行告警处理时，本方法所耗时间比传统方法要少一些，但是在处理告警信息时，在告警数量100的条件下，在同一时间内向两种方法输入另外500告警信息，在此情况下传统方法所耗时间为869ms而本方法的处理时间为234ms，因此在瞬间出现大量告警事件时，本发明方法处理的稳定性更高，更具实用性。

实施例2

参照图3，为本发明的第二个实施例，该实施例不同于第一个实施例的是，提供了一种高可用的分布式实时告警处理系统，包括：采集接入层100、告警标准化模块200、告警分析模块300、告警延时处理模块400和分布式消息列队模块500，其中采集接入层100用于对接厂商网管、网元的各种告警通知接口，进行告警信息的采集，并将采集到的告警信息传输至分布式消息列队模块500；告警标准化模块200连接于分布式消息列队模块500，对采集到的告警信息进行标准化处理，将相同属性使用相同的定义，便于进行统一的分析和处理，并将标准化处理后的告警信息再传输至分布式消息列队模块500；告警分析模块300连接于分布式消息列队模块500，对标准化处理后的告警信息进行告警关联分析、类型标准化分析、根告警分析以及告警处理规则分析，将告警信息划分为根告警和衍生告警，并对各个告警信息的处理规则解析、合并的分析，并将分析传输至分布式消息列队模块500；告警延时处理模块400与分布式消息列队模块500相连接，对告警信息进行衍生告警和根告警的判断，根据告警处理规则分析的分析结果进行规则执行；分布式消息列队模块500与采集接入层100、告警标准化模块200、告警分析模块300和告警延时处理模块400相连接，用于传输和存储采集接入层100、告警标准化模块200和告警分析模块300之间的信息，以及对告警分析模块300和告警延时处理模块400之间的告警信息进行延时处理，以找出根告警。

进一步的是，告警分析模块300包括，告警与资源的关联关系分析单元301用于建立告警与系统内部资源对象之间的对应关系；告警类型标准化单元302连接于告警与资源的关联关系分析单元301，根据厂商的接口协议对告警信息进行告警字段的标准化；根告警分析单元303连接于告警类型标准化单元302，分析告警信息之间的依赖关系，划分根源告警和衍生告警；告警处理规则分析单元304连接于根告警分析单元303，用于对告警处理规则进行解析、合并。

告警延时处理模块400首先判断当前告警是根告警或衍生告警，如果是衍生告警，将其忽略，不做处理，如果是根告警则进行自动处理，处理时，根据告警分析模块300合并的处理规则执行，比如发送短信时，根据告警分析层提供的短信模板创建短信内容，根据告警分析模块300合并的短信发送对象列表发送短信，若接收到的告警信息是已延时的告警或延时时间为0秒的告警时，则直接进行处理，无须延时操作。

分布式消息列队模块500包括，消息列队单元501与采集接入层100、告警标准化模块200、告警分析模块300相连接，用于传输和存储各个模块之间告警信息；消息队列延时模块502与告警分析模块300和告警延时处理模块400相连接，消息队列延时模块502接收告警分析模块300的新告警信息并进行延时，在延时期间内告警延时处理模块400进行告警信息是否为根告警的判断，找出根告警信息，进行规则处理。

不难理解的是，本实施例中所提供的系统，其涉及采集接入层100、告警标准化模块200、告警分析模块300、告警延时处理模块400和分布式消息列队模块500，例如可以是运行在计算机可读程序，通过提高各模块的程序数据接口实现。

应当认识到，本发明的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性计算机可读存储器中的计算机指令来实现或实施。方法可以使用标准编程技术-包括配置有计算机程序的非暂时性计算机可读存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作——根据在具体实施例中描述的方法和附图。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。

此外，可按任何合适的顺序来执行本文描述的过程的操作，除非本文另外指示或以其他方式明显地与上下文矛盾。本文描述的过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机系统的控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本发明的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文步骤的指令或程序时，本文的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本发明的方法和技术编程时，本发明还包括计算机本身。计算机程序能够应用于输入数据以执行本文的功能，从而转换输入数据以生成存储至非易失性存储器的输出数据。输出信息还可以应用于一个或多个输出设备如显示器。在本发明优选的实施例中，转换的数据表示物理和有形的对象，包括显示器上产生的物理和有形对象的特定视觉描绘。

如在本申请所使用的，术语“组件”、“模块”、“系统”等等旨在指代计算机相关实体，该计算机相关实体可以是硬件、固件、硬件和软件的结合、软件或者运行中的软件。例如，组件可以是，但不限于是：在处理器上运行的处理、处理器、对象、可执行文件、执行中的线程、程序和/或计算机。作为示例，在计算设备上运行的应用和该计算设备都可以是组件。一个或多个组件可以存在于执行中的过程和/或线程中，并且组件可以位于一个计算机中以及/或者分布在两个或更多个计算机之间。此外，这些组件能够从在其上具有各种数据结构的各种计算机可读介质中执行。这些组件可以通过诸如根据具有一个或多个数据分组(例如，来自一个组件的数据，该组件与本地系统、分布式系统中的另一个组件进行交互和/或以信号的方式通过诸如互联网之类的网络与其它系统进行交互)的信号，以本地和/或远程过程的方式进行通信。

应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。

Claims (4)

1.一种高可用的分布式实时告警处理方法，其特征在于：包括，

采集网元、网管推送的告警事件并将其发送至消息队列；

将所述告警事件进行标准格式化处理，转化成相同的数据格式；

对所述标准化后的告警事件进行分析，生成可执行的处理规则；

利用分布式延时队列统一所有告警的顺序，实现对所述告警事件的处理；

所述将所述告警事件进行标准格式化处理包括，

由于不同厂商、不同网管告警格式不同，为保证告警的后续统一处理，需要对告警进行标准化处理，将相同属性采用相同的定义，通用的告警属性包括有所属专业、所属网管、所属厂商、告警网元IP、告警网元名称、告警网元编号、告警板卡、端口及告警级别、告警类型、告警详情描述、发送时间、恢复状态；

对标准化后的告警事件的自动处理规则进行分析包括，

所述分析包括对告警与资源的关联关系分析以及根告警分析，所述对告警与资源的关联关系分析为根据从网元、网管中接收的信息，查找资源对象的内部编号，将告警与内部资源对象相联系；所述根告警分析是指分析告警之间的依赖关系，根据告警的产生原因分出根告警和衍生告警，建立完整的告警依赖关系；

所述利用分布式延时队列统一所有告警的顺序包括，

所述分布式延时队列采用时间轮在接收到新的告警时进行延时，在延时期间新告警的到来会根据所述告警依赖关系触发相关告警的关联分析，若所述相关告警为本告警引起，则所述新的告警信息为上级告警，否则为下级衍生告警，在时间t内，所述新的告警没有相应的触发他的上级告警，才会被确认为根告警；

所述时间轮包括，

所述时间轮是一个存储定时任务的环形队列，底层采用数组，所述数组中的每个元素存放一个定时任务列表，所述定时任务列表是一个环形的双向链表，链表中的每一项表示的都是定时任务项，其中封装了真正的定时任务，所述定时任务队列按照延时量进行排序，将最先发生的任务排在队列的前面，使得每次的告警处理判断只对所述上级告警进行处理，降低延时任务的复杂度；

所述延时队列还包括，有些告警类型的告警发生是独立的，因此可以直接被认定为根告警，在这种情况下，将设置延时设置为0秒，进行立即处理。

2.一种高可用的分布式实时告警处理系统，其特征在于：包括，

采集接入层(100)用于对接厂商网管、网元的各种告警通知接口，进行告警信息的采集，并将采集到的告警信息传输至分布式消息列队模块(500)；

告警标准化模块(200)连接于所述分布式消息列队模块(500)，对所述采集到的告警信息进行标准化处理，将相同属性使用相同的定义，便于进行统一的分析和处理，并将标准化处理后的告警信息再传输至所述分布式消息列队模块(500)；

告警分析模块(300)连接于所述分布式消息列队模块(500)，对所述标准化处理后的告警信息进行告警关联分析、类型标准化分析、根告警分析以及告警处理规则分析，将所述告警信息划分为根告警和衍生告警，并对各个告警信息的处理规则解析、合并分析，并将分析传输至所述分布式消息列队模块(500)；

告警延时处理模块(400)与所述分布式消息列队模块(500)相连接，对所述告警信息进行衍生告警和根告警的判断，根据所述告警处理规则分析的分析结果进行规则执行；

分布式消息列队模块(500)与所述采集接入层(100)、告警标准化模块(200)、告警分析模块(300)和告警延时处理模块(400)相连接，用于传输和存储所述采集接入层(100)、告警标准化模块(200)和告警分析模块(300)之间的信息，以及对所述告警分析模块(300)和告警延时处理模块(400)之间的告警信息进行延时处理，以找出所述根告警。

3.如权利要求2所述的高可用的分布式实时告警处理系统，其特征在于：所述告警分析模块(300)包括，

告警与资源的关联关系分析单元(301)用于建立告警与系统内部资源对象之间的对应关系；

告警类型标准化单元(302)连接于所述告警与资源的关联关系分析单元(301)，根据厂商的接口协议对所述告警信息进行告警字段的标准化；

根告警分析单元(303)连接于所述告警类型标准化单元(302)，分析所述告警信息之间的依赖关系，划分根源告警和衍生告警；

告警处理规则分析单元(304)连接于所述根告警分析单元(303)，用于对告警处理规则进行解析、合并。

4.如权利要求3所述的高可用的分布式实时告警处理系统，其特征在于：所述分布式消息列队模块(500)包括，

消息列队单元(501)与所述采集接入层(100)、告警标准化模块(200)、告警分析模块(300)相连接，用于传输和存储各个模块之间告警信息；

消息队列延时模块(502)与所述告警分析模块(300)和告警延时处理模块(400)相连接，所述消息队列延时模块(502)接收所述告警分析模块(300)的新告警信息并进行延时，在延时期间内所述告警延时处理模块(400)进行告警信息是否为根告警的判断，找出所述根告警信息，进行规则处理。