CN101022366A - 一种故障关联分析***以及方法 - Google Patents

Abstract

本发明提供了一种能够找出根本原因告警的故障管理分析***以及方法。本发明的故障关联分析***用于对被管网络产生的故障进行故障关联分析以找出根本故障原因，所述被管网络和所述故障关联分析***基于特定网络管理协议进行信息交互，其中，该故障关联分析***具备：用于进行故障管理的故障管理模块；以及用于维护被管网络的网络拓扑管理模块，其中，所述故障管理模块具备：用于对故障的告警进行核心处理的告警核心处理模块；以及用于根据得到的告警基于特定逻辑关系进行关联分析以找出根本故障原因的告警关联模块。由此，能够找出根本原因告警而避免重复告警或非根本原因告警。

Description

一种故障关联分析***以及方法

技术领域

本发明涉及电信网络管理***，具体地涉及在电信管理***中对故障进行关联分析的***以及方法。

背景技术

SNMP(Simple Network Management Protocol，简单网络管理协议)已经成为电信网络管理领域的一种广泛使用的管理协议。在SNMP网络管理中，当设备发现故障的时候，设备将向网管发送SNMP Trap消息。网管接收并解析SNMPTrap，生成相应的告警信息，提醒维护人员去关注，并及时根据显示的告警信息定位问题和修复。

当网络出现故障的时候，会引发一系列的告警，但是，并不是所有告警都反映故障的根本原因。在当前的网络管理中，大量的重复告警或非根本原因告警会同时上报到网管。这是由于，目前大部分设备在进行故障检测的时候，都仅仅局限于自身的故障空间，而忽视设备与设备之间的关联。

图1是表示通信网络中两个设备之间的关联关系的示意图。如图1所示，两个设备A、B之间的端口存在公共连接即链路b。当该链路b中断的时，设备A、B双方都会上报关于该连接故障的告警，导致不必要的重复告警。此外，当其中的某个设备例如设备A的板A出现故障时，该板A以及它的所有端口A也会产生告警，这种情况下，显然只有板A故障是根本原因告警，端口A告警皆为非根本原因告警。

上述的重复告警、非根本原因告警是一种干扰，它使得告警总体数量变大，并增加分辨故障根本原因的难度。

在目前的设备故障检测机制下，重复告警、非根本原因告警的产生往往是难以避免的。然而，从网络日常维护和管理的角度出发，管理员只希望看到根本原因告警。目前的处理方式主要依靠网络工程师依据个人的维护经验对告警进行分类、判断和分析，并得出告警的来源及根本原因。当要管理的网络变大，告警数目庞大，告警之间的相关性也变得非常复杂的时候，这种完全依靠人工判断的方式效率极为低下。这就要求网络管理***能够提供一种有效的告警关联分析方案，从大量告警中找出根本原因告警，以更好的支持管理人员进行故障定位和修复。

目前找出根本原因的告警关联分析方法大多是根据项目的特性，用硬编码实现相关逻辑，难以通用和适应变化。也有些方案是居于某种特定的通讯模型，根据模型中的管理对象的复杂逻辑关系来找出告警之间的关系。这种分析涉及到特定的通讯模型，分析结果能做到比较准确，但对象关系非常复杂，难以实现。而且当模型发生变化时就得重新建模，没有很好的网络适应性，难以在管理域外重用。

还有些方案是基于对大量历史数据的数据挖掘，进行一般意义的关联分析，得到存在相关性的告警，再通过人工的确认找出根本原因告警。该方法有通用性的特点，不过该关联性分析需要在一个大数据集里进行，处理性能受限。对于比较小的数据集，分析结果则偏离实际比较大。该分析的缺陷还在于它分析出来的结果是居于一定的可信度，并且往往需要一个附加的，人工的二次确认过程。而不同的人对可信度的要求不一样，难以统一。此外，它也是一种离线的分析，难以提供实时的分析结果，并进行在线的调整，处理。

发明内容

本发明鉴于上述问题，旨在提供一种能够有效、快速地找出根本原因告警的故障关联分析***以及方法。

本发明一方面的故障关联分析***是用于对被管网络产生的故障进行故障关联分析以找出根本故障原因，所述被管网络和所述故障关联分析***基于网络管理协议进行信息交互(如SNMP)，其中，所述故障关联分析***具备：用于进行故障管理的故障管理模块；以及用于维护被管网络的管理对象信息库的网络拓扑管理模块，其中，所述故障管理模块具备：用于对故障的告警进行核心处理的告警核心处理模块；以及用于根据得到的告警基于特定逻辑关系进行关联分析以找出根本故障原因的告警关联模块。

其中，所述告警核心处理模块具备：从所述被管网络接收基于所述协议消息并且进行解析以生成统一的告警源信息的协议消息接收和翻译器；根据生成的统一的告警源信息分析出告警对象并返回给所述协议消息接收和翻译器的对象***；以及根据所述协议消息接收和翻译器提供的告警对象进行核心处理的核心处理模块。

其中，所述特定逻辑关系是告警特征字段组成的规则比较。

其中，所述规则比较包括：告警原因关系比较、告警对象关系比较以及告警时间关系比较。

其中，所述告警对象关系比较是由表示告警对象之间相互关系的告警对象树来表示。

其中，所述告警关联模块具备：用于管理规则的规则管理模块；用于从告警核心处理模块接收告警的告警接收器；用于管理和维护告警对象树的告警对象树管理模块；用于将告警绑定到告警对象树的告警绑定管理模块；用于将接收到的告警以及已经存在的告警基于所述告警对象树中的特定逻辑关系进行关联分析并找出其中的根本原因告警的关联分析引擎模块。

其中，在所述网络拓扑管理模块具备对管理范围内的对象按照统一规则进行命名的命名服务模块，所述对象***对接收的告警源信息进行转换时调用所述命名服务模块，得到告警源的名字，并把名字返回给所述协议消息接收和翻译器进行分析以得到告警对象。

其中，所述告警对象树保存在故障关联分析***的内存中，包含所有能够作为告警源的管理对象。

其中，还进一步增加设置用于进行从拓扑管理模块的管理对象库到告警对象树动态适配的对象适配器、以及用于静态转换的对象服务工具。

其中，所述关联引擎模块具备：根据用户制定的过滤条件把不需要进行关联分析的告警剔除的过滤器管理模块；以及管理多个关联分析线程的关联线程池管理模块。

其中，所述关联线程池管理模块根据规则管理多个线程，当添加、或者删除所述规则的情况下，动态创建、或者关闭相应的线程。

本发明另一方面的故障关联分析方法，用于对被管网络产生的故障进行故障关联分析以找出根本故障原因，所述被管网络和所述故障关联分析***通过网络管理协议(如SNMP)进行信息交互，其特征在于，所述方法包括下述步骤：从所述被管网络通过特定网络管理协议接收并解析故障告警信息的接收步骤；对接收到的故障告警消息进行核心处理以获得告警对象的核心处理步骤；以及根据得到的告警对象通过特定逻辑关系进行关联分析以找出根本故障原因的告警关联步骤。

最好，在所述接收步骤中，从所述被管网络接收报警协议消息并且进行解析以生成统一的告警源信息，在所述核心处理步骤中，根据生成的统一的告警源信息分析得出告警对象。

其中，所述特定逻辑关系是指告警特征字段组成的规则比较。

其中，所述规则比较包括：告警原因关系比较、告警对象关系比较、以及告警时间关系比较。

其中，所述告警对象关系比较是由表示告警对象之间相互关系的告警对象树来表示。

其中，定义所述告警对象树的模型包括：

定义建模了告警对象之间的层次包含关系的第一接口；

定义建模了告警对象之间的一般连接关系的第二接口；

定义支持告警绑定和解除绑定的对象特性的第三接口；以及

定义表示告警对象树上一般对象的特性的第四接口。

其中，告警对象树的初始化包括下述步骤：

(1)告警对象树初始化被调用；

(2)告警对象树请求所述对象适配器根据所述第一-第四接口，返回告警对象的层次关系；

(3)所述对象适配器从所述拓扑管理模块获取管理对象信息，按照所述模型进行转换，然后将对象层次关系返回给告警对象树；

(4)告警对象树生成适用于关联分析的告警对象树实例。

其中，告警对象树的更新包括下述步骤：

(1)***初始化时，向对象适配器注册对象更新通知监听；

(2)收到对象更新信息，判断是否需要更新告警对象树；

(3)如果判断为需要通知告警对象树，则进行适当的消息转换；以及

根据转换后的消息，更新告警对象树。

其中，在所述告警关联步骤中，包括下述步骤：

(1)接收告警消息的接收步骤；

(2)将告警消息转换成包含特征字段的用于关联分析的内部消息的转换步骤；

(3)根据所述内部消息，把告警绑定到告警对象树或从告警对象树里解除绑定的告警绑定/解除步骤；

(4)将接收到的告警以及已经存在的告警基于所述告警对象树中的特定逻辑进行关联分析以找出其中的根本原因告警的关联分析步骤。

其中，在所述告警绑定/解除步骤中，若所述内部消息为非清除消息，则将告警绑定到告警对象树上；若所述内部消息如果它为清除消息，则将告警从告警对象树上解除绑定。

其中，在所述关联步骤中，进一步包括：

根据用户制定的过滤条件把不需要进行关联分析的告警剔除的过滤管理步骤。

其中，能够由用户定制所述告警特征字段组成的规则比较。

其中，还包括告警展示步骤，所述告警展示步骤包括：

(1)告警产生后，被送到告警客户端，以根本故障原因方式展示；

(2)告警同时被实施所述告警关联步骤，以进行根本故障原因分析；

(3)对根本故障原因分析的结果实施核心处理；以及

(4)将核心处理的结果发送给客户端，在客户端更新显示。

由此，根据本发明能够基于的关联分析方案，能够找出根本告警原因而避免重复告警或非根本原因告警。同时，能够提供在线的实时的分析，并能根据结果做实时调整，具有离线分析所没有的优点。

而且，利用本发明的多层次的对象告警树这样的告警客户端展示方式，能够给管理员非常直观和有效的管理方式，为快速故障定位，故障解决提供有力支持。

附图说明

图1是表示通信网络中两个设备之间的关联关系的示意图。

图2是表示本发明实施方式之一的告警关联分析的NMS框架图。

图3是表示标准化SNMP trap格式的MIB定义的示意图。

图4是表示定义了关联分析所基于的告警信息模型的示意图。

图5是表示Trap分析及告警到对象关联过程的流程图。

图6是表示告警对象树的架构图。

图7是表示本发明实施方式的告警对象树模型的定义图。

图8是表示告警对象树初始化的流程图。

图9是表示告警对象树动态更新的流程图。

图10是表示告警绑定和解除绑定的流程图。

图11是表示进行关联引擎所相关的各部分的框图。

图12是表示告警关联性分析的过程的流程图。

图13是表示一般告警关联分析的简单实例的示意图。

图14是表示层次树的根本原因告警及其包含的告警之间的关系的示意图。

通过结合附图对较佳实施例所作的详细描述，本发明的上述和其它特征和优点将变得显而易见。详细描述和附图对本发明仅是示意性质的，并非用来限制其范围的，本发明的范围由所附权利要求及其等同含义限定。

具体实施方式

图2是表示本发明实施方式的告警关联分析的网络管理***(NMS)框架图。

如图2所示，区域A和区域B分属两个不同的被管网络(Managed Network)2000、3000。被管网络2000、3000之间存在跨网络/域的相互连接。被管网络2000、3000和NMS(Network Management System，网络管理***)1000基于SNMP简单网络管理协议进行信息交互。

首先，在NMS 1000中具有故障管理模块1010(Fault Management，可以简称为FM)、网络拓扑管理模块1020(TOPO Management，可以简称为TM)。

网络拓扑管理模块1020主要提供了对MOR(Managed Object Repository，被管对象仓库)的管理。这里，MOR的目的是为了维护NMS管理范围内所有被管对象的详细信息，包括被管对象的属性、支持的操作以及相应的描述信息，MOR同时也维护了被管对象之间的包含关系。

在网络拓扑管理模块1020中设有有统一命名服务功能的命名服务模块1021，命名服务模块1021对管理范围内的对象按照统一规则进行命名。例如，机筐1，槽号4所插板子1的端口3可以表示为：“chassis＝1，slot＝4，card＝1，port＝3”。本发明中，统一命名不局限于这里给出的方案，它可采用任意的支持层次命名的命名规则。

在故障管理模块1010中包含：用于对告警进行核心处理的告警核心处理模块1011(Core Alarm Processing)1011；以及用于根据告警基于特定的逻辑进行关联分析以且找出根本原因的告警关联模块1015。

告警核心处理模块1011包含告警处理的所有核心功能，如SNMP trap接收以及解析；告警生成前的预处理：包括告警过滤、告警重定义等等；告警生成后的通知功能：包括邮件通知、短信通知以及其他额外的基于告警消息的服务等等。

在本发明实施方式中，主要侧重于SNMP trap的接收分析、告警到对象关联这两个部分，其余部分处理统一归为核心处理部分(Core Processing)。因此，在本实施方式中，如图2所示，告警核心处理模块1011概要地包含Trap接收和翻译器(Trap Receiver/Trap Parsing)1012、对象***1013以及核心处理模块1014。

其中，Trap接收和翻译器1012是在SNMP网络的情况下负责接收及解析SNMP Trap消息，生成统一的告警表达形式。然而，本实施方式中只描述在SNMP网络的情况下，如果在其他协议网络的情况下，这里的Trap接收和翻译器1012可以是基于其他网络管理协议的协议消息接收和翻译器。同样，这里虽然只举例说明了SNMP网络的情况，但本发明不限定于SNMP网络，也可同样地适用于其他协议网络。

对象***(Object Locater)1013根据生成的统一的告警，分析出告警源对象。具体地，对象***1013提取Trap消息里固定字段的内容，分析出相关的告警源信息，然后通过调用网络拓扑管理模块1020的命名服务，得到告警源对象在MOR中的名字，并把该名字填到生成的告警对象的特定关联字段里。

为支持方便、统一的告警定位，对设备发送的trap格式标准化，尤其是Trap里的告警源信息的格式的标准化，将会使得对象关联过程更统一。

图3是表示标准化SNMP trap格式的MIB定义的示意图。

在图3中，“logAlarmInstance”字段定义了故障发生的告警源信息。它为OCTET STRING类型，并遵循格式“instanceId[1]＝instance[1]，instanceId[2]＝instance[2]，......instanceId[n]＝instance[n]”，其中instanceId为Integer类型，表示实例ID，instance表示实际的实例。实际上，它可以和网络拓扑管理模块1020对象命名规则一致。但这里的实例ID常量不一定和网络拓扑管理模块1020的常量定义一致。如果不一致，则必须做相应的转换。本发明中，不局限于两者是否一致。然而，为了简化说明，后面的流程描述都基于两者为一致的基础上进行的。

要进行关联分析，需要有效建模分析所基于的告警信息模型，并使得关联规则包含其特征字段。图4是表示定义了关联分析所基于的告警信息模型的示意图。图4中各字段含义列举如下：

■Id：是一个递增的数字，标示告警产生的***ID

■alarmKey：告警的关键字，唯一标示一条告警

■alarmId：告警ID，表示一类型的告警

■entityType：告警源对象的实体类型

■entityInstance：告警源对象的具体实例。

■probableCause：告警主要原因，相当于ITU标准的PC

■specialReason：告警次要原因，相当于ITU标准的SP

■addInfo：附加信息

■neld：告警源对应的网元ID，设备ID由网管统一分配以唯一标示每个被管理的网元

■network：网络

■domain：区域

■mapName：地图名

■source：告警源在MOR中相应对象的名字。该字段为关联字段，每个告警最终都被定位到某个对象上，从而管理员能鉴别故障发生的具***置

■category：告警的种类，参照ITU-T X.733

■severity：告警的级别。参照ITU-T X.733

■createTime：告警的发生时间

■message：消息

■seqNo：序列号

■ackUser：告警确认的用户

■ackTime：告警确认的时间

■Help：帮助

在该模型定义中，probableCause，specialReason，createTime，severity，entity，source为其特征字段，分别说明了告警原因、告警时间、告警源、告警级别等重要特征。关联规则的制定以及关联分析主要是基于这几个特征字段。

进一步，下面将说明Trap分析及告警到对象关联的一般流程。

图5是表示Trap分析及告警到对象关联过程的流程图。如图5所示，Trap分析及告警到对象关联的步骤包括：

(1)Trap接收和翻译器1012接收到网元发送过来的SNMP Trap包；

(2)Trap接收和翻译器1012进行SNMP Trap包的解码，创建解码后的SNMP PDU(Protocol data unit，协议数据单元，它是标准SNMP网络管理中的术语，用于承载SNMP实体间的信息交互)，把它送到Trap接收和翻译器1012进行处理；

(3)Trap接收和翻译器1012进行除告警源外的其他信息翻译过程；

(4)Trap接收和翻译器1012从SNMP PDU中提取告警源信息，把它送给对象***1013；

(5)对象***1013对接收到的告警源信息进行一定的转换，调用根据命名服务模块1021得到告警源在MOR中的名字，然后把名字返回给Trap接收和翻译器1012进行分析；

(6)Trap接收和翻译器1012根据所翻译的信息，生成告警对象；

(7)Trap接收和翻译器1012把告警对象传递给核心处理模块1011以进行下一步处理。

关于告警关联模块1015，如图2所示，它包含：用于管理规则的规则管理模块(Rule Manager)1016；用于接收告警的告警接收器(Alarm Receiver)1017；用于将接收到的告警以及已经存在的告警基于特定的逻辑进行关联分析并找出其中的根本原因告警的关联分析引擎模块(Correlation Engine)1018；用于将告警绑定告警绑定管理模块(Alarm Bind Manager)1019以及用于管理和维护告警对象树的告警对象树管理模块1071。

告警关联模块1015的主要功能在于，根据由规则管理模块1016已定义的规则，关联分析引擎模块1018对由告警接收器1017接收到的告警以及已经存在的告警基于特定的逻辑进行关联分析，找出其中的根本原因告警。上述特定的逻辑是指告警对象树所表示的对象之间的关系。又，告警对象树存在于内存中，用于管理对象库的一个子集并包含所有能作为告警源的对象。

关于规则的定义，主要包含三部分重要因素：

1.告警原因之间的关系：指出要进行分析的两个告警集。当集合元素为1时，为指定要分析的两个告警，其中之一为根本原因告警，另外一个为其包含的非根本原因告警；

2.告警对象(告警源)之间的关系：指出要进行分析的告警其告警源要满足的关系；

3.告警时间之间的关系：指出要进行分析的告警其发生时间要满足的时序关系。

其中，告警对象(告警源)之间的关系可为以下4种：

a)包含关系(Containment Relationship)：表示告警源存在物理或者逻辑的包含关系，反映在告警对象树上，就是告警源之间存在父子关系或者祖先关系；

b)连接关系(Group Relationship)：表示告警源间存在的直接或者非直接的一般连接关系。基本上可把对象间除了包含关系以外的其他特定通讯关系都建模成一般连接关系。连接关系可理解为一种虚拟组关系，组内的对象两两存在连接关系。本发明中主要针对两个对象，可认为是两个对象存在物理或者逻辑的连接。作为典型例子，可以列举两个设备之间端口的连接关系；

c)存在关系(Have Relationship)：表示告警源间存在a)或者b)之一的关系；

d)无关系(No relationship)：表示不考虑告警源的关系。

其中，告警时间之间的关系可为以下4种：

a)之前关系(Before Relationship)：表示根本原因告警发生在非根本原因告警之前；

b)之后关系(Before Relationship)：表示根本原因告警发生在非根本原因告警之后；

c)交迭关系(OverLap Relationship)：表示时间关系存在a)或者b)之一；

d)无关系(No Relationship)：表示不考虑告警时间关系。

以下为一规则的简单例子：

  Rule 01

  {

  告警原因关系(a10，a7)，

  告警对象关系(Contained)

  告警时间关系(No Relationship)

  结果(a10为a7的根本原因)

  }

其中，定义要比较的告警为a10，a7，告警对象之间的关系为包含关系，告警时间的关系为不考虑。如果存在a10，a7，并符合该规则的条件，则能得出a10为a7的根本原因。

规则管理模块1016主要负责告警规则的管理。如图2所示，网络管理员可通过客户端在线创建关联规则。新创建的规则有标记指示该规则是否立刻激活。如果规则非立刻激活，在关联分析中它不会被考虑。根据***参数的设置，规则既可以被保存到数据库，也可以被保存到文件里。除了在线的规则创建外，用户也可以通过工具离线批量创建规则。创建完成后，工具软件可以通过特定的接口以XML文件的方式把规则提交给规则管理模块1016。

在关联规则分析比较中，对于告警源关系的比较主要依赖于告警对象树。告警对象树是一棵保存于内存的对象关系树，它不是完整MOR的复制，树里的对象仅包含MOR中能作为告警源的对象子集。这可以大大缩小分析所需要比较的对象集。由于告警对象树只是MOR的子集，为此需要对从TM到告警对象树的适配进行定义。因此，在图2所示的网络管理***(NMS)还需要设置有用于进行从MOR到告警对象树的适配的对象适配器1030。

图6是表示对象树管理模块1071的架构图。如图6所示，它包含3个重要部分：核心告警对象树1031、对象查找服务模块1032以及对象更新助手模块1033。

其中，核心告警对象树1031管理具有层次关系的对象。

为了有效支持关联分析的进行，告警对象树需要提供根据对象名字、或者根据对象的父节点的名字、或者根据存在连接关系对象的名字快速找到对象的服务，这由对象查找服务模块1032来完成。对象查找服务模块1032通过建立3个索引集分别提供了根据对象名字查找对象自身、根据对象名字查找对象包含的对象集、以及根据对象查找跟对象存在连接关系的对象集的服务。

对象更新助手模块1033用于通过对象适配器1030注册到TM模块并监听MOR中对象更新消息，负责对象告警对象树与MOR的同步。

管理不同网络的网管，其对象模型通常变化比较大。基于特定通讯模型的关联分析，比较精确，但往往也非常复杂，也难以通用。

与此相对，本发明的实施方式中建立了一套简单的、通用的对象层次模型，它把管理对象间的复杂关系归结为包含关系和一般连接关系两种，由此简化了对象模型的复杂度。另外，该模型还支持实时维护对象和告警的关联关系，能很好地缩小关联分析要处理的告警集，从而提供高效率的分析。

在本发明中，对象层次模型有两种建立方式：(1)静态建立方式：组是要由特定的对象服务工具例如图2中所示的对象服务工具1040(将在下文进行描述)来建立；(2)动态建立方式：由图2中所示的对象适配器1030从MOR中进行建立。

对象树是对象模型的一个实例，它是采用本发明中提出的通用模型，从实际的MOR中建立起来的。

图7是表示本发明实施方式的告警对象树模型的定义图。其中，如图7所示：

a)接口Container建模了资源之间的层次包含关系。Container能包含孩子节点，在拓扑结构上，这表现为物理包含或者逻辑包含关系。如机筐和机筐下的板子就是一种典型的物理包含关系；

b)接口Group建模了资源之间的一般连接关系。如两个端口通过同一条链路相连；

c)接口AlarmHolder定义了支持告警绑定和解除绑定的对象特性。该接口使得关联的告警能被绑定到对象的关联列表上；

d)类CorrelationObject定义了告警对象树上一般对象的特性。它同时实现了Container和AlarmHolder接口，这表明任何一个告警对象树对象都可以包含孩子节点以及支持告警绑定。此外，它还选择性地包含Group接口，用以支持对象的一般连接关系。

告警对象树提供服务之前，必须要进行初始化。

图8是表示告警对象树初始化的流程图。如图8所示，具体流程包括：

(1)网管启动时，关联分析主进程被启动，告警对象树初始化被调用；

(2)告警对象树请求对象适配器1030根据固定的接口条款返回对象层次树关系；

(3)对象适配器1030收到请求后，转而向网络拓扑管理模块1020请求返回MOR层次树；

(4)对象适配器1030根据与告警对象树订立的条款，进行适当的转换，然后把对象层次关系返回给告警对象树；

(5)告警对象树生成适用于关联分析的告警对象树实例，并初始化查找服务的3个索引集；

(6)告警对象树创建对象更新助手对象实例；

(7)对象更新助手模块1033向对象适配器1030发出对象更新的注册请求；

(8)对象适配器1030转而向网络拓扑管理模块1020注册对象更新。

此外，当MOR有对象被创建、删除或者更新时，告警对象树需要同步这些更新。在上述的对象树初始化流程里，对象更新助手模块1033已经被创建并且向对象适配器1030注册对象更新通知。当对象适配器1030收到消息时，它会根据固定规则把更新应用到告警对象树。

图9是表示告警对象树动态更新的流程图。如图9所示，告警对象树更新流程包括：

(1)对象适配器1030收到来自网络拓扑管理模块1020的对象更新消息；

(2)对象适配器1030判别该更新消息是否需要通知告警对象树，如果不需要，则直接结束处理(由于告警对象树是MOR的子集，故非所有消息都需要通知告警对象树)。否则，根据与告警对象树订立的条款，进行适当的消息转换；

(3)对象更新助手模块1033按照以下规则处理从对象适配器1030发送来的消息，更新告警对象树；

a)如果为对象添加消息：通过对象查找服务，找到对象被添加的父节点，把新加的对象加入到告警对象树上；

b)如果为对象删除消息：通过对象查找服务，找到对象被删除的父节点，把删除的对象从告警对象树上删除；

c)如果为对象更新消息：检查更新后的父节点，如果层次结构没有发生变化，则忽略该消息；如果层次结构发生变化，如节点的移动，则把该消息分成两步骤处理，先按b)把对象从原来的父节点中删除，然后再按a)在新父节点中添加；

d)如果是对象一般连接关系变化消息：通过对象查找服务，找到关系建立的这两个节点。如果为对象连接关系建立，在各自维护的关系列表里把对方添加进去。如果为对象连接关系解除，则把对象从各自维护的关系列表中删除。

(4)对象更新助手模块1033更新完告警对象树后，同时更新对象查找服务模块1032的3个索引集。

然而，有时从MOR到告警对象树的转换逻辑可能非常复杂的，简单的适配器难以实现该逻辑，这种情况下则需要专门的工具来进行这种转换。

为此，可以在图2所示的网络管理***1000中进一步增加设置对象服务工具(MO Service Tool)1040，它是一种可选的离线的转换工具，可由网络管理员通过客户端进行操作管理。对象服务工具1040根据预配置XML文件的指导，把MOR中的对象按照固定的接口条款转换。和原来的初始化流程相比，告警对象树初始化时，不再从对象适配器1030而是从对象服务工具1040的特定输出创建告警对象树。这种情况下，还需要把对象更新助手模块1033的创建及注册部分从初始化流程中删除。此外，由于不需要同步对象更新，故原来的对象更新流程也不再需要。

告警绑定管理模块1019把告警实时地绑定到告警对象树里的对象，告警绑定管理模块1019从告警接收器1017接收来自核心处理模块1011的告警消息，根据告警源字段，确定要关联的对象，然后把告警放到对象的告警列表里，这个过程称为从告警到对象的绑定过程。

告警绑定管理模块1019除了支持一般绑定过程外，还通过相关服务支持对告警对象树的查询，例如，获取跟指定对象有包含关系或连接关系的对象、获取对象所绑定的告警列表等等。告警关联分析过程中，对于告警关系的比较就需要频繁的使用上述这些查询。

图10是表示告警绑定和解除绑定的流程图。如图10所示，告警绑定和解除绑定的流程如图10所示：

(1)告警接收器1017从核心处理模块1011接收到告警消息；

(2)告警接收器1017进行消息转换，把告警消息转换成适用于关联分析的内部消息。其中，关联分析主要与告警模型中的特征字段相关，如告警原因、告警源、告警时间、告警级别等，其他字段可忽略。这既可以减少告警对象树的内存消耗，也使得关联分析不依赖核心告警对象定义，使得关联分析过程更具模块独立性；

(3)告警绑定管理模块1019从告警接收器1017接收转换后的消息：

a.如果它为非清除消息，则根据告警源字段把它绑定到相应告警对象树里的对象上；

b.如果它为清除消息，则根据告警源字段把它从告警对象树上的相应对象绑定列表里删除；

(4)告警绑定管理模块1019把消息发送到关联分析引擎模块1018进行关联分析处理。

关联分析引擎模块1018是关联分析的核心，它根据规则，借助告警对象树的帮助进行关联性分析，找出根本原因告警。

图11是表示进行关联引擎所相关的各部分框图。

如图11所示，在关联分析引擎模块1018中进一步设置过滤器管理模块(Filter Manager)1072，它主要是根据用户制定的过滤条件把不需要进行关联分析的告警剔除出去，这可以缩小告警关联分析所作用的告警集，从而提高关联分析的性能。

为了提高关联分析的并发度，关联线程池(Correlation ThreadPool)1073管理着多个关联分析的线程。关联线程的管理策略是为每个规则分配一个固定的关联线程。

图12是表示告警关联性分析的过程的流程图。如图12所示，告警关联性分析的详细流程如下：

(1)告警接收器1017接收从核心处理模块过来的告警消息，做一些特定的预处理，例如消息转换，把告警消息转换成关联分析内部消息；

(2)消息然后被送到过滤器管理模块1072，利用过滤器管理模块用户可以设定关联性分析的过滤条件，过滤器管理模块1072负责把不需要进行分析的告警剔除；

(3)告警绑定管理模块1019根据告警关联对象的名字，通过对象树管理模块1071的告警对象树服务，把告警绑定到告警对象树或从告警对象树里解除绑定；

(4)消息被送入先进先出的队列，等候线程池里的处理线程来处理；

(5)线程池对每个已配规则创建一个单独的处理线程，消息由单独的消息分派器分发到各处理线程，处理线程在告警对象树和规则引擎的协助下进行关联分析；

(6)处理线程调用规则引擎的服务，检查进来的告警是否满足当前规则；

(7)如果告警不满足当前规则则处理结束，否则转入下一步；

(8)处理线程根据当前告警的告警源以及规则定义的告警源关系，通过管理告警对象树获取满足规则的待比较的告警集；

(9)处理线程进行居于规则的关联分析。此过程还需多次跟规则引擎的交互，以进行特定条件的判别；

(10)处理线程把关联分析结果通过接口(CEToFaultInterface)返回给告警核心处理模块。

图13是表示一般告警关联分析的简单实例的示意图。在图13中，实线箭头线代表层次包含关系，虚线代表一般连接关系，其中MOI 2和MOI 3存在一般的连接关系(绑定关系)，节点的包含关系则如树所示。假设告警对象树已经绑定了9个告警，分别为：

MOI 2：a1，a2，a3

MOI 4：a4，a5，a6

MOI 4：a7，a8，a9

并假定规则为前述例子中定义的规则Rule 01。则当新告警a10到来的时候，规则引擎发现它匹配规则Rule01，关联分析过程被启动。由于告警源关系定义为包含关系，则MOI 4成为规则引擎比较时的匹配对象。规则引擎查找MOI 4，发现符合条件的关联告警a7，最后根据时间关系(这里定义为不考虑时序)，得出a10为根本原因告警。

经过告警分析后，关联分析需要把分析的结果：根本原因告警以及被其包含的非根本原因告警返回给核心处理模块，并最终更新客户端界面使得用户看到分析后的结果。

图14是表示层次树的根本原因告警及其包含的告警之间的关系的示意图。

另外，在本实施方式中还可以采用一种2次更新的告警展示方法，即，在告警关联分析前后，展示告警给用户，该过程的顺序如下：

1)告警产生后，立刻被送到告警客户端，以根本原因方式展示；

2)告警同时被送到告警关联分析模块，进行根本原因分析；

3)根本原因分析结果出来后，分析模块把结果返回给核心处理模块并保存进入数据库；

4)核心分析模块把结果发送给客户端，客户端更新显示。

当告警关联分析模块处理性能很好，关联分析所需要的时间几乎可被忽略的时候，管理员能实时地观察到最终的关联分析结果。

由于线程池对处理线程的管理是基于规则的，因此当规则添加、删除的情况下，需要动态创建或者关闭相应的处理线程，具体地：

1.当规则添加的情况下，线程池的处理流程如下：

(1)规则管理接收管理员从客户端发出的规则创建请求；

(2)规则管理对规则进行有效检查并把之持久化(文件或者DB)，如果没有异常，返回规则创建成功提示给管理员；

(3)如果规则非激活，则中止处理，否则，进入步骤(4)；

(4)规则管理通知线程池管理关于新规则的创建；

(5)线程池管理者创建新的关联线程，执行该关联线程的初始化，并把规则ID和对应的处理线程放进其所管理的映射表(这里，映射表的作用在于维护规则以及其处理线程的对应关系)；

2.当规则删除的情况下，线程池的处理流程如下：

(1)规则管理接收管理员从客户端发出的规则删除请求；

(2)规则管理根据对应的规则ID找到规则，把它从***中删除，然后返回删除成功提示给管理员；

(3)如果删除的规则原来为非激活状态，则中止处理；否则，进入步骤(4)；

(4)规则管理通知线程池管理关于规则的删除；

(5)线程池根据规则ID在其映射表里找到对应的处理线程，调用其退出方法以关闭其实例，然后把规则ID和处理线程从映射表中移除。

如上所述，在本发明中，针对利用SNMP的网络管理提供一种故障分析***以及方法，其中，定义了一套标准的SNMP Trap格式，用以标准化设备向网管发送的告警格式，并通过在网管拓扑管理模块采用统一的层次命名管理，使得告警翻译以及告警到对象的关联简单、统一化。

在此基础上，构造了一个具有简单层次关系的不依赖于特定通讯模型的管理告警对象树。接收到的告警根据其所关联的告警源被实时地关联到告警对象树中的相应的节点。告警对象树建模实际网络里对象间复杂的拓扑关系，把其归结为包含关系和一般连接关系两种，简化了对象关系的复杂度。

另一方面，在本发明中，允许用户定制包含告警原因、告警源、告警时间等主要特征字段的关联规则，并结合该通用的对象层次模型树来进行基于规则的关联分析。告警关系反映了不同类型告警之间的关系；告警源关系反映了告警产生时，告警所关联的对象的拓扑关系；而告警时间则反映了不同告警发生时的时序关系。

以上，参照附图对本发明的具体实施方式作了具体描述，然而，本领域中的普通技术人员应当理解，在不偏离本发明的精神和由权利要求书所限定的保护范围的情况下，本领域中的普通技术人员还可以对具体实施方式中所给出的情况作各种修改。因此，参照上述附图对本发明所作的具体实施方式描述不应当被看作是对本发明的限定。

应理解，在此描述的***和模块可在硬件、软件或硬件和软件的结合中实现。它们可通过任何形式的计算机***来实现或适用于实现在此描述的方法的其它设备。典型的硬件和软件的结合可以是有计算机程序的通用计算机***，当被加载并执行时，该计算机程序对该计算机***进行控制以使其实现在此描述的方法。作为选择，可利用一专用硬件。本发明亦可嵌入一计算机程序产品，该产品包括所有能实现在此描述的方法和功能的特征，并当在计算机***中被记载时能实现这些方法而功能。

Claims (22)

1.一种故障关联分析***，用于对被管网络产生的故障进行故障关联分析以找出根本故障原因，所述被管网络和所述故障关联分析***基于特定的网络管理协议进行信息交互，其特征在于，

所述故障关联分析***具备：用于进行故障管理的故障管理模块(1010)；以及用于维护被管网络的管理对象信息库的网络拓扑管理模块(1020)，

其中，所述故障管理模块(1010)具备：用于对故障的告警进行核心处理的告警核心处理模块(1011)；以及用于根据得到的告警基于特定逻辑关系进行关联分析以找出根本故障原因的告警关联模块(1015)。

2.如权利要求1所述的故障关联分析***，其特征在于，

所述告警核心处理模块(1011)具备：从所述被管网络接收基于所述网络管理协议的消息并且进行解析以生成统一的告警源信息的协议消息接收和翻译器(1012)；根据生成的统一的告警源信息分析出告警对象并返回给所述协议消息接收和翻译器(1012)的对象***(1013)；以及根据所述协议消息接收和翻译器(1012)提供的告警对象进行核心处理的核心处理模块(1014)。

3.如权利要求1所述的故障关联分析***，其特征在于，

所述特定逻辑关系是告警特征字段组成的规则比较。

4.如权利要求3所述的故障关联分析***，其特征在于，

所述规则比较包括：告警原因关系比较、告警对象关系比较以及告警时间关系比较。

5.如权利要求4所述的故障关联分析***，其特征在于，

所述告警对象关系是由表示告警对象之间的相互关系的告警对象树来表示。

6.如权利要求5所述的故障关联分析***，其特征在于，

所述告警关联模块(1015)具备：用于管理规则的规则管理模块(1016)；用于从告警核心处理模块(1011)接收告警的告警接收器(1017)；用于管理和维护告警对象树的告警对象树管理模块(1071)；用于将告警绑定到告警对象树的告警绑定管理模块(1019)；用于将接收到的告警以及已经存在的告警基于所述告警对象树中的相互关系进行关联分析并找出其中的根本原因告警的关联分析引擎模块(1018)。

7.如权利要求2所述的故障关联分析***，其特征在于，

在所述网络拓扑管理模块(1020)具备对管理范围内的对象按照统一规则进行命名的命名服务模块(1021)，

所述对象***(1013)对接收的告警源信息进行转换时调用所述命名服务模块(1021)，得到告警源的名字，并把名字返回给所述协议消息接收和翻译器(1012)进行分析以得到告警对象。

8.如权利要求5所述的故障关联分析***，其特征在于，

所述告警对象树保存在故障关联分析***的内存中，包含所有能够作为告警源的对象。

9.如权利要求8所述的故障关联分析***，其特征在于，

还进一步增加设置用于进行从拓扑管理模块的管理对象库到告警对象树动态适配的对象适配器(1030)、以及用于静态转换的对象服务工具(1040)。

10.如权利要求5所述的故障关联分析***，其特征在于，

所述关联引擎模块(1018)具备：根据用户制定的过滤条件把不需要进行关联分析的告警剔除的过滤器管理模块(1072)；以及管理多个关联分析线程的关联线程池管理模块(1073)。

11.一种故障关联分析方法，用于对被管网络产生的故障进行故障关联分析以找出根本故障原因，所述被管网络和所述故障关联分析***基于特定的网络管理协议进行信息交互，其特征在于，所述方法包括下述步骤：

从所述被管网络基于所述网络管理协议接收并解析故障告警信息的接收步骤；

对接收到的故障告警消息进行核心处理以获得告警对象的核心处理步骤；以及

根据得到的告警对象通过特定逻辑关系进行关联分析以找出根本故障原因的告警关联步骤。

12.如权利要求11所述的故障管理分析方法，其特征在于，

在所述接收步骤中，从所述被管网络接收基于所述网络管理协议的消息并且进行解析以生成统一的告警源信息，

在所述核心处理步骤中，根据生成的统一的告警源信息分析得出告警对象。

13.如权利要求11所述的故障关联分析方法，其特征在于，

所述特定逻辑关系是指告警特征字段组成的规则比较。

14.如权利要求13所述的故障关联分析方法，其特征在于，

所述规则比较包括：告警原因关系比较、告警对象关系比较、以及告警时间关系比较。

15.如权利要求14所述的故障关联分析方法，其特征在于，

所述告警对象关系是由表示告警对象之间的相互关系的告警对象树来表示。

16.如权利要求15所述的故障关联分析方法，其特征在于，定义所述告警对象树的模型包括：

定义建模了告警对象之间的层次包含关系的第一接口；

定义建模了告警对象之间的一般连接关系的第二接口；

定义支持告警绑定和解除绑定的对象特性的第三接口；以及

定义表示告警对象树上一般对象的特性的第四接口。

17.如权利要求16所述的故障关联分析方法，其特征在于，

告警对象树的初始化包括下述步骤：

(1)告警对象树初始化被调用；

(2)告警对象树请求所述对象适配器根据所述第一～第四接口，返回告警对象的层次关系；

(3)所述对象适配器从所述拓扑管理模块获取管理对象信息，按照所述模型进行转换，然后将对象层次关系返回给告警对象树；

(4)告警对象树生成适用于关联分析的告警对象树实例。

18.如权利要求16所述的故障关联分析方法，其特征在于，

告警对象树的更新包括下述步骤：

(1)***初始化时，向对象适配器注册对象更新通知监听；

(2)收到对象更新信息，判断是否需要通知告警对象树；

(3)如果判断为需要通知告警对象树，则进行适当的消息转换；以及根据转换后的消息，更新告警对象树。

19.如权利要求12所述的故障关联分析方法，其特征在于，在所述告警关联步骤中，包括下述步骤：

(1)接收告警消息的接收步骤；

(2)将告警消息转换成包含特征字段的用于关联分析的内部消息的转换步骤；

(3)根据所述内部消息，把告警绑定到告警对象树或从告警对象树里解除绑定的告警绑定/解除绑定步骤；

(4)将接收到的告警以及已经存在的告警基于所述告警对象树中的特定逻辑进行关联分析以找出其中的根本原因告警的关联分析步骤。

20.如权利要求19所述的故障管理分析方法，其特征在于，

在所述告警绑定/解除步骤中，若所述内部消息为非清除消息，则将告警绑定到告警对象树上；若所述内部消息如果它为清除消息，则将告警从告警对象树上解除绑定。

21.如权利要求12所述的故障管理分析方法，其特征在于，在所述关联关联步骤中，进一步包括：

根据用户制定的过滤条件把不需要进行关联分析的告警剔除的过滤管理步骤。

22.如权利要求13所述的故障管理分析方法，其特征在于，

能够由用户定制所述告警特征字段组成的规则比较。

Images