1、 本科毕业论文 (科研训练、毕业设计 ) 题 目 : 告警采集系统 的 开发 和应用 姓 名: 学 院 : 软件学院 系: 专 业: 软件工程 年 级: 学 号: 指导教师(校内): 职称: 指导教师(校外): 职称: 年 月 日 告警采集系统 的开发和应用 摘要 本文阐述 了告警采集系统的总体架构,对于它的每个模块都作了具体的分析 和设计。 同时引入了规则引擎的应用和一些开发设计思路 ,说 明了一个合理的系统设计将大大降低开发的难度和提高软件的复用性和可扩展性。 关键词 告警采集 规则引擎 告警解析 标准告警映射 告警过滤 告警重定义 The development of alarm col
2、lection system Abstract: 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 d
3、evelopment 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. 引言 . 4 2. 项目总体设计 . 4 2.1. 项目说明 . 4 2.1.1. 项目名称 . 4 2.1.2. 项目地位 . 4 2.1.3. 项目现状 .
4、5 2.1.4. 项目业务 . 5 2.1.5. 项目目的 . 5 2.2. 系统架构 . 5 2.2.1. 告警系统总体架构 . 5 2.2.2. 告警采集系统总体架构 . 6 2.3. 实现方式 . 9 3. 项目详细设计 . 9 3.1. 告警底层接收模块的建立 . 10 3.1.1. Socket 公共服务的建立 . 10 3.1.2. 原始告警接收的实现 . 11 3.2. 告警处理模块设计 . 12 3.2.1. 规则引擎服务的建立 . 12 3.2.1.1. 规则引擎理论 . 12 3.2.1.2. Drools 规则引擎的应用 . 13 3.2.1.3. 告警规则过滤 器引擎的
5、应用 . 15 3.2.2. 告警解析和标准映射的实现 . 16 3.2.3. 告警上报过滤和告警重定义的实现 . 17 3.3 告警采集线程管理服务的实现 . 17 3.4. 告警发送服务的实现 . 17 3.4.1. 告警发送队列的建立 . 17 3.4.2. 告警 发送的实现 . 18 3.5. 告警同步数据配置接收的实现 . 18 4. 系统的运行结果 . 19 4.1. 采集线程的管理 . 19 4.2. 告警采集的运行 . 19 5. 结束语 . 22 致谢语 . 22 参考文献 . 22 1. 引言 告警采集系统是联通 网管项目中 告警系统的 一个 子模块 , 由于它处于整个告警
6、系统的最底层,所以在整个系统中至关重要,告警系统中的其它模块都需要有采集系统获得的数据支持。 实现该采集系统的功能是一个重要的方面,但更为重要的是要搭建采集系统的可执行框架。因为采集系统面临着多厂商,多接口,难管理,经常变动等问题,所以要求系统要实现可配置、易于管理,易于移植 的框架结构。本文就告警采集系统的各个模块,进行了详细的分析和设计,引进了规则引擎和一些设计方法,意在使整个系统变的更加的灵活和易于扩展。 2. 项目 总体设计 2.1. 项目说明 2.1.1. 项目名称 告警采集系统 2.1.2. 项目地位 告警采集系统是整个告警系统的基础,在整个联通综合网管系统中占有举足轻重的地位。该
7、系统连接着各个厂商的网元设备,这些设备发送联通全省各个地市的基站设备的警报信息。该系统从这些设备中获得不同厂商 设备 的告警信息,并将原始的告警信息解析成标准的告警信息,并按照一定的规则对标准的告警信息进行过滤和重定义,最终按照 预先设定的格式组合成字节流发送给下一模块。从该系统发送的数据将在数据处理层进行升级、压缩、归并等处理,继续发送给应用展现层,最终进入电子运维系统。所以,告警采集系统在整个告警系统中处于底层的基础地位,告警系统的其它模块都依赖于该采集系统,在此基础上整个系统才能够顺利地运行。 2.1.3. 项目现状 (1) 多厂商、多接口 : 从已经运行和在建的移动网管系统 看,告警系
8、统都存在 厂商多,接口多( ftp 接入, Q3 接入 , CORBA 接入, TCP/IP 接入,命令行方式接入),由于接口方式太多导致接入模块不统一,造成进程管理混乱。 (2) 数据量大:对于全省综合网管,告警的数量众多,从而有可能导致系统繁忙而无法处理因而告警丢失 。 (3) 设备不断升级: 由于设备不断升级造成原有的告警采集模块,更新频繁,导致影响系统的稳定性。 (4) 各专业协作需要:告警系统需要具有开放的系统已适应运营商内部的各专业协作 。 (5) 难维护: 告警系统自身故障难定位与维护 。 2.1.4. 项目业务 告警采集主要是实现与网元的连接并采集告警数据。对于采集到的告警数据
9、按照以下的处理流程进行业务逻辑处理: 1.告警接收:连接网元接收告警 2.告警解析:解析各个厂家不同设备的告警, 分拆得到需要的告警字段,如告警级别 3.告警 标准映射 :将各个厂家的告警按照一定的规则映射为网管系统的标准告警 4.采集过滤:也就是上报过滤,过滤掉用户认为不重要的告警。过滤的告警在网管系统中不存储 5.告警重定义:根据定义的过滤条件,重新定义告警的告警级别和告警类型 6.告警前传:为了保证重要和主要告警,按照告警级别,分优先级别的前传告警 2.1.5. 项目目的 该项目除了要求完成项目所要求的业务功能之外,更为重要的是提供一个告警采集系统的可执行框架,在这个框架上实行可配置,可
10、扩展 , 易于维护的特点。使得各地的告警采集、 不同厂商的服务,经过一定的配置后,都能在这个采集框架上执行起来,而不需要重新进行设计、编码。 2.2.系统架构 2.2.1. 告警系统总体架构 电 子 运 维 系 统故 障 单 系 统 电 子 工 单 系 统 任 务 调 度 系 统应 用 展 现 层拓 扑 图 告 警 列 表E m a i l , 短 信 远 程 发布告 警 提 醒 通 知 、 发 布 规 则数 据 处 理 服 务 层告 警 升 级 规 则告 警 压 缩 归 并 层接 收 告 警 服 务 层数 据 采 集 服 务 层采 集 逻 辑 层网 元 接 入 服 务 层公共服务层短 信服
11、务邮 件服 务日 志服 务消 息服 务进 程监 控服 务T C P / I P 接 入 Q 3 接 入C o r b a 接 入 D B 采 集 接 入规 则引 擎服 务数 据库 访问 服务图 2-1 告警系统架构图 告警系统体系结构 如图 1-1 所示,目前分为五 层:数据采集层、数据处理层、应用展现层、 电子运维系统和 公共服务层。 可以看到在告警系统中数据采集服务层位于系统的最底层;在采集层对数据进行了初步地处理后,将数据发往数据处理层作进一步地处理;然后再将告警数据前传至数据展现层,对数据做出进行不同形式地展现;最后派发 成各种工单,进行任务调度。再此期间各个层次都有可能调用公共层的服
12、务。从图 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 模 式 ) , 采 用 框 架 模式 , 方 便 不 同 设 备 的 接 入原 始 告 警 解 析 ( 采 用 规 则 引 擎 D r o o l s )标 准 告 警 映 射 ( 采 用 规 则 引 擎 D r o o l s )告 警 上 报
13、过 滤 ( 采 用 规 则 过 滤 器 )告 警 重 定 义 ( 采 用 规 则 过 滤 器 )同 步 数 据 接 收 服 务 ( 接 入 方 式 : 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 告警采集模
14、块系统架构图 如图 2-2所示,告警采集模块采用统一的架构在公共服务的基础上,实现各个模块的服务功能。公共模块提供了 Socket Server 模式服务、 Socket Client模式服务、 Drools 规则引擎服务以及规则过滤器引擎服务,各个模块 相应地应用一个或一个以上的公共服务。告警采集系统从原始告警接入连接各种不同厂商的设备,获取各种告警字节流;接着对各种原始告警进行解析,拆分成各个所需的字段;然后将拆分成的各个字段,再结合数据库,组合成标准的告警格式字段;对映射成标准字段的告警必须利用规则过滤器进行上报过滤和重定义操作;同时提供对数据同步的服务;最后将各个标准告警字段转化成标准
15、的告警格式字节流向下一个模块发送,从而完成告警的采集工作。 具体的业务流程见图 2-3: 主 线 程 开始创 建 用 户 操 作 服务 端 口注 册 服 务创 建 采 集 线 程创 建 发 送 线 程创 建 网 元 连 接循 环 等 待 / 解 析告 警 开 始P O L L 等 待 告 警解 析 告 警插 入 缓 冲 区循 环 等 待 / 解 析结 束循 环 接 收 用 户请 求 开 始监 听 服 务接 收 刷 新 请求刷 新 告 警 列 表 /告 警 过 滤 器 / 告警 重 定 义循 环 循 环 接 收 用户 请 求 结 束过 滤 告 警告 警 有 效 ?并 行 处 理丢 弃 告 警无
16、效匹 配 成 功2 0 0 3 年 1 0 月 2 2 日页 1告 警 采 集 处 理 流 程创建端口异常异 常 处 理注 册 异 常创 建 采 集 线 程 异 常退 出 程 序创 建 发 送 线 程 异 常异 常 处 理 发 送网 中 网 告 警连 接 异 常解 析 告 警 异 常缓 冲 区 溢 出异 常 处 理 /发 送 网 中网 告 警有 效匹 配 失 败数 据 据 操 作 异 常创 建 告 警 处 理 连接从 缓 冲 区 获 得 告警发 送 告 警循 环 发 送 告 警 开始循 环 发 送 告 警 结束异 常 处 理 / 送网 中 网 告 警失 败连 接 异 常 ?重 新 创 建 连
17、接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标 识 服 务名 ;s e r v e r _ t y p e ,用 来 标 识 服务 类 型传
18、递 主 机 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
19、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 服 务 实 例 , 加 入 管 理 服 务 列 表 便 于 管 理 , 启 动 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 规 则 引 擎 服 务 规 则 过 滤 器
20、服 务2 . 利 用 D r o o l s 解 析 原始 告 警3 . 利 用 D r o o l s 映 射 标准 告 警 字 段4 . 利 用 规 则 过 滤 器 进行 告 警 上 报 过 滤5 . 利 用 规 则 过 滤 器 进行 告 警 重 定 义6 . 告 警 同 步 数 据 接 收7 . 告 警 多 级 队 列 创 建并 进 行 发 送图 2-4 告警采集系统实现模式图 告警采集系统 首先从 xml 配置文件中读取相关 的配置信息,再将这些配置信息传递给一个个 Socket server 服务或者 Socket client 服务实例, 进行相关的配置;再注册这些服务实例给管理服
21、务线程,便于管理这些服务实例,同时启动各个服务;接着就进行原始告警的读取、拆分, 并进行解析,同时进行告警的映射,将原始告警映射成一个个标准的告警字段;对这些标准的告警字段进行上报过滤和重定义;同时接收告警的同步数据;最后创建告警优先级队列,将告警信息按照优先级不同进行发送。这些核心的服务将由一个核心服务类来处理,该类调用 Drools 规则引擎服务和规则过滤器服务,来完成相应的功能。 该实现模式类似于 MVC(Module View Control)架构模式。 其中的多个服务模式采用多个接口,以便于将来的修正和扩展。 3. 项目详细设计 3.1. 告警底层接收模块的建立 3.1.1. Soc
22、ket公共服务的建立 告 警采集的主要两种方式在于 Socket Client 模式的采集和 Socket Server模式的 采集。也就是说一种方式主要由我们作为客户端主动的去连接网元设备,另一种方式是,我们作为服务端,由网元设备主动来连接我们 ,向我们发送原始的告警信息。 Socket Server 模式的建立,已经有现成的开源项目 QuickServer 来实现。但 QuickServer 并不能完全符合我们的要求,所以我们对其源代码进行了一定的修改。 Socket Client 模式应与 Socket Server 模式 保持一致, 即在实现和处理的 结 构上 相统一。 Socket
23、服务的处理模式如图 3-1所示 : S o c k e t 线 程管 理 配 置开 启 线 程 终 止 线 程S o c k e t 数 据处 理 接 口处 理 的 具体 实 现 . . .处 理 的 具体 实 现 . . .图 3-1 Socket 服务模式 从图 3-1我们可以看出,该服务其实只提供了数据处理的接口,并提供了基本的管理配置实现,而数据处理功能的真正实现并不再服务层实现,而是通过服务层的调用来实现。 我们在这里将 Socket Server 模式的服务用 QuickServer表示; Socket Client 模式的服务用 QuickClient 来表示;将 Sever 模式的采集服务用 CollectionServer 表示 ;将 Client 模式的采集服务用 CollectionClient来表示;将线程管理服务用 AdminServer 表示;将数据同步服务用 SyncServer表示;将以 Socket 发送的服务用 SocketSendServer 表示。 他们之间的继承关系从图 3-2种可以看出来。