CN101651576A

CN101651576A - 告警信息处理方法和***

Info

Publication number: CN101651576A
Application number: CN200910091829A
Authority: CN
Inventors: 聂华; 邵宗有; 历军; 刘润峰; 李绍辉; 刘庆伟
Original assignee: Dawning Information Industry Beijing Co Ltd
Current assignee: National Computer Network and Information Security Management Center; Dawning Information Industry Beijing Co Ltd
Priority date: 2009-08-28
Filing date: 2009-08-28
Publication date: 2010-02-17
Anticipated expiration: 2029-08-28
Also published as: CN101651576B

Abstract

本发明提供一种告警信息处理方法和装置，其中，告警信息处理方法包括：分析集群***以得到一个或多个实际的业务规则，并且根据一个或多个实际的业务规则建立规则关联模型；使用户根据规则关联模型来定义用于显示的业务规则，其中，用于显示的业务规则与实际的业务规则相对应并且同步；获取所要分析的告警信息和所需要的辅助信息，并且根据所要分析的告警信息、实际的业务规则和所需要的辅助信息利用告警关联规则引擎对所要分析的告警信息进行关联，得到所有的根源告警信息及其关联的告警信息及数量；将所得到的根源告警信息及其关联的告警信息和数量以及用于显示的业务规则呈现给用户，用户还可以查看某个根源告警信息关联的告警信息的拓扑图。

Description

告警信息处理方法和***

技术领域

本发明涉及通信领域，尤其涉及一种告警信息处理方法和***。

背景技术

集群技术越来越多地应用于科学计算、网络服务和数据库等领域，这些领域由于其自身特点，需要大量设备对数据进行运算或者存储，因此一个大规模的集群***中往往包含成千上万的设备，在这些设备上运行着相应的软件，此外还有影响这些设备运行状态的环境和网络。随着集群***规模的扩大，集群***中被管理网元物理上和逻辑上的关联性越来越多，单一的故障往往会在相关的网元中产生大量的告警信息，使得故障的识别和定位变得困难，在多个故障并发时，情况变得更加复杂。管理员面对海量的告警信息，往往很难从中找到故障的真正原因，从而无法快速实施故障修复和故障排除。

关于告警关联分析，目前有多种理论上的实现方法，实际的产品都是基于这些方法实现。

国外在业界占据主导地位的几大厂商都提供了自己的告警关联解决方案，各个公司的产品基于不同的告警关联方法实现。比如惠普公司的产品ECS，采用基于规则的方法实现；IBM公司的产品NetFACT，采用基于模型推理的方法实现。

国内的告警关联产品目前主要应用于电信行业，对网络的告警关联分析。目前大部分相关产品，都提供了告警关联的支持功能，也有许多产品说自己实现了告警关联，但其实可能只是实现了一些较基础的告警日志、告警过滤等功能，而没有进行深入的告警关联分析，即使有较强大的功能，也大部分是集成了国外的同类产品。

对于集群监控领域的告警关联研究，起步较晚，目前国内总体尚处于理论探讨、应用试验阶段，还没有完全成熟商用的产品成规模地投入使用。

发明内容

针对相关技术中存在的一个或多个问题，本发明的目的在于提供一种告警信息处理方法和***，以解决上述问题中的至少之一。

为实现上述目的，根据本发明的一个方面，提供了一种告警信息处理方法，包括：

分析集群***以得到一个或多个实际的业务规则，并且根据一个或多个实际的业务规则建立规则关联模型；

使用户根据规则关联模型来定义用于显示的业务规则，其中，用于显示的业务规则与实际的业务规则相对应并且同步；

获取所要分析的告警信息和所需要的辅助信息，并且根据所要分析的告警信息、实际的业务规则和所需要的辅助信息利用告警关联规则引擎对所要分析的告警信息进行关联，得到所有的根源告警信息及其关联的告警信息和数量；

将所得到的根源告警信息及其关联的告警信息和数量以及用于显示的业务规则呈现给用户，用户可以查看某个根源告警关联的告警信息的拓扑图。

优选地，建立规则关联模型的步骤包括：分析集群***的特点，得到一个或多个实际的业务规则；以及根据一个或多个实际的业务规则以告警关联规则引擎能够识别的方式建立业务规则关联模型。

优选地，业务规则关联模型包括以下一种或多种：同一部件，适用于同一部件上存在因果关系的告警；同一部件类型，适用于同一部件类型存在因果关系的告警；同一设备，适用于同一设备上存在因果关系的告警；同一设备类型，适用于同一设备类型存在因果关系的告警；以及拓扑关系，适用于原因告警和结果告警是拓扑关联且存在因果关系，并且原因告警是交换机告警，结果告警是设备告警，结果告警发生地次数大于设定值的情况。

优选地，在用户定义用于显示的业务规则的步骤中，用于显示的业务规则被存储在数据库中，实际的业务规则被存储在规定的目录下。

优选地，所需要的辅助信息包括以下一个或多个：设备和机柜对应信息、拓扑信息、节点分组信息、以及软硬件对应信息。

优选地，告警关联规则引擎在每个实际的业务规则被执行之后，自动检验实际的业务规则的状态，并根据状态对其进行相应操作。

优选地，告警关联规则引擎在规则中定义创建、修改、和/或删除规则的操作。

为实现上述目的，根据本发明的另一个方面，提供了一种告警信息处理***，包括：

模型建立装置，用于对集群***进行分析得到一个或多个实际的业务规则，并且根据一个或多个实际的业务规则建立规则关联模型；

规则定义装置，用于使用户根据规则关联模型来定义用于显示的业务规则，其中，规则定义单元使用于显示的业务规则与实际的业务规则相对应并且同步；

告警信息关联装置，用于获取要分析的告警信息和所需要的辅助信息，并且根据所要分析的告警信息、实际的业务规则和所需要的辅助信息对所要分析的告警信息进行关联，得到所有的根源告警信息及其关联的告警信息和数量；以及

关联结果呈现装置，用于将所得到的根源告警信息及其关联的告警信息和数量以及用于显示的业务规则呈现给用户。

优选地，模型建立装置包括：分析单元，用于分析集群***的特点，得到一个或多个实际的业务规则；建立单元，用于根据一个或多个实际的业务规则以告警信息关联单元能够识别的方式建立业务规则关联模型。

优选地，业务规则关联模型包括以下一种或多种：

同一部件，适用于同一部件上存在因果关系的告警；

同一部件类型，适用于同一部件类型存在因果关系的告警；

同一设备，适用于同一设备上存在因果关系的告警；

同一设备类型，适用于同一设备类型存在因果关系的告警；以及

拓扑关系，适用于原因告警和结果告警是拓扑关联且存在因果关系，并且原因告警是交换机告警，结果告警是设备告警，结果告警发生地次数大于设定值的情况。

优选地，规则定义单元将用于显示的业务规则存储在数据库中，将实际的业务规则存储在规定的目录下。

借助本发明上述至少一个技术方案，通过对海量告警信息的关联关系进行分析，查找到根源告警，呈现给管理员，减少了告警数量，能极大地减轻管理员的工作负担，实现了告警管理***的及时性和稳定性。

附图说明

图1是根据本发明的告警信息处理方法的流程图；

图2是根据本发明的告警信息处理***的框图；

图3是根据本发明的实施例的关联规则库的实现与管理***的示意图；

图4是根据本发明的实施例的增加规则的流程图；

图5是根据本发明的实施例的告警关联分析的简单逻辑示意图；

图6是根据本发明的实施例的告警关联分析结果的示意图；以及

图7是根据本发明的实施例的告警关联分析的详细流程图。

具体实施方式

功能概述

考虑到相关技术中存在的一个或多个问题，本发明提出了一种告警信息处理方法和***，通过对海量告警信息的关联关系进行分析，查找到根源告警，呈现给管理员，减少了告警数量，能极大地减轻管理员的工作负担，实现了告警管理***的及时性和稳定性。

图1是根据本发明的告警信息处理方法的流程图。如图1所示，本发明的告警信息处理方法包括以下步骤：

步骤102，分析集群***以得到一个或多个实际的业务规则，并且根据一个或多个实际的业务规则建立规则关联模型；

步骤104，使用户根据规则关联模型来定义用于显示的业务规则，其中，用于显示的业务规则与实际的业务规则相对应并且同步；

步骤106，获取所要分析的告警信息和所需要的辅助信息，并且根据所要分析的告警信息、实际的业务规则和所需要的辅助信息利用告警关联规则引擎对所要分析的告警信息进行关联，得到所有的根源告警信息及其关联的告警信息和数量；

步骤108，将所得到的根源告警信息及其关联的告警信息和数量以及用于显示的业务规则呈现给用户，用户能够查看某个根源告警信息关联的告警信息的拓扑图。

其中，步骤102包括：分析集群***的特点，得到一个或多个实际的业务规则；以及根据一个或多个实际的业务规则以告警关联规则引擎能够识别的方式建立业务规则关联模型。

其中，业务规则关联模型包括以下一种或多种：同一部件，适用于同一部件上存在因果关系的告警；同一部件类型，适用于同一部件类型存在因果关系的告警；同一设备，适用于同一设备上存在因果关系的告警；同一设备类型，适用于同一设备类型存在因果关系的告警；以及拓扑关系，适用于原因告警和结果告警是拓扑关联且存在因果关系，并且原因告警是交换机告警，结果告警是设备告警，结果告警发生地次数大于设定值的情况。

其中，步骤104中，用于显示的业务规则被存储在数据库中，实际的业务规则被存储在规定的目录下。

其中，所需要的辅助信息包括以下一个或多个：设备和机柜对应信息、拓扑信息、节点分组信息、以及软硬件对应信息。

其中，告警关联规则引擎在每个实际的业务规则被执行之后，自动检验实际的业务规则的状态，并根据状态对其进行相应操作。告警关联规则引擎在规则中定义创建、修改、和/或删除规则的操作。

图2是根据本发明的告警信息处理***的框图。如图2所示，本发明的告警信息处理***包括：

模型建立装置202，用于对集群***进行分析得到一个或多个实际的业务规则，并且根据一个或多个实际的业务规则建立规则关联模型。模型建立装置202包括：分析单元202-2，用于分析集群***的特点，得到一个或多个实际的业务规则；建立单元202-4，用于根据一个或多个实际的业务规则以告警信息关联单元能够识别的方式建立业务规则关联模型。

规则定义装置204，用于使用户根据规则关联模型来定义用于显示的业务规则，其中，规则定义单元使用于显示的业务规则与实际的业务规则相对应并且同步。

告警信息关联装置206，用于获取要分析的告警信息和所需要的辅助信息，并且根据所要分析的告警信息、实际的业务规则和所需要的辅助信息对所要分析的告警信息进行关联，得到所有的根源告警信息及其关联的告警信息和数量。

关联结果呈现装置208，用于将所得到的根源告警信息及其关联的告警信息和数量以及用于显示的业务规则呈现给用户。

其中，规则定义单元将用于显示的业务规则存储在数据库中，将实际的业务规则存储在规定的目录下。

其中，所需要的辅助信息包括以下一个或多个：设备和机柜对应信息、拓扑信息、节点分组信息、以及软硬件对应信息。告警关联规则引擎在规则中定义创建、修改、和/或删除规则的操作。

以下详细介绍本发明的更具体实现。

具体地，本发明采用基于规则的关联方法实现。在本发明的开发中涉及到以下几个关键点：

一、规则关联模型的建立

规则关联模型的建立主要分为两步：

第一步：分析集群***的特点，找出其规则，对规则进行归纳总结，提供一种通用的业务规则模型。

下表中是业务规则模型的几个例子。

关联模型名称	描述
关联模型名称	描述	同一部件	此模型适用于同一部件上存在因果关系的告警。比如：CPU电压过高告警与CPU温度过高告警，它们之间存在因果关系，并且这种因果关系只限于同一个CPU内部。
同一部件类型	此模型适用于同一部件类型存在因果关系的告警。	同一部件
同一部件类型	此模型适用于同一部件类型存在因果关系的告警。	同一设备	此模型适用于同一设备上存在因果关系的告警。比如：交换机内存利用率过高告警和端口输入丢包率过高告警，它们之间存在因果关系，且这种因果关系只限于同一设备内部。
同一设备类型	此模型适用于同一设备类型存在因果关系的告警。	同一设备
同一设备类型	此模型适用于同一设备类型存在因果关系的告警。	拓扑关系(交换机-设备)	此模型适用于原因告警和结果告警是拓扑关联且存在因果关系，并且原因告警是交换机告警，结果告警是设备告警，结果告警发生的次数大于设定值的情况。比如：交换机自身状态(不可到达)告警和服务器自身状态(不可到达)告警，它们之间存在因果关系，且这种因果关系是拓扑关系。当某个交换机发生不可到达告警的同时，和该交换机连接的服务器有3个以上发生不可到达告警，则认为是交换机不可到达告警引起了服务器不可到达告警。

第二步是将这些业务规则模型转换为***中规则引擎可以识别的方式，即以一定的规则语法将业务逻辑表示出来。

下面以同一部件关联模型的逻辑为例进行说明。

1package rules.correlation_${templateName}_${causeAlarmValueID}_${resultAlarmValueID}23import com.dawning.gridview.alarmSystem.generic.type.database.AlarmInfo；4import com.dawning.gridview.alarmSystem.generic.type.correlation.EquipToRack；5import com.dawning.gridview.alarmSystem.generic.type.correlation.NodeGroup；6import com.dawning.gridview.alarmSystem.generic.type.correlation.Topo；7import com.dawning.gridview.alarmSystem.alarmcorrelation.AlarmAnalyze；89global com.dawning.gridview.alarmSystem.alarmcorrelation.AlarmAnalyze aiAnalyze；1011rule″${ruleName}″12 when13 $cause：AlarmInfo(alarmValueID＝＝″${causeAlarmValueID}″)14 $result：AlarmInfo(alarmValueID＝＝″${resultAlarmValueID}″，15 name_type＝＝$cause.name_type，16 name_typeName＝＝$cause.name_typeName，17 name_subtype＝＝$cause.name_subtype，18 name_subtypeName＝＝$cause.name_subtypeName，19 alarmTime＞＝$cause.alarmTime)20 then21 aiAnalyze.addEdge($cause，$result，″${databaseRuleName}″，″${templateName}″)；22 end

上面代码的语法描述如下：

(1)第1行：package package-name(包名)

包名是强制性的。就像java中的包一样，包名也就是名称空间名，与文件或目录名称无关。

其中，${templateName}、${causeAlarmValueID}、${resultAlarmValueID}是可配置数据，在实际生成规则时由用户设定值代替。

(2)第3行-第7行：import

import同java中的含义一样。对于任何要在规则中使用的对象，需要制定完整的路径和类型名。规则引擎将会从同名的java包中自动导入类。

(3)第9行：global

global是全局变量，通常用来返回数据，如一个动作的记录，获得提供数据或服务给规则使用。

全局变量在规则文件中声明并使用，在Java文件中进行赋值。这里的aiAnalyze是告警分析类实例的全局变量。

(4)第11行：rule“name”

规则名称。在这里，“name”是一个可配置数据${ruleName}，在生成规则的时候用实际值代替可配置数据。

(5)第12行-第19行：when

规则的条件部分。在告警关联模块中，关联模型不同，对应的条件也不同。

(6)第20行-第21行：then

规则的动作部分。它允许java代码语义块。这里的aiAnalyze.addEdge()是调用告警分析类的添加边的方法。

二、业务规则的管理

用户定义规则的前提是存在业务规则模型。***中预先定义了一些业务规则，此外，用户可以根据实际情况制定业务规则，并可以对已经定义的业务规则进行修改、删除、查看等操作。用户在用户界面进行操作，看到的是能够理解的信息，而底层运行的实际的规则文件是一些编码形式，因此需要在二者之间进行相互转换，即把用于显示的规则和实际的规则文件分开。***实现是将用于显示的规则存储到数据库中，实际的规则文件存储在规定的目录下，两者之间是同步的。

如图3所示，用户界面对规则的操作通过和数据库交互进行，实际的规则文件根据数据库中的内容生成，在用户进行告警关联分析操作时，Drools规则引擎使用的是实际的规则文件，而不是数据库中用户定义的规则文件。

图4示出了根据本发明的实施例的用户增加规则流程，如图4所示，该流程包括以下步骤：

步骤402-404：判断用户设定值的合法性，不能为空的字段判断是否为空。

规则名称、关联模型、原因告警的alarmValueID(告警值ID)和结果告警的alarmValueID都不能为空，如果为空，则需要提示用户。

步骤406：判断用户设定的原因告警和结果告警的alarmValueID是否存在。

如果alarmValueID不存在，提示相应信息。

步骤408-410：判断规则名是否已经存在。

比较新增加的规则名是否和表AlarmCorrelationRule中的Name字段重复，如果存重复，提示用户规则名重复，需要重新输入一个规则名。

步骤412：判断要增加的规则是否已经存在。

比较新增加的规则的关联模型+原因告警alarmValueID+结果告警alarmValueID在AlarmCorrelationRule表中是否已经存在，如果存在，提示用户规则已经存在。

步骤414；判断增加规则后是否会形成环。

将所有规则以图的方式存储，顶点表示alarmValueID，将alarm cause表中的所有alarmValueID都存储到图顶点，图以邻接矩阵方式存储。在用户增加规则时，在规则的原因告警和结果告警alarmValueID对应的顶点之间加一条边，判断是否存在环，如果存在，不合法。

步骤416：判断选择的原因告警、结果告警是否和关联模型匹配。

步骤418：如果匹配，则在数据库表中增加一条记录。

步骤420：生成相应的规则文件，调用生成规则文件子流程。

三、告警关联分析的处理流程

告警关联分析的前提是存在规则和要分析的数据，此外，要进行分析还需要一些辅助信息。要分析的数据主要是告警信息，辅助信息包括设备和机柜对应信息、拓扑信息、节点分组信息等。

图5是根据本发明的实施例的一个告警关联分析的简单逻辑示意图。如图5所示，告警关联分析整体流程分为以下步骤：

步骤1、获取所要分析的告警信息，用户通过UI设置查询条件；

步骤2、将告警信息传送给告警关联分析逻辑；

步骤3、告警关联分析逻辑获取用于分析的辅助信息与规则库信息；

用于分析的辅助信息包括：拓扑信息、设备和机柜对应信息、节点分组信息、软件硬件对应信息等；

用于分析的规则库信息是当前大型机所有生效的规则信息；

步骤4、告警关联分析

规则引擎将规则信息、告警信息和辅助信息***到工作内存，对告警信息进行关联和后续处理。

结果返回给UI。

分析后得到所有的根源告警及其关联的告警信息和数量，以列表的形式返回UI。得到根源告警关联的告警信息，以图的方式显示给用户。图6是根据本发明的实施例的一个告警关联分析结果的示意图。

图7是根据本发明的一个实施例的告警关联分析的详细流程图。

如图7所示，告警关联分析的详细流程可以分为以下步骤：

步骤702-704：如果要分析的告警信息列表为空，则抛出异常，提示用户当前没有要分析的数据；

步骤706-708：检查规则文件是否正确生成，如果没有正确生成，则重新生成；

步骤710-714：如果不存在规则文件，则抛出异常，提示用户当前没有定义规则，无法进行分析；

步骤716：读取规则，创建规则引擎的工作内存；

步骤718：设置规则全局变量aiAnalyze，其值为this，代表Strust的Action调用时生成的告警分析类的实例；

步骤720：获取告警分析所需的辅助信息，包括：拓扑信息列表、节点分组信息列表、设备和机柜对应信息列表等；

步骤722；将各种辅助信息和告警信息都***到工作内存中；

步骤724：激活规则，进行数据匹配；

步骤726；释放工作内存；

步骤728：对数据进行后续处理。后续处理子流程主要是对规则引擎过滤后的信息进行处理。首先将数据存储到一个有向图中，图中的顶点表示告警信息，有向边表示规则信息，边的起始顶点表示原因告警、终止顶点表示结果告警。对图进行遍历等操作，获取根源告警和根源告警关联的告警信息和数量，以及由根源告警引起的所有告警的信息链。

四、告警关联规则引擎的实现

***采用开源的Drools规则引擎作为告警关联规则引擎，进行数据匹配的验证。Drools规则引擎需要的对象包括规则、要分析的数据、其它辅助信息。Drools规则引擎符合JSR-94规范，提供了外部程序使用和控制规则引擎的接口API，因此，只需要调用这些API就可以实现将规则加载到***中并使用它们。将规则加载到***中的步骤如下：

第一步：创建规则引擎对象，这个对象是由配置信息动态生成的。

首先，生成配置信息。

Properties baseProp＝new Properties()；baseProp.put(″newInstance″，true)；baseProp.put(″poll″，10)；baseProp.put(″dir″，this.getClass().getResource(″/″).toURI().getPath()+this.RULE_PATH+″/″+hpcID)；

然后，根据配置信息创建规则引擎对象。

RuleAgent ruleAgent＝RuleAgent.newRuleAgent(props)；

第二步：从规则库中取得与告警关联相关的规则包，并加载到规则引擎中。

StatefulSession workingMemory＝ruleAgent.getRuleBase(hpcID).newStatefulSession()；

第三步：向规则引擎导入需要处理的业务对象。导入的对象是用户自己的对象，例如告警对象，拓扑信息对象，节点分组对象等。在例子中，假设规则引擎处理的对象是用户自定义的告警对象和拓扑信息对象。引擎将对导入的所有对象的属性值与当前加载的规则包中的规则进行匹配比对，把匹配成功的规则放在Agenda中。

for(int i＝0；i＜lsAi.size()；i++){workingMemory.insert(lsAi.get(i))；

}for(int i＝0；i＜lsTopo.size()；i++){workingMemory.insert(lsTopo.get(i))；}

第四步：激活规则。在规则引擎执行规则的过程中，可能会出现的操作包括：

有些对象的属性值将被修改(比如修改告警级别)；

有些新的对象被创建(如告警分析后，导致一些新类型的告警被创建)；

有些对象被删除(如告警过滤)；

规则引擎会在每个规则被执行之后自动作这样的检验：当前状态下，Agenda中等待执行的规则是否还满足条件，剔除不满足条件的等待执行的规则；同时检查规则包中原来没有在Agenda中的规则是否符合当前状态的规则，如果有则把它们加入到Agenda中。引擎最终会清空Agenda。

workingMemory.fireAllRules()；

规则引擎将对对象的创建、修改、删除等操作都定义在规则中，这保证了程序的稳定性。当某些告警过滤和告警关联规则发生改变后，只需要将改变后的规则包重新调入引擎。引擎只对规则执行的准确性负责(如保证规则间的互斥关系、规则的执行顺序)，但不会关心规则的具体内容。

本发明选用了开源的Drools规则引擎。这还可以通过自主开发的方式，或者选用商业的规则引擎产品来实现。

通过上述告警信息处理方法和***，本发明采用目前居于主流的基于规则的方法解决了集群监控中继续解决的告警关联分析问题。发明实现的方法将业务规则逻辑与程序分离，方便用户管理和灵活制定业务规则，通过告警关联分析之后，减少了告警数量，减轻了***管理人员的工作负担，实现了告警管理***的及时性和稳定性。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种告警信息处理方法，其特征在于，包括：

分析集群***以得到一个或多个实际的业务规则，并且根据一个或多个所述实际的业务规则建立规则关联模型；

使用户根据所述规则关联模型来定义用于显示的业务规则，其中，所述用于显示的业务规则与所述实际的业务规则相对应并且同步；

获取所要分析的告警信息和所需要的辅助信息，并且根据所要分析的告警信息、所述实际的业务规则和所需要的辅助信息利用告警关联规则引擎对所要分析的告警信息进行关联，得到所有的根源告警信息及其关联的告警信息和数量；以及

将所得到的根源告警信息及其关联的告警信息和数量以及用于显示的业务规则呈现给用户，所述用户能够查看某个根源告警信息关联的告警信息的拓扑图。

2.根据权利要求1所述的方法，其特征在于，建立规则关联模型的步骤包括：

分析所述集群***的特点，得到一个或多个实际的业务规则；以及

根据一个或多个所述实际的业务规则，以所述告警关联规则引擎能够识别的方式建立所述业务规则关联模型。

3.根据权利要求2所述的方法，其特征在于，所述业务规则关联模型包括以下一种或多种：

同一部件，适用于同一部件上存在因果关系的告警；

同一部件类型，适用于同一部件类型存在因果关系的告警；

同一设备，适用于同一设备上存在因果关系的告警；

4.根据权利要求1所述的方法，其特征在于，在用户定义用于显示的业务规则的步骤中，所述用于显示的业务规则被存储在数据库中，所述实际的业务规则被存储在规定的目录下。

5.根据权利要求1所述的方法，其特征在于，所需要的辅助信息包括以下一个或多个：设备和机柜对应信息、拓扑信息、节点分组信息、以及软硬件对应信息。

6.根据权利要求1所述的方法，其特征在于，所述告警关联规则引擎在每个实际的业务规则被执行之后，自动检验所述实际的业务规则的状态，并根据所述状态对其进行相应操作。

7.根据权利要求6所述的方法，其特征在于，所述告警关联规则引擎在规则中定义创建、修改、和/或删除规则的操作。

8.一种告警信息处理***，其特征在于，包括：

模型建立装置，用于对集群***进行分析得到一个或多个实际的业务规则，并且根据一个或多个所述实际的业务规则建立规则关联模型；

规则定义装置，用于使用户根据所述规则关联模型来定义用于显示的业务规则，其中，所述规则定义单元使所述用于显示的业务规则与所述实际的业务规则相对应并且同步；

告警信息关联装置，用于获取要分析的告警信息和所需要的辅助信息，并且根据所要分析的告警信息、所述实际的业务规则和所需要的辅助信息对所要分析的告警信息进行关联，得到所有的根源告警信息及其关联的告警信息和数量；以及

9.根据权利要求8所述的***，其特征在于，模型建立装置包括：

分析单元，用于分析所述集群***的特点，得到一个或多个实际的业务规则；

建立单元，用于根据一个或多个所述实际的业务规则以所述告警信息关联单元能够识别的方式建立所述业务规则关联模型。

10.根据权利要求9所述的***，其特征在于，所述业务规则关联模型包括以下一种或多种：

同一部件，适用于同一部件上存在因果关系的告警；

同一部件类型，适用于同一部件类型存在因果关系的告警；

同一设备，适用于同一设备上存在因果关系的告警；

11.根据权利要求8所述的***，其特征在于，所述规则定义装置将所述用于显示的业务规则存储在数据库中，将所述实际的业务规则存储在规定的目录下。

12.根据权利要求8所述的***，其特征在于，所需要的辅助信息包括以下一个或多个：设备和机柜对应信息、拓扑信息、节点分组信息、以及软硬件对应信息。

13.根据权利要求12所述的***，其特征在于，所述告警关联规则引擎在规则中定义创建、修改、和/或删除规则的操作。