CN106936620B - 一种告警事件的处理方法和处理装置 - Google Patents

Abstract

本发明公开一种告警事件的处理方法和装置，该方法包括：利用主控节点接收告警源发来的告警事件；利用主控节点以及各告警事件处理节点根据接收的各告警事件的属性对告警事件进行分组，使得在各告警事件处理节点中，属于同一组的告警事件被分发给相应的一个任务进行处理；其中，每个所述告警事件处理节点中配置多个任务，多个任务并发处理告警事件。本发明的技术方案中每个告警事件处理节点都设置有多个任务，解决了现有技术中单一任务的告警处理导致的效率低、告警处理延迟的问题，同时对告警事件分组，保证了在每个告警事件处理节点中相同分组的告警事件被分发到该节点中的同一个任务，实现告警事件的处理一致性和准确性。

Description

一种告警事件的处理方法和处理装置

技术领域

本发明涉及计算机技术领域，具体涉及一种告警事件的处理方法和处理装置。

背景技术

随着互联网技术在各个领域的广泛应用，网络管理系统监控的设备和业务越来越多，每天产生的告警量越来庞大，对网管系统的告警处理能力提出了更高的要求。现有技术中网络管理系统对告警事件的每个处理环节(包括过滤、压制、相关性分析过滤、关联分析和合并)都是使用单一进程、单一任务进行处理。告警事件产生后，由于每个处理环节是单线程状态，系统会按照接收顺序依次将每条事件送入各节点：事件过滤处理完后送入事件压制处理、事件压制处理完送入相关性分析过滤处理，相关性分析过滤处理后再送入合并服务处理。

由此可知，现有技术方案至少存在如下缺陷：

1)当告警量很大时，这种告警处理方式不能及时的处理告警事件，会产生很大的延迟；

2)由于采用单一进程的模式，这些服务都存在同一个进程中，当一个告警处理环节中的进程发生故障(如宕机)后，告警处理服务随之终止，安全性能差。

发明内容

本发明提供了一种告警事件的处理方法和处理装置，以解决现有技术存在的告警事件处理延迟和安全性能差的问题。

为了达到上述目的，本发明的技术方案是这样实现的：

根据本发明的一个方面，提供了一种告警事件的处理方法，该方法包括：

利用主控节点接收告警源发来的告警事件；

利用主控节点以及各告警事件处理节点根据接收的各告警事件的属性对告警事件进行分组，使得在各告警事件处理节点中，属于同一组的告警事件被分发给相应的一个任务进行处理；其中，每个告警事件处理节点中都配置有多个任务，多个任务并发处理告警事件。

可选地，告警事件处理节点包括：

根据告警事件的处理顺序设置的告警事件过滤处理节点，告警事件压制处理节点，告警事件相关性分析过滤处理节点，告警事件关联分析处理节点和告警事件合并处理节点。

可选地，该方法还包括：根据每个告警事件处理节点的负载均衡情况，配置每个告警事件处理节点上的任务数量。

可选地，每个告警事件处理节点的多个任务均匀分布在多个服务器上；

当其中一个服务器发生故障时，则在运行正常的服务器上新建任务并将原来分配给发生故障的服务器上的任务处理的告警事件，分配给该新建的任务处理。

可选地，主控节点为单任务节点。

根据本发明的另一个方面，提供了一种与上述告警事件的处理方法相对应的一种告警事件的处理装置，该装置包括：

接收单元，用于利用主控节点接收告警源发来的告警事件；

分组处理单元，用于利用主控节点以及各告警事件处理节点根据接收的各告警事件的属性对告警事件进行分组，使得在各告警事件处理节点中，属于同一组的告警事件被分发给相应的一个任务进行处理；其中，每个告警事件处理节点中都配置有多个任务，多个任务并发处理告警事件。

可选地，分组处理单元具体用于，根据告警事件的告警标题和实例名称对告警事件进行分组，将告警标题和实例名称相同的告警事件分到同一组。

可选地，告警事件处理节点包括：

根据告警事件的处理顺序设置的告警事件过滤处理节点，告警事件压制处理节点，告警事件相关性分析处理节点和告警事件合并处理节点。

可选地，该装置进一步包括：

任务设置单元，用于根据每个告警事件处理节点的负载均衡情况，配置每个告警事件处理节点上的任务数量。

本发明的有益效果是：本发明的技术方案，通过利用主控节点和各告警事件处理节点对接收的告警事件根据告警事件的属性进行分组，并将同一组的告警事件分给相应告警事件处理节点中的相应任务处理，实现了同一实例上产生的相同类型告警由同一个任务进行处理，保证了事件处理的一致性。此外，每个告警事件处理节点上都设置有多个任务并发处理分组的告警事件，即启动多个进程和多个任务并行处理，解决了现有技术中每个环节单一任务模式处理告警事件导致的延迟问题。

附图说明

图1是本发明一个实施例的一种告警事件的处理方法的流程示意图；

图2是本发明另一个实施例的告警事件处理的Storm拓扑图；

图3是本发明一个实施例的一种告警事件的处理装置的框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1是本发明一个实施例的一种告警事件的处理方法的流程示意图，参见图1，该方法包括：

步骤S11，利用主控节点接收告警源发来的告警事件；

步骤S12，利用主控节点以及各告警事件处理节点根据接收的各告警事件的属性对告警事件进行分组，使得在各告警事件处理节点中，属于同一组的告警事件被分发给相应的一个任务进行处理；其中，每个告警事件处理节点中都配置有多个任务，多个任务并发处理告警事件。

经过图1所示的方法，对接收的告警事件进行分组，将相同类型的事件送入同一个任务进行处理，保证了告警事件处理的一致性。另外，告警事件的每一个处理环节都是多任务的，即启动多个进程和多个任务并行处理告警事件，如此，提高了告警事件的处理效率，避免了延迟。

以下结合一个具体的应用场景对本实施例的这种告警事件的处理方法的实现步骤进行说明。

本实施例中将这种告警事件的处理方法应用于网络管理系统中，该网络管理系统采用实时数据处理技术Storm来对告警事件进行处理。Storm是个实时的、分布式以及具备高容错的计算系统，在保证高可靠性的前提下还可以让事件处理进行的更加实时，具备容错和分布计算这些特性，使得Storm可以扩展到不同的机器上进行大批量的数据处理。Storm集群主要由一个主节点和一群工作节点组成，各工作节点通过Zookeeper进行协调。

图2是本发明另一个实施例的告警事件处理的Storm拓扑图，参见图2，拓扑topology是一组由Spouts(数据源)和Bolts(数据操作)通过Stream Groupings(数据流分发流向)进行连接的图。

图2中包括：主控节点(EventSpout)21，还包括：根据告警事件的处理顺序设置的告警事件过滤处理节点(EventFilterBolt)22，表示告警事件压制处理节点(EventSuppressBolt)23，告警事件相关性分析过滤处理节点(ECSchemeBolt)24，告警事件关联分析处理节点(EventAnalysBolt)25，告警事件合并处理节点26以及数据存储入库(EventDBServer)27。

结合图2，告警事件具体的处理流程描述如下：

1)由主控节点EventSpout负责接收来自告警源的告警事件，此任务是单一任务模式，即在EventSpout节点中启动一个任务负责接收所有的告警事件，这样设置的目的是为了保证接收的告警事件的顺序不会发生错乱。具体的告警源可以是网管系统监控的设备或业务，如某一个监控主机。

2)EventSpount接收到告警事件后，对各告警事件根据属性进行分组，本实施例中，EventSpount是根据告警事件的告警标题和实例名称进行分组的(即分组名＝告警标题+实例名称)，然后根据分组名将告警事件分发到告警事件过滤处理节点EventFilterBolt。

其中，告警标题可以是事件类型，实例名称是一个具体的对象，如：一个主机上的文件系统名称或者该主机的唯一标识ID。例如，这里的分组名可以是：CPU告警+主机1、内存告警+主机1。可以理解，主控节点实时接收大量的告警事件，对每个告警事件都按照告警标题加上实例名称这样的分组规则进行分组。

3)告警事件过滤处理节点EventFilterBolt接收到告警事件后，对告警事件过滤，一般的，这里的告警事件为同一组的多个告警事件，将这同一组告警事件分发给本节点中之前处理过该组告警事件的那个任务(如果有的话)处理，即相应的一个任务可以理解为一个指定的任务，每次收到该组的告警事件后，将告警事件分发给该指定的任务处理，而不是分发给其他任务。

事件过滤处理过程包括：将告警事件与网管系统中预先配置的事件过滤规则进行匹配，如果该告警事件与事件过滤规则不匹配，则将告警事件根据告警标题+实例名称进行分组，根据分组名将告警事件分发到告警事件压制节点EventSuppressBolt；如果告警事件匹配了过滤规则，则将告警事件发送给EventDBServer，由EventDBServer任务负责入库，不再向下分发。

需要说明的是，如果一个告警事件与预设的过滤规则相匹配，则说明该告警事件是需要被过滤掉的，而不需要继续后面的处理。另外，告警事件过滤处理节点也需要对收到的告警事件进行分组，以保证属于同一实例的告警事件会被分发到同一个任务中处理。

4)告警事件压制处理节点EventSuppressBolt接收到告警事件后，对告警事件进行压制，告警事件压制处理过程包括：将告警事件与网管系统中预先配置的事件压制规则进行匹配，如果告警事件匹配了压制规则，告警事件会送入压制服务任务中进行一段时间的压制，在压制期间，如果没有恢复事件产生，则将告警事件根据告警标题+实例名称进行分组，根据分组名再将事件分发到告警事件相关性分析过滤节点ECSchemeBolt；如果压制期间产生恢复事件，告警事件仅需要入库，不再向相关性分析服务传递；需要说明的是，这里的告警事件和恢复事件是相对的，有的告警事件可以自动恢复，比如一个网络设备的端口down事件产生时，接下来会有一个端口up事件产生，这个up事件对应down事件就是恢复事件。

如果告警事件没有匹配压制规则，也将告警事件根据告警标题+实例名称进行分组，根据分组名将告警事件分发到告警事件相关性分析过滤节点ECSchemeBolt；

5)告警事件相关性分析过滤节点ECSchemeBolt接收告警事件后，对告警事件进行相关性分析过滤，告警事件相关性分析过滤处理过程包括：将告警事件与相关性分析的过滤规则进行匹配，如果告警事件匹配相关性分析过滤规则，将告警事件送入相关性分析节点EventAnalyseBolt；如果告警事件没有匹配相关性分析过滤规则，则将告警事件根据告警标题+实例名称进行分组，根据分组名将告警事件分到告警事件合并节点BuildAlertBolt；

6)告警事件相关性分析节点EventAnalyseBolt对接收到的告警事件进行关联分析处理，然后将分析产生的结果事件根据告警标题+实例名称进行分组，根据分组名将结果事件分发到告警事件合并节点BuildAlertBolt；

7)告警事件合并节点BuildAlertBolt收到告警事件后，根据告警标题+实例名称对告警事件进行合并。如果告警事件的告警级别是非清除级别，对已经存在的告警进行更新；如果告警事件的告警级别是清除级别，则对已经存的告警进行清除，这样当一个告警事件自动恢复的时候，网管系统会自动将告警事件清除，不需要人工去手动清除，提高了效率，节省了人工。

需要强调的是，在本实施例中，每个告警事件处理环节中都配置多个任务进行并发处理分组的告警事件，比如：针对告警事件过滤环节，系统配置有12个并发处理任务；而主控节点接收到的告警事件的数量为1万件，则可以先将这1万件告警事件进行分组，如分组后为600组，然后将600组告警事件均匀分配给这12个任务。并且，多个任务可以均匀的分布不同的worker(即承担一定任务量的进程)中，如：系统配置了3个worker，那么每个worker可以启动4个告警事件过滤处理任务，这样保证完成告警事件过滤环节设定的12个任务。在本发明的另一个实施例中，每个Worker可以运行在不同的服务器中，比如：前述3个worker可以在3台服务器运行，这样当其中一个服务器发生故障后，系统可以在其它两台服务器上再启动一个Worker，接管宕掉的那个worker，如此提高了系统的安全性。

此外，为了保证相同实例上的相同类型的告警事件由同一个任务进行处理，系统会根据告警事件的告警标题+实例名称进行分组，相同的分组名会被送入同一个任务进行处理。例如，主控节点接收到3个告警事件，这3个告警事件的告警标题加实例名称都是CPU告警+主机1，也就是说，主机1的CPU告警了3次，这时，主控节点将这3个告警事件按照分组规则分组后送入告警事件过滤处理节点，告警事件过滤处理节点接收到这一组的告警事件后，会在自己的多个任务中寻找之前处理过分组名为CPU告警+主机1的那个任务，如任务一，并将新接收到的这一组的告警事件分发给任务一，以后每次接收到分组名为CPU告警+主机1的告警事件，告警事件过滤处理节点都会把这组告警事件分给任务一，以此保证告警事件处理的一致性和准确性。另外，如果告警事件过滤处理节点查找之后发现没有处理过该分组的任务，则新指定一个任务，后续分发给该新指定的任务。

图3是本发明一个实施例的一种告警事件的处理装置的框图，参见图3，该告警事件的处理装置30包括：

接收单元301，用于利用主控节点接收告警源发来的告警事件；

分组处理单元302，用于利用主控节点以及各告警事件处理节点根据接收的各告警事件的属性对告警事件进行分组，使得在各告警事件处理节点中属于同一组的告警事件被分发给相应的一个任务进行处理；其中，每个告警事件处理节点中都配置有多个任务，多个任务并发处理告警事件。

实际应用时，可以在网络管理系统的主控节点上设置接收单元，而在网络管理系统的主控节点以及各个告警事件处理节点上设置分组处理单元。

在本实施例中，分组处理单元302具体用于，根据所述告警事件的告警标题和实例名称对告警事件进行分组，将告警标题和实例名称相同的告警事件分到同一组。

在本实施例中，告警事件处理节点包括：根据告警事件的处理顺序设置的告警事件过滤处理节点，告警事件压制处理节点，告警事件相关性分析处理节点和告警事件合并处理节点。

在本实施例中，该装置30进一步包括：任务设置单元，用于根据每个告警事件处理节点的负载均衡情况，配置每个告警事件处理节点上的任务数量。

需要说明的是，本实施例中的这种告警事件的处理装置的工作过程是和前述告警事件的处理方法的步骤相对应的，因此，本实施例的告警事件的处理装置的具体工作过程可以参见前述告警事件的处理方法部分的相关说明，在此不再赘述。

综上可知，本发明的技术方案，通过对接收的告警事件根据告警事件的属性进行分组，并将同一组的告警事件分给相应告警事件处理节点中的相应任务处理，实现了同一实例上产生的相同类型告警由同一个任务进行处理的效果，保证了事件处理的一致性。此外，每个告警事件处理节点上都设置有多个任务并发处理分组的告警事件，采用多个进程和多个任务，解决了现有技术中每个环节单一任务模式处理告警事件导致的延迟问题。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (9)

1.一种告警事件的处理方法，其特征在于，该方法包括：

利用主控节点接收告警源发来的告警事件；

利用主控节点以及各告警事件处理节点根据接收的各告警事件的属性对告警事件进行分组，使得在各告警事件处理节点中，属于同一组的告警事件被分发给相应的一个任务进行处理；

其中，每个所述告警事件处理节点中都配置有多个任务，多个任务并发处理告警事件；

所述主控节点为单任务节点；

所述告警事件处理节点包括：告警事件过滤处理节点；

所述告警事件过滤处理节点将告警事件与预先配置的事件过滤规则进行匹配，如果不匹配，则将所述告警事件进行分组，根据分组名称将所述告警事件分发到告警事件压制处理节点；如果匹配，则将所述告警事件发送给数据存储入库节点，由数据存储入库节点负责入库。

2.根据权利要求1所述的方法，其特征在于，所述根据所述告警事件的属性对告警事件进行分组包括：

根据所述告警事件的告警标题和实例名称对告警事件进行分组，将告警标题和实例名称相同的告警事件分到同一组。

3.根据权利要求1或2所述的方法，其特征在于，所述告警事件处理节点包括：

根据告警事件的处理顺序设置的告警事件过滤处理节点，告警事件压制处理节点，告警事件相关性分析过滤处理节点，告警事件关联分析处理节点和告警事件合并处理节点。

4.根据权利要求1所述的方法，其特征在于，该方法还包括：

根据每个告警事件处理节点的负载均衡情况，配置每个告警事件处理节点上的任务数量。

5.根据权利要求1所述的方法，其特征在于，每个所述告警事件处理节点的多个任务均匀分布在多个服务器上；

当其中一个服务器发生故障时，则在运行正常的服务器上新建任务并将原来分配给发生故障的服务器上的任务处理的告警事件，分配给该新建的任务处理。

6.一种告警事件的处理装置，其特征在于，该装置包括：

接收单元，用于利用主控节点接收告警源发来的告警事件；

分组处理单元，用于利用主控节点以及各告警事件处理节点根据接收的各告警事件的属性对告警事件进行分组，使得在各告警事件处理节点中，属于同一组的告警事件被分发给相应的一个任务进行处理；其中，每个所述告警事件处理节点中都配置有多个任务，多个任务并发处理告警事件；所述主控节点为单任务节点；

所述告警事件处理节点包括：告警事件过滤处理节点；

所述告警事件过滤处理节点将告警事件与预先配置的事件过滤规则进行匹配，如果不匹配，则将所述告警事件进行分组，根据分组名称将所述告警事件分发到告警事件压制处理节点；如果匹配，则将所述告警事件发送给数据存储入库节点，由数据存储入库节点负责入库。

7.根据权利要求6所述的装置，其特征在于，

所述分组处理单元具体用于，根据所述告警事件的告警标题和实例名称对告警事件进行分组，将告警标题和实例名称相同的告警事件分到同一组。

8.根据权利要求6或7所述的装置，其特征在于，所述告警事件处理节点包括：

根据告警事件的处理顺序设置的告警事件过滤处理节点，告警事件压制处理节点，告警事件相关性分析处理节点和告警事件合并处理节点。

9.根据权利要求8所述的装置，其特征在于，该装置进一步包括：

任务设置单元，用于根据每个告警事件处理节点的负载均衡情况，配置每个告警事件处理节点上的任务数量。

Images