告警采集系统的开发和应用-毕业论文

本科毕业论文(科研训练、毕业设计)题 目：告警采集系统的开发和应用姓 名：学 院：软件学院系：专 业：软件工程年 级： 学 号：指导教师（校内）： 职称： 指导教师（校外）： 职称： 年 月 日告警采集系统的开发和应用 摘要本文阐述了告警采集系统的总体架构，对于它的每个模块都作了具体的分析和设计。同时引入了规则引擎的应用和一些开发设计思路，说明了一个合理的系统设计将大大降低开发的难度和提高软件的复用性和可扩展性。关键词告警采集 规则引擎 告警解析 标准告警映射 告警过滤 告警重定义The development of alarm collection systemAbstract：In this paper, we explain the structure of the alarm collection system. And we analyze the design of modules in this system. Also we introduce the application of rule engine and some concepts of design. At the end, we discuss a good design will reduce the complexity in the development of the system, and it will promote the reuse of the software and make the system extensible.Keywords：Alarm Collection； Rule Engine； Alarm Analyze； Standard Alarm Mapping； Alarm Filter； Alarm Redefine目录1.引言52.项目总体设计52.1.项目说明52.1.1.项目名称52.1.2.项目地位52.1.3.项目现状52.1.4.项目业务62.1.5.项目目的62.2.系统架构62.2.1.告警系统总体架构62.2.2.告警采集系统总体架构72.3.实现方式103.项目详细设计103.1.告警底层接收模块的建立113.1.1.Socket公共服务的建立113.1.2.原始告警接收的实现123.2.告警处理模块设计133.2.1.规则引擎服务的建立.规则引擎理论.Drools规则引擎的应用.告警规则过滤器引擎的应用163.2.2.告警解析和标准映射的实现173.2.3.告警上报过滤和告警重定义的实现183.3 告警采集线程管理服务的实现183.4. 告警发送服务的实现183.4.1.告警发送队列的建立183.4.2.告警发送的实现193.5.告警同步数据配置接收的实现194.系统的运行结果204.1.采集线程的管理204.2.告警采集的运行205.结束语23致谢语23参考文献231. 引言告警采集系统是联通网管项目中告警系统的一个子模块，由于它处于整个告警系统的最底层，所以在整个系统中至关重要，告警系统中的其它模块都需要有采集系统获得的数据支持。实现该采集系统的功能是一个重要的方面，但更为重要的是要搭建采集系统的可执行框架。因为采集系统面临着多厂商，多接口，难管理，经常变动等问题，所以要求系统要实现可配置、易于管理，易于移植的框架结构。本文就告警采集系统的各个模块，进行了详细的分析和设计，引进了规则引擎和一些设计方法，意在使整个系统变的更加的灵活和易于扩展。2. 项目总体设计2.1. 项目说明2.1.1. 项目名称告警采集系统2.1.2. 项目地位告警采集系统是整个告警系统的基础，在整个联通综合网管系统中占有举足轻重的地位。该系统连接着各个厂商的网元设备，这些设备发送联通全省各个地市的基站设备的警报信息。该系统从这些设备中获得不同厂商设备的告警信息，并将原始的告警信息解析成标准的告警信息，并按照一定的规则对标准的告警信息进行过滤和重定义，最终按照预先设定的格式组合成字节流发送给下一模块。从该系统发送的数据将在数据处理层进行升级、压缩、归并等处理，继续发送给应用展现层，最终进入电子运维系统。所以，告警采集系统在整个告警系统中处于底层的基础地位，告警系统的其它模块都依赖于该采集系统，在此基础上整个系统才能够顺利地运行。2.1.3. 项目现状(1) 多厂商、多接口：从已经运行和在建的移动网管系统看，告警系统都存在厂商多，接口多（ftp接入，Q3接入, CORBA接入，TCP/IP接入，命令行方式接入），由于接口方式太多导致接入模块不统一，造成进程管理混乱。(2) 数据量大：对于全省综合网管，告警的数量众多，从而有可能导致系统繁忙而无法处理因而告警丢失。(3) 设备不断升级：由于设备不断升级造成原有的告警采集模块，更新频繁，导致影响系统的稳定性。(4) 各专业协作需要：告警系统需要具有开放的系统已适应运营商内部的各专业协作。(5) 难维护：告警系统自身故障难定位与维护。2.1.4. 项目业务告警采集主要是实现与网元的连接并采集告警数据。对于采集到的告警数据按照以下的处理流程进行业务逻辑处理：1.告警接收：连接网元接收告警2.告警解析：解析各个厂家不同设备的告警，分拆得到需要的告警字段，如告警级别3.告警标准映射：将各个厂家的告警按照一定的规则映射为网管系统的标准告警4.采集过滤：也就是上报过滤，过滤掉用户认为不重要的告警。过滤的告警在网管系统中不存储5.告警重定义：根据定义的过滤条件，重新定义告警的告警级别和告警类型6.告警前传：为了保证重要和主要告警，按照告警级别，分优先级别的前传告警2.1.5. 项目目的该项目除了要求完成项目所要求的业务功能之外，更为重要的是提供一个告警采集系统的可执行框架，在这个框架上实行可配置，可扩展，易于维护的特点。使得各地的告警采集、不同厂商的服务，经过一定的配置后，都能在这个采集框架上执行起来，而不需要重新进行设计、编码。2.2. 系统架构2.2.1. 告警系统总体架构图2-1 告警系统架构图告警系统体系结构如图1-1所示，目前分为五层：数据采集层、数据处理层、应用展现层、电子运维系统和公共服务层。可以看到在告警系统中数据采集服务层位于系统的最底层；在采集层对数据进行了初步地处理后，将数据发往数据处理层作进一步地处理；然后再将告警数据前传至数据展现层，对数据做出进行不同形式地展现；最后派发成各种工单，进行任务调度。再此期间各个层次都有可能调用公共层的服务。从图1-1我们可以清楚地了解整个系统的流程，以及告警数据采集系统在整个系统中所占的地位和作用。2.2.2. 告警采集系统总体架构图2-2 告警采集模块系统架构图如图2-2所示，告警采集模块采用统一的架构在公共服务的基础上，实现各个模块的服务功能。公共模块提供了Socket Server模式服务、Socket Client模式服务、Drools规则引擎服务以及规则过滤器引擎服务，各个模块相应地应用一个或一个以上的公共服务。告警采集系统从原始告警接入连接各种不同厂商的设备，获取各种告警字节流；接着对各种原始告警进行解析，拆分成各个所需的字段；然后将拆分成的各个字段，再结合数据库，组合成标准的告警格式字段；对映射成标准字段的告警必须利用规则过滤器进行上报过滤和重定义操作；同时提供对数据同步的服务；最后将各个标准告警字段转化成标准的告警格式字节流向下一个模块发送，从而完成告警的采集工作。具体的业务流程见图2-3:图2-3 告警采集处理流程2.3. 实现方式为保证采集模块的整体架构的合理性和通用性，以及开发难度的降低，该模块的程序实现采用Java代码，整体程序实现架构见图2-4：图2-4 告警采集系统实现模式图告警采集系统首先从xml配置文件中读取相关的配置信息，再将这些配置信息传递给一个个Socket server服务或者Socket client服务实例，进行相关的配置；再注册这些服务实例给管理服务线程，便于管理这些服务实例，同时启动各个服务；接着就进行原始告警的读取、拆分，并进行解析，同时进行告警的映射，将原始告警映射成一个个标准的告警字段；对这些标准的告警字段进行上报过滤和重定义；同时接收告警的同步数据；最后创建告警优先级队列，将告警信息按照优先级不同进行发送。这些核心的服务将由一个核心服务类来处理，该类调用Drools规则引擎服务和规则过滤器服务，来完成相应的功能。该实现模式类似于MVC(Module View Control)架构模式。其中的多个服务模式采用多个接口，以便于将来的修正和扩展。3. 项目详细设计3.1. 告警底层接收模块的建立3.1.1. Socket公共服务的建立告警采集的主要两种方式在于Socket Client模式的采集和Socket Server模式的采集。也就是说一种方式主要由我们作为客户端主动的去连接网元设备，另一种方式是，我们作为服务端，由网元设备主动来连接我们,向我们发送原始的告警信息。Socket Server模式的建立，已经有现成的开源项目QuickServer来实现。但QuickServer并不能完全符合我们的要求，所以我们对其源代码进行了一定的修改。Socket Client模式应与Socket Server模式保持一致，即在实现和处理的结构上相统一。Socket服务的处理模式如图3-1所示:图3-1 Socket服务模式从图3-1我们可以看出，该服务其实只提供了数据处理的接口，并提供了基本的管理配置实现，而数据处理功能的真正实现并不再服务层实现，而是通过服务层的调用来实现。我们在这里将Socket Server模式的服务用QuickServer表示；Socket Client模式的服务用QuickClient来表示；将Sever模式的采集服务用CollectionServer表示；将Client模式的采集服务用CollectionClient来表示；将线程管理服务用AdminServer表示；将数据同步服务用SyncServer表示；将以Socket发送的服务用SocketSendServer表示。他们之间的继承关系从图3-2种可以看出来。图3-2 Socket服务继承关系从图3-2中我们可以看出告警采集服务的各种主要服务都是基于QuickServer和QuickClient这两种服务，他们中继承了Socket服务的主要特点，更重要的是他们实现了Socket服务提供的处理接口，这样的设计方便于开发人员当其中某种服务需要更改或者需要增加某种服务时，不需要触及底层的核心服务，具有比较高的可扩展性和可维护性。同时这些服务都是基于线程的，所以线程管理也成为关键的问题，要确保线程的正确停止和开启，否则Socket服务要么可能不能开启，要么可能被未完全回收的线程耗去资源。3.1.2. 原始告警接收的实现无论是基于QuickServer的服务还是基于QuickClient的服务它们的共同特征就是在于他们实现了两种服务提供的各自的一个处理接口，所以原始的告警接收处理就是集中在一个类中处理，而这个类是最具核心功能的它除了告警的接收，其它的告警采集业务功能的实现也都集中在这个类中，包括规则引擎的执行。我们将这个类用AlarmHandler表示。在这个类中我们要对获得的字节流进行处理，原始告警采集的字节流的接收主要问题就是集中在，我们一次接收多长的字节流，而怎么将字节流拆分成一条条的原始告警，而原始告警文本的长度并不是一定的，所以原始告警文本可能在半中间被截断获得，同时原始告警文本包含有中文，而一个中文字符包含有两个字节，而获得的字节流的最后一个字符很可能是一个中文字符的第一个字节，而第二个字节可能在下个字节流中获得。基于以上的情况我们才用如图3-3的处理方法:图3-3原始告警接收流程从图3-3我们可以知道，原始告警接收过程关键问题就是字节流的拼接过程。3.2. 告警处理模块设计3.2.1. 规则引擎服务的建立. 规则引擎理论Java规则引擎是推理引擎的一种，它起源于基于规则的专家系统。Java规则引擎将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。Java规则引擎接受数据输入，解释业务规则，并根据规则做出业务决策。从这个意义上来说，它是软件方法学在关注点分离上的一个重要的进展。规则引擎包括三部分：Rule Base（规则库）、Working Memory（工作区），用来存放原始数据以及Rule Engine（推理引擎）。其中推理引擎包含三部分：Pattern Matcher、Agenda和Execution Engine。Pattern Matcher决定选择执行哪个规则，何时执行规则；Agenda管理Pattern Matcher挑选出来的规则的执行次序；Execution Engine负责执行规则和其他动作。它们的结构如图3-4所示：图3-4 规则引擎架构和人类的思维相对应，规则引擎存在两者推理方式：演绎法（Forward-Chaining）和归纳法（Backward-Chaining）。演绎法从一个初始的事实出发，不断地应用规则得出结论（或执行指定的动作）。而归纳法则是从假设出发，不断地寻找符合假设的事实。Rete算法是目前效率最高的一个Forward-Chaining推理算法，Drools项目是Rete算法的一个面向对象的Java实现。规则引擎的推理步骤如下：1.将初始数据（fact）输入Working Memory。2.使用Pattern Matcher比较规则（rule）和数据（fact）。3.如果执行规则存在冲突（conflict），即同时激活了多个规则，将冲突的规则放入冲突集合。4.解决冲突，将激活的规则按顺序放入Agenda。5.使用规则引擎执行Agenda中的规则。重复步骤2至5，直到执行完毕所有Agenda中的规则。使用规则引擎可以让你的系统更加的高效和具有很大的可升级性；同时能够提高软件的生产效率和可维护性；规则库中规则集的集中化，可以形成专家知识库，规则引擎可以用来做决策支持系统和数据挖掘的开发工具之一；规则库的应用大大增加了软件的灵活性，开发人员可以根据不同用户定制不同的规则库，为不同的用户定制不同的产品。. Drools规则引擎的应用Drools是一个开源的规则引擎，它是一个基于Rete算法的前向链式推理（演绎推理法）的专家执行系统。其体系结构见图3-5：图3-5 Drools规则引擎体系结构Rete算法被包含在drools-core的模块中，drools-core是整个系统的基础；drools-smf模块即Semantic Module Framework（语义模块框架）模块，该模块通过创建工厂集合，这些工厂集合执行了各种spi（Servic Provider Interface）接口，通过这些工厂集合来创建规则集。规则集也可以直接通过执行spi来直接创建，不必经过smf模块，我们称这样的规则集为“native”规则集，即本地化的规则集。smf模块是一个运行时的模块，即在程序运行的时候被动态载入的。smf模块中注册着多种的语义模式，在程序运行时，程序将根据寻找namespace（域名空间）来决定该用哪个语义模块，从储存语义模式的仓库中选择合适的创建工厂来创建特定语义的规则集。Drools目前包含了四种语义执行方式，它们分别是python、groovy、java和pojo。这些语言的实现都是依赖于drools-smf模块中drools-base中的公关函数的实现。为了能够编译这些语言，Drools系统还包括了drools-io模块。drools-io模块是基于xml的驱动系统，drools-io模块并不知道drools-smf模块用经过寻找选择过的创建工厂替换了它自己创建的包含了各种元素的配置对象。这些创建工厂就是根据域名空间来从语义模式仓库中选择出的特定语言的创建工厂。为了保持规则引擎的通用性，为了能够比较方便的实现不同规则引擎的规则兼容性，Drools规则引擎还引用了标准的JSR-94通用API,同时还允许第三方的程序加载不同的规则集。在我们的开发系统中，在前面我们已经分析过了，告警采集系统面临着多接口、多厂商和经常变动的问题，如果每遇到一个厂商就进行一次编码，再对程序重新进行编译，再进行测试，这将大大加重程序员的负担。而使用规则引擎则将业务逻辑和软件技术相分离。也就是说告警采集解析如果采用了Drools的规则引擎，我们就不必在源程序代码中编写解析逻辑，而这些解析逻辑将编写成规则文件，放到程序的外边，由程序运行时动态加载。这样当遇到一个新的厂商我们就不必找到源程序进行修改只要，编写规则文件和配置文件就可以顺利完成，这样这是我们这个系统期望达到的最佳目标。而且Drools可以使用Java语言来定义规则，而不必另外学一门新的规则语言，这可以省下大量的开发时间，节省成本。Drools开源项目的使用方式并不复杂，首先就是定义规则集，规则可以用xml文件编写，当然当规则量大时，为了方便管理可以从数据库中加载规则集。定义好规则文件中后，就是要在程序中启动规则引擎、创建规则、导入对象因子、激活规则和获得执行规则后的结果。在这个项目中我们使用Java语言来编写规则集。具体使用方式和代码可参阅源程序文档。. 告警规则过滤器引擎的应用告警规则过滤器引擎即告警上报过滤以及重定义规则引擎并不是采用目前比较成熟的开源项目或者是商业的规则引擎，而是采用自己编写的规则引擎，规则的存放是存在数据库中，其原因在于：1. 在前面的告警采集解析和告警标准映射的阶段，我们编写的规则文件虽然是xml文件，但文件中所涉及的规则逻辑是采用Java语言编写，所以这里的规则文件的编写必须由编程人员或熟悉Java语言的人员来完成，并不要求客户来编写这些规则文件。而告警上报过滤和重定义规则则是客户提出要求由他们来编写的，这相对于告急解析和映射来说有着更频繁的变动。2. 虽然目前已有的规则引擎比较成熟，无论在稳定性还是在处理速度性能上都达到了比较理想的水平。但是目前的规则引擎规则的定义都有一套特定的定义语言，要么是目前流行的编程语言，要么是自己定义的比较复杂的语言。而这些语言对于编程人员来说并不是什么难事，而对于客户来说可能就不那么容易理解和接受，至少培训客户将带来成本上的增加。所以针对以上两点，Drools的规则引擎并不完全符合我们这个模块的要求，我们必须有一套比较简易的规则语言和解析规则语言的引擎。经过选择我们选定xml格式的规则语言，这里的xml格式中，只涉及到元素和属性，并不涉及其它复杂的语言，所以对于客户来说是比较容易掌握的，规则语言定义如下： 从该规则来看，我们可以知道：是根节点，它的下面可以包含操作符：、等操作，在这些操作符下，依照操作符的逻辑特点可以包含一个到多个节点，形成一个递归的特点，其实也就是一棵树，这棵树是一个多叉树，如图3-6可以表示为：AndOrAndNotAnd操作And操作操作图3-6由于这些规则是用户自己定义的，同时规则数量纵多，所以规则必须存储到数据库中，这样方便管理。而用户则是通过前台的界面定制、修改规则，然后提交到数据库中，而程序则从数据库中加载规则。我采用这样的XML格式来说，好处在于这种格式易于理解，对于用户来说并不是太困然，同时在Java语言中提供标准的解析XML文档树的类和方法，对于解析这样一棵XML文档树易入反掌。3.2.2. 告警解析和标准映射的实现告警采集系统中需要用到Drools规则引擎的有多处地方，但主要用到Drools规则引擎的有两个模块就是，原始告警的解析和标准告警的映射这两个模块。所谓的原始告警解析就是把诸如这样的告警文本，拆分成各种可用的字段：+ HW_SWITCH 2005-01-19 01:08:57ALARM 420811 故障告警 提示告警 3706 对象编号 = 1618 对象名称 = 常太长基 对象类型 = BTS 网元编号 = 16 网元名称 = 莆田BSC 网元类型 = BSC 模块编号 = 1 告警名称 = UPS电源异常告警 网管类型 = 环境告警 定位信息 = 对象类型=0,站点号=22,模块号=1,站点类型=9,单板ID=129,单板号=0,支路号=0 详细解释 = 支路号0表示市电掉电告警：当UPS判断到交流输入市电掉电后，会上报一个市电掉电告警信号；支路号1表示电池欠压告警： 蓄电池放电到欠压点66.00.5Vdc时，UPS将上报该告警信号。 修复建议 = 无- END告警文本所对应地解析规则可参见源代码，这里不再做详诉。将告警文本拆分成多个字段后，我们将从这些字段中提取有用的信息，再根据特定的条件查询数据库，获得其它的信息，再将这些信息封装到一个通用的标准类中，这样的一个过程就称为标准告警映射。每个不同的设备告警，它的映射过程有所不同，或者数据库表的不同，或者配置文件的不同，这些都将作为规则配置到规则文件当中，在程序执行的时候动态载入。3.2.3. 告警上报过滤和告警重定义的实现告警规则过滤器引擎是在程序一开始运行时就载入到内存当中，而告警上报过滤和告警重定义的实现就是依靠该规则引擎来实现。告警上报过滤的概念就是把采集来的经过解析和标准化映射的告警，传入规则引擎，由规则引擎决定是否对这个告警实行过滤。也就是说规则里定义一些规则，这些规则制定了在标准告警中的一些字段必须符合某些特定的值域，如果规则引擎发现了一个标准告警符合条件，则它就把该告警视为无用的告警，将其直接丢弃。而告警重定义则是，当过滤器发现一个告警满足了重定义的条件的时候，就会根据规则返回一个告警需要重定义的级别和重定义类型，程序就根据这个规则的返回值对标准告警的某些特定字段的值进行重新的设定，以满足要求。3.3 告警采集线程管理服务的实现从上文的分析中我们知道告警采集线程管理服务即AdminServer服务，是继承QucickServer服务的，所以它的后台实现也是实现QuickServer提供的核心处理接口来实现。在程序开始运行时，我们将告警采集中的所有线程都注册给AdminServer,这样AdminServer根据所有线程id就可以方便的实现对某个服务线程的管理。在前台的管理界面中我们通过建立Socket的连接，连接上AdminServer服务器，再通过向AdminServer发送消息实现简单的管理。而AdminServer接收并解析前台发送的消息，然后对相应的线程实现控制。前台的各个线程展示也是通过读取Server端的xml配置文件来实现。3.4. 告警发送服务的实现3.4.1. 告警发送队列的建立原始告警经过接收、解析和标准映射后，就要转化成标准的告警字节流的形式，而标准告警是具有优先级的。所以我们要将标准告警按照一定的优先级的方式发送。同时告警发送队列是有多个线程访问的，所以要解决数据访问的同步问题，否则会造成数据插入和发送的错误。多级队列用Java中的Vector向量来实现。告警发送的优先级策略我们根据客户的要求，就是高优先级告警优先的原则，就是优先级最高的告警优先发送，其次是低优先级的。同时尽量避免为了避免发送队列溢出而丢失告警的情况发生，我们规定当有某个队列的长度超过总容量的2/3时，优先发送该级别的队列。这些控制都将在队列本身所处的类中进行控制。3.4.2. 告警发送的实现告警发送模式的设计我们采用工厂创建型模式和适配器桥接模式，如图3-7所示：图3-7 告警发送模式告警发送我们目前采用Socket的发送形式，不过Socket发送时，如果前台处理速度跟不上将会造成Socket连接的断开，这样有可能导致告警的丢失或告警发送队列的溢出。所以目前我们虽然采用Socket发送模式，但我们计划以后将系统升级为采用JMS(Java Message Service)这种更加稳定的Java消息服务来进行告警的发送。由于基于Socket发送服务和基于JMS的发送服务是两个不同的设计，所以我们必须采用适配器的方式使两种服务兼容；同时我们必须在运行时决定采用使用哪种服务，所以我们也采用了简单的工厂创建型模式。从图3-7我们可以看到在类SocketSendServerImpl和类JmsSendServerImpl，它们都实现接口SendServerInterface，它们都提供公有的方法init()和startServer()。通过实现这两个方法使两个完全不同的类相协调，使它们能够工作在一起。这种模式称为适配器的桥接模式。同时这两种模式我们要在程序运行时进行选择其中一种服务模式启动，为了使系统有着更加合理的结构我们采用了工厂创建型模式。通过SendServerFactory中的createInstance()方法来创建实际的发送服务。crateInstance()方法根据类型type和配置信息config来创建所需要类型的服务，并通过SendServer类的setInstance方法设定服务对象的引用，并由SendServer启动服务。3.5. 告警同步数据配置接收的实现告警同步数据配置服务SyncServer，主要是用来接收配置信息，并解析配置信息进行相关的配置操作。该服务接收规则过滤器的同步配置信息，我们知道规则过滤器是在程序一开始就启动并加载到内存当中。如果前台对数据库的规则进行了修改，如果不对内存中的规则进行相应的操作，那么对告警信息的过滤和重定义将会出错。所以SyncServer就是要从前台获得相关的配置信息，并解析这些信息，对内存中的规则进行相应地修改、刷新。同时该服务器还接收丢失的标准告警，将获得的标准告警插入最高级别的告警队列中。由于SyncServer是继承QuickServer的，所以它的所有控制操作将集中在实现QucikServer提供的处理接口。跟采集服务的实现模式是如出一辙的。在这里就不做过多的介绍。4. 系统的运行结果4.1. 采集线程的管理在程序启动时，会启动管理服务AdminServer，在其它线程启动时会将它们自身和id值注册到AdminServer中。AdminServer是基于Socket Server模式的，所以我们也编写的简单的管理客户端界面，实现采集线程管理的。客户端的线程信息由xml配置文件获得。界面的设计如图4-1：图4-1 告警采集线程管理客户端界面从图4-1我们可以知道只要选中左边的树图中的某个节点，再点击右边的按钮，我们就可以对线程就行相关的操作。4.2. 告警采集的运行告警采集系统的运行主要经过以下几个步骤：1. 初始化阶段。在初始化阶段，程序从xml配置文件中读取需要启动服务的相关信息，并创建服务对象如:采集服务、发送队列、发送服务、管理服务等对象，并且设置服务状态。配置文件的格式参见源程序文档。2. 启动阶段。在服务的启动阶段，程序开启服务，并把自身注册给管理服务线程，启动服务线程，各个服务开始运行。3. 运行阶段。在服务的运行阶段，各个服务都是循环进行不会终止，除非管理服务发出终止命令，或程序运行发生异常。运行时先由采集服务进行员是告警采集，接着将原始告警拆分成多