会员体验
专利管家(专利管理)
工作空间(专利管理)
风险监控(情报监控)
数据分析(专利分析)
侵权分析(诉讼无效)
联系我们
交流群
官方交流:
QQ群: 891211   
微信请扫码    >>>
现在联系顾问~
首页 / 专利库 / 复杂事件处理 / 基于复杂事件处理引擎的监控系统

基于复杂事件处理引擎的监控系统

申请号 CN201511000974.0 申请日 2015-12-28 公开(公告)号 CN105653425B 公开(公告)日 2018-10-19
申请人 中国民航信息网络股份有限公司; 发明人 肖慧彬; 雷晓彬; 李婷; 李文亮;
摘要 本发明公开了一种基于复杂事件处理引擎的监控系统,所述系统包括:代理、复杂事件处理引擎、存储器以及主控单元;所述代理为一个或多个,部署在应用服务器上,一个应用服务器上部署一个代理;所述代理,用于监控应用服务器,收集应用的事件信息并发送给所述复杂事件处理引擎;复杂事件处理引擎,用于基于预先配置的规则对所述事件信息进行过滤和分析,得到最终的报警数据,并交由所述存储器保存;存储器,用于保存所述复杂事件处理引擎得到的报警数据,以及保存所述复杂事件处理引擎所需的规则;主控单元,用于控制所述复杂事件处理引擎所需规则的配置、基于所述报警数据控制前端界面的展示、以及控制所述代理;前端界面,用于用户配置规则、以及向用户展示报警数据。
权利要求

1.一种基于复杂事件处理引擎的监控系统,其特征在于,所述系统包括:代理、复杂事件处理引擎、存储器以及主控单元;所述代理为一个或多个,部署在应用服务器上,一个应用服务器上部署一个代理;

所述代理,用于监控应用服务器,收集应用的事件信息并发送给所述复杂事件处理引擎;

复杂事件处理引擎,用于基于预先配置的规则对所述事件信息进行过滤和分析,得到最终的报警数据,并交由所述存储器保存;

存储器,用于保存所述复杂事件处理引擎得到的报警数据,以及保存所述复杂事件处理引擎所需的规则;所述复杂事件处理引擎所需的规则包括:事件关联的规则,其中,所述事件关联的规则,用于所述复杂事件处理引擎在对事件信息分析和过滤的过程中将不同报警事件进行关联;

主控单元,用于控制所述复杂事件处理引擎所需规则的配置、基于所述报警数据控制前端界面的展示、以及控制所述代理;

前端界面,用于用户配置规则、以及向用户展示报警数据。

2.根据权利要求1所述的系统,其特征在于,所述存储器包括缓存单元,所述缓存单元用于保存所述复杂事件处理引擎得到最终的报警数据、以及供所述复杂事件处理引擎对事件信息进行过滤和分析的规则。

3.根据权利要求2所述的系统,其特征在于,所述存储器还包括数据库,所述数据库用于保存供所述复杂事件处理引擎对事件信息进行过滤和分析的规则。

4.根据权利要求2所述的系统,其特征在于,所述复杂事件处理引擎与所述缓存单元之间通过数据处理器交互。

5.根据权利要求2所述的系统,其特征在于,所述主控单元,还用于用户通过所述前端界面配置的规则发送到所述缓存单元进行保存,并将所述缓存单元中的规则转储到数据库,以进行持久化保存。

6.根据权利要求1所述的系统,其特征在于,所述前端界面,用于针对终端用户提供新增规则、修改规则、删除规则、和/或查看历史数据的功能项。

7.根据权利要求6所述的系统,其特征在于,所述前端界面,用于为终端用户展示配置规则的界面,一个规则对应一个界面;接收用户在相应规则界面输入的规则内容并生成相应的规则;所述界面为根据预先配置的规则模板展示的界面,和/或随机展示的界面,所述规则模板用于终端用户配置具有相同功能特性的一类报警规则。

8.根据权利要求7所述的系统,其特征在于,所述前端界面,还用于将生成的规则发送给所述主控单元;

所述主控单元,还用于将所述规则发送到缓存单元进行保存。

9.根据权利要求1所述的系统,其特征在于,所述前端界面,用于针对系统管理员提供管理规则模板、管理监控点、管理代理、和/或管理应用的功能项;所述规则模板用于终端用户配置具有相同功能特性的一类报警规则。

10.根据权利要求9所述的系统,其特征在于,

所述前端界面,用于提供用于管理监控点的界面;接收系统管理员输入的监控点信息,并将所述监控点信息发送给所述主控单元;

所述主控单元,还用于将所述监控点信息封装为报文并发送给所述代理;

所述代理,还用于接收监控点信息的报文,对所述报文进行解析,并从FTP服务器上下载具体的插件,再基于所述报文中包含的监控信息对插件进行处理,最后将插件加入到执行调度配置文件中,并开始调度。

11.根据权利要求9所述的系统,其特征在于,

所述前端界面,还用于为系统管理员提供管理代理的界面;在所述管理代理的界面,接收系统管理员选择要升级的代理和版本号,并发送给主控单元;

所述主控单元,还用于根据所述要升级的代理和版本号生成升级报文并发送给相应的代理;

所述代理,还用于接收所述升级报文,对所述升级报文进行解析,基于所述升级报文从指定的FTP服务器上下载代理升级包,对所述代理升级包进行解压替换掉原来的jar包,替换完之后自动重启,完成自身的升级操作。

12.根据权利要求9所述的系统,其特征在于,

所述前端界面,还用于针对系统管理员提供管理规则模板的界面,在该界面上接收系统管理员配置的规则模板信息,并发送给所述主控单元;

主控单元,还用于根据所述规则模板信息生成相应的规则模板,并发送给缓存单元进行保存;以及,在终端用户配置规则时,还用于调用所述缓存单元中的规则模板并发送给所述前端界面。

13.根据权利要求1所述的系统,其特征在于,所述代理包括:数据发送模块、任务调度模块和任务接收模块;

任务接收模块,用于通过消息中间件接收主控单元发送的监控命令,接收监控命令后对所述监控命令进行处理,生成一个个可执行的监控脚本,并由任务调度模块进行调度;

所述任务调度模块,用于实时检测所述监控脚本,发现应用异常时生成事件信息的报文并交由数据发送模块;

所述数据发送模块,用于将所述事件信息的报文通过消息中间件发送给复杂事件处理引擎。

14.根据权利要求1所述的系统,其特征在于,所述复杂事件处理引擎与所述代理之间通过消息中间件通信。

15.根据权利要求1所述的系统,其特征在于,所述主控单元与所述代理之间通过消息中间件通信。

16.根据权利要求14所述的系统,其特征在于,所述消息中间件包括AMQ服务器;

所述代理,用于将应用的事件信息发送到AMQ服务器上;

所述AMQ服务器,用于采用主题topic方式在所述代理与所述复杂事件处理引擎之间传输数据;

所述复杂事件处理引擎,用于通过订阅topic的方式获取所述应用的事件信息。

说明书全文

基于复杂事件处理引擎的监控系统

技术领域

[0001] 本发明涉及监控技术领域,尤其涉及一种基于复杂事件处理引擎的监控系统。

背景技术

[0002] 在当前的监控领域,各类监控技术及监控软件层出不穷。通过对这些监控技术研究发现,基本上所有的监控技术采用的报警手段,都是基于“满足单一规则——触发报警”的模式,例如“某服务器CPU IDLE低于10%,则报警”,或者“某服务器磁盘空间使用率超过80%,则报警”,这类规则能起到基础的异常情况捕获及报警的作用。
[0003] 但是,随着软件产业的飞速发展,分布式、虚拟化、云服务等多种软件体系架构的兴起,上述传统的监控报警技术已经无法满足当前的运维需求,因为通过传统的“阈值+比较”的监控技术,当服务规模大到一定程度时,会在很短的时间间隔内甚至同一之间内产生大量的报警事件。由此,当前运维存在的缺陷是如何在海量服务器、大量报警事件并发时,去伪存真,在海量监控事件中提炼得出管理员最需要的关键报警信息,如果能够做到这一点,将会极大程度的节约管理员的精力并且大幅度的提高报警效率。

发明内容

[0004] 为解决现有存在的技术问题,本发明实施例提供一种基于复杂事件处理引擎的监控系统。
[0005] 为达到上述目的,本发明实施例的技术方案是这样实现的:
[0006] 一种基于复杂事件处理引擎的监控系统,所述系统包括:
[0007] 代理、复杂事件处理引擎、存储器以及主控单元;所述代理为一个或多个,部署在应用服务器上,一个应用服务器上部署一个代理;
[0008] 所述代理,用于监控应用服务器,收集应用的事件信息并发送给所述复杂事件处理引擎;
[0009] 复杂事件处理引擎,用于基于预先配置的规则对所述事件信息进行过滤和分析,得到最终的报警数据,并交由所述存储器保存;
[0010] 存储器,用于保存所述复杂事件处理引擎得到的报警数据,以及保存所述复杂事件处理引擎所需的规则;
[0011] 主控单元,用于控制所述复杂事件处理引擎所需规则的配置、基于所述报警数据控制前端界面的展示、以及控制所述代理;
[0012] 前端界面,用于用户配置规则、以及向用户展示报警数据。
[0013] 其中,所述存储器包括缓存单元,所述缓存单元用于保存所述复杂事件处理引擎得到最终的报警数据、以及供所述复杂事件处理引擎对事件信息进行过滤和分析的规则。
[0014] 其中,所述存储器还包括数据库,所述数据库用于保存供所述复杂事件处理引擎对事件信息进行过滤和分析的规则。
[0015] 其中,所述复杂事件处理引擎与所述缓存单元之间通过数据处理器交互。
[0016] 其中,所述主控单元,还用于用户通过所述前端界面配置的规则发送到所述缓存单元进行保存,并将所述缓存单元中的规则转储到所述数据库,以进行持久化保存。
[0017] 其中,所述前端界面,用于针对终端用户提供新增规则、修改规则、删除规则、和/或查看历史数据的功能项。
[0018] 其中,所述前端界面,用于为终端用户展示配置规则的界面,一个规则对应一个界面;接收用户在相应规则界面输入的规则内容并生成相应的规则;所述界面为根据预先配置的规则模板展示的界面,和/或随机展示的界面,所述规则模块用于终端用户配置具有相同功能特性的一类报警规则。
[0019] 其中,所述前端界面,还用于将生成的规则发送给所述主控单元;
[0020] 所述主控单元,还用于将所述规则发送到所述缓存单元进行保存。
[0021] 其中,所述前端界面,用于针对系统管理员提供管理规则模块、管理监控点、管理代理、和/或管理应用的功能项;所述规则模块用于终端用户配置具有相同功能特性的一类报警规则。
[0022] 其中,所述前端界面,用于提供用于管理监控点的界面;接收系统管理员输入的监控点信息,并将所述监控点信息发送给所述主控单元;
[0023] 所述主控单元,还用于将所述监控点信息封装为报文并发送给所述代理;
[0024] 所述代理,还用于接收监控点信息的报文,对所述报文进行解析,并从FTP服务器上下载具体的插件,再基于所述报文中包含的监控信息对插件进行处理,最后将插件加入到执行调度配置文件中,并开始调度。
[0025] 其中,所述前端界面,还用于为系统管理员提供管理代理的界面;在所述管理代理的界面,接收系统管理员选择要升级的代理和版本号,并发送给主控单元;
[0026] 所述主控单元,还用于根据所述要升级的代理和版本号生成升级报文并发送给相应的代理;
[0027] 所述代理,还用于接收所述升级报文,对所述升级报文进行解析,基于所述升级报文从指定的FTP服务器上下载代理升级包,对所述代理升级包进行解压替换掉原来的jar包,替换完之后自动重启,完成自身的升级操作。
[0028] 其中,所述前端界面,还用于针对系统管理员提供管理规则模块的界面,在该界面上接收系统管理员配置的规则模板信息,并发送给所述主控单元;
[0029] 主控单元,还用于根据所述规则模块信息生成相应的规则模板,并发送给所述缓存单元进行保存;以及,在终端用户配置规则时,还用于调用所述缓存单元中的规则模块并发送给所述前端界面。
[0030] 其中,所述应用包括:数据发送模块、任务调度模块和任务接收模块;
[0031] 任务接收模块,用于通过消息中间件接收主控单元发送的监控命令,接收监控命令后对所述监控命令进行处理,生成一个个可执行的监控脚本,并由任务调度模块进行调度;
[0032] 所述任务调度模块,用于实时检测所述监控脚本,发现应用异常时生成事件信息的报文并交由数据发送模块;
[0033] 所述数据发送模块,用于将所述事件信息的报文通过消息中间件发送给复杂事件处理引擎。
[0034] 其中,所述复杂事件处理引擎与所述应用之间通过消息中间件通信。
[0035] 其中,所述主控单元与所述应用之间通过消息中间件通信。
[0036] 其中,所述消息中间件包括AMQ服务器;所述代理,用于将应用的事件信息发送到AMQ服务器上;所述AMQ服务器,用于采用主题topic方式在所述代理与所述复杂事件处理引擎之间传输数据;所述复杂事件处理引擎,用于通过订阅topic的方式获取所述应用的事件信息。
[0037] 本发明实施例针对现有技术存在的缺陷,提出一种基于复杂事件处理引擎的监控方法及系统,采用复杂事件处理技术及大数据处理方法,针对监控运维大数据处理,提高报警命中率的同时也大幅提高运维监控报警效率。与此同时,通过前端界面还能够支持最大限度的个性化定制。

附图说明

[0038] 在附图(其不一定是按比例绘制的)中,相似的附图标记可在不同的视图中描述相似的部件。具有不同字母后缀的相似附图标记可表示相似部件的不同示例。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。
[0039] 图1为本发明实施例监控系统的外部连接示意图;
[0040] 图2为本发明实施例监控系统提供给终端用户的功能项示意图;
[0041] 图3为本发明实施例监控系统提供给管理员用户的功能项示意图;
[0042] 图4为本发明实施例监控系统的概念架构示意图;
[0043] 图5为本发明实施例监控系统的监控逻辑架构示意图;
[0044] 图6为本发明实施例监控系统的物理架构示意图。

具体实施方式

[0045] 如图1所示,本发明实施例的监控系统在对应用进行监控时需要从应用服务器收集事件信息,并对其进行分析和过滤,最终产生的报警数据可以通过第三方通知相关人员,例如通过短信网关以短信方式通过通知相关人员或通过邮件网关以邮件方式通知相关人员。另外,本发明实施例的监控系统提供有前端界面,对于终端用户(如,运维工程师),前端界面呈现为其定制的用户界面,该用户界面便于终端用户配置报警的规则、数据查询等,对于系统管理员,前端界面呈现为其定制的用户界面,该用户界面便于系统管理员对规则配置、监控点、代理及应用等项目进行管理。
[0046] 如图2所示,在应用实例中,对于终端用户,本发明实施例监控系统的前端界面为其呈现的用户界面主要提供有新增规则、修改规则、删除规则和查看历史数据等功能项;如图3所示,在应用实例中,对于系统管理员,本发明实施例监控系统的前端界面为其呈现的用户界面上主要提供有管理规则模板、管理监控点、管理代理(Agent)、管理应用等功能项。
[0047] 实施方式之规则模板管理:
[0048] 当终端用户在界面中配置规则时需要先有一个具体的规则模板。规则模板指的是具有相同功能特性的一类报警规则的模板。例如“应用×××在×××时间内发送×××次含有关键字为×××的报错则报警”就是一个规则模板。终端用户可以根据需要将此规则补充完整即可。例如“应用CUSS在60秒时间内发生5次含有关键字为ERROR的报警则报警”。
[0049] 规则模板的配置过程中,所述前端界面针对系统管理员提供管理规则模块的界面,在该界面上接收系统管理员配置的规则模板信息,并发送给所述主控单元;主控单元根据所述规则模块信息生成相应的规则模板,并发送给所述缓存单元进行保存;以及,在终端用户配置规则时,主控单元调用所述缓存单元中的规则模块并发送给所述前端界面,前端界面将为终端用户展示配置规则的界面,该界面上显示有该规则模板。
[0050] 首先根据具体的规则模板为终端用户提供一个人性化的用户界面。用户界面在设计时要依据具体的规则模板,将需要自定义的内容留由用户自己填写。用户填写完之后点击规则会自动生成一个规则。一个具体的规则例子如下表1所示:
[0051]
[0052] 表1
[0053] 用户界面生成的最终的规则通过主控单元存放到Redis和数据库中。当终端用户需要修改某个具体的规则时,需要先将Redis中的相应规则删除,再根据需要生成最新的规则。实际配置时,还可以配置与规则相关联的报警联系人,所谓的报警联系人也就是当事件触发了这个规则后,生成了报警,这个报警应该发给谁。
[0054] 对于监控点的管理:
[0055] 监控点管理指的是当需要对应用的某个关键点进行监控时,如何自动化的完成。例如,需要对应用的某个日志中的关键点进行监控,或者需要对操作系统的CPU、内存等进行监控。
[0056] 本发明实施例的监控系统在实现针对具体点的监控时由插件来完成。此处所述的插件大部分指的是perl脚本,也有部分的shell脚本。例如监控CPU时,具体的监控工作由指定的perl脚本来完成,perl脚本执行完之后将检查的结果(即事件信息)返回给Agent,Agent重新对事件信息进行封装,封装成符合系统要求的报文格式,并通过发送接口发送给CEP。
[0057] 在前端界面添加具体的监控点时,需要终端用户输入一些其他的辅助信息。以日志错误关键字监控为例,需要终端用户输入的内容有:日志文件名称、日志所在路径、具体的错误关键字、插件调度的事件间隔、应用名称等信息。当终端用户输入这些监控点信息后,前端界面将这些监控点信息通过主控单元以报文的形式发送给Agent。Agent接收到报文之后,对报文进行解析,并从FTP服务器上下载具体的插件,再基于报文中包含的信息对插件进行处理,最后将插件加入到Agent的执行调度配置文件中,并开始调度。当添加新的监控点时,Agent自动加载新的插件并进行调度,无需重启Agent。
[0058] 实施方式之Agent管理:
[0059] Agent自身也需要管理,例如升级、重启、停止等操作。这些操作是Agent正常运转时不可或缺的功能。下面重点讲述Agent自动升级功能方案,其操作,例如重启、停止等与此类似。
[0060] Agent在升级时,前端界面为系统管理员提供管理代理的界面;需要系统管理员在前端界面选择要升级的Agent和具体的版本号,选择完之后点击确定按钮,在所述管理代理的界面,接收系统管理员选择要升级的代理和版本号,并发送给主控单元;主控单元会根据所述要升级的代理和版本号生成一条升级报文并向相应的Agent发送该升级报文。Agent接收到升级报文之后对其进行解析,如果发现是升级报文,则按照升级步骤进行处理。升级时,Agent基于所述升级报文从指定的FTP服务器上下载Agent升级包,对Agent升级包进行解压替换掉原来的jar包,替换完之后Agent自动重启,这样就完成了Agent的升级操作。
[0061] 需要说明的是,Agent自动重启需要一个辅助工具,此处使用的是开源的java service wrapper,它可以对java进程进行监控,发现java进程异常终止会自动对其进行重启。
[0062] 实施方式之规则管理:
[0063] 当用户需要对事件进行过滤和分析时,需要配置报警规则。报警规则规定了一些报警事件在什么时候可以触发,例如较为简单的事件流规则“在×××时间内,出现×××次包含关键字为ERROR的报错则报警”,较为复杂的规则“在×××时间内,某IP出现包含ERROR的关键,然后另外一台IP出现包含WARNING的关键则报警”。
[0064] 为了方便终端用户对规则的管理,监控系统的前端界面针对每一个规则设计了一个人性化的界面用来配置规则。其中,每个规则模板对应一个界面,终端用户只需要在相应的用户界面上输入必要的项,前端界面就会基于终端用户输入的内容生成对应的EPL语句,进而得到相应的规则。每个规则的增、删、改等操作都将同步到缓存单元,以确保CEP在过滤和分析时加载的规则都是最新的。
[0065] 如图4所示,本发明实施例的监控系统在概念架构根据职责不同主要分为如下几个部分:复杂事件处理引擎、缓存单元、数据库、主控单元、前端界面以及对于不同应用的各Agent。其中,
[0066] Agent用于收集应用的事件信息并发送给复杂事件处理引擎,部署在各个应用服务器上。Agent可以有多个,一个应用对应一个Agent。如图4所示,对应于应用1、应用2、应用3和应用4分别设置有Agent。
[0067] 复杂事件处理引擎,用于从缓存单元加载规则,并基于所述规则对各个Agent发送的事件信息进行分析和过滤,得到最终的报警数据。这里,如必要的话,复杂事件处理引擎在对事件信息分析和过滤的过程中,可以采用事件关联的规则将不同事件进行关联。所述事件关联的规则存储在缓存单元中,处理过程中复杂事件处理引擎从缓存单元加载相应规则。
[0068] 缓存单元,用于存储复杂事件处理引擎处理后的报警数据,且存储有所述复杂事件处理引擎对事件信息进行分析和过滤所需要的规则。
[0069] 主控单元,用于管理缓存单元到数据库的转储,管理用户权限,以及提供前端界面等。这里,主控单元提供的前端界面,用于呈现针对不同用户的用户界面,在所述用户界面上展示所述报警数据、和/或展示历史数据等。
[0070] 数据库,用于存储所述缓存单元中转储的数据。
[0071] 实际应用中,在每个应用的应用服务器上都部署有相应的Agent,每个Agent负责一个应用的事件信息收集并实时报送给复杂事件处理引擎。主控单元将缓存单元中的规则存到数据库中,以进行持久化的存储,并且在数据不断增加时可以有效缓解数据堆积,提升系统效率。同时,主控单元还以缓存单元和/或数据库的数据为基础,读取数据并通过前端界面呈现给用户。
[0072] 本发明实施例的监控系统逻辑架构如图5所示。
[0073] 如图5所示,Agent与复杂事件处理引擎、以及主控单元之间通过消息中间件通信。每个Agent包括三个模块:数据发送模块、任务调度模块和任务接收模块;任务接收模块通过消息中间件接收主控单元发送的监控命令,接收监控命令后对所述监控命令进行处理,生成一个个可执行的监控脚本,并由任务调度模块进行调度。任务调度模块实时检测所述监控脚本,发现应用异常时生成事件信息报文(固定格式的报文)并交由数据发送模块,数据发送模块将应用的事件信息报文通过消息中间件发送给复杂事件处理引擎。
[0074] 如图5所示,复杂事件处理引擎通过通信适配层、消息中间件接收各个Agent发送的事件信息。复杂事件处理引擎启动后,从缓存单元中加载规则,并基于该规则对Agent发送的事件进行分析和过滤,得到最终数据(例如是否需要报警、以何种方式报警等数据),并通过数据处理器分发给相应的缓存单元进行保存。
[0075] 如图5所示,主控单元通过通信适配层、消息中间件向各个Agent发送任务,如监控命令等。主控单元可以包括:数据管理模块、子管理模块、应用管理模块、管理结构和数据展现接口以及前端界面,其中,主控单元为用户提供前端界面,终端用户可以通过前端界面配置自己需要的规则,数据管理模块将终端用户配置的这些规则放到缓存单元的同时会持久化到数据库中。系统管理员可以在前端界面配置具体的监控点,由管理接口将系统管理员配置的监控点交由自管理模块和应用管理模块,再由自管理模块与应用管理模块生成监控命令并通知Agent执行。主控单元从缓存单元读取最终的报警数据,并通过数据展现接口在前端界面进行展示。
[0076] 本发明实施例监控系统的物理架构如图6所示,其中,Agent部署在应用服务器上,如图6中应用1、应用2、应用3……应用N分别表示应用服务器,在每台应用服务器部署一个Agent。Agent收集的事件信息发送到ActiveMQ服务器(AMQ服务器)上,本发明实施例的监控系统有2台AMQ服务器,分别是ActiveMQ-1、ActiveMQ-2,Agent随机选择一台AMQ服务器进行发送。这里,ActiveMQ是能力强劲的开源消息总线,AMQ服务器的作用相当于消息中间件。AMQ服务器采用主题topic方式,复杂事件处理引擎订阅topic。
[0077] 复杂事件处理引擎的硬件架构包括主机和备机,对时间信息进行分析和过滤的过程中,主备检测通过zookeeper来实现,当zookeeper发现主机发生宕机后,备机会自动接管。复杂事件处理引擎的主备引擎处理相同的数据,加载相同的规则,生成的数据都是相同的。ZooKeeper是一个分布式的、开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
[0078] 缓存单元使用Redis来实现,Redis是一个key-value存储系统,硬件架构上包括主缓存和备缓存。
[0079] 主控单元采用JBOSS,其硬件结构上也包括主机和备机,并使用了JBOSS的HA架构。
[0080] 用户登录系统时,会首先请求Apache服务器,Apache服务器将请求转发给JBoss即主控单元,主控单元会定时从Redis(即缓存单元)中转储数据到数据库中。如图6所示,数据库(DB)在硬件结构上包括DM和EDB。本发明实施例的监控系统采用分布式部署的方案,Agent部署在应用服务器上,并且每台服务器只能部署一个Agent,Agent用来采集各个应用的事件信息,Agent采集的事件信息通过消息中间件(AMQ服务器)发送到复杂事件处理引擎(CEP,Complicate Event Processor)进行分析和过滤。CEP采用订阅的方式从AMQ服务器上订阅消息,共有两台CEP,他们处理相同的数据,并通过Zookeeper来做主备切换。CEP处理后的数据,如果产生报警则直接通过报警接口发送出去,并且把最终的数据保存到缓存单元(Redis)中,控制单元定期将缓存单元中的数据同步到数据库(DB)中。
[0081] 需要注意的是,本发明实施例监控系统使用的复杂事件处理引擎是开源的Esper,它能应对复杂事件处理和事件流的分析。同时具有较高的吞吐量和较低的响应时间。它在实时性要求比较高的系统中扮演着重要的角色。在Esper中,规则又称为EPL。
[0082] 本发明实施例针对现有技术存在的缺陷,还提出一种基于复杂事件处理引擎的监控方法,采用复杂事件处理技术及大数据处理方法,针对监控运维大数据处理,在海量运维监控事件中进行复合关联分析,能够支持监控事件的不同层级、不同维度的匹配分析,提高报警命中率的同时也大幅提高运维监控报警效率。与此同时,还能够支持最大限度的个性化定制。
[0083] 本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用硬件实施例、软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。
[0084] 本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0085] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0086] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0087] 以上所述,仅为本发明的较佳实施例而已,并非用于限定本发明的保护范围。