CN103607295A - 一种告警处理的方法及告警系统 - Google Patents

Abstract

本发明提供一种告警处理的方法及告警系统，该方法包括：接收告警消息；根据预存的告警关系分析所述告警消息，查找根源告警并处理。通过本发明能够迅速找到根源告警，并对相关联的告警进行合理展现，以便于运维人员迅速定位问题。

Description

一种告警处理的方法及告警系统

技术领域

本发明涉及网络通信领域，特别是涉及一种告警处理的方法及告警系统。

背景技术

通常，当网元设备发生故障时，设备告警信息会上报到告警系统（模块），从而完成网元设备的状态监控和故障管理。目前网元设备发生故障时，由于通信系统中的系统相关性和检测机制等原因，往往会上报多个相关告警，这其中包括根源告警以及由该根源告警引发的其他告警。例如，市电停电产生的一系列告警，如市电输入为零、UPS（Uninterruptible Power Supply，不间断电源）整流器停止工作、电池放电等等。这个时候产生的大量告警信息如果同时发送，不但会对告警系统（模块）容量造成冲击，而且事件根源信息也容易被淹没在海量告警信息中，直接导致用户很难及时分析大量的告警信息，从中找到故障源，以准确定位系统产生故障的原因。

发明内容

本发明要解决的技术问题是提供一种告警处理的方法及告警系统，以便于迅速找到根源告警。

为了解决上述技术问题，本发明提供了一种处理告警的方法，包括：

接收告警消息；

根据预存的告警关系分析所述告警消息，查找根源告警并处理。

进一步地，上述方法还具有下面特点：所述预存的告警关系包括：

在配置管理数据库中预存的设备之间的连接关系和告警关联关系；

在关系数据库中预存告警类型之间的告警关联关系。

进一步地，上述方法还具有下面特点：所述分析所述告警消息包括：

分析所述告警发生的设备和所述告警的类型。

进一步地，上述方法还具有下面特点：

所述告警消息为发生告警，所述根据预存的告警关系分析所述告警消息，查找根源告警并处理，包括：

查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在子告警，如存在，则将子告警作为根源告警的记录删除；如不存在，则查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在父告警，如存在，则将所述告警作为根源告警的记录删除，如不存在，则所述告警为根源告警。

进一步地，上述方法还具有下面特点：

所述告警消息为告警恢复，所述根据预存的告警关系分析所述告警消息，查找根源告警并处理包括，

查找当前要恢复的告警的所有直接子告警；

遍历每一条所述直接子告警，如所述直接子告警没有别的父告警，则将所述直接子告警作为根源告警，然后删除当前要恢复的告警，如所述直接子告警有别的父告警，则删除当前要恢复的告警和所述直接子告警的父子关系及删除当前要恢复的告警。

为了解决上述问题，本发明还提供了一种告警系统，包括：

接收模块，用于接收上报的告警消息；

处理模块，用于根据预存的告警关系分析所述告警消息，查找根源告警并处理。

进一步地，上述告警系统还具有下面特点：所述处理模块分析的预存的告警关系包括：

在配置管理数据库中预存的设备之间的连接关系和告警关联关系；

在关系数据库中预存告警类型之间的告警关联关系。

进一步地，上述告警系统还具有下面特点：

所述处理模块，分析所述告警消息包括：分析所述告警发生的设备和所述告警的类型。

进一步地，上述告警系统还具有下面特点：

所述接收模块，接收到的告警消息为发生告警；

所述处理模块包括：

分析单元，用于查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在子告警，如存在，则将子告警作为根源告警的记录删除；如不存在，则查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在父告警，如存在，则将所述告警作为根源告警的记录删除，如不存在，则所述告警为根源告警。

进一步地，上述告警系统还具有下面特点：

所述接收模块，接收到的告警消息为告警恢复；

所述处理模块包括：

恢复单元，用于查找当前要恢复的告警的所有直接子告警；遍历每一条所述直接子告警，如所述直接子告警没有别的父告警，则将所述直接子告警作为根源告警，然后删除当前要恢复的告警，如所述直接子告警有别的父告警，则删除当前要恢复的告警和所述直接子告警的父子关系及删除当前要恢复的告警。

综上，本发明提供一种告警处理的方法及告警系统，能够迅速找到根源告警，并对相关联的告警进行合理展现，以便于运维人员迅速定位问题。

附图说明

图1为本发明实施例的处理告警的方法的流程图；

图2为本发明一应用示例的处理告警的方法的流程图；

图3为本发明实施例的告警系统的示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。

图1为本发明实施例的处理告警的方法的流程图，如图1所示，本实施例的方法包括：

S11、接收上报的告警消息；

S12、根据预存的告警关系分析所述告警消息，查找根源告警并处理。

其中，所述预存的告警关系包括：

在CMDB（Configuration Management Database，配置管理数据库）中预存的设备之间的连接关系和告警关联关系；在关系数据库中预存告警类型之间的告警关联关系。

本发明实施例的智能告警关联方法，可以在海量告警中迅速找到根源告警，以定位和解决问题。

以下以一具体应用示例对本发明的方法进行详细说明。

图2为本发明一应用示例的处理告警的方法的流程图，如图2所示，本示例包括以下步骤：

步骤101，CMDB预存设备之间的告警关联关系；

为了使所管设备之间的连接、安装等关系更直观，通过CMDB将其进行虚拟化，在本发明实施例中，针对于物理上没有连接关系但实际确实存在告警关联的情况，CMDB中需要额外预设多个设备之间的告警关联关系：表征当前设备发生告警可能是由哪些设备产生告警引起的以及当前设备发生告警可能引起哪些设备发生告警。

由于设备之间具有物理上的连接关系（ConnectTo，A ConnectTo B表征A设备连接到B设备上，一般的，由于其物理上的连接关系，B设备发生告警可能会引起A设备也产生告警），因此产生的告警也具有一定的关联性，但由于存在物理上没有连接关系但实际确实存在告警关联的情况，因此需要额外整理出设备的AlarmTo（告警关联）关系以使告警关联分析的结果更准确。为了使这种关系一目了然，可将AlarmTo关系存入CMDB。

告警的AlarmTo关系可以描述为A AlarmTo（B、C），表示A设备发生告警，可能是由B设备或者C设备的相关告警引起的。AlarmTo关系具有一定的传递性。假设存在A AlarmTo（B、C），D AlarmTo（A），E AlarmTo（A）三个关联关系，则可得B设备或者C设备产生告警可能导致A设备产生告警，进而可能导致D设备和E设备产生告警。

由于AlarmTo关系并不是CMDB中固有的关系，因此需要先建立此关系，然后建立设备的告警关联时才能引用AlarmTo关系。

步骤102，关系型数据库中初始化具体告警码之间的关联关系：表征当前类型的告警可能是由别的哪些类型的告警引起以及当前类型的告警可能引起哪些类型的告警。

关系数据库预存告警码之间的告警关联关系：

通常告警码可以表征设备发生了什么样的告警，为了使关联告警分析更精确，需要把告警码之间的关联关系也保存起来，存为告警码关联表。告警码的关联关系明确当前告警码可能有哪些告警码引起以及当前告警码可能引起哪些告警码。

步骤103，告警系统接收到告警之后，进行关联告警分析：

A、分析当前告警以确定是哪个设备发生的哪种告警码的告警，通过查询CMDB的设备连接关系和告警关联关系，找到此设备发生告警可能导致哪些设备发生告警，再查询关系型数据库中告警码之间的关联关系，找到此告警码可能导致哪种告警码发生，再结合CMDB的查询结果，在当前所有已存在的告警中找是否有满足条件的告警，若存在，此即为当前告警的子告警（比如：A设备的某条告警a可引起B设备的某条告警b，在这种情况下，a告警就是b告警的父告警，b告警就是a告警的子告警），若不存在，则不处理。

B、通过查询CMDB的设备连接关系和告警关联关系，找到此设备发生告警可能是由于哪些设备产生告警导致的，再查询关系型数据库中告警码之间的关联关系，找到此告警码可能是由哪种告警码导致的，再结合CMDB的查询结果，在当前所有已存在的告警中找是否有满足条件的告警，若存在，此即为当前告警的父告警，若不存在，当前告警即为根源告警。

比如：A设备的某条告警a（告警码是aa）可能引起B设备的某条告警b（告警码是bb），通过CMDB里A的设备连接关系和告警关联关系可以找到B，查询关系库通过aa可以查到bb，然后在当前所有已经存在的告警中查找是否有满足条件的告警，此处条件是指：是否有B设备发生的告警码是bb的告警存在。已经存在的每条告警都包含这样的信息：什么设备发生的什么告警码的告警，所以这个查找就是简单的匹配。

本实施例中，告警系统接收到告警之后，将当前告警作为根源告警，并找到发生告警的设备（curDev）以及告警码（curAlarmCode）。

查询当前告警的子告警：根据curDev反查CMDB，找到当前设备被AlarmTo的设备即为sonDevs（子告警设备），若不存在，则查当前设备被ConnectTo的设备即为sonDevs，根据curAlarmCode查告警码关联表，找到当前告警码可能引起的告警码sonAlarmCodes（子告警码），结合sonDevs和sonAlarmCodes在当前所有已存在的告警中找是否有符合条件的告警，若有，则为当前告警的子告警，将此子告警归在当前告警下，将子告警作为根源告警的记录删掉，若无，则到下一步，查询是否有父告警。

查询当前告警的父告警：根据curDev反查CMDB，找到当前设备AlarmTo的设备即为fartherDevs，若不存在则查当前设备ConnectTo的设备即为fartherDevs，根据curAlarmCode查告警码关联表，找到当前告警码可能由哪些告警码引起，这些告警码即为fartherAlarmCodes，结合fartherDevs和fartherAlarmCodes在当前所有已存在的告警中找是否有符合条件的告警，若有，则为当前告警的父告警，将当前告警归在父告警下，将当前告警作为根源告警的记录删掉，若无，则当前告警为根源告警，不处理。

步骤104，告警系统接收到告警恢复消息之后，进行如下处理：将当前告警删除掉，并且将当前告警的直接子告警置为根源告警。

告警系统接收到告警恢复之后，先找到当前要恢复告警的所有直接子告警。遍历每一条直接子告警，若子告警没有别的父告警，则将此子告警作为根源告警，然后删除当前告警，否则，只删除子告警与当前要恢复告警的父子关系即可。

举个实际例子：比如空调的回风高温告警（a告警）和内风机故障的告警（b告警）都可能引起温湿度传感器的温度过高的告警（c告警），在这种情况下，c告警的父告警有两个a告警和b告警，c告警为a告警的直接子告警，此时，如果a告警恢复，不能简单的把c告警置为根源告警，因为c告警还有一个父告警b告警，因此，我们只需要把c告警和a告警的告警关联关系清除即可。这种情况下，若c告警没有别的父告警，那么a告警恢复之后，c告警就是根源告警。

针对每一条上报的告警都查找其父告警和子告警，这样系统中已经存在的告警关系实际是一个个像拓扑图一样的东西，为了使后续界面正确的展示告警关联关系，因此告警恢复的时候，当前告警恢复了，其直接子告警（举个例子，a告警引起b告警，b告警引起c告警，c告警引起d告警，这样b告警就是a告警的直接子告警，但是c和d告警就不是a告警的直接子告警）就不应该在当前这个告警关联拓扑图上了（比如上个例子，b告警恢复了，那么c和d告警就不应该在abcd这四个告警组成的拓扑图上，b告警恢复之后，拓扑图就变成两个，一个是单独的a告警，一个是c告警引起d告警，而不能是a告警引起c告警，进而引起d告警，这样只有将子告警置为根源节点，后续界面才能正确显示）。

以上所述为针对一条上报的告警，进行告警关联分析，对每一条上报的告警都进行如上告警关联分析之后，即可得到当前所有告警的父子关系，进而找到所有的根源告警。

图3为本发明实施例的告警系统的示意图，如图3所示，本实施例的告警系统包括：

接收模块，用于接收上报的告警消息；

处理模块，用于根据预存的告警关系分析所述告警消息，查找根源告警并处理。

其中，所述处理模块分析的预存的告警关系包括：

在配置管理数据库中预存的设备之间的连接关系和告警关联关系；

在关系数据库中预存告警类型之间的告警关联关系。

其中，所述处理模块，分析所述告警消息包括：分析所述告警发生的设备和所述告警的类型。

在一优选实施例中，所述接收模块，接收到的告警消息为发生告警；

所述处理模块可以包括：

分析单元，用于查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在子告警，如存在，则将子告警作为根源告警的记录删除；如不存在，则查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在父告警，如存在，则将所述告警作为根源告警的记录删除，如不存在，则所述告警为根源告警。

在一优选实施例中，所述接收模块，接收到的告警消息为告警恢复；

所述处理模块包括：

恢复单元，用于查找当前要恢复的告警的所有直接子告警；遍历每一条所述直接子告警，如所述直接子告警没有别的父告警，则将所述直接子告警作为根源告警，然后删除当前要恢复的告警，如所述直接子告警有别的父告警，则删除当前要恢复的告警和所述直接子告警的父子关系及删除当前要恢复的告警。

本发明实施例的告警系统预存告警关联关系，包括CMDB中预存设备之间的连接关系和告警关联关系及关系数据库中预存告警码之间的告警关联关系。告警系统接收到每一条告警进行关联告警分析，找到当前告警的父告警和子告警，若找不到父告警，则当前告警即为根源告警。系统接收到告警恢复，需要将当前告警进行恢复，并将其直接子告警置为根源告警。

综上所述，本发明实施例根据CMDB和关系数据库中预存的告警关联关系，对每一条上报的告警进行关联告警分析，找到其父告警和子告警，以此找到根源告警，防止根源告警淹没在海量告警信息中，便于运维人员迅速定位和解决问题。

本发明实施例仅阐述实现告警关联的业务逻辑，以期使运维人员能在海量或者重复告警中找到真正的根源告警，迅速定位和解决问题。本发明实施例也并未特指网络管理系统，本发明适用于具有网络管理功能的各种系统，尤其涉及其中的告警相关模块。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本发明不限制于任何特定形式的硬件和软件的结合。

以上仅为本发明的优选实施例，当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，熟悉本领域的技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。

Claims (10)

1.一种处理告警的方法，包括：

接收告警消息；

根据预存的告警关系分析所述告警消息，查找根源告警并处理。

2.如权利要求1所述的方法，其特征在于：所述预存的告警关系包括：

在配置管理数据库中预存的设备之间的连接关系和告警关联关系；

在关系数据库中预存告警类型之间的告警关联关系。

3.如权利要求1所述的方法，其特征在于：所述分析所述告警消息包括：

分析所述告警发生的设备和所述告警的类型。

4.如权利要求1-3任一项所述的方法，其特征在于：

所述告警消息为发生告警，所述根据预存的告警关系分析所述告警消息，查找根源告警并处理，包括：

查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在子告警，如存在，则将子告警作为根源告警的记录删除；如不存在，则查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在父告警，如存在，则将所述告警作为根源告警的记录删除，如不存在，则所述告警为根源告警。

5.如权利要求1-3任一项所述的方法，其特征在于：

所述告警消息为告警恢复，所述根据预存的告警关系分析所述告警消息，查找根源告警并处理包括，

查找当前要恢复的告警的所有直接子告警；

遍历每一条所述直接子告警，如所述直接子告警没有别的父告警，则将所述直接子告警作为根源告警，然后删除当前要恢复的告警，如所述直接子告警有别的父告警，则删除当前要恢复的告警和所述直接子告警的父子关系及删除当前要恢复的告警。

6.一种告警系统，其特征在于，包括：

接收模块，用于接收上报的告警消息；

处理模块，用于根据预存的告警关系分析所述告警消息，查找根源告警并处理。

7.如权利要求6所述的告警系统，其特征在于：所述处理模块分析的预存的告警关系包括：

在配置管理数据库中预存的设备之间的连接关系和告警关联关系；

在关系数据库中预存告警类型之间的告警关联关系。

8.如权利要求6所述的告警系统，其特征在于：

所述处理模块，分析所述告警消息包括：分析所述告警发生的设备和所述告警的类型。

9.如权利要求6-8所述的告警系统，其特征在于：

所述接收模块，接收到的告警消息为发生告警；

所述处理模块包括：

分析单元，用于查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在子告警，如存在，则将子告警作为根源告警的记录删除；如不存在，则查询所述配置管理数据库和所述关系数据库，查找所述告警是否存在父告警，如存在，则将所述告警作为根源告警的记录删除，如不存在，则所述告警为根源告警。

10.如权利要求6-8任一项所述的告警系统，其特征在于：

所述接收模块，接收到的告警消息为告警恢复；

所述处理模块包括：

恢复单元，用于查找当前要恢复的告警的所有直接子告警；遍历每一条所述直接子告警，如所述直接子告警没有别的父告警，则将所述直接子告警作为根源告警，然后删除当前要恢复的告警，如所述直接子告警有别的父告警，则删除当前要恢复的告警和所述直接子告警的父子关系及删除当前要恢复的告警。

Images