CN1529455A

CN1529455A - 网络故障实时相关性分析方法及系统

Info

Publication number: CN1529455A
Application number: CNA031347290A
Authority: CN
Inventors: 俊谭; 谭俊
Original assignee: Harbour Networks Holdings Ltd
Current assignee: Huawei Technologies Service Co Ltd
Priority date: 2003-09-29
Filing date: 2003-09-29
Publication date: 2004-09-15
Anticipated expiration: 2023-09-29
Also published as: CN100456687C

Abstract

本发明提供了一种网络故障实时相关性分析方法及系统，属于计算机网络通信领域。来自各种网络设备和业务对象的故障事件信息写入原始事件列表中，分析控制引擎从原始事件列表中按照原始事件级别和类型选择性读取事件进行相关性分析，在动态的分析算法中综合运用历史故障分析情景、网络动态性能参数、动态拓扑信息和事件时间特征等各种领域信息，克服了现有的故障关联分析方法中忽视动态网络状态信息、推理过程过于依赖预设规则和缺乏自动学习能力等不足，能够对故障引起的原始事件集合进行有效的相关性分析，较好解决了网络故障风暴发生时的实时故障原因分析和故障定位问题。

Description

网络故障实时相关性分析方法及系统

所属技术领域

本发明属于计算机网络通信领域，具体涉及一种网络管理中基于领域综合信息对网络故障事件进行实时相关性分析的方法及系统。

背景技术

在计算机和通信网络中，当某个设备或者服务发生故障时，会因为设备、服务和业务之间紧密联系而引起一系列网络事件，负责监控该网络的网络管理系统通过设备发来的事件通知或者网管系统的轮询监控，会发现大量的异常事件，并通过SNMP Trap、Syslog或者Indication反映到网络管理员的管理界面上，从而表现为“网络故障风暴”。由于这种故障风暴往往在很短的时间内导致大量的事件，淹没了最根本的故障事件，让管理员难以从中发现故障发生的真正原因，要解决故障，就需要从中分析出最根本的故障原因，也就是分析这些事件之间的相关性，寻求根源事件。为了进行事件相关性分析，业界发展出几种典型的方法：如基于规则的分析(Rule Based Reasoning)、基于模型的分析(ModelBased Reasoning)、基于状态转移图(State Transition Graph)的分析、基于代码簿(CodeBook)的分析及基于案例的分析(Case-Based Reasoning)，这些方法都能在一定程度上解决故障相关性分析的问题，并且各有优点。但是这些方法均无法完全解决以下问题：

(1)无法动态的考虑网络拓扑连结信息；

(2)无选择的处理所有的输入事件，效率难以提高，资源消耗大；

(3)推理过程过于依赖预设规则、特征表或模型，缺乏自动学习能力，缺少对知识库以外的新情况的适应能力和处理能力；

(4)在固定的时间范围内观察事件序列，不能动态的改变关联分析的时间范围；

(5)在分析过程中缺少对条件概率和时间因素的考虑；

(6)不能在基于静态信息的分析过程中结合实时获取的网络运行参数。

发明内容

本发明提供一种基于领域综合信息对网络故障事件进行实时相关性分析的方法及系统，克服了现有的故障关联分析方法中忽视动态网络状态信息、推理过程过于依赖预设规则和缺乏自动学习能力等不足，可有效的识别故障源头的关键事件并将其在网络中定位。

本发明的技术内容：一种网络故障实时相关性分析方法，包括：

(1)事件提取接口采集网络中产生的各种故障事件，并写入原始事件列表中；

(2)从原始事件列表中读取一条事件，通过历史故障情景信息进行事件匹配，对网络设备、服务运行参数进行实时检测；

(3)如果未有匹配事件，基于信息模型、拓扑依赖关系选取出与当前处理的事件相关的网络对象进行实时检测，并将实时检测的结果作为条件应用回推理过程中；

(4)返回原始事件列表继续查找与当前处理事件相关的事件或者与实时检测结果吻合的事件，并将该事件加入到工作列表中；

(5)在原始事件列表中已经没有其他可以加入工作列表的事件，则从工作列表中的事件构造一个新的故障情景并加入到历史故障情景信息中，清空工作列表；

(6)从原始事件列表中读取下一个符合选择策略的事件，返回到第二步，如果没有事件在列表中，则挂起等待有事件输入。

所述的信息模型包括：

(1)对被管理网络中的各种被管理对象进行面向对象抽象；

(2)按照抽象后的被管理类之间的继承关系组成一个层次化的信息模型；

(3)在信息模型中用关联类定义被管理类之间的相互关系。：

所述拓扑依赖关系包括：

(1)在网络运行中保持拓扑依赖关系与网络实际拓扑的一致；

(2)将故障相关性分析程序运行的网络节点设为参考点；

(3)通过参考点计算到达其他各个节点的可达性依赖关系。

(4)利用来自设备的拓扑改变的通告触发拓扑同步程序由最新的拓扑重新计算拓扑依赖关系；

所述推理过程包括：

(1)为每一步推理赋予一个置信概率，并通过计算每步的概率得出最后分析结果的概率；

(2)在故障情景创建中定义时间约束函数来描述事件的时间特性以及相关联的事件之间的时间关系；

(3)用形式化方法进行告警内容的表示和匹配。

将历史故障情景信息构造为一张便于快速查询的故障情景表。

所述原始故障事件采集进一步包括：

(1)在处理不同的事件类型时，按照预定规则动态改变原始事件队列的长度；

(2)按照事件级别和用户定义规则来决定哪些事件作为相关性分析的起始点；

(3)对原始事件进行预处理，针对不同协议的故障事件提供可扩展的事件获取接口，将它们转化为统一的内部格式并过滤。

所述构造新的故障情景包括：

(1)提取故障特征参数；

(2)提取故障传播路径；

(3)利用故障特征参数和传播路径构造新的故障解决情景。

一种网络故障实时相关性分析系统，包括：

分析控制引擎：用于按照分析控制引擎算法调用其他模块和接口来完成故障相关性分析；

事件提取接口：用于接收网络设备发来的各种网络事件，将事件转化为统一的格式，写入原始事件列表，供分析控制引擎调用；

实时网络参数检测接口：用于检测网络中各种设备和服务的属性、性能和可达性等实时信息，被分析控制引擎所调用，接受故障分析引擎的参数以决定对哪个网络设备进行实时检测，并将结果返回给分析控制引擎；

信息模型：描述一系列对应于网络协议对象和设备对象的管理类，以及它们之间的相互依赖关系；

信息模型查询接口：用于从信息模型中查询管理类、管理类属性和管理类之间关系的函数，在运行时为分析控制引擎提供来自信息模型的信息；

拓扑同步模块：用于被网络拓扑改变事件触发运行拓扑依赖关系生成算法，生成正确反映当前网络拓扑连结关系的拓扑依赖关系并存入拓扑依赖关系库，拓扑依赖关系库为分析控制引擎提供相关信息；

故障情景表生成模块：用于在已经找到相关性的一组事件上建立一个故障情景，并将此情景存入故障情景表中，通过故障情景表与后续的事件进行匹配。

所述信息模型以散列表文件方式存储，分析控制引擎在分析过程中通过模型查询接口提取信息模型的信息。

进一步包括预处理模块：按照预定的预处理规则对接收到的原始事件进行预先处理。

本发明的技术效果：充分利用了网络中各种动态和静态信息，实时信息和历史信息，在网络出现故障时，从复杂的故障现象及其引起的事件风暴中，有效的识别故障源头的关键事件并将其在网络中定位；此外，因为在分析中应用了与实际网络拓扑状况同步的拓扑依赖关系，以及实时获取的网络运行参数，提高了故障定位的准确性；通过对原始输入事件进行预处理(包括协议格式转换、过滤和选择)，避免了从所有输入的事件入手进行相关性分析，提高了处理效率；利用构造故障处理历史情景表，使本方法具有了从历史经验中自我学习的能力，而且用情景表对事件进行快速匹配，使得有的事件可以直接在情景表中得到匹配，从而避免了对所有的事件都进行全过程的相关性分析，处理效率得到提高；且由于在分析算法中应用概率逻辑和时间约束函数、正则表达式模糊匹配，能够更加灵活的处理事件之间的复杂关系，提高了相关性分析的适用能力。

附图说明

图1是本发明网络故障实时相关性分析系统的结构示意图；

图2是本发明网络故障实时相关性分析方法的流程图；

图3是本发明网络故障实时相关性分析方法的拓扑依赖生成算法流程图；

图4是本发明网络故障实时相关性分析方法的一个具体实施例的网络示意图；

图5是本发明网络故障实时相关性分析方法的一个具体实施例中的信息模型的示意图。

具体实施方式

参考图1，本发明以分析控制引擎为控制模块，通过与信息模型查询接口，事件提取接口和预处理模块、实时网络参数检测接口、故障情景表生成模块、拓扑同步模块的交互来实施网络故障实时相关性分析。具体步骤为：

1、事件提取接口以不同的协议(SNMP/SYSLOG等)提取来自各种网络设备和业务对象的故障事件信息，并将它们的格式转化为统一的内部格式，然后通过事件预处理模块，对这些事件信息进行压缩、过滤(按照预设的过滤器)，写入原始事件列表中；通过对原始事件进行预处理，可有效提高处理效果；

2、分析控制引擎从原始事件列表中按照原始事件级别和类型选择性读取一条事件进行相关性分析；在分析过程中综合应用故障情景表、信息模型信息、实时检测信息和拓扑信息，在分析过程中会按照需要继续从原始事件列表中读取事件来构造事件传播路径，直到无法再找到下一个可以匹配的事件为止；

(1)将历史故障情景信息构造为一张便于快速查询的故障情景表。在情景表中可进行事件的快速匹配；

(2)构造面向对象的层次化网络信息模型：对网路中的硬件、链路、软件和网络服务等被管理对象进行面向对象抽象，按照这些抽象后的管理类之间的继承关系组织成为一个层次化的信息模型。在此模型中同时用关联类定义了被管理类之间的包含、依赖、连结等相互关系。模型以散列表(Hash)文件方式存储，可通过模型对象管理接口访问，利用模型定义的管理类的层次和相互依赖关系来进行推导；在信息模型中描述了一系列对应于网络协议对象和设备对象的管理类，以及它们之间各种各样的关系。信息模型中定义的管理类可以分为拓扑子模型、开放服务子模型和网络通信子模型三个大类。

以下用开放服务系统子模型作为例子来介绍管理类的定义：开放服务系统子模型主要用于描述数据通信网络中的各个节点设备及其内部各个模块，它将一切提供数据传输服务或者数据处理服务的网络节点抽象为一个开放的服务系统，由软件、硬件按照一种可扩展和剪裁的方式进行组合构成不同的系统，其中管理类为：

a、开放服务系统：(Open Service System)代表一切在数据通信网络上提供各层数据服务的系统；包括路由器、交换机或者服务器等；

b、软件(software)：开放服务系统中通过软件实现的功能模块；

c、硬件(hardware)：开放服务系统中通过硬件和固件实现的功能模块；

d、应用(application)：各种应用程序，如邮件客户端；

e、操作系统(os)：各种实时和分时操作系统；如VxWorks，Windows，Unix，Linux等；

f、资源(resource)：系统中基本的共享对象：如内存、磁盘、CPU、中断等；

g、设备(device)：组成硬件的各个模块；

h、服务(service)：

i、协议栈(protocol stack)：

j、内核(kernel)：

k、驱动(driver)：

l、内存(memory)：

m、硬盘(harddisk)：

n、中央处理器(cpu)：

o、总线(bus)：

p、适配器(adapter)：

q、网络适配器(network adapter)：

u、控制器(controller)：

在该信息模型中存在管理类之间的各种依赖关系，如协议依赖关系、开发服务依赖关系等。

(3)实时检测：将推理过程和对网络设备、服务运行参数的实时检测结合起来。

(4)基于指定参考点进行拓扑依赖关系实时计算：将故障相关性分析程序运行的网络节点设为参考点，在此基础上计算到达其他各个节点的可达性依赖关系，并在网络运行中保持与网络拓扑的同步；拓扑依赖关系描述了节点和节点之间的物理性连结，是协议互通性和服务可用性的基础。其中参考点，指当我们考虑到拓扑图中某个节点的可达性时，作为出发点的那一节点，在实际的被管网络中，往往就是网管平台所处的节点，或者是网络探测器(软件或硬件)所处的节点位置。参考图3，建立依赖关系是一个递归算法，每次拓扑发生改变后，都会触发自动运行算法，更新依赖依赖关系，保证当前故障定位和关联的准确性，从而达到下一步需要检测的可能关联的网络实例对象的集合。

(5)在控制分析引擎内部完成相关性分析方法最核心的逻辑，参考图2，

a、从列表中读取一个事件Ei(i＝1～n)，在情景表中用该事件进行匹配，看是否有跟该事件相关的故障历史情景(该故障情景的特征事件与该事件匹配)，对每一个符合的情景，按照步骤(b)处理；

b、调用实时检测模块，对该情境中的相关对象类的相关实例(同时考虑与该事件产生节点相关的拓扑依赖的节点)进行实时状态检测，看返回结果是否符合情景描述的特征范围；然后再到原始事件列表中搜索有没有相关实例产生的后继事件，看是否符合情景定义的特征；如果以上检查通过，则标记这些相关的事件并调用输出模块格式化输出分析结果；

c、如果(b)中检测不符合，则调用模型查询接口，在网络信息模型中查询与产生该事件的对象对应的管理类；同时考虑与该事件产生节点相关的拓扑依赖的节点，得到下一步需要检测的可能相关的网络实例对象的集合；

d、调用实时检测模块检测这些对象的当前状态是否符合星系模型中定义的关系所描述的特征范围，然后检查在原始事件列表中是否有这些对象发出的相关事件，如果有，则将这些事件加入到工作事件列表，转步骤(e)；如果以上检测不通过，则检查工作事件列表是否为空，如果为空转步骤(e)如果不为空，则调用故障情景构造模块为这些事件构造新的故障情景并加入到故障情景表中，同时清空工作事件列表；然后再标记和移除这些事件并格式化输出分析结果，转步骤(e)；

e、从原始事件列表中读取下一个符合选择策略的事件，然后转步骤(a)，如果没有事件在列表中，则挂起等待有事件输入；

其中，在上述步骤提及的匹配和实时状态检测的推理过程包括：基于概率的规则推理：为每一步推理赋予一个置信概率，并通过计算每步的概率得出最后分析结果的概率；对时间约束因素的处理：在故障情景创建中定义时间约束函数来描述事件的时间特性以及相关联的事件之间的时间关系；用正则表达式进行告警内容的模糊匹配。

3、当完成一遍相关性分析后(完成对当前事件列表中所有事件的扫描)，为本遍分析中关联到一起的事件构造故障情景并加入到故障情景表，然后将这些事件移出原始事件列表并构造输出分析结果；

4、在与分析控制引擎进行以上工作的同时，事件采集模块(包括事件采集接口和事件预处理模块)还在同步的向原始事件列表中写入新接收到的事件，拓扑同步模块也同时监控网络拓扑的变化，随时刷新网络拓扑依赖关系库；如果原始事件列表中没有事件了，分析控制引擎将挂起，等待有新的事件写入；事件预处理模块将新的事件写入原始事件列表时，如果发现分析控制引擎挂起，将唤醒该进程。

具体采用一个局域网的例子说明，参考图4，其中A，C，D是局域网中运行Linux操作系统的主机，S是一台三层交换机，R是一台连接此局域网与Web服务器的路由器，也是此局域网的网关。A、C直接与S相连，D直接与R相连，RP是一台运行Windows的PC，也是我们执行相关性分析的参考点，相关性分析系统就运行在这台主机上。

首先，参考图5，本实施例采用一个简化的信息模型，在此网络中：主机A，C，D，RP，路由器R，交换机S都可以被看作是开放服务系统，每个开放服务系统包含了一个协议栈，协议栈负责完成应用与网络上其他开放服务系统中对等实体间的通信。数据向下流经应用、操作系统、协议、接口，然后进入物理网络，经过二层转发和三层路由到达另一个开放服务系统，向上经过接口、协议、操作系统直到另一端的应用。

1)信息模型实例化

以上的模型将在实际的网络环境中生成一些对应于以上模型实体的实例：如路由器R上的应用，我们将其命名为Application_R，R上的操作系统，命名为：OS_R，

与此类推，我们得到其他实例：Protocols_R，Interface_R；

同样：

对于主机A，我们得到Application_A，Service_A，OS_A，Protocols_A，Interface_A；

对于主机C，我们得到Application_C，Service_B，OS_C，Protocols_C，Interface_C；

对于主机D，我们得到Application_D，Service_D，OS_D，Protocols_D，Interface_D；

而且存在以下依赖关系：

Application->Service；

Service->OS；

OS->Protocols；

Protocols->Interface；(注意：这是一个简化的模型)；

假设模型中有定义web_browse_in_url->DNS service；

X.interface.fail等价于X.down；

2)拓扑依赖关系生成

对于图4所示的网络，网络管理平台将通过自动发现得到其拓扑数据，然后运行拓扑依赖关系生成算法，(以RP为参考点)得到以下拓扑依赖关系集合：RD＝{A->S，C->S，S->R，D->R，Intemet->R，R->RP}

其中：’X->Y’的含义可以解释为“要访问X，必须先经过Y”；

R->RP表示R是与参考点RP直接相连的网络节点；

当网络拓扑或参考点发生改变时，该算法自动更新依赖关系，从而保持依赖关系能够反映实际的网络运行状况。

3)事件提取接口开始接收网络中产生的各种事件。

假设在主机A上运行了一个DNS服务(可以看作一个服务)，而在主机D上有个程序在不断的访问Web服务器上的主页www.harboumetworks.com，可以将其看作一个Applicaion，我们命名为web_browse_in_url。

假设在某个时刻，事件提取接口从各个主机的SNMP代理接收到以下事件，这事件被格式化后表示如下：

　　{

　　E0＝RP.ping.S.fail：t0，表示t0时刻从RP上无法ping到交换机S，

　　E1＝RP.ping.C.fail：t1，表示t1时刻从RP上无法ping到主机C，

　　E2＝RP.ping.C.fail：t2，表示t2时刻从RP上无法ping到主机C，

　　E3＝D.web_browse_in_url.Web_Server.fail：t3表示t3时刻主机D上无法访问Web
服务器。
        <!-- SIPO <DP n="9"> -->
        <dp n="d9"/>
　　E4＝RP.ping.A.fail：t4，表示t4时刻从RP上无法ping到主机A，

　　E5＝RP.ping.A.fail：t5，表示t5时刻从RP上无法ping到主机A，

　　E6＝R.down：t6，表示t6时刻R失效，

　　E7＝RP.web_browse_in_url.web_server.fail：t7表示t7时刻主机RP上无法访问
Web服务器。

　　E8＝R.up：t8，表示t8时刻R恢复工作，

　　}

4)E0...E4随后被送给预处理模块处理后，得到压缩后的原始事件集合，注意这里过滤了重复的事件(E2，E5)和故障状态已经解除的成对事件(E6，E8)；

{

E0＝RP.ping.S.fail：t0，表示t0时刻从RP上无法ping到交换机S，

E1＝RP.ping.C.fail：t1，表示t1时刻从RP上无法ping到主机C，

E3＝D.web_browse_in_url.Web_server.fail：t3表示t3时刻主机D上无法访问Web服务器。

E4＝RP.ping.A.fail：t4，表示t4时刻从RP上无法ping到主机A，

E7＝RP.web_browse_in_url.Web_Server.fail：t7表示t7时刻主机RP上无法访问Web服务器。

}

5)利用领域综合信息对通信网络中的故障事件进行实时相关性分析：

(a)分析控制引擎从原始事件列表中读取一条事件：E0＝RP.ping_S.fail：t0；从中解析出

节点对象：源节点RP，目的节点S，

应用对象：RP.ping，ping属于Applications；

应用对象状态：fail；

将E0标记并加入工作事件列表；

(b)打开并查询情景表中有无与RP，S，ping相关的情景，发现情景表为空(系统第一次初始化，还没有加入新的情景)，关闭情景表；

(c)调用信息模型查询接口，查询ping(Application)，得到关系：Applications->Services，Services->Protocols，Protocols->Interface；再查询拓扑依赖关系库，得到R->RP，S->R；

(d)调用网络状态实时检测接口，检查S.Interface，发现S.Interface状态为fail，则根据依赖关系可以推断出以下结果：

S.Interface.fail＝＝S.down；

S.down＝>A.down and C.down；

A.down＝＝A.Interface.fail＝>A.application.fail and A.services.fail

C.down＝＝C.Interface.fail＝>C.application.fail and C.services.fail；

A.services.fail＝>A.DNS.fail＝>*.browse_web_in_url.fail

(e)从E1开始检查原始事件列表。读取E1

E1＝RP.ping.C.fail：t1，从中解析出

节点对象：源节点RP，目的节点C，

应用对象：RP.ping，ping属于Applications；

应用对象状态：fail；

ping属于application，要求RP和C，以及拓扑依赖的S，R上的applications，services，protocols，interface均保持正常，则S.down，C.down均可推出E1，所以E1被关联上，分析引擎将E1标记并加入到工作事件列表中；

继续往下读取E3：

E3＝D.web_browse_in_url.Web_server.fail：t3解析得到：

节点对象：D，Web_server；

应用对象：web_browse_in_url；

应用对象状态：fail；

根据前面得到的：A.services.fail＝>A.DNS.fail＝>^*.browse_web_in_url.fail，可以得出E3也是E1的相关事件，于是E3被标记并加入到工作事件列表中。

同理，可以分析出E4和E7都是E1的相关事件，于是标记该事件被加入到工作列表。

(f)发现原始事件列表中已经没有未标记的事件，则调用输出模块对原始事件列表进行格式化输出：

输出告警：

　　 Alarm1＝

　　{

　　Cause：RP.ping.S.fail：t0

　　Affects：

　　 [

　　RP.ping.C.fail：t1

　　D.web_browse_in_url.Web_server.fail：t3

　　RP.ping.A.fail：t4

　　RP.web_browse_in_url.Web_Server.fail：t7

　　    ]

　　}

(g)利用故障特征参数和故障传播路径为这些事件构造新的故障解决情景Scenel：S.down＝>{A.down and C.down and^*.web_browse_in_url.fail}并加入到故障情景表中。

(h)清空工作事件列表；从原始事件列表中移除这些事件。

(j)如果此时有新的事件加入到原始事件引擎则转(3)，否则挂起，等待新的事件输入；

(k)假设有新的事件来到：

E9＝D.web_browse_in_url.Web_Server.fail：t9

E10＝A.down：t10；

(l)事件分析引擎读取E9，在事件情景表中查询，发现在Scene1中有^*.web_browse_in_url.fail这个事件特征模式与之匹配，将E9加入到工作事件列表中，继续查看在原始事件列表中是否有特征事件：A.down和C.down，读取到E10，满足A.down，将E10加入工作事件列表；这时候列表中没有其他的事件了，还余下一个特征C.down需要被证实，于是调用实时检测接口，检测发现：C.down＝true；于是情景得到匹配，直接得出结果S.down。以下同(1)描述的步骤。

在上一步中，如果对C的实时检测结果C.down＝false；则上述情景不能完全被置信，可以给予一个置信概率。表示还可能有其他的原因。

通过运用领域综合信息，包括基于网络信息模型的管理对象层次信息及相互关系、自动学习的故障处理历史信息、实时采集的网络运行参数、网络动态拓扑信息、事件时间特征等，并在推理过程中运用动态分析方法，较好解决了在复杂网络环境中的故障相关性分析问题。

参考图1，本发明网络故障实时相关性分析系统，包括：

分析控制引擎：分析过程的主要控制逻辑执行者，用于按照分析控制引擎算法调用其他模块和接口来完成故障相关性分析；

信息模型：描述了一系列对应于网络协议对象和设备对象的管理类，以及它们之间各种各样的关系，信息模型中定义的管理类可以分为拓扑子模型、开放服务子模型和网络通信子模型三个大类；

事件提取接口：用于接收网络设备发来的各种网络事件，包括SNMPTRAP、SYSLOG、CMIP Event Report等各种协议的事件通告，将该事件转化为统一的格式，并交给预处理模块；

预处理模块：用于对接收到的原始事件进行简单的过滤(按照设定的规则去除一些管理人员无需关心的事件)、压缩(去除重复的事件)、重定义(把一个或多个事件重新定义为一个新的事件)等预先处理，有利于相关性分析；

实时网络参数检测接口：用于检测网络中各种设备和服务的属性、性能和可达性等实时信息，被故障分析引擎所调用，接受故障分析引擎的参数以决定对哪个网络设备进行实时检测，并将结果返回给故障分析引擎；

故障情景表生成模块：用于在已经找到相关性的一组事件上建立一个故障情景，并将此情景存入故障情景表中，这些建立的故障情景供后续分析快速查找使用，建立的故障情景可供后续分析快速查找并使用；

拓扑同步模块：用于被网络拓扑改变事件触发运行拓扑依赖关系生成算法，生成正确反映当前网络拓扑连结关系的拓扑依赖关系并存入拓扑依赖关系库，供故障相关性分析使用。

Claims

1.一种网络故障实时相关性分析方法，包括：

2.如权利要求1所述的网络故障实时相关性分析方法，其特征在于所述的信息模型包括：

(1)对被管理网络中的各种被管理对象进行面向对象抽象；

(3)在信息模型中用关联类定义被管理类之间的相互关系。

3.如权利要求1或2所述的网络故障实时相关性分析方法，其特征在于所述拓扑依赖关系包括：

(1)在网络运行中保持拓扑依赖关系与网络实际拓扑的一致；

(2)将故障相关性分析程序运行的网络节点设为参考点；

(3)通过参考点计算到达其他各个节点的可达性依赖关系。

(4)利用来自设备的拓扑改变的通告触发拓扑同步程序由最新的拓

扑重新计算拓扑依赖关系；

4.如权利要求1所述的网络故障实时相关性分析方法，其特征在于所述推理过程包括：

(3)用形式化方法进行告警内容的表示和匹配。

5.如权利要求1所述的网络故障实时相关性分析方法，其特征在于将历史故障情景信息构造为一张便于快速查询的故障情景表。

6.如权利要求1所述的网络故障实时相关性分析方法，其特征在于所述原始故障事件采集进一步包括：

7.如权利要求1所述的网络故障实时相关性分析方法，其特征在于所述构造新的故障情景包括：

(1)提取故障特征参数；

(2)提取故障传播路径；

(3)利用故障特征参数和传播路径构造新的故障解决情景。

8.一种网络故障实时相关性分析系统，包括：

9.如权利要求8所述的网络故障实时相关性分析系统，其特征在于所述信息模型以散列表文件方式存储，分析控制引擎在分析过程中通过模型查询接口提取信息模型的信息。

10.如权利要求8或9所述的网络故障实时相关性分析系统，其特征在于进一步包括预处理模块：按照预定的预处理规则对接收到的原始事件进行预先处理。