基于Apriori算法的IT服务集中监控管理系统的制作方法

本发明涉及基于Apriori算法的IT服务集中监控管理系统。

背景技术：

目前，在我国IT服务集中监控管理还处于初级阶段，已经搭建了综合IT服务集中监控管理体系的企业仅占少数。因此，对于绝大多数的企业而言，企业无法集中管理自身的网络资源、服务器资源、系统资源等，无法做到数据与信息的共享，标准化和程序化的企业IT服务集中监控管理依旧没有实现。这种广泛应用中的传统IT管理模式主要存在以下两个特点：

1、传统的IT监控采用单点管理模式，管理部门与管理部门，管理产品与管理产品之间是相互独立的，计算机运维人员一般只了解其中某一方面或某一部分的计算机资源，如服务器管理人员只关心如何查看服务器CPU以及内存的使用率等，这种管理模式下，运维管理人员无法了解企业IT系统整体的计算机资源分布和性能分布，对企业整体IT系统运行情况缺乏全面的掌握，由此使得管理人员很难针对企业自身的IT系统运行情况制定出有效的整体管理策略和管理方法，企业对信息系统的管理要求无法得到满足。

2、传统的IT服务管理模式下，IT服务运维管理人员常常处于“救火队式”的混乱状态，运维人员只有等待故障发生而后被动地解决故障。另一方面，运维人员只能通过远程登录到监控设备后执行繁琐的命令才能查看设备的运行状态，缺少方便有效的智能化手段主动监控系统资源状态。又或是由于使用不同品牌的不同设备，造成IT管理人员需要使用不同设备各自不同的管理平台进行设备管理，这些情况使得管理人员对于计算机资源的管理不仅复杂又耗时，造成IT管理人员数量庞大，且人员分工不合理，从而导致系统管理复杂度增加，管理成本也随之增加。

由于不断增加的企业IT系统的规模、复杂性以及对IT系统持续上升的依赖性，依旧采用传统的IT系统集中监控管理模式已经无法全面保证企业IT运行环境可信性和安全性。企业信息化依赖程度越来越高，由于网络、关 键服务器和应用系统故障对企业造成的损失不断增加。需要保持业务连续安全运行的企业数量繁多，要确保业务的连续性则需要依赖企业IT系统能提供7X24小时的持续服务，这一切都需要IT运维集中监控管理系统的支撑。目前国内企业的IT运维管理产品和服务的应用尚且处于基础应用水平，主要为IT运维管理软件安装及使用，运维流程梳理优化开发及管理体制的改进与完善。随着客户信息化建设加快，客户服务系统规模愈加庞大，信息系统架构复杂程度增加，新兴业务模式要求IT服务能更加个性化和精细化。这些都要求更专业的IT服务管理产品及更有针对性的服务策略和更精细的解决方案。

技术实现要素：

本发明的目的是提供基于Apriori算法的IT服务集中监控管理系统，，以完成诸如服务器端自动数据挖掘这样的任务，灵活性强。

本发明为解决其技术问题所采用的技术方案是，

基于Apriori算法的IT服务集中监控管理系统，该系统包括有：IT服务集中监控管理单元、IT服务集中监控系统核心流程单元；

IT服务集中监控管理单元包含有：IT设备状态数据采集模块、状态告警触发模块、运维事件处理模块；

IT服务集中监控系统核心流程单元包含有：IT设备状态数据并发采集流程、状态告警规则诊断流程、告警关联事件定位流程；

IT设备状态数据采集模块是IT服务集中监控管理系统的基础功能模块之一，它是系统产生状态数据的基础模块，为数据规则诊断、数据聚合统计等功能提供了前提；

状态告警触发模块是系统获得状态数据或者聚合统计数据后，通过对数据进行分析后，触发状态数据告警的模块，也是状态数据价值产生的所在，通过告警能够使得运维人员更快发现异常情况或未来可能发生的异常情况，并处理；

运维事件处理模块是告警事件发生后运维人员管理告警事件以及运维事件流程的功能模块；

IT设备状态数据并发采集流程主要包含：采集任务定时触发、采集任务 执行，进入数据采集模块，系统接收到采集策略后需要根据采集策略新增采集策略任务，首先系统解析采集策略，循环采集策略列表内每个监控项ki，若该监控项ki开启采集，根据监控项采集策略中采集方式，判断需要新增的采集任务类型，根据采集任务类型匹配任务注册器中任务从而生成新任务，新任务添加到任务生成器队列；

状态告警规则诊断流程是系统执行状态数据分析的重要组成部分，主要包含：状态告警数据预处理、状态告警规则诊断、状态告警关联规则诊断；

告警关联事件定位流程在于运维人员处理事件是通过分析关联告警以及关联告警的原始事件定位告警原因。

进一步，所述的IT设备状态数据采集模块分为采集策略管理、数据采集、数据格式化三个部分；

采集策略管理主要由运维管理人员在配置管理模块配置监控项后调用接口触发，用以将运维人员配置的监控项转化为数据采集模块统一格式化的采集策略，并进行维护，主要功能包括：新增采集策略、更新采集策略、删除采集策略；

采集策略内容包括：监控项基础信息(如监控项ID、名称、IP地址等)、是否开启采集、采集方法、采集时间间隔、采集脚本、采集参数、数据处理脚本、数据格式；

新建一个采集策略，运维人员在配置管理模块选择一个系统提供的监控项模板，模板可以帮助用户快速新增监控项，在新增监控项后，系统通过调用数据采集模块新增采集策略接口新增采集策略；

更新采集策略，运维人员在配置管理模块选择一个监控项，修改监控项内容，在修改监控项后，系统通过调用数据采集模块更新采集策略接口修改采集策略；

删除采集策略的方法是运维人员在配置管理模块选择一个监控项，执行删除操作，在修改监控项后，系统通过调用数据采集模块删除采集策略接口删除采集策略；

数据采集模块的采集策略管理功能保存当前需要进行的采集策略，根据采集时间间隔，任务生成器定时生成当前需要进行采集的采集任务，采集任 务根据不同类别采集方式生成，为了适应目前系统需求，即能够采集包括网络设备、服务器、机房基础环境、中间件、应用、数据库、虚拟资源等在内的各项设备，系统目前提供的采集方式包括：jdbc连接、http连接、jmx连接、snmp连接、webservice、remotessh、telnet、email、wmic、jar包执行以及syslog等，采集任务包括主动建立连接采集以及被动监听采集，如jmx、jdbc、snmpget等均属于主动采集，而syslog、snmptrap等类型任务属于被动监听采集类型，对于主动采集任务，任务生成器生成采集任务后，采集任务激活，在采集执行器中执行，同指定设备建立不同类型连接，执行采集脚本等内容，获得原始状态数据，若该采集策略设置有数据处理脚本，系统根据数据处理脚本重新处理数据，得到状态数据，而对于被动监听类型采集，系统根据采集策略开启端口监听，若通过监听的端口收到状态数据，根据数据内容查找对应的采集策略，并进行关联，若未查找到策略，则数据抛弃；

数据格式化的目的是为了能够将各种类型的状态数据整合，为接下来的数据聚合、数据分析、以及数据入库等做准备，在数据采集后，得到基础状态数据，数据处理模块根据状态数据关联的采集策略组装最终状态数据，最终状态数据首先组合数据关联设备基础信息、采集时间等，对于状态数据具体数值，根据策略中的数据格式定义，系统处理数据格式，组合得到最终的状态数据中，并通过activemq发送状态数据给后续模块。

进一步，所述的状态告警触发模块采用接口触发，系统通过activemq中间件接收状态数据以及聚合统计数据，当数据到达时，则触发数据分析开始，包含有告警规则管理、状态数据或聚合统计数据触发告警、状态告警触发关联告警、生成告警事件及告警通知；

告警规则管理主要由运维管理人员使用，主要功能包括：新增告警规则、更新告警规则、删除告警规则，告警规则内容包括：监控项告警规则基础信息(如监控项ID等)、告警规则ID、告警规则名称、告警规则表达式、告警规则有效时间、告警自动处理操作信息等；

新建一个告警规则，运维人员在配置管理模块选择一个系统提供的监控项模板，模板可以帮助用户快速新增监控项告警规则，在新增监控项后，系统通过调用告警模块新增告警规则接口新增告警规则；

更新告警规则，运维人员在配置管理模块选择一个监控项，修改监控项告警规则内容，在修改监控项后，系统通过调用告警模块更新告警规则接口修改告警规则；

删除告警规则的方法是运维人员在配置管理模块选择一个监控项，删除监控项告警规则，删除后，系统通过调用数据采集模块删除告警规则接口删除告警规则；

状态数据或聚合统计数据触发告警是系统收到新采集的状态数据或刚生成的聚合统计数据后，触发告警规则诊断操作，规则诊断阶段，系统根据接收到状态数据后首先对状态数据进行预处理，预处理的内容是对一条状态数据中多个子项数据扁平化处理，以便对各子项进行分别处理；数据经过预处理后，系统根据状态数据查找对应的告警规则，根据告警规则中定义的规则表达式，与事件数据进行匹配，目前的告警规则根据匹配次数分为两种：一种为一次匹配，即只要事件数据与表达式匹配则认为该数据异常，触发告警；第二种为多次匹配，则当事件数据与表达式匹配时，查看历史匹配结果，若在告警规则定义的条件内(如有效时间，或采集次数)，相同监控项的状态数据与表达式匹配次数达到要求，则认为触发告警，否则储存匹配规则，等待下次诊断；

状态告警触发关联告警在触发告警后，系统根据告警信息，从告警关联规则分析模块获取关联告警规则，若该类型告警不存在关联告警规则，则告警触发操作结束，进入生成告警事件阶段，若该类型告警存在关联告警规则，则根据关联告警规则，获取关联告警信息以及置信度，触发关联告警；

生成告警事件及告警通知：确认触发状态告警后，系统通过调用运维流程管理接口，新增告警事件，同时通知运维人员，目前支持的通知方式包括：短信通知、微信消息推送以及邮件通知，确认触发关联告警后，系统通过调用运维流程管理接口，新增关联告警事件，同时通知运维人员，目前支持的通知方式包括：短信通知、微信消息推送以及邮件通知。

进一步，所述的在运维事件处理流程模块中涉及到普通运维人员以及运维管理人员，包含运维事件处理流程、告警事件分析等主要模块；

运维事件处理流程主要包括事件分配，事件受理，事件处理，事件审核， 事件关闭几个步骤，其中事件分配、事件审核由运维管理人员执行，事件受理、事件处理有普通运维人员执行，事件关闭由系统控制执行，在告警触发模块生成告警事件后，同时生成运维事件，告警事件与运维事件关联，运维管理人员收到告警事件通知后，可以为该告警事件分配相关处理人，被分配的运维人员则拥有受理事件的权限，拥有受理事件权限的运维人员，可以受理告警事件，受理告警是处理告警事件的前提，受理后该告警事件不得由他人修改，运维人员处理完设备异常情况，确认设备状态后，在运维管理流程模块处理告警事件，而后提交审核，运维管理人员在接收到告警审核要求后，通过查看设备当前状态，确认设备是否恢复正常，若无异常则审核通过，否则审核退回，审核通过的告警系统由系统自动关闭，审核退回的告警事件重新回到运维人员受理状态；

告警事件分析是运维人员受理告警事件之后，通过查看告警事件对应原始状态数据以及告警事件关联告警原始数据等，尽快定位及发现设备异常问题原因，从而尽快解决问题的过程，运维人员为了处理告警事件，首先需要尽快确定告警发生原因，多数情况下告警的发生原因能够通过查看告警的原始状态数据以及告警内容发现，某些时候，运维人员无法直观的了解设备异常的根本原因，则需要运维人员通过关联分析来定位可能的告警原因。

进一步，所述的IT设备状态数据并发采集流程在数据管理子系统启动时，自动生成定时任务，每隔1秒钟，采集任务触发线程执行，采集任务触发线程循环任务生成器，获取任务，根据当前时间与任务的最后完成时间间隔，判断时间差是否超过采集周期，若超过采集周期则表示该任务需要立即执行，触发采集任务，将采集任务加入任务执行队列，若不超过采集周期则任务不需触发，若任务从未执行，系统为保证任务随机性，减少大量任务同时采集的可能性，在任务采集周期内随机生成时间间隔，作为该任务最后采集时间；

数据管理子系统启动时创建采集任务执行线程池，用于并发执行采集任务，系统同时创建有任务计划线程，计划线程的作用在于从任务执行队列中获取下一个任务，使用采集任务执行线程池中线程执行采集任务，采集任务执行过程中，首先判断任务是否超时或任务是否为旧任务，若是则任务丢弃 记录日志，接着根据采集任务创建用于格式化的采集结果result，result中定义了监控项基本信息、基本采集信息(采集时间等)，创建成功后，系统依据采集策略通过建立连接执行采集脚本等方式获取状态数据，采集完成后，若采集策略中存在数据处理脚本，则系统执行脚本处理数据，而后将数据写入result，若不存在数据处理脚本，直接将采集到的数据写入result。

进一步，所述的状态告警规则诊断流程从系统接收到实时状态数据或聚合数据开始，接收到数据后，系统首先对数据进行扁平化预处理，根据数据子项内容生成一条或多条用于规则诊断的中间数据，数据预处理后，根据数据信息，获取不同类型规则匹配器，并放入规则诊断线程池等待执行匹配，通过规则匹配线程执行初始告警规则诊断操作，告警规则诊断后，判断诊断结果，如果匹配则触发状态告警事件，并通知运维人员，继续执行状态告警关联规则诊断，若不匹配则保存结果，结束规则诊断，关联规则诊断是在匹配告警规则后执行，若关联规则匹配成功，同样生成关联告警事件；

状态告警规则诊断过程是对状态数据与规则表达式是否一致的检验过程，匹配起开始执行匹配任务后，首先构造匹配任务并初始化匹配执行结果，系统的告警规则诊断线程获取到规则匹配任务后，首先根据诊断匹配器信息获取相应的告警规则，同时处理告警规则，转化为可执行的规则，获取规则中所有匹配表达式，逐个使用状态数据替换表达式中变量，并判断表达式是否成立，若表达式成立则与表达式匹配，每次匹配缓存匹配结果，根据所有表达式匹配结果得到最终告警规则匹配结果；

关联规则诊断流程是本次设计新增的主要功能之一，是为了通过分析关联规则，根据当前一直的告警信息了解可能出现的告警，从而尽快处理相关问题，关联规则的诊断流程主要是通过获取已经产生的告警事件关联规则，根据关联规则获取关联告警，从而触发关联告警事件，在进行关联规则诊段过程中，系统首先获取到等待进行关联规则匹配的告警事件，获取告警事件的状态告警规则编号，通过编号向系统的关联规则管理模块获取关联的告警规则，若获取到的关联告警规则为空，表示该告警事件不存在关联事件，若关联规则存在，系统生成关联告警事件，关联告警事件与告警事件不同，关联告警事件不存在告警等级，以关联规则中的置信度作为参考属性保存，对 事件处理的时效性要求较低。

进一步，所述的告警关联事件定位流程是对告警原因分析过程中通过对可能造成告警的关联事件进行分析从而确定告警原因的过程，关联分析过程中，系统首先查看告警事件是否存在关联规则，若不存在则停止关联分析，若存在关联规则，首先通过获取关联规则查找关联告警事件，根据关联告警事件信息查找产生告警监控项的关联监控项，为了确认关联事件状态，系统提供告警事件前后三个周期的关联监控项状态数据展示，从而让运维人员更直观的了解关联监控项状态，定位告警原因，在告警关联分析的过程中，如果通过查看关联监控项状态无法明确，可以进步一查看关联监控项的其他关联项状态，从而纵向分析告警事件，全面分析一个设备系统内的所有监控项状态。

本发明的优点在于，该系统采用WEKA软件执行Apriori算法计算，它可以通过简单的方式快速实现自己的数据挖掘算法。重要的是它可以在Java项目中引入WEKA的类库，以完成诸如服务器端自动数据挖掘这样的任务，这正是本系统中需要使用的方法，操作性能上更加优化，设计新颖，是一项很好的设计方案。

附图说明

下面结合附图和具体实施方式来详细说明本发明：

图1是本发明IT服务集中监控管理系统功能结构图；

图2是本发明数据采集模块功能用例图；

图3是本发明告警触发模块功能用例图；

图4是本发明运维流程管理模块功能用例图；

图5是本发明数据并发采集流程图；

图6是本发明规则诊断流程图；

图7是本发明状态数据聚合统计主流程图；

图8是本发明聚合统计实时线程流程图；

图9是本发明聚合统计历史线程流程图；

图10是本发明告警事件生成管理流程图；

具体实施方式

为了使本发明实现的技术手段、创作特征、达成目的与功效易于明白了解，下面结合图示与具体实施例，进一步阐述本发明。

如图1所示，本发明提出的基于Apriori算法的IT服务集中监控管理系统，该系统包括有：IT服务集中监控管理单元、IT服务集中监控系统核心流程单元；

IT服务集中监控管理单元包含有：IT设备状态数据采集模块、状态告警触发模块、运维事件处理模块；

IT服务集中监控系统核心流程单元包含有：IT设备状态数据并发采集流程、状态告警规则诊断流程、告警关联事件定位流程；

IT设备状态数据并发采集流程是系统根据采集策略实时采集监控项状态数据的流程，是保证状态数据实时性以及数据模块工作高效性的核心流程；状态告警规则诊断流程是指系统对状态数据或聚合统计数据进行告警规则分析以及对告警事件进行关联告警分析的主要流程；告警关联事件定位流程是运维人员在处理告警事件时对告警原因进行关联分析的主要流程。

IT设备状态数据采集模块是IT服务集中监控管理系统的基础功能模块之一，它是系统产生状态数据的基础模块，为数据规则诊断、数据聚合统计等功能提供了前提，如图2。

状态告警触发模块是系统获得状态数据或者聚合统计数据后，通过对数据进行分析后，触发状态数据告警的模块，也是状态数据价值产生的所在，通过告警能够使得运维人员更快发现异常情况或未来可能发生的异常情况，并处理；

运维事件处理模块是告警事件发生后运维人员管理告警事件以及运维事件流程的功能模块；

IT设备状态数据并发采集流程主要包含：采集任务定时触发、采集任务执行，进入数据采集模块，系统接收到采集策略后需要根据采集策略新增采集策略任务，首先系统解析采集策略，循环采集策略列表内每个监控项ki，若该监控项ki开启采集，根据监控项采集策略中采集方式，判断需要新增的采集任务类型，根据采集任务类型匹配任务注册器中任务从而生成新任务， 新任务添加到任务生成器队列；

状态告警规则诊断流程是系统执行状态数据分析的重要组成部分，主要包含：状态告警数据预处理、状态告警规则诊断、状态告警关联规则诊断；

告警关联事件定位流程在于运维人员处理事件是通过分析关联告警以及关联告警的原始事件定位告警原因。

在IT设备状态数据采集模块分为采集策略管理、数据采集、数据格式化三个部分；

采集策略管理主要由运维管理人员在配置管理模块配置监控项后调用接口触发，用以将运维人员配置的监控项转化为数据采集模块统一格式化的采集策略，并进行维护，主要功能包括：新增采集策略、更新采集策略、删除采集策略；

采集策略内容包括：监控项基础信息(如监控项ID、名称、IP地址等)、是否开启采集、采集方法、采集时间间隔、采集脚本、采集参数、数据处理脚本、数据格式；

新建一个采集策略，运维人员在配置管理模块选择一个系统提供的监控项模板，模板可以帮助用户快速新增监控项，在新增监控项后，系统通过调用数据采集模块新增采集策略接口新增采集策略；

更新采集策略，运维人员在配置管理模块选择一个监控项，修改监控项内容，在修改监控项后，系统通过调用数据采集模块更新采集策略接口修改采集策略；

删除采集策略的方法是运维人员在配置管理模块选择一个监控项，执行删除操作，在修改监控项后，系统通过调用数据采集模块删除采集策略接口删除采集策略；

数据采集模块的采集策略管理功能保存当前需要进行的采集策略，根据采集时间间隔，任务生成器定时生成当前需要进行采集的采集任务，采集任务根据不同类别采集方式生成，为了适应目前系统需求，即能够采集包括网络设备、服务器、机房基础环境、中间件、应用、数据库、虚拟资源等在内的各项设备，系统目前提供的采集方式包括：jdbc连接、http连接、jmx连接、snmp连接、webservice、remotessh、telnet、email、wmic、jar包执行以 及syslog等，采集任务包括主动建立连接采集以及被动监听采集，如jmx、jdbc、snmpget等均属于主动采集，而syslog、snmptrap等类型任务属于被动监听采集类型，对于主动采集任务，任务生成器生成采集任务后，采集任务激活，在采集执行器中执行，同指定设备建立不同类型连接，执行采集脚本等内容，获得原始状态数据，若该采集策略设置有数据处理脚本，系统根据数据处理脚本重新处理数据，得到状态数据，而对于被动监听类型采集，系统根据采集策略开启端口监听，若通过监听的端口收到状态数据，根据数据内容查找对应的采集策略，并进行关联，若未查找到策略，则数据抛弃；

数据格式化的目的是为了能够将各种类型的状态数据整合，为接下来的数据聚合、数据分析、以及数据入库等做准备，在数据采集后，得到基础状态数据，数据处理模块根据状态数据关联的采集策略组装最终状态数据，最终状态数据首先组合数据关联设备基础信息、采集时间等，对于状态数据具体数值，根据策略中的数据格式定义，系统处理数据格式，组合得到最终的状态数据中，并通过activemq发送状态数据给后续模块。

如图3，状态告警触发模块采用接口触发，系统通过activemq中间件接收状态数据以及聚合统计数据，当数据到达时，则触发数据分析开始，包含有告警规则管理、状态数据或聚合统计数据触发告警、状态告警触发关联告警、生成告警事件及告警通知；

告警规则管理主要由运维管理人员使用，主要功能包括：新增告警规则、更新告警规则、删除告警规则，告警规则内容包括：监控项告警规则基础信息(如监控项ID等)、告警规则ID、告警规则名称、告警规则表达式、告警规则有效时间、告警自动处理操作信息等；

新建一个告警规则，运维人员在配置管理模块选择一个系统提供的监控项模板，模板可以帮助用户快速新增监控项告警规则，在新增监控项后，系统通过调用告警模块新增告警规则接口新增告警规则；

更新告警规则，运维人员在配置管理模块选择一个监控项，修改监控项告警规则内容，在修改监控项后，系统通过调用告警模块更新告警规则接口修改告警规则；

删除告警规则的方法是运维人员在配置管理模块选择一个监控项，删除 监控项告警规则，删除后，系统通过调用数据采集模块删除告警规则接口删除告警规则；

状态数据或聚合统计数据触发告警是系统收到新采集的状态数据或刚生成的聚合统计数据后，触发告警规则诊断操作，规则诊断阶段，系统根据接收到状态数据后首先对状态数据进行预处理，预处理的内容是对一条状态数据中多个子项数据扁平化处理，以便对各子项进行分别处理；。例如，一条文件系统使用率的状态数据中，保存有C盘使用率40％、D盘使用率70％的子项内容，经过数据预处理后，系统生成两条用于进行告警规则匹配的事件数据，分别为C盘使用率40％事件数据以及D盘使用率70％事件数据。数据经过预处理后，系统根据状态数据查找对应的告警规则，根据告警规则中定义的规则表达式，与事件数据进行匹配，目前的告警规则根据匹配次数分为两种：一种为一次匹配，即只要事件数据与表达式匹配则认为该数据异常，触发告警；第二种为多次匹配，则当事件数据与表达式匹配时，查看历史匹配结果，若在告警规则定义的条件内(如有效时间，或采集次数)，相同监控项的状态数据与表达式匹配次数达到要求，则认为触发告警，否则储存匹配规则，等待下次诊断；

状态告警触发关联告警在触发告警后，系统根据告警信息，从告警关联规则分析模块获取关联告警规则，若该类型告警不存在关联告警规则，则告警触发操作结束，进入生成告警事件阶段，若该类型告警存在关联告警规则，则根据关联告警规则，获取关联告警信息以及置信度，触发关联告警；

生成告警事件及告警通知：确认触发状态告警后，系统通过调用运维流程管理接口，新增告警事件，同时通知运维人员，目前支持的通知方式包括：短信通知、微信消息推送以及邮件通知，确认触发关联告警后，系统通过调用运维流程管理接口，新增关联告警事件，同时通知运维人员，目前支持的通知方式包括：短信通知、微信消息推送以及邮件通知。

如图4，在运维事件处理流程模块中涉及到普通运维人员以及运维管理人员，包含运维事件处理流程、告警事件分析等主要模块；

运维事件处理流程主要包括事件分配，事件受理，事件处理，事件审核，事件关闭几个步骤，其中事件分配、事件审核由运维管理人员执行，事件受 理、事件处理有普通运维人员执行，事件关闭由系统控制执行，在告警触发模块生成告警事件后，同时生成运维事件，告警事件与运维事件关联，运维管理人员收到告警事件通知后，可以为该告警事件分配相关处理人，被分配的运维人员则拥有受理事件的权限，拥有受理事件权限的运维人员，可以受理告警事件，受理告警是处理告警事件的前提，受理后该告警事件不得由他人修改，运维人员处理完设备异常情况，确认设备状态后，在运维管理流程模块处理告警事件，而后提交审核，运维管理人员在接收到告警审核要求后，通过查看设备当前状态，确认设备是否恢复正常，若无异常则审核通过，否则审核退回，审核通过的告警系统由系统自动关闭，审核退回的告警事件重新回到运维人员受理状态；

告警事件分析是运维人员受理告警事件之后，通过查看告警事件对应原始状态数据以及告警事件关联告警原始数据等，尽快定位及发现设备异常问题原因，从而尽快解决问题的过程，运维人员为了处理告警事件，首先需要尽快确定告警发生原因，多数情况下告警的发生原因能够通过查看告警的原始状态数据以及告警内容发现，某些时候，运维人员无法直观的了解设备异常的根本原因，则需要运维人员通过关联分析来定位可能的告警原因。

如图5，IT设备状态数据并发采集流程在数据管理子系统启动时，自动生成定时任务，每隔1秒钟，采集任务触发线程执行，采集任务触发线程循环任务生成器，获取任务，根据当前时间与任务的最后完成时间间隔，判断时间差是否超过采集周期，若超过采集周期则表示该任务需要立即执行，触发采集任务，将采集任务加入任务执行队列，若不超过采集周期则任务不需触发，若任务从未执行，系统为保证任务随机性，减少大量任务同时采集的可能性，在任务采集周期内随机生成时间间隔，作为该任务最后采集时间；

数据管理子系统启动时创建采集任务执行线程池，用于并发执行采集任务，系统同时创建有任务计划线程，计划线程的作用在于从任务执行队列中获取下一个任务，使用采集任务执行线程池中线程执行采集任务，采集任务执行过程中，首先判断任务是否超时或任务是否为旧任务，若是则任务丢弃记录日志，接着根据采集任务创建用于格式化的采集结果result，result中定义了监控项基本信息、基本采集信息(采集时间等)，创建成功后，系统依据 采集策略通过建立连接执行采集脚本等方式获取状态数据，采集完成后，若采集策略中存在数据处理脚本，则系统执行脚本处理数据，而后将数据写入result，若不存在数据处理脚本，直接将采集到的数据写入result。

如图6，所述的状态告警规则诊断流程从系统接收到实时状态数据或聚合数据开始，接收到数据后，系统首先对数据进行扁平化预处理，根据数据子项内容生成一条或多条用于规则诊断的中间数据，数据预处理后，根据数据信息，获取不同类型规则匹配器，并放入规则诊断线程池等待执行匹配，通过规则匹配线程执行初始告警规则诊断操作，告警规则诊断后，判断诊断结果，如果匹配则触发状态告警事件，并通知运维人员，继续执行状态告警关联规则诊断，若不匹配则保存结果，结束规则诊断，关联规则诊断是在匹配告警规则后执行，若关联规则匹配成功，同样生成关联告警事件；

状态告警规则诊断过程是对状态数据与规则表达式是否一致的检验过程，匹配起开始执行匹配任务后，首先构造匹配任务并初始化匹配执行结果，系统的告警规则诊断线程获取到规则匹配任务后，首先根据诊断匹配器信息获取相应的告警规则，同时处理告警规则，转化为可执行的规则，获取规则中所有匹配表达式，逐个使用状态数据替换表达式中变量，并判断表达式是否成立，若表达式成立则与表达式匹配，每次匹配缓存匹配结果，根据所有表达式匹配结果得到最终告警规则匹配结果；

关联规则诊断流程是本次设计新增的主要功能之一，是为了通过分析关联规则，根据当前一直的告警信息了解可能出现的告警，从而尽快处理相关问题，关联规则的诊断流程主要是通过获取已经产生的告警事件关联规则，根据关联规则获取关联告警，从而触发关联告警事件，在进行关联规则诊段过程中，系统首先获取到等待进行关联规则匹配的告警事件，获取告警事件的状态告警规则编号，通过编号向系统的关联规则管理模块获取关联的告警规则，若获取到的关联告警规则为空，表示该告警事件不存在关联事件，若关联规则存在，系统生成关联告警事件，关联告警事件与告警事件不同，关联告警事件不存在告警等级，以关联规则中的置信度作为参考属性保存，对事件处理的时效性要求较低。

告警关联事件定位流程是对告警原因分析过程中通过对可能造成告警的 关联事件进行分析从而确定告警原因的过程，关联分析过程中，系统首先查看告警事件是否存在关联规则，若不存在则停止关联分析，若存在关联规则，首先通过获取关联规则查找关联告警事件，根据关联告警事件信息查找产生告警监控项的关联监控项，为了确认关联事件状态，系统提供告警事件前后三个周期的关联监控项状态数据展示，从而让运维人员更直观的了解关联监控项状态，定位告警原因，在告警关联分析的过程中，如果通过查看关联监控项状态无法明确，可以进步一查看关联监控项的其他关联项状态，从而纵向分析告警事件，全面分析一个设备系统内的所有监控项状态。

通过对本IT服务集中监控管理系统的需求分析，可以发现要实现该系统的功能，首先需要实时采集各种被监控项的状态数据，用以来对监控项状态实行实时监控以保证有效的产生高度可信的告警信息。另外从系统的智能改进可以发现，需要基于关联规则对告警事件的关联度进行分析获得他们的关联关系，这些关联关系不仅能够帮助有效预警而且能够帮助用户关联分析告警原因，而这些关联关系需要通过数据挖掘生成，而想得到正确的关联规则需要大量的样本数据进行分析，数据采集的设计直接影响到关联规则生成的质量。

IT设备状态数据管理子系统主要内容包括：状态数据采集与聚合策略管理、IT设备状态数据采集、IT设备状态数据聚合统计三方面。其中状态数据采集与聚合策略管理包括采集策略和聚合策略，用于对用户配置的监控项的信息处理后获得管理系统所能识别的策略规则；IT设备状态数据采集只要作用为通过主动采集与被动采集的方式采集监控项的状态数据，这些状态数据是后续模块使用的基础数据；IT设备状态数据聚合统计则是对采集到的状态数据根据聚合策略进行归档统计，从而获取到状态数据的统计信息，这些数据同样作为IT设备状态数据分析子系统的源数据使用。

策略管理主要是对本IT服务集中监控管理系统的采集策略以及聚合策略进行管理，对采集策略的管理将采集策略按照设备进行划分，用户页面操作监控项，系统调用接口对采集策略进行增、删、改、查管理，对聚合策略的管理同样根据设备、监控项进行划分，可以聚合策略进行增加、删除、修改和排序等操作。

1、采集策略管理

系统设计PolicyManager类来对采集策略进行管理，类的方法有Load、Add、Delete、Update、Select等。采集策略信息通过多个关联结构类统一描述。

采集策略信息可划分为设备信息、设备配置项信息、监控项信息以及监控项返回值列信息四个主要构造类。其实设备信息顾名思义，指的是一般定义上的计算机设备，例如一台服务器设备等。而配置项代表这个设备上的所有应用、软件等，如一台服务器上可以包括的配置项有：虚拟机、操作系统、应用服务等。配置项上的监控项则代表这个配置项的某项状态属性，例如操作系统的CPU使用率、文件系统使用率等。监控项返回值列信息定义了状态数据格式化过程中每一列数据的类型和名称等，例如对于CPU使用率的返回值，我们可以定义名称分别为I/OWait以及Used的不同类型CPU状态数据。对于某些无法具体定义传统意义上设备概念的配置项，如网络设备中交换机等，我们可以认为其为仅有一个配置项的采集设备。以上过程的策略定义能够满足大部分传统监控系统的需求，同时以设备方式组合，使得运维人员能够更好的理解系统定义的配置项以及监控项，有利于运维人员查看和管理。另外部分无法挂载的配置项，系统以另外的技术服务方式组织配置项。

下面详细介绍一下采集策略管理中的基本功能：

①加载采集策略

加载采集策略使用的是LOAD方法，由CollectorPolicyManager类调用LOAD方法从配置管理中心获取当前所有的设备策略，通过PARSE方法将加载到的采集策略组织成PolicyDevice结构储存。

②新增采集策略

新建采集策略首先调用PARSE方法，用PolicyDevice结构描述要增加的采集策略，而后调用ADD方法新增采集策略，添加采集策略时要进行排重，已有的采集策略不进行再次新增。采集策略的新增是从上到下逐层进行的，首先新增采集设备，然后新增配置项，由配置项新增监控项，最后新增监控的返回值类信息。

③修改采集策略

修改采集策略首先调用PARSE方法，用PolicyDevice结构描述要修改的采集策略，而后调用UPDATE方法修改采集策略，修改采集策略的过程较为复杂，需要逐层检查每一层数据的新增、修改或删除然后进行相应操作。

④删除采集策略

删除已有的采集策略，使用的是Delete方法，方法声明为：public bool Delete(string deviceID)，通过采集策略编号删除采集策略。

⑤采集策略查询

查询采集策略的信息，使用的是Select方法，方法声明为：public bool Select(string deviceID)，通过采集策略ID查找采集策略信息，另外还提供通过设备IP查找采集策略的方法。由PolicyDevice结构描述查找到的采集策略信息。

2、聚合策略管理

聚合策略是系统对状态数据进行聚合统计所需要的策略信息。系统设计AggregatePolicyManager类来对聚合策略进行管理，类的方法有Load、Add、Delete、Update、Select等。聚合策略基本信息通过AggregatePolicy结构描述，具体的操作方法与采集策略管理类似，此处不再赘述。

在聚合策略中可以定义基础聚合策略以及区间比例聚合策略，其中AggregateRange主要用于区间比例聚合策略。基础聚合策略即常见的对数据进行时间上聚合统计，如统计一个月的平均值等。而区间聚合则较为特殊，根据聚合规则表达式统计符合这一表达式的的数据，例如可以定义规则表达式为CPU使用率>＝80％的，则统计CPU使用率大于80的数据所占有的比例。

当前的IT运维规模愈加庞大，对于集中监控管理系统数据采集并发性的要求也越加严格，因此在如何解决数据采集的性能问题上，本文对状态数据采集的实现设计进行详细介绍。

系统的状态数据采集主要基于任务生成器队列、采集执行器生成线程、采集执行器队列、执行任务计划线程、任务执行线程池完成。其中任务生成器队列代表系统通过对采集策略的解析，根据任务注册器生成任务生成器的后用于存储任务生成器的队列。采集执行器生成线程的任务是通过定时触发根据任务生成器队列生成执行任务，是采集执行器队列的生产者。采集执行器队列中缓存的是采集执行器生成线程生成的执行任务。执行任务计划线程是执行任务队列的消费者，将队列中的任务放入任务执行线程池，任务执行线程池顾名思义用于执行采集任务。

整个状态数据采集过程主要三个过程：生成采集任务生成器过程，生成 采集任务执行器过程，执行采集任务过程。

(1)生成采集任务生成器

任务生成器是系统创建的用于表示可执行采集任务的结构体，其主要由CollectorCreatorManager类进行管理。当系统启动加载结束所有采集策略后，同时触发CollectorCreatorManager中的LOAD方法用以生成所有任务生成器，同时在系统接收到新的采集策略或变更采集策略时，通过CollectorCreatorManager中的Add及Update方法添加及修改任务生成器。生成的任务生成器保存在任务生成器队列中。

系统获取到采集策略后，首先解析采集策略中的每个配置项的监控项。循环每个监控项的采集策略，用监控项的采集方式与任务注册器列表中注册器匹配，从而生成对应的任务生成器。任务注册器列表是系统启动时定义的可支持采集的采集任务注册器的集合。另外对于需要被动采集的任务，系统在启动时已开启端口监控以采集数据，因此在生成任务生成器过程中，若匹配到被动采集任务，则不生成对应任务生成器。

(2)生成采集任务执行器

采集执行器是基于Runnable实现的用于定义采集任务执行过程以及执行采集任务的线程，所有的采集执行器只负责定义某个周期的采集过程，不要负责多个周期的采集，以免长期占用线程池资源。生成采集执行器的过程主要功能实现基于采集执行器生成线程、采集执行器队列、执行任务计划线程。

采集执行器生成线程在系统启动时定义，每秒执行一次，调用根据CollectorCreatorManager类中getExecutor方法，根据任务生成器Creator生成当前时间需要执行任务的采集执行器Executor，同时计算采集的计划执行时间写入采集执行器，生成的采集执行器放入采集执行器队列中，由此可知采集执行器生成线程是采集执行器队列的生产者。getExecutor的具体实现过程为：循环任务生成器队列，获取任务生成器，根据当前时间与任务生成器的最后完成时间间隔，判断时间差是否超过采集周期，若超过采集周期则表示该任务需要立即执行，生成任务执行器，若不超过采集周期则不生成。若任务生成器从未执行，系统为保证任务随机性，减少大量任务同时采集的可能 性，在任务采集周期内随机生成时间间隔，作为该任务最后采集时间。

采集执行器队列是一个线程安全的阻塞队列，用于存放当前需要执行采集任务的采集执行器，其主要由CollectorExecutorManager类进行管理。采集执行器生成线程生成的采集执行器Executor通过addPeriodicExecutor方法存入采集执行器队列中。

执行任务计划线程在系统启动时创建，其主要作用是若采集执行器队列不为空，则将采集执行器队列中的采集执行器线程放入任务执行线程池中，等待采集执行器通过执行线程执行。

(3)执行采集任务

执行采集的过程也就是采集执行器运行的过程。采集执行器运行过程中首先检查采集任务的时效性以及有效性，若采集任务在执行时的时间已经超过计划采集时间一个采集周期，则表示由于等待时间过长，当前采集周期内采集任务失效，任务丢弃。另外系统校验当前采集任务对应的采集策略是否存在，以保证采集任务的有效性。检验结束后，系统首先创建通用采集结果结构，而后开始执行采集。采集的具体执行方法根据不同类型的采集任务而区分，例如JDBC类型的采集任务，首先根据采集参数创建JDBC连接，而后执行采集脚本中定义的sql语句，获得原始采集数据；而SNMP类型采集任务，则根据采集参数及采集脚本定义基于SNMP协议的数据包，通过接受返回的数据包获得采集数据。获得原始数据后，系统根据配置的数据处理脚本处理原始数据，处理过后数据根据采集策略中定义的监控项返回值列信息执行格式化操作，由此的到最终的状态数据，并通过activemq发送给其他模块。

状态数据聚合统计是集中监控管理系统的必备功能模块之一，其目的之一是为系统的报表模块提供源数据，用以宏观上展示被监控设备及系统的状态；其二则是通过聚合统计获得的统计数据同样能够作为设备状态诊断的源数据，使得系统能够对某个时间段内的设备状态进行分析，而不仅仅是对设备瞬时状态的分析，从而提高系统的可用性。

状态数据聚合统计模块主要基于三个实时数据线程、历史数据线程以及策略的定时同步完成。其中实时数据线程主要处理实时产生的IT设备状态数 据执行聚合操作获取统计数据；历史数据线程用于处理历史数据的聚合统计操作；而定时任务则是为了实时获取最新的聚合策略，如图7。

(1)实时线程

实时线程是系统状态数据聚合统计模块用于处理实时的状态数据并进行聚合统计的线程。实时状态聚合统计根据需求包括实时基础统计以及业务聚合统计，实时基础统计即对数据进行时间上的聚合统计，如按分钟统计、按天统计等；业务聚合统计则是系统定义的根据相同的业务关系进行聚合的统计过程，如对一个业务系统的统计等，如图8。

系统获取到从amq收到的实时状态数据后，首先对数据执行入库操作，并解析状态数据，系统使用EsperData类描述获得的状态数据，解析的目的是为了去除状态数据中聚合统计不关心的数据内容，仅仅关心需要聚合的数据内容。

系统主要基于Esper引擎实现，实现基于事件流进行数据处理，把要分析的数据抽象成事件，然后将数据发送到CEP引擎，引擎就会根据事件的输入和最初注册的处理模型，得到事件处理结果。系统根据从聚合策略解析得到的统计策略生成相应的聚合事件，聚合事件发送到Esper实时缓存中等待处理。

在Esper引擎中，系统总共实现两次数据处理，分别是基础统计与业务聚合，经过处理的数据获得统计值的数据系统首先执行入库操作，而后根据处理结果再次生成统计事件或聚合事件，并将事件放入Esper实时缓存中进行下一轮聚合操作。

(2)历史线程

历史线程是系统状态数据聚合统计模块用于处理历史状态数据并进行聚合统计的线程。历史线程的聚合统计同样包括实时基础统计以及业务聚合统计。历史线程的实现过程与实时线程类似，具体流程图如图9所示。

IT设备状态数据分析子系统是利用IT设备状态数据采集子系统采集的数据样本，根据告警规则进规则诊断，对告警事件进行关联规则挖掘，并进行关联规则诊断。下面分别对IT设备状态告警规则诊断模块、状态告警事件关联规则挖掘模块、状态告警事件关联规则诊断模块进行设计，其中对状态 告警事件关联规则挖掘模块进行详细说明。

IT设备状态告警规则诊断模块是系统获取到IT设备实时状态数据或聚合统计数据后，根据知识库或配置模块中定义的告警规则，通过对于状态数据进行告警规则匹配从而触发状态告警的过程。告警规则诊断功能主要包括：告警规则管理、状态数据预处理、状态告警规则匹配、状态告警事件生成、状态告警事件通知这五个过程。

状态告警规则是系统对状态数据进行告警分析所需要的规则表达结构。系统设计RuleManager类来对聚合策略进行管理，类的方法有Load、Add、Delete、Update、Select、Parse等。告警规则基本信息通过DiagnoseRule结构描述，具体的操作方法与采集策略管理以及聚合策略管理类似，此处不再赘述。

状态数据预处理是对状态数据进行扁平化处理，从而有利于进行规则匹配。系统选用JEXL解析引擎实现对规则的匹配，数据预处理后，根据数据信息，获取不同类型规则匹配器，并放入规则诊断线程池等待执行，通过规则匹配线程执行初始告警规则诊断操作。状态告警规则诊断过程是对状态数据与规则表达式是否一致的检验过程，匹配起开始执行匹配任务后，首先构造匹配任务并初始化匹配执行结果，系统的告警规则诊断线程获取到规则匹配任务后，首先根据诊断匹配器信息获取相应的告警规则，同时处理告警规则，转化为可执行的规则。获取规则中所有匹配表达式，逐个使用状态数据替换表达式中变量，并判断表达式是否成立，若表达式成立则与表达式匹配，每次匹配缓存匹配结果，根据所有表达式匹配结果得到最终告警规则匹配结果。

经过状态告警规则匹配后，系统需要根据匹配结果对生成告警事件，告警事件生成管理包括生成新的告警事件以及修改为历史告警状态两个过程。首先系统确认执行告警规则诊断的告警规则是否已经存在实时状态告警，若存在告警则获取当前最新告警规则匹配结果，若告警规则匹配则不生成新的告警事件改为增加触发告警的状态数据到告警原始状态数据记录，若不匹配则将已存在的告警事件其告警状态修改为历史告警，代表这个告警事件当前已经不再发生。若执行告警规则诊断的告警规则不存在实时状态告警，判断 这台状态告警规则的历史告警信息是否已经由运维人员处理结束，若未处理则表明告警事件重新发生激活历史告警事件为当前告警事件，若告警事件已处理则表明运维人员的处理结果为达到预期异常状况依旧存在因此新增告警事件，告警处理流程图如图10。

状态告警关联规则挖掘模块是利用基于IT设备状态数据采集子系统采集的状态数据样本触发状态告警获得的状态告警数据，基于Apriori算法进行数据挖据，得出发生告警事件间的关联规则，为之后的告警事件关联规则应用提供基础模型。

(1)告警事件数据预处理

对于目前系统需要进行的告警事件关联分析，并非需要系统中保存的所有状态告警数据，所以首先需要明确数据库中对进行告警信息关联规则挖掘有用的状态告警数据是哪些，这些数据中哪些属性是关联分析过程中关心的需要提取的，重复或缺失的属性又需要如何处理。对于数据库中现有数据来说其中有许多噪声数据，不完整或者不一致的状态告警数据不在少数，因此若要建立有效的关联分析模型必须对这些状态告警数据进行数据预处理，从而提高告警数据质量、缩小状态告警数据范围、减少状态告警数据关联规则分析不必要的开销，最终达到关联规则分析建模的要求。以当前本IT服务集中监控系统拥有告警事件数据100多万条，如此大量的数据若全部用于关联分析，会消耗大量的时间和资源，另外还有部分数据本质上对关联规则分析毫无作用，还有部分数据需要提前进行处理后再进行分析才能提高效率。

有鉴于此，我们需要对这些状态告警数据进行预处理，具体的数据预处理工作流程包括数据集成、数据抽取、数据清洗、数据更新。

①告警信息的数据集成

告警关联分析所需的数据分散于多个数据表中，数据来源于告警信息表(AlarmInfo)、告警规则表(Rulebase)、告警规则表达式表(RuleExpression)、配置项信息表(CiInfo)、配置项关系表(CiRelation)、配置项监控项关系表(CiKiRelationship)、监控项信息表(KiInfo)，其中告警信息表主要保存当前存在的告警信息，而为了通过告警规则查找关联配置项的监控项告警规则需要通过告警规则表、配置项信息表、配置项关系表、配置项监控项关系表、 监控项信息表等进行关联查找，由于这些数据存放在多个数据表中因此系统不能有效的对数据进行统一处理，需要通过告警事件唯一编号关联把这些表里的数据集成到一起，代替使用多表关联查询来显示数据。

首先，系统目前存储的告警事件都是独立存在的，并没有任何的关联关系，为了方便进行告警事件的关联分析，如何通过告警事件找到同一时间关联配置项的告警信息就是数据集成所需要进行的。从关联分析角度而言，两条告警事件如果在一个时间段发生，且告警事件关联配置项存在关联关系，这都是可能成为关联告警信息的数据。因此需要做的工作是通过对这些数据进行集成，合并归类告警信息，得到时间范围内告警关系表，用来反映同一个采集周期内告警发生的关联关系。

②告警关联分析所需属性的抽取

完成数据集成后，观察集成后数据可以发现系统为了满足业务需求数据中依然保留了大量的业务属性，例如集成后的数据中存放了状态告警原始状态数据、告警规则表达式等，然而在建立关联分析模型时，并不需要所有的属性，删除原有数据中与关联分析无关的属性，仅保留那些有用信息可以提高分析的效率和正确率。

告警关联分析主要需要知道哪些告警事件同时发生了，这些告警事件触发的告警规则是什么，关于告警事件中告警状态、告警原始状态数据、告警处理标志位等都是关联分析不需要关注的信息，知道告警规则后需要知道关联配置项的告警规则，只需要通过告警规则关联配置项唯一编号以及监控项告警规则唯一编号标示即可，对于配置项的类型或名称等并不关心。另外对于告警规则，我们只需要告警规则唯一编号进行标示即可，不需要例如告警规则表达式等其他信息，所以这些属性都可以删除。数据抽取的过程只需要保留可以被关联分析模型使用的最少的属性。

③数据清洗处理方案

完成了以上几步数据的预处理后，等待进行关联分析的源数据中还存在大量噪声数据、错误数据、缺失属性数据，也就是“伪样本”。由于数据中的“伪样本”会导致分析结果有偏差，因此在数据挖掘初期数据预处理过程中需要对数据进行数据清洗，从而尽量消除“伪样本”存在的可能，提高数据 关联分析的有效性和准确性。

处理缺值记录。实际系统运行过程中，记录中属性值的缺失情况是不可避免，然而缺失的属性可能严重影响最终的分析结果。首先，属性值缺失可能导致丢失有用信息，在本系统中若告警信息中缺失了状态告警规则信息则这条告警信息最重要的信息已经丢失，告警信息对于关联分析则不存在任何价值；再者，脏数据存在可能使挖掘过程陷入混乱，从而产生不可靠的输出，例如在本系统中若存在错误的告警信息，若告警信息的关联配置项的相关配置项信息无法查找，则可能导致最终系统无法找到告警信息对应告警规则无法找到任何的关联规则，这种情况会导致系统对于这些告警信息处理无法提供任何有效帮助。因此，在进行数据挖掘前，对数据的缺值进行有效的处理是十分必要的。处理缺值有很多方法，主要有删除元组、数据补齐和不处理三类。由于系统支持手工定义告警事件，在手工生成告警事件过程中，由于人工疏忽可能导致部分数据缺失，对于该类型数据系统采用删除数据的方式进行。对于其他由系统自动生成的数据，由于采用删除缺值的方法可能导致丢失关键数据，因此不选用删除控制记录的方法。数据补齐又有手工填补、利用缺省值填补、利用均值填补、利用同类别均值填补、利用最有可能的值填补等方法。在本系统由于系统配置管理模块主要以配置项及监控项进行采集定义，在进行状态数据整理查询技术服务信息或设备信息时，对于部分配置项无法获取所属技术服务等信息，系统采用缺省值填补数据。

删除重复记录，为保证系统的可用性，系统设定在系统重启是重新采集数据，因此可能造成重复的状态数据以及告警数据产生，另外系统在意外情况下可能产生重复的告警数据，而类似的重复数据的出现可能影响对关联规则支持度与置信度的计算，因此需要手工删除。

处理错误记录。系统的数据库中存在错误数据的情况无法避免,这些“伪样本”数据可能是人工录入错误造成的，也可能是系统运行缺陷或系统异常造成的。对于错误数据，如果可以推断可能的值则自动进行修正。例如系统中如果发现配置项的关联关系错误，则可以通过修改关联关系从而使得系统在分析过程能够查找到正确的关联告警规则。但如果遇到无法推断可能值的情况，采取删除错误记录的方式，删除后能提高数据挖掘算法的效率和准确 度。若发现系统中的告警信息对应的配置项不存在，由于那个无法获知当时触发告警时的原始数据，因此对于此类告警信息执行删除操作。

④预处理任务的执行策略

本IT服务集中监控管理系统的关联分析采用定时任务的方式，在资源不紧张的时段进行计算，每次分析计算任务开始前系统对最新的已完成预处理的数据补充上次执行后的增量数据，用以保证数据能够及时、有效地更新。

告警信息数据的预处理模块在系统每次执行告警规则关联分析前调用执行，从而对用于关联分析的数据进行数据更新，当数据预处理操作结束后才进行核心的关联分析操作。

(2)关联规则分析

根据上述的数据预处理,完成了本IT服务集中监控管理系统的数据准备，可以开始对数据进行分析。下面主要对如何使用WEKA实现关联规则的计算进行介绍，获得关联规则并验证。

①关联规则分析的环境配置

本文采用Apriori算法进行关联规则的分析，使用数据挖掘开源软件WEKA进行算法的计算，WEKA软件使用Java语言实现的，便于在本系统中调用相应的接口实现计算，一次找出所有的频繁项集，然后由频繁项集产生强关联规则，满足最小支持度和最小置信度的规则将作为分析的结果。

WEKA软件由官方网站下载获得，安装后无须特殊配置即可使用。WEKA软件提供图形界面客户端程序、weka.jar类库文件及weka-src.jar源码文件供开发者使用。项目开发前期可以使用WEKA的客户端图形界面进行小规模数据的调试和验证，项目投入运行时采用在JAVA项目中引入WEKA的JAR包、调用相应的接口完成关联规则的计算。

WEKA的使用首先要在工程中引入weka.jar类库文件，配置相应的数据库连接参数，包括数据库连接地址、用户名、密码和数据查询语句，编码时引用相应的类，创建具体的实例进行计算。此外还需要设置最小值支持度、最小置信度等参数，参数的配置可以实现weka.core.OptionHandler接口，这个接口为各种数据挖据方法都提供了设置、获取参数的功能，至此就完成了关联分析计算任务前的基本的配置和程序编码。

在前面的步骤中已经完成了数据预处理，数据的属性都是关联分析需要的，数据也采用了增量更新的方式扩展数据样本，但这些数据仍然有优化的空间，还可以进一步缩小数据扫描的范围，提高分析效率。

关联规则分析数据准备首先需要除去那些明显不存在相关性或者相关性很低的数据。例如某个时间段内，同一个设备的所有配置项仅产生了一条告警，那么这条告警信息和其他告警信息就没有明显的相关性，这样的记录就可以删除。那为什么不在数据预处理中删除这些记录呢？数据预处理之后的数据虽然是历史数据，但它仍然会随着时间的推移增加，数据之间的关联关系也会改变。例如上面的例子，若该条记录为最新记录，那么在接下来的一个周期内，同一个设备可能产生其他的告警事件，那么多个告警事件就会从原来的无相关性变为有相关性，因此有些数据的处理是在每次计算之前进行的，删除的数据只是表示在本次分析任务中无相关性，可能以后会产生相关性，所以某些数据优化的步骤是在分析任务执行过程中进行。

删除多余数据之后，余下的数据样本需要转换为WEKA支持的ARFF格式文本数据文件，该文本数据文件由系统的专门模块负责生成，生成完毕后才启动关联分析模块进行关联规则分析。

WEKA导入ARFF格式文本数据后，创建一个数据实例，而后创建Apriori算法实例，设置算法相关的属性和参数，最后进行计算并返回计算结果。

计算任务运行一定时间后将获得Apriori的计算结果,计算后获得的关联规则不能直接使用，需要转化为数据库表的记录，在此基础上封装一些接口来查询和访问这些关联规则。

②关联规则分析任务的拆分和部署

系统的数据日益增多，面对如此庞大的数据量该如何高效、有序的进行关联规则分析任务是该子系统设计的重点。首先按照业务目标把分析任务分为不同的子任务，设置他们之间的优先级和依赖关系，由调度模块控制任务的队列和执行。然后根据数据量的预判，把子系统分别部署到不同的服务器，以保证计算任务执行时有充分的资源，并且能够同时执行多个没有依赖关系的子任务，缩短任务完成所需要的时间。

③关联规则结果验证

为了保证关联规则的正确性，需要对计算结果做验证性的功能，以保证对外提供的数据查询接口可以正常的运行。根据每个计算子任务的目标，分别编写测试脚本对每个子任务的数据完整性、对外接口运行的正确性进行验证。

④关联规则存储和发布

通过以上的关联规则分析，为触发关联告警以及告警关联事件定位提供了规则模型，这些关联规则数据经过存储和发布，以服务接口的方式提供给其他子系统。

关联规则分析的结果如“{先导}＝>{后继},支持度，置信度，提升度”的形式，这种结构数据无法直接提供给其他模块使用，需要根据关联分析结果数据的含义，设计对应数据库表结构，转换存储格式后存入数据库。数据库表中的属性包含唯一编号、先导、后继、支持度、置信度、提深度、对应分析任务批次号等。在数据分析子系统中，设计了关联规则管理模块进行这部分的工作，把分析结果转换为数据矩阵的方式存储到数据库中，再通过封装一定的访问接口从数据库中获取这些数据。

由于数据量较大，数据分析过程需要耗费较长的时间，为避免由于分析过程中遇到性能问题、异常和各种故障导致分析过程中断，影响其他服务的正常运行存储方案设计为两个独立的数据库，分别是主数据库和备用数据库，保证主数据库正在被使用，同时备用数据库参与分析过程的结果存储，每次分析完成都保存到备用数据库中，校验数据通过后，通过数据库链接管理模块，切换备用数据库为主数据库，相互交换主备关系，为下一次计算做准备。当主备数据库在切换进行过程中，关联分析模块为暂停运行状态。

由于分析过程中需要耗费较多的服务器资源，系统把需要分析的任务分为多个子任务，每个子任务的每次分析都用唯一的批次号来区分。所有的任务排队进行分析，任务队列的调度由专门的关联分析任务模块进行管理，使得计算所耗费的时间对系统的影响减到最小。系统管理人员可以随时查看任务的执行情况、耗费的时间，如果分析任务遇到失败或异常，会主动给相关人员发送通知邮件，以便可以及时排查问题和解决故障。

告警关联规则存储到数据库中后，想获得这些关联规则数据需要调用该 子系统的对外服务接口。

(3)与其他算法比较

在数据挖掘过程中核心的部分就是影响其关联规则分析性能的基础算法，最经典的是Apriori算法。Apriori算法利用Apriori性质来生成候选项集，大大压缩了频繁集的大小，取得了很好的性能。Apriori性质是指频繁项集的所有非空子集也一定是频繁。Apriori算法从单元素项集开始，通过组合满足最小支持度要求的项集来形成更大的集合。但Apriori算法在计算过程中产生大量的候选项集同时需要重复扫描数据库。

在Apriori算法基础上也有不少改进优化的算法，例如FP-growth算法基于Apriori构建，但采用了FP-tree的数据结构减少扫描次数，大大加快算法速度。FP-growth算法只对数据库进行两次扫描，而Apriori算法对于每个潜在的频繁项集都会扫描数据集判定给定模式是否频繁，因此FP-growth算法的速度要比Apriori算法快。但由于该算法要递归生成条件数据库和条件FP-tree，所以内存开销巨大。在本系统中由于数据量庞大因此使用FP-growth算法所需的内存开销更加不可估量，另外本系统的数据分析子系统的其他功能内存消耗同样不小，因此对于内存开销较大的本系统而言，FP-growth算法并不适合。

此外还有Eclat算法，Eclat算法加入了倒排的思想，加快频繁集生成速度，具体就是将事务数据中的项作为key，每个项对应的事务ID作为value，由频繁k项集求交集，生成候选k+1项集。Eclat的数据处理方式很适合用关系型数据表示和实现，而本系统中的告警事件并不适合用于关系型数据进行表示。另外在Eclat算法中，它由2个集合的并集产生新的候选集,通过计算这2个项集的Tidset的交集快速得到候选集的支持度，因此，当Tidset的规模庞大时求Tidset的交集的操作将消耗大量时间，影响了算法的效率，另外Tidset的规模相当庞大也会消耗系统大量的内存。因此Eclat算法也不适用于大规模数据量的IT设备集中监控管理系统。