1 事件关联技术
1．1 根本原因与根本原因分析
根本原因(root cause)是影响网络正常工作并触发告警的原因，如路由器软件出现问题、接收缓存不足，则在MIB中if-InDiscards信息将超过阈值，触发“丢弃输入报文”事件。根本原因分析是识别故障的根本原因以及这些原因影响到的网元，它可以简单地定义为解释一系列症状和事件并且查明引起这些症状和事件的原因。
识别根本原因是外延推理常见的问题。外延推理是从结果推论原因的过程(如告警)。许多网络管理系统的外延推理过程分为两个步骤：首先，它们在网络中建立原因一结果传播模型；然后为不确定的根本原因研究模型来解释观察到的告警。有些系统需要用户在专家系统规则中提取出有关根本原因分析的知识。因此，外延推理的问题依赖于用户。另外还有些系统通过基于事例的推理或者代码书的方法进行外延推理。
1．2 事件关联
事件关联是对多个事件的一种解释。一方面通过去除冗余减少了事件数量；另一方面增强了事件内所含的语义信息。事件关联可以看成是一种数据简约及由事件推理与识别故障的技术。事件关联技术到目前为止已经得到了巨大的发展，国内外的研究机构已先后提出多种事件关联技术。这些事件关联技术涉及了计算机科学的不同研究领域，包括人工智能、自动控制论、神经网络、信息论以及图论。下面介绍在RCA系统中使用的两种事件关联的方法：
1．2．1 基于规则的推理
基于规则的推理(RBR)也称为基于规则的专家系统，是最早出现的一种事件关联技术，也是现在用得比较多的一种事件关联技术。基于规则的推理把领域知识以规则集的形式表示，再将网络当前状态与规则的条件部分进行比较，以确定是否采用该规则。规则推理问题求解过程符合人的认知过程，容易实现，有利于问题求解和专家系统的开发。然而基于规则的推理存在很多不足。只依靠专家的经验获得规则，使得基于规则推理存在一定的局限性。为此引入了数据挖掘技术。数据挖掘根据某种关联规则算法，自动找出隐藏在大量事件中的规律性，形成关联规则。
1．2．2 基于事例的推理
基于事例的推理(CBR)是通过过去求解类似问题的经验和知识获得当前问题结果的一种推理模式。在基于事例的系统中，知识的基本单元是事例而不是规则。很多过去发生的事例被存储、检索，并用来解决新问题。由解决新问题的经验构成新的事例；系统将新的事例加入到数据库中，为将来使用作好准备。这样系统可以通过自己的方法来获取知识而不必从通信专家那里获取知识。基于事例推理的另外一个特点是可以根据出现的错误自动改正将来的行为，而且基于事例推理可以通过调整过去的事例来构建新的方法，以自适应的方式面对和处理新的问题。可见，基于事例的推理在一定程度上克服了基于规则的推理的不足：
a)在基于规则的推理中，知识单元是规则，规则必须在原理上解释所有问题类型，因此它的获取过程费力，而且不一定有效。在基于事例的推理中，知识的单元是事例，是从完整的特殊事例中推理而来，无须将经验分解开来，也不需要使用其中的某些部分产生规则，知识获取比较容易。
b)在基于规则的推理中，检索是基于对规则的完全匹配。如果当前网络的状态与规则的前件不匹配，系统将退出整个推理过程。在基于事例的推理中，检索是基于对事例的部分匹配，还可以通过修改添加新的事例。
c)在基于规则的推理中，规则的维护、修改必须要将以前的规则删除，重新得到一个新规则。基于事例的推理进行知识维护，只需要用户将新的事例加入事例库，比较容易实现。
d)基于规则的推理适用于网络规模不大而且微小事件的重复出现；基于事例的推理适用于大规模网络中的复杂问题的整体解决。
2 系统总体设计
2．1 总体结构
实现自动故障管理不仅简单地包括快速获得网络事件和正确关联到它的根本原因，也需要对事件丰富的响应，根据分析的结果进行通告。RCA系统由三个阶段实现，包括事件确认、事件关联、事件通告。在事件确认阶段，RCA系统消灭了临时的网络故障，同时过滤了冗余事件。在关联阶段，RCA系统定位了网络故障的根本原因。在事件通告阶段，RCA系统不但向管理员通报特定的设备或接口故障，同时也根据事先设定的排错流程给出排错方案，如图1所示。
2．2 事件确认阶段
对于有效的网络故障管理来说，发现问题的根本原因是必要的。消灭临时网络告警的能力是正确分析根本原因的主要因素。临时网络失效通常是网络正常操作的一部分。例如，由于网络拥塞或其他临时条件而产生的数据丢失。RCA在关联过程之前应用事件过滤技术进行事件确认，完成临时告警以及其他冗余告警的消除。
事件确认的过程：a)当事件检测模块将发现的事件输入RCA系统后，首先应用忽略规则，检测是否存在用户定义的特定上下文环境c，如果存在则将该事件忽略。b)如果不存在则应用事件压缩规则查看临时事件数据库中是否在某一时间间隔中存在同样事件。如果存在，则将该事件与以前发生的事件进行合并，并且刷新关联数据库；如果不存在则存人临时数据库。c)在应用过滤规则中，主要是定期检查临时数据库中事件发生的时间属性，如果事件发生的时间小于预设的阈值则认为可能是临时事件，将该事件从临时数据库中删除。存入事件关联数据库中的事件即为通过事件确认的事件。
2．3 事件关联阶段
当网络设备故障通过确认阶段鉴别之后，RCA主要通过关联引擎执行根本原因分析来得出故障的确切原因。关联引擎的输入来自两方面：经过事件确认存储在关联数据库中的事件和存储在知识库中的知识，其输出端输出故障假设。测试模块则对故障假设实施测试，验证假设。关联引擎工作原理如图2所示。
1)关联数据库经过事件确认的事件数据按照一定的格式统一保存在关联数据库中，等待关联引擎进行事件关联。
2)知识库知识主要由规则库和事例库组成。规则库是一些故障精练的描述，它是按一定的语法格式书写的，并在相应的模块内存储一张规则表。在规则库中，对规则的描述包括规则的序号、前提、结论和规则本身的可信度。事例库提供支持问题求解的一组案例，它是系统过去进行问题求解经验的聚集。事例库应用一定的事例表示方法，构造数据结构，存储事例的类别、特征、属性、方法、解答以及一般知识或领域知识等信息。
3)事件关联引擎支持基于规则的推理和基于事例的推理，关联引擎提供数据库的检索、比较、修改、添加、删除等功能。首先，关联数据库中的事件所表达的当前网络的状态与规则库中规则的条件部分进行比较，以决定该规则是否被采用。当条件满足时，输出规则的后项。在最简单的情况下，一条规则就可以判断网络故障的根源。实际上这种情况十分少见，多数时候关联引擎需要将当前得到的结论再作为条件在规则库中进行多次推理，最终得出故障假设。
如果应用基于规则的推理未得出结论，则进一步应用基于事例的推理。根据问题描述，关联引擎的事例检索机制从事例库中查找一个与当前问题相匹配的事例。如果该事例满足问题描述的要求，则输出相应的结果；否则根据问题描述，对检索出的事例进行修改，事例改写的结果形成一个满足全部问题描述要求的答案。该结果同时作为一个新的事例经索引机制组织添加到事例库中以备将来使用。
基于规则的推理和基于事例的推理是常用的事件关联技术，在满足关联引擎需求的同时，具有容易实现的优点。
2．4 通告阶段
只向网络管理员通告事件关联的结果是不够的。由于计算机本身并不知道怎样排除错误，为了减轻管理员的负担，在通告阶段首先建立排错流程库，管理人员事先设定排错条件和排错步骤。系统根据根本原因分析的结果查询排错条件并按照管理经验设定规则给出排错方案；同时告警的级别和告警的方式可以根据实际的需要进行设定，尽量及时准确地向管理员进行通告，以减轻网络故障所带来的损失。
3 实验及运行结果
RCA系统用于大型数据库集群系统的故障管理。所管理的数据库集群系统由4个Force10 FA00高性能交换机将10个Cluster连接起来，每个Cluster包含了6个计算节点，18个磁盘控制器和1个磁带库；Cluster内部通过私有网络连接。系统还提供了一套备份网络，因此需要管理的接口总数达500个。实验通过收集事件。并且将事件输入RCA系统，对比分析前与分析后的事件数测试系统的性能。表1、2分别显示分析前和分析后的事件数与每分钟平均事件数。
实验结果表明，通过对网络中的事件进行根本原因分析，平均减少告警日志中90％的数据。
4 结束语
网络故障RCA系统能够消除临时告警和冗余事件，并且应用事件关联技术对事件的根本原因进行分析，及时准确地向网络管理员进行通告，给出排错方案，极大地减轻了网络管理员的工作负担，为故障的排除奠定了基础。下一步需要做的工作就是进一步改进基于规则的推理和基于事例的推理算法，增强关联引擎的功能，更准确、快速地定位网络故障的根源。