首页> 中国专利> 一种告警关联规则挖掘方法、规则挖掘引擎及系统

一种告警关联规则挖掘方法、规则挖掘引擎及系统

摘要

本发明实施例公开一种告警关联规则的挖掘方法、装置及系统,其中,该方法包括:获得告警序列,所述告警序列包括多条告警;计算每个k-项集的支持度,得到k-项频繁项集集合;由该k-项频繁项集集合生成k+1-项频繁项集集合;针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集;从而,在告警关联规则的挖掘过程中,减少了由于置信度参数的影响而产生的虚假规则,有效减少关联规则结果集中的虚假规则。

著录项

  • 公开/公告号CN101937447A

    专利类型发明专利

  • 公开/公告日2011-01-05

    原文格式PDF

  • 申请/专利权人 华为技术有限公司;

    申请/专利号CN201010197275.0

  • 发明设计人 周伟;

    申请日2010-06-07

  • 分类号G06F17/30(20060101);

  • 代理机构

  • 代理人

  • 地址 518129 广东省深圳市龙岗区坂田华为总部办公楼

  • 入库时间 2023-12-18 01:26:38

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2016-08-03

    未缴年费专利权终止 IPC(主分类):G06F17/30 授权公告日:20120523 终止日期:20150607 申请日:20100607

    专利权的终止

  • 2012-05-23

    授权

    授权

  • 2011-03-02

    实质审查的生效 IPC(主分类):G06F17/30 申请日:20100607

    实质审查的生效

  • 2011-01-05

    公开

    公开

说明书

技术领域

本发明实施例涉及通信技术领域,特别是涉及一种告警关联规则挖掘方法、规则挖掘引擎及系统。

背景技术

在通信网络运行过程中,电信设备每天都会产生大量告警,而且一个设备故障会引起其他设备产生告警。70年代有人提出了使用规则引擎根据告警关联规则自动处理电信告警。随着网络的发展,网络结构越来越复杂,电信设备之间的关系也越来越复杂,导致人工很难完整的定义告警关联规则。

在告警关联规则挖掘领域,有人提出将频繁模式的挖掘技术应用于告警关联规则的挖掘,频繁模式即事件序列上频繁出现且相互临近并有一定结构关系的事件类型的集合。频繁模式可以认为是关联规则。对于频繁模式的挖掘,有人提出在事件序列中滑动窗口的WinEPI算法。现有技术中WinEPI算法被应用于告警关联规则的挖掘,该算法利用滑动窗口来指定事件在时间上的相邻程度并发现事件序列中事件间在时间上的偏序关系。

具体的,应用到告警关联规则挖掘中,每一条告警就是一个事件,每条告警的所属网元、所属地域和所属设备名称就是该事件的属性。而网元的集合、地域集合及设备的集合则分别是对应的属性域。事件序列即一系列有顺序的事件集合,并且每个事件都有一个与其相关联的发生时间,网络中的告警日志或告警数据库便是待分析的事件序列。如图1所示,为一个抽象的事件序列的例子,其中:时间窗口是一个半开半闭的时间区间,如[35,40),包含告警事件<A,35>,不包含告警事件<F,40>。窗口滑动步长指两个连续窗口的起始时间之差,取值不大于时间窗口的长度。一个时间窗口中的告警序列即是一个事务。不包含任何事件的窗口称为无效窗口,在计算一个事件序列上的窗口总数时,不统计无效窗口。

发明人在实现本发明的过程中,发现:在电信网络中,告警之间的频繁程度相差很大,有些告警经常发生,有些告警较少发生,如图2所示,告警A是经常发生的告警,在一个时间段内连续多次发生;告警B是偶然告警,在一个时间段内发生一次或少数几次。告警A和告警B之间实际上没有关联关系(因为无论告警B是否发生,告警A发生的概率都接近100%),但采用现有的WinEPI算法挖掘告警关联规则的应用过程中,会误认为告警A和告警B之间有强关联关系(即模式是强关联规则),从而现有技术输出的关联规则结果集中会存在虚假规则。

发明内容

本发明实施例提供一种告警关联规则挖掘方法、规则挖掘引擎及系统,以减少关联规则结果集中的虚假规则。

本发明实施例提供如下技术方案:

一方面,本发明实施例提供一种告警子系统,包括:

规则挖掘引擎,用于获得告警序列,所述告警序列包括多条告警,每条告警至少用告警类型属性和告警发生时间表示,N为该告警序列的总告警类型数;计算每个k-项集的支持度,得到包含支持度不小于最小支持度的k-项集的k-项频繁项集集合,其中k-项集表示k种告警类型的集合,k={1,2,...,L,...,N};由该k-项频繁项集集合生成k+1-项频繁项集集合;针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;并将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集;

规则推理引擎,用于接收所述规则挖掘引擎输出的关联规则结果集,并对输入的告警与所述关联规则结果集中的关联规则进行匹配,根据匹配结果以关联的告警处理方式处理所述告警。

另一方面,本发明实施例提供一种告警关联规则的挖掘方法,该方法包括:

获得告警序列,所述告警序列包括多条告警,每条告警至少用告警类型属性和告警发生时间表示;

计算每个k-项集的支持度,得到k-项频繁项集集合,该k-项频繁项集集合包含支持度不小于最小支持度的k-项集,其中,k={1,2,...,L,...,N},k-项集表示k种告警类型的集合,N为该告警序列中总告警类型数;

由该k-项频繁项集集合生成k+1-项频繁项集集合;

针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集。

另一方面,本发明实施例提供一种告警关联规则的规则挖掘引擎,包括:

告警获得单元,用于获得告警序列,所述告警序列包括多条告警,每条告警至少用告警类型属性和告警发生时间表示;

执行单元,用于计算每个k-项集的支持度,得到k-项频繁项集集合,该k-项频繁项集集合包含支持度不小于最小支持度的k-项集;由该k-项频繁项集集合生成k+1-项频繁项集集合,针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集,其中,k={1,2,...,L,...,N},k-项集表示k种告警类型的集合,N为该告警序列中总告警类型数。

另一方面,本发明实施例提供一种网络管理系统,包括:电信设备和所述的告警子系统。

可见,本发明实施例在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,由规则挖掘引擎根据k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。从而,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则减少关联规则结果集中的虚假规则。

附图说明

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

图1为一个抽象的事件序列示例;

图2为一个告警序列的示例;

图3为本发明实施例的一种告警子系统的结构示意图;

图4为本发明实施例的一种告警关联规则的挖掘方法的流程示意图;

图5为本发明实施例的另一种告警关联规则的挖掘方法的流程示意图;

图6为本发明实施例的涉及的告警序列T的示例;

图7a为本发明实施例的一种告警关联规则的挖掘方法的交互示意图;

图7b为本发明实施例的一种网络管理系统的结构示意图;

图8a为本发明实施例的另一种告警关联规则的挖掘方法的交互示意图;

图8b为本发明实施例的另一种网络管理系统的结构示意图;

图9为本发明实施例的一种规则挖掘引擎的结构示意图;

图10为本发明实施例的应用于告警子系统中的一种规则挖掘引擎的结构示意图;

图11为本发明实施例的应用于告警子系统中的另一种规则挖掘引擎的结构示意图。

具体实施方式

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

首先介绍本发明实施例的告警关联规则挖掘方案涉及的相关定义,如下:

告警:每条告警至少用告警类型属性和告警发生时间来表示,每条告警可以以一个二元组(A,t)表示,A表示告警类型属性,t表示告警发生时间。需要说明的是,告警类型属性至少可以由告警类型字段和告警网元ID字段组合表示,进一步的,告警类型字段至少可以用告警类型ID、告警子类型ID组合表示。

告警序列T:由一系列具有时间偏序关系的告警组成的序列,时间区间为[Ts,Tend],这里的Ts表示起始时间,Tend表示结束时间。

项集:表示告警类型的集合,其中:ii表示告警类型。包含k个项的项集称为k-项集,这里的项表示一种告警类型。具体的,k-项集表示k种告警类型的集合,1-项集表示一种告警类型的集合,如ii为1-项集,ii,i2,...,ik为k-项集。k-项集简称为P(k),不包含ik项的k-项集简称为:P(k+1)/ik。项集也可以理解为模式。

支持度:k-项集的支持度定义为:α表示k-项集,如i1,i2,...,ik,举例说明,α发生的窗口数指的是告警类型i1,i2,...,ik共同发生的窗口数。特别的,1-项集ii的支持度定义为:需要说明的是,最小支持度min_sup可以是人工指定的阈值。

极大置信度:k-项集的极大置信度定义为:

ii表示告警类型,α表示k-项集,如i1,i2,...,ik。特别的,1-项集不定义极大置信度。需要说明的是,最小置信度min_conf可以是人工指定的阈值。

频繁项集:支持度不小于最小支持度的项集称为频繁项集。

关联规则:极大置信度不小于最小置信度的频繁项集称为关联规则。极大关联规则定义为:Rulemax={i1i2...ik},ii表示告警类型。

请参阅图3,为本发明实施例的一种告警子系统,该告警子系统用于管理电信设备告警,如图3所示,本发明实施例的告警子系统包括:

规则挖掘引擎10,用于获得告警序列,所述告警序列包括多条告警,每条告警至少用告警发生时间和告警类型属性表示,N为该告警序列的总告警类型数;计算每个k-项集的支持度,得到包含支持度不小于最小支持度的k-项集的k-项频繁项集集合,其中k-项集表示k种告警类型的集合,k={1,2,...,L,...,N};由该k-项频繁项集集合生成k+1-项频繁项集集合;针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;并将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集;

规则推理引擎20,用于接收规则挖掘引擎10输出的关联规则结果集,并对输入的告警与所述关联规则结果集中的关联规则进行匹配,根据匹配结果以关联的告警处理方式处理所述告警。具体的,这里的告警处理方式可以是对告警字段进行过滤、合并、修改或删除处理等等,也可以是不做任何处理。

在一种实现方式下,规则推理引擎20具体用于接收规则挖掘引擎10输出的关联规则结果集,并对输入的告警与该关联规则结果集中的关联规则进行匹配,根据匹配结果执行预先定义的告警处理动作。例如:如果输入的告警能匹配关联规则{AC},则处理能匹配该关联规则的告警,这里的告警处理动作可以是上述的删除、过滤、合并或修改告警字段等操作中的一种或多种。应当理解的是,这里的告警处理动作具体可根据业务需求而定。如果输入的告警与关联规则A=>B无法匹配,可以不做任何改动。应当理解的是,也可以改变告警字段,具体可根据业务需求而定。

进一步的,本发明实施例的告警子系统可以包括:告警存储设备30,用于存储电信设备产生的告警。这里存储的告警可以是电信设备产生的原始告警,也可以是处理后的告警。

相应的,规则挖掘引擎10具体用于从告警存储设备30读取告警序列,所述告警序列包括多条告警,每条告警至少用告警发生时间和告警类型属性表示,N为该告警序列的总告警类型数;计算每个k-项集的支持度,得到包含支持度不小于最小支持度的k-项集的k-项频繁项集集合,其中k-项集表示k种告警类型的集合,k={1,2,...,L,...,N};由该k-项频繁项集集合生成k+1-项频繁项集集合;针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据作为分母的、该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;并将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集。

相应的,规则推理引擎20进一步用于将处理后的告警保存到告警存储设备30。应当理解,这里的告警存储设备30具体可以是告警数据库,数量可以是一个或多个。

可见,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则。具体的:正如本领域技术人员所知,多种告警类型同时发生的概率越大,则所述多种告警类型它们之间就越可能具有强关联关系,现有WinEPI算法中,针对频繁模式P=i1,i2,...,ik,ik+1,其支持度为sup(P),则由该模式得到所有满足条件的关联规则的方法如下:如果则认为属于满足条件的关联规则。同理,计算满足条件则保留规则。这些规则在计算置信度时,分子都相同,不同的是分母,即分母为该模式中各个项(即告警类型)的支持度。相对于现有技术,本发明实施例的告警子系统中,由规则挖掘引擎根据作为分母的、k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。

进一步的,本发明实施例在告警关联规则的挖掘过程中,减缓了现有WinEPI算法可能导致内存不足的问题。具体的:由于使用了滑动窗口,窗口中的告警顺序无法表示告警之间的实际衍生关系,另外,由于电信网络中存在传输、延时、丢失等问题,进一步干扰了告警顺序。实际应用中,规则和往往会共同出现,并且规则在实际中并不能表示告警A是告警B的根源告警。因此这种前后件的规则定义在电信告警挖掘中意义不大,考虑到这些,本发明实施例通过考察“告警A和告警B同时发生”的概率,相对于现有WinEPI算法考察“告警A发生的情况下告警B发生”的概率的情况,从而减缓现有WinEPI方法中候选项集的数量太多所导致的内存不足问题。

请参阅图4,为本发明实施例的一种告警关联规则的挖掘方法的流程示意图,可以应用于如图3所示的告警子系统中的规则挖掘引擎,该方法可以包括如下步骤:

S401、获得告警序列,所述告警序列包括多条告警,每条告警至少用告警类型属性和告警发生时间表示;

具体的,根据配置的告警序列T的起始时间和结束时间从告警数据库中读取发生在所述起始时间和结束时间之间的告警。

每条告警表示为二元组形式(A,t),这里的A表示告警特征属性,t表示告警发生时间。

S402、计算每个k-项集的支持度,得到k-项频繁项集集合,该k-项频繁项集集合包含支持度不小于最小支持度的k-项集,其中,k={1,2,...,L,...,N},k-项集表示k种告警类型的集合,N为该告警序列中总告警类型数;

应当理解的是,本发明实施例方法从k=1开始执行,即计算告警序列中每种告警类型的支持度。

S403、由该k-项频繁项集集合生成k+1-项频繁项集集合,其中k={1,2,...,L,...,N};

S404、针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集。

具体的,根据作为分母的、该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;如果所述极大置信度不小于最小置信度,将该k+1-项频繁项集加入关联规则结果集。

在一种实现方式下,S401包括:根据配置的告警序列的起始时间和结束时间,以及告警关键字段从告警存储设备中读取发生在所述起始时间和结束时间之间的告警的关键属性,并输出告警序列,所述告警序列中的每条告警用二元组形式(A,t)表示,A表示告警类型属性,t表示告警发生时间;

相应的,本实施例方法进一步包括:统计所述告警序列中告警的类型,N为所述告警序列中总告警类型数。

在另一种实现方式下,S401包括:根据配置的告警序列的起始时间和结束时间,从告警存储设备中读取发生在所述起始时间和结束时间之间的告警序列;

相应的,本实施例方法进一步包括:根据配置的告警关键字段将所述告警序列中的每条告警数据转换为规范的二元组形式(A,t),输出规范化后的告警序列并统计所述规范化后的告警序列T中告警的类型,其中A表示告警类型属性,t表示告警发生时间,N为所述规范化后的告警序列T中总告警类型数。

可见,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则。具体的:正如本领域技术人员所知,多种告警类型同时发生的概率越大,则所述多种告警类型它们之间就越可能具有强关联关系,现有WinEPI算法中,针对频繁模式P=i1,i2,...,ik,ik+1,其支持度为sup(P),则由该模式得到所有满足条件的关联规则的方法如下:如果则认为属于满足条件的关联规则。同理,计算满足条件则保留规则。这些规则在计算置信度时,分子都相同,不同的是分母,即分母为该模式中各个项(即告警类型)的支持度。相对于现有技术,本发明实施例的告警子系统中,由规则挖掘引擎根据作为分母的、k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。

进一步的,本发明实施例在告警关联规则的挖掘过程中,减缓了现有WinEPI算法可能导致内存不足的问题。具体的:由于使用了滑动窗口,窗口中的告警顺序无法表示告警之间的实际衍生关系,另外,由于电信网络中存在传输、延时、丢失等问题,进一步干扰了告警顺序。实际应用中,规则和往往会共同出现,并且规则在实际中并不能表示告警A是告警B的根源告警。因此这种前后件的规则定义在电信告警挖掘中意义不大,考虑到这些,本发明实施例通过考察“告警A和告警B同时发生”的概率,相对于现有WinEPI算法考察“告警A发生的情况下告警B发生”的概率的情况,从而减缓现有WinEPI方法中候选项集的数量太多所导致的内存不足问题。

请参阅图5,为本发明实施例的另一种告警关联规则的挖掘方法的流程示意图,可以应用于如图3所示的告警子系统中的规则挖掘引擎,其中:

输入:告警序列T,告警类型I={i1,i2,...,in},模式α=i1,i2,...,ik(k≤n),时间窗口长度win,窗口滑动步长step。

输出:关联规则结果集。

其中,该方法可以包括如下步骤:

S501、读取告警序列T,并进行预处理,即根据时间窗口长度win和窗口滑动步长step将该告警序列T划分为多个窗口:

具体的,从告警序列T的起始时间0开始,[0,win)的时间长度为第1个窗口,[0+step,win+step)为第2个窗口,...,依次类推,直到最后一个窗口的结束时间刚好大于或等于T的结束时间为止,将告警序列T划分为个窗口,表示向上取整。如果一个窗口内没有任何告警发生,则将该窗口记为无效窗口。则

S502、计算所有k-项集的支持度(即sup(ii)),将支持度不小于最小支持度(即sup(ii)≥min_sup)的k-项集加入k-项频繁项集集合,本步骤中k=1;

应当理解的是,这里是计算告警序列T中每种告警类型的支持度。具体的,统计每种告警类型ii发生的窗口数,并基于计算每种告警类型ii的支持度。需要说明的是,同一种告警类型在同一窗口发生多次只记一次。

S503、从k-项频繁项集集合中选取两个未被同时选择过的k-项集,这两个k-项集中有k-1个项都相同;

这两个k-项集分别可表示为P(k+1)/ik和P(k+1)/ik+1

S504、取所述两个k-项集的合集生成k+1-项集,计算该k+1-项集的支持度,如果其支持度不小于最小支持度,则将该k+1-项集加入k+1-项频繁项集集合;反之,可以丢弃。

这里以i1,i2,...,ik,ik+1来表示该k+1-项集,具体的过程包括:统计告警类型i1,i2,...,ik,ik+1共同发生的窗口数,需要说明的是,本发明实施例中不考虑每种告警类型发生的次数,只要在同一个窗口告警类型i1,i2,...,ik,ik+1均出现至少一次,则i1,i2,...,ik,ik+1共同发生的窗口数增加1;

基于计算该k+1-项集的支持度;

如果sup(i1,i2,...,ik,ik+1)≥min_sup,则将该k+1-项集i1,i2,...,ik,ik+1加入k+1-项频繁项集集合;反之,可以丢弃。

S505、判断k+1-项频繁项集集合是否为空,如果不为空,进入步骤S506,反之,进入步骤S508。

S506、针对所述k+1-项频繁项集集合中的每个k+1-项频繁项集,计算该k+1-项频繁项集的极大置信度,如果该k+1-项频繁项集的极大置信度不小于最小置信度,则进入步骤S507;反之,可以丢弃;

这里以i1,i2,...,ik,ik+1来表示该k+1-项频繁项集,具体的过程包括:基于计算该k+1-项频繁项集的极大置信度,其中:max[sup(i1),sup(i2),...,sup(ik),sup(ik+1)]表示sup(ii)中的最大值。

如果confmax(i1,i2,...,ik,ik+1)≥min_conf,则进入步骤S507;反之,可以丢弃。

S507、将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集。设k=k+1,返回执行步骤S503。

S508、合并关联规则结果集中具有包含关系的关联规则,保留极大规则,输出合并后的关联规则结果集。这是可选步骤。流程结束。

可见,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则。具体的:正如本领域技术人员所知,多种告警类型同时发生的概率越大,则所述多种告警类型它们之间就越可能具有强关联关系,现有WinEPI算法中,针对频繁模式P=i1,i2,...,ik,ik+1,其支持度为sup(P),则由该模式得到所有满足条件的关联规则的方法如下:如果则认为属于满足条件的关联规则。同理,计算满足条件则保留规则。这些规则在计算置信度时,分子都相同,不同的是分母,即分母为该模式中各个项(即告警类型)的支持度。相对于现有技术,本发明实施例的告警子系统中,由规则挖掘引擎根据作为分母的、k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。

进一步的,本发明实施例在告警关联规则的挖掘过程中,减缓了现有WinEPI算法可能导致内存不足的问题。具体的:由于使用了滑动窗口,窗口中的告警顺序无法表示告警之间的实际衍生关系,另外,由于电信网络中存在传输、延时、丢失等问题,进一步干扰了告警顺序。实际应用中,规则和往往会共同出现,并且规则在实际中并不能表示告警A是告警B的根源告警。因此这种前后件的规则定义在电信告警挖掘中意义不大,考虑到这些,本发明实施例通过考察“告警A和告警B同时发生”的概率,相对于现有WinEPI算法考察“告警A发生的情况下告警B发生”的概率的情况,从而减缓现有WinEPI方法中候选项集的数量太多所导致的内存不足问题。

进一步的,本发明实施例在告警关联规则的挖掘过程中,提高了挖掘速度,从而提高了系统处理性能。具体的:在现有技术方案中,由k-项频繁项集生成k+1-项候选项集时,过程如下:设i1,i2,...,ik-1,ik和i1,i2,...,ik-1,ik+1为k-项频繁项集,记为P(k+1)/ik+1和P(k+1)/ik,即k+1-项集P(k+1)分别去掉ik+1和ik后得到的项集。然后查找如下k-项集P(k+1)/i1,P(k+1)/i2,...,P(k+1)/ik-1是否都是频繁项集。若都存在,则P(k+1)为k+1-项候选项集,然后将所有的k+1-项候选项集统计支持度,检查是否满足最小支持度的要求。采用本发明实施例的极大置信度定义后,要求P(k+1)满足新的置信度要求,即sup(P(k+1))≥max(sup(ii))×min_conf,根据Apriori性质:所有频繁项集的子集必然是频繁项集,所以P(k+1)的任意子集都必须满足sup((P(k+1)的任意子集)≥max(sup(ii))×min_conf。这样,对于每个频繁项,我们都已经记录了其支持度,在由P(k+1)/ik+1和P(k+1)/ik构造准k+1-项候选项集P(k+1)时,我们首先判断如果不成立,则说明P(k+1)不满足置信度条件,无需再判断每个子集是否是频繁项集,从而提高了告警关联规则的挖掘处理速度,进而提高了系统处理性能。

为了便于理解,下面结合一个实例来介绍本发明实施例方案:

如图6所示,为本发明实施例涉及的告警序列T,其中,告警序列T中共有三种类型告警,分别为A、B、C,时间窗口长度为10秒,滑动步长为5秒,最小支持度0.1,最小置信度0.5。基于图6所示的告警序列下的告警关联规则的挖掘实例,介绍如下:

1、根据时间窗口和滑动步长将告警序列T划分为15个窗口,如图6中的win1-win15,分别计算告警类型A、B、C的支持度:

sup(A)=13/15=0.867>0.1

sup(B)=5/15=0.333>0.1

sup(C)=8/15=0.533>0.1

则生成1-项频繁项集集合{{A},{B},{C}}

2、从1-项频繁项集集合中选取两个未被同时选择过的1-项集,这两个1-项集中有0个项相同。本实例中,可选取{A},{B}或{A},{C}或{B},{C}。

3、将选取出的两个1-项集合并为一个2-项集并计算该2-项集的支持度:

sup(AB)=4/15=0.267>0.1

sup(AC)=7/15=0.467>0.1

sup(BC)=2/15=0.133>0.1

则生成2-项频繁项集集合{{AB},{AC},{BC}}

4、判断2-项频繁项集集合是否为空,在本实例中,该2-项频繁项集集合不为空,进入下一步。

5、计算每个2-项频繁项集的极大置信度:

confmax(AB)=sup(AB)max(sup(A),sup(B))=4/1513/15=4/13<0.5

confmax(AC)=sup(AC)max(sup(A),sup(C))=7/1513/15=7/13>0.5

confmax(BC)=sup(BC)max(sup(B),sup(C))=2/158/15=2/8<0.5

6、2-项集{AC}的极大置信度不小于最小置信度,将其加入告警关联规则结果集{{AC}};

7、从2-项频繁项集集合{{AB},{AC},{BC}}中选取两个未被同时选择过的2-项集,这两个1-项集中有1个项相同。本实例中,可选取{AB},{AC}或{AB},{BC}或{AC},{BC}

8、将选取出的2-项集合并为一个3-项集,并计算该3-项集的支持度:sup(ABC)=1/15=0.067<0.1

9、3-项集{ABC}的极大置信度小于最小置信度,丢弃该3-项集;相应的,在本实例中,3-项频繁项集集合为空;以及,相应的,输出告警关联规则结果集{{AC}};

10、可选的,合并关联规则结果集中具有包含关系的关联规则,保留极大规则,输出合并后的关联规则结果集。由于本例中只有一个关联规则,则最终输出的关联规则结果集为{{AC}}。

下面结合一个具体的应用来描述本发明方案:

请参阅图7a,为本发明实施例一种告警关联规则的挖掘方法的交互示意图,该方法应用于如图7b所示的网络管理系统下,其中,所述网络管理系统包括:电信设备70:电信告警的产生源,在电信设备运行期间会产生电信告警;以及,告警子系统:网络管理系统中专用于管理设备告警的子系统,其中,告警子系统包括:规则挖掘引擎71:用于执行本发明实施例所述的规则挖掘方法;规则推理引擎72:用于对输入的告警与已注入的告警关联规则进行匹配,并处理告警;可选的,还包括,告警数据库73:用于保存告警;告警展示界面74:用于向网络管理员展示告警。

如图7a所示,该方法可以包括如下步骤:

S701、电信设备70在运行期间产生并上报告警;这里的告警为原始告警;

S702a-702b、告警保存到告警数据库73之后,发送到告警展示界面以向网络管理员展示该告警;

S703、规则挖掘引擎71从告警数据库73中读取已保存的告警数据;

具体的,根据配置的告警序列T的起始时间和结束时间从告警数据库73中读取发生在告警序列T的起始时间和结束时间之间的告警数据。需要说明的是,对于读取的对象,在一种实现方式下,可以是读取告警的所有属性;在另一种实现方式下,可以是读取告警的部分关键属性,即至少包括告警类型属性和告警发生时间,应当理解的是,还可以包括告警停止时间、告警确认时间等其他字段。这里的告警类型属性至少可以由告警类型字段和告警网元ID字段组合而成,进一步的,这里的告警类型字段至少可以用告警类型ID、告警子类型ID组合表示。

在一种实现方式下,S703具体为:规则挖掘引擎71从告警数据库73中读取发生在告警序列T的起始时间和结束时间之间的每条告警数据(A,t),A表示告警类型属性,其至少可以由告警网元ID、告警类型ID、告警子类型ID组合而成,t表示告警发生时间。

S704、规则挖掘引擎71采用前述实施例的告警关联规则的挖掘方法,对S703中读取的告警数据进行处理,输出告警关联规则,亦即告警关联规则结果集。详情请参阅前面的方法实施例,这里不再赘述。

S705、规则挖掘引擎71将告警关联规则注入规则推理引擎72中。

S706、电信设备70再次上报告警,电信设备再次上报的告警输入规则推理引擎72。

S707、当规则推理引擎72中注入有告警关联规则之后,由规则推理引擎72对输入的告警与已注入的告警关联规则之间进行匹配,并根据匹配结果处理告警。

需要说明的是,这里的处理告警可以是执行预定义的动作。预定义的动作主要是由具体业务决定的,即根据具体业务需求而定的,包括但不限于本发明实施例涉及的处理方式:

如果匹配上,处理方式包括:过滤、删除、合并、修改告警字段等等,未来也许还有其他新的处理方式。

如果不能匹配上,可以不做任何改动,也可以改变告警字段,未来也许会有其他处理方式。

例如:如果输入的告警能匹配告警关联规则A=>B,则处理能匹配该告警规则的告警,这里的处理可以是上述的过滤、删除、合并、修改告警字段等操作中的一种或多种。

S708、规则推理引擎72完成推理(即匹配和处理)之后,将处理后的告警发送至告警数据库73以保存到告警数据库73。

S709、处理后的告警保存到告警数据库73之后,发送到告警展示界面以展示处理后的告警。

可见,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则。具体的:正如本领域技术人员所知,多种告警类型同时发生的概率越大,则所述多种告警类型它们之间就越可能具有强关联关系,现有WinEPI算法中,针对频繁模式P=i1,i2,...,ik,ik+1,其支持度为sup(P),则由该模式得到所有满足条件的关联规则的方法如下:如果则认为属于满足条件的关联规则。同理,计算满足条件则保留规则。这些规则在计算置信度时,分子都相同,不同的是分母,即分母为该模式中各个项(即告警类型)的支持度。相对于现有技术,本发明实施例的告警子系统中,由规则挖掘引擎根据作为分母的、k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。

进一步的,本发明实施例在告警关联规则的挖掘过程中,减缓了现有WinEPI算法可能导致内存不足的问题。具体的:由于使用了滑动窗口,窗口中的告警顺序无法表示告警之间的实际衍生关系,另外,由于电信网络中存在传输、延时、丢失等问题,进一步干扰了告警顺序。实际应用中,规则和往往会共同出现,并且规则在实际中并不能表示告警A是告警B的根源告警。因此这种前后件的规则定义在电信告警挖掘中意义不大,考虑到这些,本发明实施例通过考察“告警A和告警B同时发生”的概率,相对于现有WinEPI算法考察“告警A发生的情况下告警B发生”的概率的情况,从而减缓现有WinEPI方法中候选项集的数量太多所导致的内存不足问题。

请参阅图8a,为本发明实施例另一种告警关联规则的挖掘方法的交互示意图,该方法应用于如图8b所示的网络管理系统下,其中,所述网络管理系统包括:电信设备80:电信告警的产生源,在电信设备运行期间会产生电信告警;以及,告警子系统:网络管理系统中专用于管理设备告警的子系统,其中,告警子系统包括:规则挖掘引擎81:用于执行本发明实施例所述的规则挖掘方法;规则推理引擎82:用于对输入的告警与已注入的告警关联规则进行匹配,并处理告警;可选的,还包括,告警数据库83:用于保存告警;告警展示界面84:用于向网络管理员展示告警。本实施例中,规则挖掘引擎81的部署与图7b所示的实施例稍有差异。

如图8a所示,该方法可以包括如下步骤:

S801、电信设备80在运行期间产生并上报告警;这里的告警为原始告警;

S802a-802b、告警保存到告警数据库83之后,发送到告警展示界面以向网络管理员展示该告警;

S803、规则挖掘引擎81从告警数据库83中读取已保存的告警数据;

具体的,根据配置的告警序列T的起始时间和结束时间从告警数据库83中读取发生在告警序列T的起始时间和结束时间之间的告警数据。需要说明的是,对于读取的对象,在一种实现方式下,可以是读取告警的所有属性;在另一种实现方式下,可以是读取告警的部分关键属性,至少包括告警类型属性和告警发生时间,应当理解的是,还可以包括告警停止时间、告警确认时间等其他字段。这里的告警类型属性至少可以由告警类型字段和告警网元ID字段组合而成,进一步的,这里的告警类型字段至少可以用告警类型ID、告警子类型ID组合表示。

在一种实现方式下,S803具体为:规则挖掘引擎81从告警数据库83中读取发生在告警序列T的起始时间和结束时间之间的每条告警数据(A,t),A表示告警类型属性,其是由告警网元ID、告警类型ID、告警子类型ID组合而成,t表示告警发生时间。

S804、规则挖掘引擎81采用前述实施例的告警关联规则的挖掘方法,对S803中读取的告警数据进行处理,输出告警关联规则,亦即告警关联规则结果集。详情请参阅前面的方法实施例,这里不再赘述。

S805、规则挖掘引擎81将告警关联规则注入规则推理引擎82中。

S806、电信设备80再次上报告警;

S807a-807b、告警保存到告警数据库83之后,发送到告警展示界面以向网络管理员展示该告警;这里的告警是原始告警。

S808、规则挖掘引擎81从告警数据库83中读取已保存的、S806再次上报的告警数据。

S809a-809b、规则推理引擎82对读取到的告警与已注入的告警关联规则之间进行匹配,并根据匹配结果对告警数据库83中对应的告警执行预定义的动作。

需要说明的是,这里预定义的动作主要是由具体业务决定的,即根据具体业务需求而定的,包括但不限于本发明实施例涉及的处理方式:

如果匹配上,处理方式包括:过滤、删除、合并、修改告警字段等等,未来也许还有其他新的处理方式。

如果不能匹配上,可以不做任何改动,也可以改变告警字段,未来也许会有其他处理方式。

例如:如果读取的告警能匹配告警关联规则A=>B,则处理告警数据库中对应的告警,这里的处理可以是上述的过滤、删除、合并、修改告警字段等操作中的一种或多种。

S810、修改展示界面中相应的告警。

可见,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则。具体的:正如本领域技术人员所知,多种告警类型同时发生的概率越大,则所述多种告警类型它们之间就越可能具有强关联关系,现有WinEPI算法中,针对频繁模式P=i1,i2,...,ik,ik+1,其支持度为sup(P),则由该模式得到所有满足条件的关联规则的方法如下:如果则认为属于满足条件的关联规则。同理,计算满足条件则保留规则。这些规则在计算置信度时,分子都相同,不同的是分母,即分母为该模式中各个项(即告警类型)的支持度。相对于现有技术,本发明实施例的告警子系统中,由规则挖掘引擎根据作为分母的、k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。

进一步的,本发明实施例在告警关联规则的挖掘过程中,减缓了现有WinEPI算法可能导致内存不足的问题。具体的:由于使用了滑动窗口,窗口中的告警顺序无法表示告警之间的实际衍生关系,另外,由于电信网络中存在传输、延时、丢失等问题,进一步干扰了告警顺序。实际应用中,规则和往往会共同出现,并且规则在实际中并不能表示告警A是告警B的根源告警。因此这种前后件的规则定义在电信告警挖掘中意义不大,考虑到这些,本发明实施例通过考察“告警A和告警B同时发生”的概率,相对于现有WinEPI算法考察“告警A发生的情况下告警B发生”的概率的情况,从而减缓现有WinEPI方法中候选项集的数量太多所导致的内存不足问题。

请参阅图9,为本发明实施例的一种规则挖掘引擎的结构示意图,如图9所示,本发明实施例的规则挖掘引擎,可以包括:

告警获得单元91,用于获得告警序列,所述告警序列包括多条告警,每条告警至少用告警类型属性和告警发生时间表示;

具体的,根据配置的告警序列T的起始时间和结束时间从告警数据库中读取发生在告警序列T的起始时间和结束时间之间的告警数据。需要说明的是,对于读取的对象,在一种实现方式下,可以是读取告警的所有属性;在另一种实现方式下,可以是读取告警的部分关键属性,至少包括告警类型属性和告警发生时间,应当理解的是,还可以包括告警停止时间、告警确认时间等其他字段。这里的告警类型属性至少可以由告警类型字段和告警网元ID字段组合而成,进一步的,这里的告警类型字段至少可以用告警类型ID、告警子类型ID组合表示。

在一种实现方式下,告警获得单元91具体用于读取发生在告警序列T的起始时间和结束时间之间的每条告警数据,每条告警表示为二元组形式(A,t),A表示告警类型属性,该告警类型属性是至少由告警网元ID、告警类型ID、告警子类型ID组合而成,t表示告警发生时间。

以及,执行单元92,用于计算每个k-项集的支持度,得到k-项频繁项集集合,该集合包含支持度不小于最小支持度的k-项集;由该k-项频繁项集集合生成k+1-项频繁项集集合,针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集,其中,k={1,2,...,L,...,N},k-项集表示k种告警类型的集合,N为该告警序列中总告警类型数。

关于如上功能单元的具体实现可参考方法实施例的描述。

本发明实施例装置的各个单元可以集成于一体,也可以分离部署。上述单元可以合并为一个单元,也可以进一步拆分成多个子单元。

可见,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则。具体的:正如本领域技术人员所知,多种告警类型同时发生的概率越大,则所述多种告警类型它们之间就越可能具有强关联关系,现有WinEPI算法中,针对频繁模式P=i1,i2,...,ik,ik+1,其支持度为sup(P),则由该模式得到所有满足条件的关联规则的方法如下:如果则认为属于满足条件的关联规则。同理,计算满足条件则保留规则。这些规则在计算置信度时,分子都相同,不同的是分母,即分母为该模式中各个项(即告警类型)的支持度。相对于现有技术,本发明实施例的告警子系统中,由规则挖掘引擎根据作为分母的、k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。

进一步的,本发明实施例在告警关联规则的挖掘过程中,减缓了现有WinEPI算法可能导致内存不足的问题。具体的:由于使用了滑动窗口,窗口中的告警顺序无法表示告警之间的实际衍生关系,另外,由于电信网络中存在传输、延时、丢失等问题,进一步干扰了告警顺序。实际应用中,规则和往往会共同出现,并且规则在实际中并不能表示告警A是告警B的根源告警。因此这种前后件的规则定义在电信告警挖掘中意义不大,考虑到这些,本发明实施例通过考察“告警A和告警B同时发生”的概率,相对于现有WinEPI算法考察“告警A发生的情况下告警B发生”的概率的情况,从而减缓现有WinEPI方法中候选项集的数量太多所导致的内存不足问题。

请参阅图10,为本发明实施例的应用于告警子系统中的一种规则挖掘引擎的结构示意图,如图10所示,本发明实施例的规则挖掘引擎,可以包括:

第一参数配置模块14,用于接收并保存配置的参数,所述配置的参数包括:最小置信度、最小支持度、时间窗口长度、窗口滑动步长、告警关键字段、告警序列T的起始时间和结束时间;

其中,这里的告警关键字段至少包括告警类型属性和告警发生时间,应当理解的是,还可以包括告警停止时间、告警确认时间等其他字段。这里的告警类型属性至少可以由告警类型字段和告警网元ID字段组合而成,进一步的,这里的告警类型字段至少可以用告警类型ID、告警子类型ID组合表示。

在一种实现方式下,参数配置模块14具体可以是GUI界面或命令行工具或其它接口,供参数配置者配置参数。

第一告警读取模块11,用于根据所述配置的告警序列T的起始时间和结束时间,以及告警关键字段从告警数据库31中读取发生在所述起始时间和结束时间之间的告警的关键属性,并输出告警序列T,其中告警序列T中的每条告警用二元组形式(A,t)表示;A表示告警类型属性,该告警类型属性是至少由告警网元ID、告警类型ID、告警子类型ID组合而成,t表示告警发生时间。

第一告警规范化模块12,用于统计告警读取模块11输出的告警序列T中告警的类型,N为该告警序列T中总告警类型数;较优的,还用于生成告警类型集合(如I={i1,i2,...,in})。

第一执行模块13,用于根据所述配置的时间窗口长度和窗口滑动步长将所述告警序列T划分为多个窗口,计算每个k-项集的支持度,得到k-项频繁项集集合,该k-项频繁项集集合包含支持度不小于配置的最小支持度的k-项集;由该k-项频繁项集集合生成k+1-项频繁项集集合,针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;将极大置信度不小于配置的最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集,向规则推理引擎21输出关联规则结果集,其中,k={1,2,...,L,...,N},k-项集表示k种告警类型的集合,N为该告警序列T中总告警类型数。

关于如上功能单元的具体实现可参考方法实施例的描述。

本发明实施例装置的各个单元可以集成于一体,也可以分离部署。上述单元可以合并为一个单元,也可以进一步拆分成多个子单元。

可见,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则。具体的:正如本领域技术人员所知,多种告警类型同时发生的概率越大,则所述多种告警类型它们之间就越可能具有强关联关系,现有WinEPI算法中,针对频繁模式P=i1,i2,...,ik,ik+1,其支持度为sup(P),则由该模式得到所有满足条件的关联规则的方法如下:如果则认为属于满足条件的关联规则。同理,计算满足条件则保留规则。这些规则在计算置信度时,分子都相同,不同的是分母,即分母为该模式中各个项(即告警类型)的支持度。相对于现有技术,本发明实施例的告警子系统中,由规则挖掘引擎根据作为分母的、k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。

进一步的,本发明实施例在告警关联规则的挖掘过程中,减缓了现有WinEPI算法可能导致内存不足的问题。具体的:由于使用了滑动窗口,窗口中的告警顺序无法表示告警之间的实际衍生关系,另外,由于电信网络中存在传输、延时、丢失等问题,进一步干扰了告警顺序。实际应用中,规则和往往会共同出现,并且规则在实际中并不能表示告警A是告警B的根源告警。因此这种前后件的规则定义在电信告警挖掘中意义不大,考虑到这些,本发明实施例通过考察“告警A和告警B同时发生”的概率,相对于现有WinEPI算法考察“告警A发生的情况下告警B发生”的概率的情况,从而减缓现有WinEPI方法中候选项集的数量太多所导致的内存不足问题。

请参阅图11,为本发明实施例的应用于告警子系统中的另一种规则挖掘引擎的结构示意图,与图10所示实施例稍有差异,如图11所示,本发明实施例的规则挖掘引擎,可以包括:

第二参数配置模块14′,用于接收并保存配置的参数,所述配置的参数包括:最小置信度、最小支持度、时间窗口长度、窗口滑动步长、告警关键字段、告警序列T的起始时间和结束时间;

其中,这里的告警关键字段至少包括告警类型属性和告警发生时间,应当理解的是,还可以包括告警停止时间、告警确认时间等其他字段。这里的告警类型属性至少可以由告警类型字段和告警网元ID字段组合而成,进一步的,这里的告警类型字段至少可以用告警类型ID、告警子类型ID组合表示。

在一种实现方式下,参数配置模块14′具体可以是GUI界面或命令行工具或其它接口,供参数配置者配置参数。

第二告警读取模块11′,用于根据所述配置的告警序列T的起始时间和结束时间,从告警数据库31′中读取发生在所述起始时间和结束时间之间的告警序列T。

第二告警规范化模块12′,用于根据所述配置的告警关键字段将告警读取模块11′输出的告警序列中的每条告警数据转换为二元组形式(A,t),输出规范化后的告警序列T并统计规范化后的告警序列T中告警的类型;较优的,还用于生成告警类型集合,其中,N为规范化后的告警序列T中总告警类型数,A表示告警类型属性,该告警类型属性至少由告警网元ID、告警类型ID、告警子类型ID组合而成,t表示告警发生时间。

实际应用中,告警规范化模块12′进一步用于对时间字段进行规范化处理,例如时区、夏令时转换。

以及,较优的,告警规范化模块12′进一步用于保存规范化前后的告警序列。

第二执行模块13′,用于根据所述配置的时间窗口长度和窗口滑动步长将规范化后的告警序列T划分为多个窗口,并计算每个k-项集的支持度,得到k-项频繁项集集合,该k-项频繁项集集合包含支持度不小于最小支持度的k-项集;由该k-项频繁项集集合生成k+1-项频繁项集集合,针对该k+1-项频繁项集集合中的每个k+1-项频繁项集,根据该k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度;将极大置信度不小于最小置信度的k+1-项频繁项集作为关联规则加入关联规则结果集,并向规则推理引擎21′输出关联规则结果集,其中,k={1,2,...,L,...,N},k-项集表示k种告警类型的集合,N为该规范化后的告警序列T中总告警类型数。

关于如上功能单元的具体实现可参考方法实施例的描述。

本发明实施例装置的各个单元可以集成于一体,也可以分离部署。上述单元可以合并为一个单元,也可以进一步拆分成多个子单元。

可见,本发明实施例相对于现有技术,在告警关联规则的挖掘过程中,通过使用新定义的极大置信度,减少了由于置信度参数的影响而产生的虚假规则,从而减少关联规则结果集中的虚假规则。具体的:正如本领域技术人员所知,多种告警类型同时发生的概率越大,则所述多种告警类型它们之间就越可能具有强关联关系,现有WinEPI算法中,针对频繁模式P=i1,i2,...,ik,ik+1,其支持度为sup(P),则由该模式得到所有满足条件的关联规则的方法如下:如果则认为属于满足条件的关联规则。同理,计算满足条件则保留规则。这些规则在计算置信度时,分子都相同,不同的是分母,即分母为该模式中各个项(即告警类型)的支持度。相对于现有技术,本发明实施例的告警子系统中,由规则挖掘引擎根据作为分母的、k+1-项频繁项集所包含的k+1个1-项集的支持度中的最大值和作为分子的、该k+1-项频繁项集的支持度,计算该k+1-项频繁项集的极大置信度,并将极大置信度不小于最小置信度的k+1-项频繁项集加入关联规则结果集,这样的话,由该k+1-项频繁项集(亦即模式)得到的所有规则(即规则的前件和后件为该模式的子集)的传统置信度均不小于最小置信度,从而可以认为该k+1-项频繁项集中的所有项(亦即告警类型)均同时出现的概率会很大,由此该k+1-项频繁项集中的所有项可认为构成一种强亲密度关联模式,表达的关联程度更强。

进一步的,本发明实施例在告警关联规则的挖掘过程中,减缓了现有WinEPI算法可能导致内存不足的问题。具体的:由于使用了滑动窗口,窗口中的告警顺序无法表示告警之间的实际衍生关系,另外,由于电信网络中存在传输、延时、丢失等问题,进一步干扰了告警顺序。实际应用中,规则和往往会共同出现,并且规则在实际中并不能表示告警A是告警B的根源告警。因此这种前后件的规则定义在电信告警挖掘中意义不大,考虑到这些,本发明实施例通过考察“告警A和告警B同时发生”的概率,相对于现有WinEPI算法考察“告警A发生的情况下告警B发生”的概率的情况,从而减缓现有WinEPI方法中候选项集的数量太多所导致的内存不足问题。

进一步的,本发明实施例在告警关联规则的挖掘过程中,提高了挖掘速度,从而提高了系统处理性能。具体的:在现有技术方案中,由k-项频繁集生成k+1项候选集时,操作过程如下:设i1,i2,...,ik-1,ik和i1,i2,...,ik-1,ik+1为k-项频繁项集,记为P(k+1)/ik+1和P(k+1)/ik,即k+1-项集P(k+1)分别去掉ik+1和ik后得到的项集。然后查找如下k-项集P(k+1)/i1,P(k+1)/i2,...,P(k+1)/ik-1是否都是频繁项集。若都存在,则P(k+1)为k+1-项候选项集,然后将所有的k+1-项候选项集统计支持度,看是否满足最小支持度的要求。采用本发明实施例的极大置信度定义后,要求P(k+1)满足新的置信度要求,即sup(P(k+1))≥max(sup(ii))×min_conf,根据Apriori性质:所有频繁项集的子集必然是频繁项集,所以P(k+1)的任意子集都必须满足sup((P(k+1)的任意子集)≥max(sup(ii))×min_conf。这样,对于每个频繁项,我们都已经记录了其支持度,在由P(k+1)/ik+1和P(k+1)/ik构造准k+1-项候选项集P(k+1)时,我们首先判断如果不成立,则说明P(k+1)不满足置信度条件,无需再判断每个子集是否是频繁项集,从而提高了告警关联规则的挖掘处理速度,进而提高了系统处理性能。

需要说明的是,前述实施例描述中所采用的第一、第二、第三的说法,没有限定顺序的意思,仅为方便区分而已。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件(如处理器)来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)或随机存储记忆体(Random Access Memory,RAM)等。

以上所述仅是本发明的具体实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号