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