CN104021195A - 基于知识库的告警关联分析方法 - Google Patents

Abstract

本发明提供了一种基于知识库的告警关联分析方法，包括：步骤1：获取告警总线中存在的告警信息；步骤2：对所述告警信息进行告警吸收关联分析，得到根源告警；步骤3：对所述告警信息进行告警推论关联分析，推论出新告警作为根源告警；步骤4：把关联分析的结果，通过置位关联标识符的方式，在告警总线中进行标识；步骤5：确定根源告警后，对子告警进行自动确认，并在关闭根源告警时同步关闭所有相关的子告警。本发明能够依据知识库中存储的告警吸收和告警推论的关联规则，对告警总线中的多个告警进行实时规则匹配，依次建立吸收关系和推论关系，形成树形结构，从而实时分析出根源告警，将衍生告警吸收，或者根据既有告警推论得出一个新告警。

Description

基于知识库的告警关联分析方法

技术领域

本发明涉及IT设备监控领域，尤其涉及一种基于知识库的告警关联分析方法。

背景技术

随着信息系统系统在各个行业中处于越来越重要的地位，对监控系统的要求也越来越高。目前，IT监控系统建设目标的主流技术定位是实现系统级监控。在这个阶段，IT监控系统不再注重“大而全”的单一商业化产品实现，而是各个机构结合自身的应用系统特点和管理要求，通过信息系统整合的方式，将多数据源的异构监控告警信息统一进行管理、关联分析，从而完成面向系统的监控。

目前IBM公司的NetCool产品、HP公司的Openview产品等均实现了通过统一的告警处理引擎对不同来源的底层监控平台获取的原始告警信息进行集中监控和管理。但是，这些产品在实时告警关联分析处理方面还比较薄弱甚至欠缺，同时由于缺乏统一的标准，告警关联分析在技术路线选择上和最终效果上都有一定的差别。从而导致告警信息泛滥，运维人员工作强度过大，运维效率偏低。

在实际的监控系统中，经统计发现告警在每天不是平均分布的，经常是在短时间内产生大量的报警。运维人员在处理告警时，有可能因为没有从大量告警中找到最主要告警信息而延误故障的处理时间。此外有些故障发生时，个别监控源的根源告警可能被阻塞，或者一些逻辑概念上的根源告警无法从监控系统直接获得，这些都会影响故障处理效率。因此针对以上的场景，需要一套算法来进行告警关联分析，减少无效报警，同时定位根源报警，即当多个关联告警同时发生时，可以根据多个告警有效分析出根源告警，将衍生告警吸收；或者可以根据多个既有告警推论得出一个新告警作为根源告警。

发明内容

有鉴于此，本发明提供了一种基于知识库的告警关联分析方法，能够依据知识库中存储的告警吸收和告警推论的关联规则，对告警总线中的多个告警进行实时规则匹配，依次建立吸收关系和推论关系，形成树形结构，从而实时分析出根源告警，将衍生告警吸收，或者根据既有告警推论得出一个新告警。并且能够在告警通知过程中，将告警直接通过展示层呈现，从而使运维人员能够快速并准确地定位故障。

本发明提供的基于知识库的告警关联分析方法，包括：

步骤1：获取告警总线中存在的告警信息；

步骤2：对所述告警信息进行告警吸收关联分析，得到根源告警；

步骤3：对所述告警信息进行告警推论关联分析，推论出新告警作为根源告警；

步骤4：把关联分析的结果，通过置位关联标识符的方式，在告警总线中进行标识；

步骤5：确定根源告警后，对子告警进行自动确认，并在关闭根源告警时同步关闭所有相关的子告警。

所述步骤2包括：

步骤2.1：基于特定吸收关联关系，对所述告警信息进行被吸收匹配；

步骤2.2：基于特定吸收关联关系，对所述告警信息进行吸收匹配；

步骤2.3：基于通用吸收关联关系，对所述告警信息进行被吸收匹配；

步骤2.4：基于通用吸收关联关系，对所述告警信息进行吸收匹配；

其中，所述通用吸收关联关系是指能够通过配置关联关系获得的具有明确因果关系的告警吸收关系；所述特定吸收关联关系是指目前无法通过配置关联关系获得明确因果关系的告警吸收关系，需要单独定义的告警吸收关系。

所述步骤2.1包括：

步骤2.1.1：从特定吸收关联关系中的首条规则开始；

步骤2.1.2：针对所述告警，判断其是否匹配特定吸收关联关系中当前规则的基本告警，即判断所述告警是否可被吸收，如果可被吸收，则进入步骤2.1.3；否则，进入步骤2.1.5；

步骤2.1.3：获取根源告警属性；

步骤2.1.4：判断告警内存库中是否存在匹配的根源告警，如果存在，则创建被吸收关系，然后进入步骤2.1.5；否则，直接进入步骤2.1.5

步骤2.1.5：逐条遍历所述特定吸收关联关系，如果遍历没有结束，则进入步骤2.1.2；否则进入步骤2.2。

所述步骤2.2包括：

步骤2.2.1：从特定吸收关联关系中的首条规则开始；

步骤2.2.2：针对所述告警，判断其是否匹配特定吸收关联关系中当前规则的根源告警，即判断所述告警是否可吸收其它告警，如果可以，则进入步骤2.2.3；否则，进入步骤2.2.5；

步骤2.2.3：获取基本告警属性；

步骤2.2.4：判断告警内存库中是否存在匹配的基本告警，如果存在，则创建吸收关系，然后进入步骤2.2.5；否则直接进入步骤2.2.5；步骤2.2.5：逐条遍历所述特定吸收关联关系，如果遍历没有结束，则进入步骤2.2.2；否则进入步骤2.3。

所述步骤2.3包括：

步骤2.3.1：从通用吸收关联关系中的首条规则开始；

步骤2.3.2：针对所述告警，判断其是否匹配通用吸收关联关系中当前规则的基本告警，即判断所述告警是否可被吸收，如果可被吸收，则进入步骤2.3.3；否则，进入步骤2.3.8；

步骤2.3.3：获取根源告警属主类型编码以及告警关联代码；

步骤2.3.4：获取根源告警编码；

步骤2.3.5：获取根源告警属主；

步骤2.3.6：获取根源告警；

步骤2.3.7：判断告警内存库中是否存在匹配的根源告警，如果存在，则创建被吸收关系，然后进入步骤2.3.8；否则直接进入步骤2.3.8；

步骤2.3.8：逐条遍历所述通用吸收关联关系，如果遍历没有结束，则进入步骤2.3.2；否则，进入步骤2.4。

所述步骤2.4包括：

步骤2.4.1：从通用吸收关联关系中的首条规则开始；

步骤2.4.2：针对所述告警，判断其是否匹配通用吸收关联关系中当前规则的根源告警，即判断告警是否可吸收其它告警，如果可吸收，则进入步骤2.4.3；否则，进入步骤2.4.8；

步骤2.4.3：获取基本告警属主类型编码以及告警关联代码；

步骤2.4.4：获取基本告警编码；

步骤2.4.5：获取基本告警属主；

步骤2.4.6：获取基本告警；

步骤2.4.7：判断告警内存库中是否存在匹配的基本告警，如果存在，则创建吸收关系，然后进入步骤2.4.8；否则，直接进入步骤2.4.8。

步骤2.4.8：逐条遍历所述通用吸收关联关系，如果遍历没有结束，则进入步骤2.4.2；否则，进入步骤3。

所述步骤3包括：

步骤3.1：基于特定推论关联关系，对所述告警信息进行推论匹配；

步骤3.2：基于通用推论关联关系，对所述告警信息进行推论匹配；

其中，所述通用推论关联关系是指能够通过配置关联关系获得的具有明确因果关系的告警推论关系；所述特定推论关联关系是指目前无法通过配置关联关系获得明确因果关系的告警推论关系，需要单独定义的告警推论关系。

所述步骤3.1包括：

步骤3.1.1：判断所述告警是否符合推论条件，如果满足，则进入步骤3.1.2；否则进入步骤3.2；

步骤3.1.2：获取推论代码；

步骤3.1.3：获取推论告警信息；

步骤3.1.4：创建推论告警；

步骤3.1.5：生成推论树，然后进入步骤3.2。

所述步骤3.2包括：

步骤3.2.1：判断所述告警是否符合推论条件，如果满足，则进入步骤3.2.2；否则结束；

步骤3.2.2：获取推论代码；

步骤3.2.3：获取推论告警信息；

步骤3.2.4：判断是否需要等待其他原始告警；如果需要，则进入步骤3.2.5；否则，进入步骤3.2.8；

步骤3.2.5：进行延时；

步骤3.2.6：判断延时是否超时，若未超时，则进入步骤3.2.7；否则结束；

步骤3.2.7：扫描告警内存库，判断具有相同的推论代码的原始告警是否都已出现，若是，则进入步骤3.2.8；否则，返回步骤3.2.5；

步骤3.2.8：创建推论告警；

步骤3.2.9：生成推论树并结束。

综上所述，本发明方法能够依据知识库中存储的告警吸收和告警推论的关联规则(通过对告警信息本身、外部数据依赖关系、告警发生的时段和频率甚至外部的问题支持数据库等信息的分析，得到这些规则)，对告警总线中的多个告警进行实时规则匹配，同时使用基于树形规则的相关性分析模型，来依次建立吸收关系和推论关系，并形成树形结构。从而使监控系统在多个关联告警同时发生，能够自动根据多个告警有效分析出根源告警，将衍生告警吸收；或者能够自动根据多个既有告警推论得出一个新告警。本发明方法能够实现对资源内部告警关联和跨资源关联的支持，可以有效减少告警数量，快速定位告警根源，从而大大减少运维人员人为处理的工作强度，显著提高运维效率。

附图说明

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

图1为本发明实施例提供的基于知识库的告警关联分析方法的流程示意图；

图2为吸收树原理图；

图3为告警吸收流程图；

图4为特定告警吸收规则E-R图；

图5为特定告警吸收流程图；

图6为告警属主与告警属主的关系E-R图；

图7为根源分析吸收树E-R图；

图8为告警关系E-R图；

图9为通用告警被吸收流程图；

图10为通用告警吸收流程图；

图11为推论树原理图；

图12为特定告警推论E-R图；

图13为特定告警推论数据结构关系图；

图14为特定告警推论流程图；

图15为通用告警推论E-R图；

图16为通用告警推论数据结构关系图；

图17为通用告警推论流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1为本发明实施例提供的基于知识库的告警关联分析方法的流程示意图，如图1所示，本实施例的基于知识库的告警关联分析方法，包括：

步骤1：获取告警总线中存在的告警信息；

步骤2：对所述告警信息进行告警吸收关联分析，得到根源告警；

根据告警的因果关系或既有知识的归纳总结，建立告警吸收关系规则库，对告警总线中的多个告警进行规则匹配，依次建立吸收关系，最终形成如图2所示的树形结构。

通用吸收规则：告警关联可以通过配置关联关系获得，具有明确的因果关系。

特定吸收规则：告警吸收关系目前无法通过配置关联关系获得明确的因果关系，但是具有一定的关联性，需要单独定义其关联规则。根据实际运维管理的需求，对特定的告警进行基于告警ID和属主ID的细颗粒度匹配，再继续进行通用吸收规则的匹配。

由于不同告警进入自监控源到告警总线时延不同，在对一个告警进行告警吸收分析时，不仅其父告警可能已经进入告警总线，其子告警也可能已经进入告警总线，因此，告警吸收分析需要进行吸收匹配和被吸收匹配两个过程。在规则匹配的操作上先进行被吸收匹配，再进行吸收匹配，流程如图3所示。

对于特定告警的告警吸收规则，建立单独的rootana_absorb_sp表，如表1所示。其判断流程较通用告警吸收算法简单。以实体-关系E-R图形式展现如图4所示：

表1特定告警根源分析吸收树表(rootana_absorb_sp)

特定告警吸收流程如图5所示：

新告警的ID字段EVENTID是否可以匹配上rootana_absorb表中的源告警ID字段A_EVENTID和源属主ID字段A_OWNER_ID以及源报警对象字段A_OBJECT_NAME。

如果有匹配，则直接查询告警窗口内，是否存在匹配的根告警ID字段R_EVENTID和根属主ID字段R_OWNER_ID和根报警对象字段R_OBJECT_NAME组合的告警

如果存在，则对源告警通过置位告警通知标志位(Acknowledged＝1)来进行确认。同时，在告警关系表(rootevent_rlt)中创建一条关系记录，将根告警的序列号作为R_SERIAL，将源告警的序列号作为O_SERIAL，关系类型定义为吸收告警(RlT_TYPE＝0)。逐条匹配特定吸收规则，如有多条匹配则记录多个被吸收规则。

新告警的ID字段EVENTID是否可以匹配上rootana_absorb表中的根告警ID字段R_EVENTID和根属主ID字段R_OWNER_ID和根报警对象字段R_OBJECT_NAME。

如果有匹配，则直接查询告警窗口内，是否存在匹配源告警ID字段A_EVENTID和源属主ID字段A_OWNER_ID以及源报警对象字段A_OBJECT_NAME组合的告警。

如果存在，则对源告警通过置位告警通知标志位(Acknowledged＝1)来进行确认。同时，在告警关系表(rootevent_rlt)中创建一条关系记录，将新告警作为根告警，将根告警的序列号作为R_SERIAL，将源告警的序列号作为O_SERIAL，关系类型定义为吸收告警(RlT_TYPE＝0)。逐条匹配特定吸收规则，如有多条匹配则记录多个吸收规则。

通用告警吸收过程的和逻辑比较复杂，调用的数据表也比较多，比特定吸收规则多了两个数据表：

告警属主与告警属主的关系表(eventowner_vs_owner)和属主类型关系表(rootowner_rlt)。

表2给出了告警属主与告警属主的关系表(eventowner_vs_owner)，用于存储源属主和根属主之间的关联关系。如表2所示，根据源属主ID和依赖关系ID可查询到被依赖属主ID。以实体-关系E-R图形式展现如图6所示：

表2告警属主与告警属主的关系表(eventowner_vs_owner)

表3给出了根源分析吸收树表(rootana_absorb)，用于存储源告警编码、源属主类型的组合与根告警编码、根属主类型的关联关系。根据源告警信息可查询到根告警属主类型编码和根告警编码以及依赖关系ID。依赖关系如果是同一个告警属主设置为SAMEOWNER；如果是同一报警设备设置为SAMEMACHINE；如果不是同一属主、同一报警设备，可以根据规则建立关系，如数据库故障，可建立依赖关系，其他设备访问此数据库的中间件、应用程序也会告警，两个告警为吸收关系。由于关联告警通常在一个时间段内发生，新告警发生时，并不需要将其和过早发生的告警进行吸收关系分析，设定告警窗口。以实体-关系E-R图形式展现如图7所示：

表3根源分析吸收树表(rootana_absorb)

表4给出了属主类型关系表(rootowner_rlt)，用于存储源属主、源属主类型和根属主、根属主类型的关联关系。存储非SAMEOWNER和SAMEMACHINE的告警属主类型依赖关系。这里使用告警属主类型编码进行吸收分析，主要目的是确定属主类型，缩小范围，再调用关系表eventowner_vs_owner，可有效减少查询消耗的内存数据库资源。

表4属主类型关系表(rootowner_rlt)

表5给出了告警关系表(rootevent_rlt)，主要用于存储告警之间的吸收关系。两个告警存在吸收关系，其中的根源(父)告警也可能是其他告警的原始(子)告警，因此，告警的吸收关系可能不只是两个层级，而是一个树形结构，我们需要找到的是最根源的告警进行处理，同时我们还希望了解这个最根源告警的衍生影响，因此，通过告警关系表可以有效的建立和维护树形吸收关系。以实体-关系E-R图形式展现如图8所示：

表5告警关系表(rootevent_rlt)

被吸收匹配流程图如图9所示：

告警流水表中的告警是否可以匹配上rootana_absorb表中源告警编码(A_EVENTID)和源告警属主类型编码(A_OWNER_CLASSID)。

如果有匹配，则查询rootown_rlt表，根据源告警属主类型编码A_OWNER_CLASSID获得根告警属主类型编码(R_OWNER_CLASSID)以及告警关联关系(relationship_id)。

查询rootana_absorb表，根据根源告警编码(A_EVENTID)、源告警属主类型编码(A_OWNER_CLASSID)、根告警属主类型编码(R_OWNER_CLASSID)以及告警关联关系(relationship_id)，可获取根告警编码(R_EVENTID)和根告警属主类型编码(R_OWNER_CLASSID)。

在eventowner_vs_owner表中查询，根据告警关联关系relationship_id、源属主ID(FROM_SDID)和被依赖属主ID(TO_SDID)是否有匹配项。可获得被依赖属主的ID字段OWNER_ID。

扫描告警内存库告警流水表中，时间窗口内所有告警编码为R_EVENTID且告警属主编码TO_SDID的告警。

如果存在，则告警被吸收关系确定，将源告警和根告警的主键Serial以及其父-子关系写入rootevent_rlt数据表，生成唯一的关系序列号(RELATIONKEY)，并生成关系创建时间。

逐条匹配通用吸收规则，如有多条匹配则记录多个被吸收规则。

吸收匹配流程如图10所示：

通用被吸收匹配完成后，系统会再查询该告警的TREVENTID是否可以匹配上rootana_absorb表中的根告警编码R_EVENTID和根属主类型编码R_OWNER_CLASSID；

如果有匹配，则查询rootowner_rlt表，根据根告警属主类型编码R_OWNER_CLASSID获得源告警属主类型编码(A_OWNER_CLASSID)以及告警关联关系(relationship_id)。

在eventowner_vs_owner表中查询告警关联关系relationship_id、源告警属主ID(FROM_SDID)和被依赖属主ID(TO_SDID)是否有匹配项，可获得源属主的OWNER_ID。

遍历告警内存库中时间窗口内是否存在告警编码为A_EVENTID且告警属主为FROM_SDID的告警。

如果存在，则可以确定源告警。告警吸收关系确定后，将告警告警的主键Serial和其父-子关系写入rootevent_rlt数据表。

告警关联关系对于互相关联告警集合，由于只有子告警和根告警存活于告警内存库中，需要对关联类告警标识符进行置位(TRRLTEVENT＝1)，证明告警为关联告警，则还需要对前置告警在恢复类根告警标识符进行置位(TRRECOVERYROOT＝1)

可选地，所述步骤2包括：

步骤2.1：基于特定吸收关联关系，对所述告警信息进行被吸收匹配；

进一步地，所述步骤2.1包括：

步骤2.1.1：从特定吸收关联关系中的首条规则开始；

步骤2.1.2：针对所述告警，判断其是否匹配特定吸收关联关系中当前规则的基本告警，即判断所述告警是否可被吸收，如果可被吸收，则进入步骤2.1.3；否则，进入步骤2.1.5；

步骤2.1.3：获取根源告警属性；

步骤2.1.4：判断告警内存库中是否存在匹配的根源告警，如果存在，则创建被吸收关系，然后进入步骤2.1.5；否则，直接进入步骤2.1.5

步骤2.1.5：逐条遍历所述特定吸收关联关系，如果遍历没有结束，则进入步骤2.1.2；否则进入步骤2.2。

步骤2.2：基于特定吸收关联关系，对所述告警信息进行吸收匹配；

进一步地，所述步骤2.2包括：

步骤2.2.1：从特定吸收关联关系中的首条规则开始；

步骤2.2.2：针对所述告警，判断其是否匹配特定吸收关联关系中当前规则的根源告警，即判断所述告警是否可吸收其它告警，如果可以，则进入步骤2.2.3；否则，进入步骤2.2.5；

步骤2.2.3：获取基本告警属性；

步骤2.2.4：判断告警内存库中是否存在匹配的基本告警，如果存在，则创建吸收关系，然后进入步骤2.2.5；否则直接进入步骤2.2.5；步骤2.2.5：逐条遍历所述特定吸收关联关系，如果遍历没有结束，则进入步骤2.2.2；否则进入步骤2.3。

步骤2.3：基于通用吸收关联关系，对所述告警信息进行被吸收匹配；

进一步地，所述步骤2.3包括：

步骤2.3.1：从通用吸收关联关系中的首条规则开始；

步骤2.3.2：针对所述告警，判断其是否匹配通用吸收关联关系中当前规则的基本告警，即判断所述告警是否可被吸收，如果可被吸收，则进入步骤2.3.3；否则，进入步骤2.3.8；

步骤2.3.3：获取根源告警属主类型编码以及告警关联代码；

步骤2.3.4：获取根源告警编码；

步骤2.3.5：获取根源告警属主；

步骤2.3.6：获取根源告警；

步骤2.3.7：判断告警内存库中是否存在匹配的根源告警，如果存在，则创建被吸收关系，然后进入步骤2.3.8；否则直接进入步骤2.3.8；

步骤2.3.8：逐条遍历所述通用吸收关联关系，如果遍历没有结束，则进入步骤2.3.2；否则，进入步骤2.4。

步骤2.4：基于通用吸收关联关系，对所述告警信息进行吸收匹配；

进一步地，所述步骤2.4包括：

步骤2.4.1：从通用吸收关联关系中的首条规则开始；

步骤2.4.2：针对所述告警，判断其是否匹配通用吸收关联关系中当前规则的根源告警，即判断告警是否可吸收其它告警，如果可吸收，则进入步骤2.4.3；否则，进入步骤2.4.8；

步骤2.4.3：获取基本告警属主类型编码以及告警关联代码；

步骤2.4.4：获取基本告警编码；

步骤2.4.5：获取基本告警属主；

步骤2.4.6：获取基本告警；

步骤2.4.7：判断告警内存库中是否存在匹配的基本告警，如果存在，则创建吸收关系，然后进入步骤2.4.8；否则，直接进入步骤2.4.8。

步骤2.4.8：逐条遍历所述通用吸收关联关系，如果遍历没有结束，则进入步骤2.4.2；否则，进入步骤3。

其中，所述通用吸收关联关系是指能够通过配置关联关系获得的具有明确因果关系的告警吸收关系；所述特定吸收关联关系是指目前无法通过配置关联关系获得明确因果关系的告警吸收关系，需要单独定义的告警吸收关系。

步骤3：对所述告警信息进行告警推论关联分析，推论出新告警作为根源告警；

由于监控源采集算法的局限性，并非所有的告警都能够被实时准确的发送到告警处理平台，如网络中断、服务挂死等特定场景下，根源告警的告警信息无法发送，而此时与之相关联的其他告警会发送到告警平台。另外，这对一些逻辑概念的监控(如中间件集群、网络主备链路组等)，无法直接采集监控点的信息，都需要按照规则树进行告警推论，如图11所示。

当发生大量告警，这些告警通过告警吸收模型验证，互相不存在父-子关系，但这些告警的发生却有紧密的关联关系，因此需要建立另一类模型，通过多个有关联关系的“独立”告警，推导出一个新告警作为根源告警。

通用推论规则：通过配置关联关系推导得出，具有明确的因果关系。

特定推论规则：告警关系无法通过现有的配置关联关系推论，但是具有一定的关联性，需要单独定义其推论关系。

(1)特定告警推论

随着运维经验的积累，对特定的告警之间的逻辑关系进行基于告警ID和属主ID的细颗粒度推论，再继续进行通用推论规则的匹配。因此对特定告警的推论，需要单独设计关联规则。

对于特定告警的告警推论规则，建立单独的rootana_conclude_c_sp和rootana_conclude_p_sp表，如表6及表7所示。其判断流程较通用告警吸收算法简单，适用于特定逻辑关系固定的告警推论。以实体-关系E-R图形式展现如图12所示：

表6特定告警推论源告警表(rootana_conclude_c_sp)

表7特定告警根告警(rootana_conclude_p_sp)

数据结构关系如图13所示：

特定告警推论流程如图14所示：

当一个或多个新告警发生，提取报警属主ID和告警编码，据此查询告警推论源告警(rootana_conclude_c_sp)中的推论KEY(CONCLUDE_KEY)

查询rootana_conclude_p_sp表中相同的CONCLUDE_KEY，确定父(推论)告警的告警属主类型编码和告警编码。

查询告警属主与告警属主的关系表(eventowner_vs_owner)，根据FROM_SDID和relationship_id，将查询结果TO_SDID作为父(推论)告警属主；

根据EVENT表中告警短消息OBJECTFormat字段生成父(推论)告警报警对象。

(2)通用告警推论

表8和表9分别给出了告警推论源告警表(rootana_conclude_c)和告警推论表(rootana_conclude_p)，其中，告警推论源告警表存储了源告警属主类型和告警编码信息的组合，用于判断是否可进行告警推论；存储了推论KEY，用于标识是否适用于统一推论规则；存储依赖关系ID。以实体-关系E-R图形式展现如图15所示：

表8告警推论源告警表(rootana_conclude_c)

表9告警推论表(rootana_conclude_p)

数据结构关系如图16所示。

告警推论流程如图17所示。

当一个告警经过特定告警推论过程后，进入通用告警推论过程，系统自动在告警流水表的告警记录数据结构内提取告警属主类型IDTROWNERCLASSID和告警编码TREVENTID，据此查询告警推论源告警(rootana_conclude_c)中的推论KEY(CONCLUDE_KEY)；

查询rootana_conclude_c表中相同的CONCLUDE_KEY，确定父(推论)告警的告警属主类型编码和告警编码。

根据rootana_conclude_c中的TIMEWINDOW，在时间窗口内，等待匹配推论规则CONCLUDE_KEY的新告警。

如IFEXTEND为0，则任一告警发生，即推论根告警，生成父(推论)告警；如IFEXTEND为1，则等待所有匹配项，均发生，再生成父(推论)告警。

根据rootana_conclude_p表，可以确定父(推论)告警编码和告警属主类型；

查询告警属主与告警属主的关系表(eventowner_vs_owner)，根据FROM_SDID和relationship_id，将查询结果TO_SDID作为父(推论)告警属主。

根据EVENT表中告警短消息OBJECTFormat字段生成父(推论)告警报警对象。

可选地，所述步骤3包括：

步骤3.1：基于特定推论关联关系，对所述告警信息进行推论匹配；

进一步地，所述步骤3.1包括：

步骤3.1.1：判断所述告警是否符合推论条件，如果满足，则进入步骤3.1.2；否则进入步骤3.2；

步骤3.1.2：获取推论代码；

步骤3.1.3：获取推论告警信息；

步骤3.1.4：创建推论告警；

步骤3.1.5：生成推论树，然后进入步骤3.2。

步骤3.2：基于通用推论关联关系，对所述告警信息进行推论匹配；

进一步地，所述步骤3.2包括：

步骤3.2.1：判断所述告警是否符合推论条件，如果满足，则进入步骤3.2.2；否则结束；

步骤3.2.2：获取推论代码；

步骤3.2.3：获取推论告警信息；

步骤3.2.4：判断是否需要等待其他原始告警；如果需要，则进入步骤3.2.5；否则，进入步骤3.2.8；

步骤3.2.5：进行延时；

步骤3.2.6：判断延时是否超时，若未超时，则进入步骤3.2.7；否则结束；

步骤3.2.7：扫描告警内存库，判断具有相同的推论代码的原始告警是否都已出现，若是，则进入步骤3.2.8；否则，返回步骤3.2.5；

步骤3.2.8：创建推论告警；

步骤3.2.9：生成推论树并结束。

其中，所述通用推论关联关系是指能够通过配置关联关系获得的具有明确因果关系的告警推论关系；所述特定推论关联关系是指目前无法通过配置关联关系获得明确因果关系的告警推论关系，需要单独定义的告警推论关系。

步骤4：把关联分析的结果，通过置位关联标识符的方式，在告警总线中进行标识；

步骤5：确定根源告警后，对子告警进行自动确认，并在关闭根源告警时同步关闭所有相关的子告警。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换，而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (9)

1.一种基于知识库的告警关联分析方法，其特征在于，所述方法包括：

步骤1：获取告警总线中存在的告警信息；

步骤2：对所述告警信息进行告警吸收关联分析，得到根源告警；

步骤3：对所述告警信息进行告警推论关联分析，推论出新告警作为根源告警；

步骤4：把关联分析的结果，通过置位关联标识符的方式，在告警总线中进行标识；

步骤5：确定根源告警后，对子告警进行自动确认，并在关闭根源告警时同步关闭所有相关的子告警。

2.根据权利要求1所述的一种基于知识库的告警关联分析方法，其特征在于，所述步骤2包括：

步骤2.1：基于特定吸收关联关系，对所述告警信息进行被吸收匹配；

步骤2.2：基于特定吸收关联关系，对所述告警信息进行吸收匹配；

步骤2.3：基于通用吸收关联关系，对所述告警信息进行被吸收匹配；

步骤2.4：基于通用吸收关联关系，对所述告警信息进行吸收匹配；

其中，所述通用吸收关联关系是指能够通过配置关联关系获得的具有明确因果关系的告警吸收关系；所述特定吸收关联关系是指目前无法通过配置关联关系获得明确因果关系的告警吸收关系，需要单独定义的告警吸收关系。

3.根据权利要求2所述的一种基于知识库的告警关联分析方法，其特征在于，所述步骤2.1包括：

步骤2.1.1：从特定吸收关联关系中的首条规则开始；

步骤2.1.2：针对所述告警，判断其是否匹配特定吸收关联关系中当前规则的基本告警，即判断所述告警是否可被吸收，如果可被吸收，则进入步骤2.1.3；否则，进入步骤2.1.5；

步骤2.1.3：获取根源告警属性；

步骤2.1.4：判断告警内存库中是否存在匹配的根源告警，如果存在，则创建被吸收关系，然后进入步骤2.1.5；否则，直接进入步骤2.1.5

步骤2.1.5：逐条遍历所述特定吸收关联关系，如果遍历没有结束，则进入步骤2.1.2；否则进入步骤2.2。

4.根据权利要求2所述的一种基于知识库的告警关联分析方法，其特征在于，所述步骤2.2包括：

步骤2.2.1：从特定吸收关联关系中的首条规则开始；

步骤2.2.2：针对所述告警，判断其是否匹配特定吸收关联关系中当前规则的根源告警，即判断所述告警是否可吸收其它告警，如果可以，则进入步骤2.2.3；否则，进入步骤2.2.5；

步骤2.2.3：获取基本告警属性；

步骤2.2.4：判断告警内存库中是否存在匹配的基本告警，如果存在，则创建吸收关系，然后进入步骤2.2.5；否则直接进入步骤2.2.5；步骤2.2.5：逐条遍历所述特定吸收关联关系，如果遍历没有结束，则进入步骤2.2.2；否则进入步骤2.3。

5.根据权利要求2所述的一种基于知识库的告警关联分析方法，其特征在于，所述步骤2.3包括：

步骤2.3.1：从通用吸收关联关系中的首条规则开始；

步骤2.3.2：针对所述告警，判断其是否匹配通用吸收关联关系中当前规则的基本告警，即判断所述告警是否可被吸收，如果可被吸收，则进入步骤2.3.3；否则，进入步骤2.3.8；

步骤2.3.3：获取根源告警属主类型编码以及告警关联代码；

步骤2.3.4：获取根源告警编码；

步骤2.3.5：获取根源告警属主；

步骤2.3.6：获取根源告警；

步骤2.3.7：判断告警内存库中是否存在匹配的根源告警，如果存在，则创建被吸收关系，然后进入步骤2.3.8；否则直接进入步骤2.3.8；

步骤2.3.8：逐条遍历所述通用吸收关联关系，如果遍历没有结束，则进入步骤2.3.2；否则，进入步骤2.4。

6.根据权利要求2所述的一种基于知识库的告警关联分析方法，其特征在于，所述步骤2.4包括：

步骤2.4.1：从通用吸收关联关系中的首条规则开始；

步骤2.4.2：针对所述告警，判断其是否匹配通用吸收关联关系中当前规则的根源告警，即判断告警是否可吸收其它告警，如果可吸收，则进入步骤2.4.3；否则，进入步骤2.4.8；

步骤2.4.3：获取基本告警属主类型编码以及告警关联代码；

步骤2.4.4：获取基本告警编码；

步骤2.4.5：获取基本告警属主；

步骤2.4.6：获取基本告警；

步骤2.4.7：判断告警内存库中是否存在匹配的基本告警，如果存在，则创建吸收关系，然后进入步骤2.4.8；否则，直接进入步骤2.4.8。

步骤2.4.8：逐条遍历所述通用吸收关联关系，如果遍历没有结束，则进入步骤2.4.2；否则，进入步骤3。

7.根据权利要求1所述的一种基于知识库的告警关联分析方法，其特征在于，所述步骤3包括：

步骤3.1：基于特定推论关联关系，对所述告警信息进行推论匹配；

步骤3.2：基于通用推论关联关系，对所述告警信息进行推论匹配；

其中，所述通用推论关联关系是指能够通过配置关联关系获得的具有明确因果关系的告警推论关系；所述特定推论关联关系是指目前无法通过配置关联关系获得明确因果关系的告警推论关系，需要单独定义的告警推论关系。

8.根据权利要求7所述的一种基于知识库的告警关联分析方法，其特征在于，所述步骤3.1包括：

步骤3.1.1：判断所述告警是否符合推论条件，如果满足，则进入步骤3.1.2；否则进入步骤3.2；

步骤3.1.2：获取推论代码；

步骤3.1.3：获取推论告警信息；

步骤3.1.4：创建推论告警；

步骤3.1.5：生成推论树，然后进入步骤3.2。

9.根据权利要求7所述的一种基于知识库的告警关联分析方法，其特征在于，所述步骤3.2包括：

步骤3.2.1：判断所述告警是否符合推论条件，如果满足，则进入步骤3.2.2；否则结束；

步骤3.2.2：获取推论代码；

步骤3.2.3：获取推论告警信息；

步骤3.2.4：判断是否需要等待其他原始告警；如果需要，则进入步骤3.2.5；否则，进入步骤3.2.8；

步骤3.2.5：进行延时；

步骤3.2.6：判断延时是否超时，若未超时，则进入步骤3.2.7；否则结束；

步骤3.2.7：扫描告警内存库，判断具有相同的推论代码的原始告警是否都已出现，若是，则进入步骤3.2.8；否则，返回步骤3.2.5；

步骤3.2.8：创建推论告警；

步骤3.2.9：生成推论树并结束。