司徒放，张灏龙，曹健

0 引言

随着网格和云计算的兴起以及信息产业的规模不断变大，复杂分布式应用的数量不断增多，它们都广泛存在于如金融、通讯、电力、制造、医疗、交通等不同行业。这些系统一般都是由多个独立子系统集成而成，子系统使用的开发技术和使用方式往往存在千差万别，而且大多运行在异构的节点网络之上。这些都极大的增加了分布式系统的管理难度，因此，IT企业通常要花费高出设备成本4到20倍的费用来对分布式系统进行配置和管理[1]。

监控是分布式系统配置和管理的基础设施，对各个子系统和计算节点进行及时、准确的信息收集，是对其进行有效管理的前提条件。分布式系统普遍采用事件机制，进行消息传递以及异常处理。各个子系统产生的事件定义和管理接口的差异无法避免，因此监控系统需要对事件进行规范化处理。而应用中节点和组件会不断产生大量事件，这时需要对事件进行过滤、组合和抽象。最后，系统还需要允许用户自定义管理规则，使管理动作能根据产生的事件被自动触发。

不少学者都在分布式系统的运行时监控上开展了工作，例如在监控规则的描述和定义方面，有使用自定义的脚本语言定义事件和监控规则的GEM[6]，使用类似正则表达式的方式描述事件模式的EBBA[7]，使用基于布尔式HFSL/HASL作为事件过滤和管理动作的HiFi[8]，使用状态机描述检测动作的STAT[9]。在运行时配置方面，STAT[9]使用STATL语言动态修改状态机配置，MonArch[10]通过探针修改监控配置，而 YANCEES[11]则使用插件扩展的形式获得运行时配置的支持。

与上述工作相比，本文提出的监控框架有以下特点：

1）基于复杂事件的监控处理方法。复杂事件是对若干个事件的抽象和复合得到的事件[2]。使用复杂事件可以对大量的基本事件进行提炼，更容易被分析和理解。在分布式系统监控中，对事件之间的关联关系、先后顺序、时间周期和出现次数的描述非常普遍，使用复杂事件可以自然的表达，因而比一般的规则更易于把这些关系描述清楚。

2）可动态加载、配置的监控探针。为了保证高可用性，系统需要在不重启的情况下持续运行，因此探针需要有被动态加载的能力以适应新的监控需求。此外，探针也支持动态配置监控参数（如监控周期、监控方式等），以实现更有效的监控。

3）系统采用事件驱动架构。监控服务器通过订阅各个节点的探针事件，实现对节点的监控。对于每个订阅，系统还提供简单的事件过滤，减少发送无用事件，减轻网络和监控服务器的负担。

1 监控框架概览

监控框架 EMMI（Event Monitoring and Management Infrastructure）是笔者开发的一个基于复杂事件的可配置监控框架，用于对分布式系统进行监控。如图1所示，EMMI主要分为监控服务器、事件消息传输通道和分布式计算节点3个部分。这3个部分，就好比神经中枢、脊椎和神经元，它们一起构成了 EMMI监控神经系统。图中的菱形图例代表探针，可以看到在EMMI的3个部分的组件都装有探针，通过探针不仅实现了对计算节点的监控，也实现了对监控组件自身的监控。

图1 EMMI监控框架概览

分布式计算节点是一个计算机节点，在每个计算节点上都运行了探针平台守护进程，该守护进程对外暴露了探针加载和管理的接口，因此监控服务器可以通过它向计算节点加载和管理探针。探针可以对管理对象实施监控，并发布监控事件。如果监控事件被监控服务器订阅，那么探针平台会把事件用消息的形式封装，传送到事件消息传输通道。

事件消息传输通道实际是一个消息中间件，它可以部署在某个计算节点或者监控服务器上。传输通道负责缓存来自网络的各个监控事件消息，将它们按照时间戳排序，然后通知消费者取走事件。在 EMMI中，由监控服务器中的事件消息转换模块消费传输通道中的事件。

监控服务器主要负责监控事件处理、规则匹配和管理决策。监控服务器由事件消息转换模块、事件流引擎构成。事件消息转换模块负责从传输通道中取走事件消息，并转换为事件流引擎可以处理的事件。这些事件作为输入提供给事件流引擎。事件流引擎读入各个事件，并按照事件规则对事件进行处理，当规则匹配时，对应的响应动作会被调用。在系统中响应动作可以有很多种，例如可以将事件数据存入数据库，或做日志记录，也可以调用事件决策探针，执行管理决策操作。

2 可配置的探针平台

EMMI主要使用探针对分布式系统信息进行收集，产生事件。底层监控探针平台基于 JMX（Java Management Extensions）[3]构建。JMX是Java 5推出的一套为应用植入动态管理功能的扩展规范。除了JVM直接支持JMX外，现在很多 Java中间件如 JBoss、Tomcat、ActiveMQ、WebSphere、GlassFish等都支持JMX管理方式。JMX是EMMI探针平台的基础，它使EMMI的探针编写与配置管理都更加方便。使用JMX，可以以标准的方式远程管理跨平台的各种应用，而且其松耦合的组件开发形式，可以实现探针的可插拔性，从而降低了移植和维护成本。探针平台分为装配层、代理层和分布式服务层3个层次[3] [4]，如图2所示，灰色背景的组件为EMMI提供或增强的组件。

图2 探针平台的三层架构

装配层(Instrumentation Level)主要定义了EMMI探针平台上的探针。探针的任务是完成对受管理的应用与资源的监控细节的封装，并对外暴露出属性、操作和事件通告。在JMX中，这种可管理资源的封装被称为 MBean（Managed Bean）。因此EMMI的探针都是MBean。例如，进程表探针可以获得当前系统运行的进程列表，并通过它对外的进程列表属性发布出来，管理应用可以直接查询这个属性，也可以通过订阅属性变化事件，在进程表发生变化时得到通知。进程表探针还可以暴露管理操作，如杀死进程、转储进程信息等。

代理层(Agent Level)包括MBean服务器和一系列代理服务。代理层相当于 EMMI的探针管理容器，对内它维护探针的生命周期（如探针加载、卸载），为探针提供各类代理服务（如阈值监视器、定时服务、关联服务等），对外它提供探针的遍历、查找、管理等接口，并将探针的管理元数据暴露给管理应用使用。EMMI扩展JMX MBean服务器为探针平台，增加了新的探针定义方式，而且可以向探针注入平台资源，简化探针编写难度。

分布式服务层(Distributed Services Level)主要为监控平台提供连接器和适配器，以供管理应用访问。JMX本身带有RMI连接器，因此管理应用可以使用RMI连接探针平台（如JDK5自带的jconsole程序）。在EMMI中，还提供了基于HTTP的适配器，因此EMMI可以通过浏览器访问。

2.1 探针的实现形式

EMMI中的探针都是 MBean。JMX中有两种类型的MBean[3]，一种称为标准 MBean，使用 JavaBean的内省（Introspection）方法，将MBean所定义的getter/setter方法转化为探针要暴露的属性，其他操作方法转化为探针要暴露的操作接口。另一种称为动态 MBean，使用编程方式动态生成属性、操作接口。前者简单且容易编写，适合编写新探针时用。后者非常灵活，既可以对遗留系统的非JMX监控组件进行封装，也可以满足管理接口需要在运行时才能确定等情形（例如针对不同用户权限，一个探针可以有不同的访问接口）。后者编写相对复杂，需要编程实现探针所有接口。由于MBean服务器使用基于MBeanInfo元数据描述的方式向上层管理应用提供MBean访问接口，因此两种MBean实现尽管不同，但是它们对外暴露的管理方式都是统一的。

受Spring和Guice框架的启发，EMMI提供了一个融合两种实现形式的方案，如图3所示。

图3 框架中探针的实现形式

对于新建的 EMMI探针，可以使用基于内省混合标注（Java Annotation）的创建方式；对于已存在的管理监控组件，使用XML方式配置。一个使用标注创建简单的作业管理探针的示例如图4所示。

图4 使用标注创建探针的示例

在图4中的ActiveJobRecords和MaxActiveJobNumber都是管理属性，但是ActiveJobRecords没有标注setter方法，所以它是只读属性。prepareEventSender(…)并没有标注为探针操作，所以它不会对外公开。对调用参数的标注，是为了避免构造函数和方法中的参数名称信息被Java编译器丢弃。表1为EMMI可定义的探针特性。

表1 可定义的探针特性

EMMI中还有一个特殊的资源注入标注@ProbeResource，被它标注的方法会在探针加载时被自动调用，探针平台会根据方法的第一个参数判断需要注入的对象。这些对象是探针平台预先定义并统一管理的资源，如监控线程、事件发布器、平台环境信息、运行时为探针生成的信息（如 ObjectName）等等。图 4中 prepareEventSender是一个注入的方法，探针加载时这个方法会被调用并传入EventSender实例，探针可以保留这个实例供发布事件时使用。这种依赖注入的方式能简化探针的资源获取方式，同时，由探针平台统一配置资源，更便于资源管理、监控和优化。

代码标注的方式简化了探针编写的难度，但是，对于已存在的JMX管理组件，无法在源代码级别进行标注，因此，EMMI还采用了与Apache Modeler组件类似的配置方式，即使用外部XML配置探针，对应的XML标签可参考表1。

2.2 探针的事件模型

EMMI的事件沿用了JMX的通告（Notification）模型。JMX通告采用事件发布/订阅机制，但由于没有预定义事件schema，因此无法被上层事件流引擎直接处理。为此，EMMI利用通告的用户数据域 UserData存放可供事件流引擎处理的事件实例。这是一个java.util.Map结构，里面维护了键值对的列表，包含了事件的全部属性。JMX通告本身的事件类型、事件源、时间戳、事件信息等，都属于事件的基本属性。

在上层管理应用进行事件订阅时，需要同时指定过滤规则。JMX通告产生后，探针平台首先从订阅列表中检查其是否被订阅，再根据过滤规则进行一遍过滤。对满足条件的情况，平台会将事件从通告用户数据域中取出，发往事件消息传输通道，如图5所示。

图5 监控事件的传输过程

事件在节点和监控服务器之间传输时，JMX默认采用RMI来传输通告，这会导致性能和可靠性问题[4]，因此，EMMI使用Java消息服务（JMS）中间件替代直接的RMI传输，探针平台作为消息生产者，把事件作为消息的载荷放入传输通道。监控服务器端的事件消息转换器作为消息的消费者，收到消息后取出其中的事件实例，交给事件流引擎处理。

3 基于复杂事件的监控规则

基于JMX的监控平台已经可以满足普通的监控需求：在平台上加载监控探针和决策探针，让决策探针作为监控探针发出的事件的响应者。如果监控事件和响应动作不复杂，那么这种方式是很适合的。但是在分布式系统中，还需要对节点间多个事件的时序、关联进行分析，单个节点上的探针没办法侦测到多个节点上发生的事件，只能交给决策探针使用编程方式作进一步判断。这样做会使事件规则和决策处理耦合在一起，代码不便于表述和维护。

在 EMMI中，各个监控探针平台过滤后的事件都不直接处理，而是发往事件传输通道，最终交由事件流引擎处理。经过事件流引擎对事件的整理、提炼，可以抽象出用于决策处理的复杂事件。

3.1 复杂事件处理

目前，很多商业公司和研究机构都推出了自己的事件流引擎，如Esper、Coral8、StreamBase、Apama、TelegraphCQ等。它们都采用事件处理语言 EPL（Event Processing Language）对处理规则进行描述。尽管目前 EPL没有统一标准，但他们都采用类似SQL的语法。与SQL不同，EPL的处理对象不是数据表，而是事件流中的事件。事件流引擎首先存储并预处理 EPL语句，让每个事件流入状态机进行匹配，监测它们是否满足复杂事件规则，如果满足，则作出响应[2]。这种方式和提交一次查询一次的 SQL正好相反，一条 EPL语句提交后会被持续查询，查询不匹配的事件会被引擎丢弃。EPL专门针对事件机制有特色的语法，例如事件时序、事件模式、事件窗口等等，这些在下文的监控规则中得到体现。

EMMI使用Esper作为事件流处理引擎。Esper是业界有名的事件流引擎。它有 Java开源版本，并且开发仍在持续进行。使用Esper进行复杂事件处理时，首先需要定义事件schema，然后再向引擎注册EPL语句，并绑定EPL对应的响应动作[5]。

3.2 事件schema定义

事件schema可类比数据库的表格schema，定义了事件包含的所有属性，以及事件的表示形式。Esper支持用JavaBean、java.util.Map、org.w3c.dom.Node等方式表示事件，且要求每条EPL语句中的事件，都要预先定义好schema。EMMI主要使用Map表示事件，Map里面的每对键值对都需要在事件schema中预先定义。如图6所示定义了仿真计算的作业开始事件：

图6 作业开始事件的定义

3.3 监控规则配置

Esper支持用编程方式创建EPL。EMMI针对Esper编写了配置探针，使规则的配置可以通过探针平台完成。事件流引擎探针可以动态的在引擎中定义事件 schema、注册EPL、配置事件响应、配置规则等。

如图7所示，EMMI的监控规则由一条EPL语句以及若干个事件响应动作组成。在配置规则时，首先检查 EPL中的事件是否存在 schema，如果存在则注册 EPL，否则返回错误信息，最后根据规则制定的响应动作按照类型分别创建监听器，并绑定到EPL语句上。

图7 事件schema和监控规则的配置

EMMI支持多种事件响应，如决策探针的调用、数据库更新、日志记录等。它们都实现了Esper的事件更新监听器接口。当事件发生时，事件流引擎会通知EPL语句绑定的监听器。数据库更新监听器和日志记录监听器按照规则配置进行更新和记录，事件决策监听器比较特别，它按照规则配置，调用安插在事件流引擎探针平台上的事件决策探针的某个操作。决策探针与封装监控实现的探针不同，它封装的是无法在规则配置里面简单写清楚的管理决策，包括文件操作，远程节点的探针调用，数据库事务操作，修改引擎配置等等，如图8所示。

图8 由事件触发的监听器

4 系统实现与应用

EMMI目前应用于分布式仿真计算项目中，负责对进行仿真计算的节点进行监控，监控内容包括节点计算资源、系统中间件运行状态、仿真作业运行情况等。目前各个计算节点都是Windows操作系统，上面装有Sun JRE 6并运行了探针平台守护进程（JMX版本 1.4）。监控服务器为 Linux操作系统，部署了Active MQ 5.2.0作为事件传输通道，Esper 3.0作为事件流引擎。另外，EMMI在服务器端编写了探针平台的HTTP适配器，可以为管理员提供基于网页的管理门户。表2所示为当前EMMI在仿真项目监控中开发的几类探针。

表2 EMMI在实际仿真项目监控中的探针

4.1 监控规则配置实例

例1 利用复杂事件对过期作业进行自动处理

配置首先创建了一个提示作业结束的规则，其condition是一条 EPL语句，该语句描述了当作业成功完成（JobCompleteEvt）或作业错误结束（JobErrorEvt）或作业被取消（JobCancelEvt）三者之一被触发时，把一个作业结束事件（JobFinishEvt）放入事件流中。作业结束事件并不真实存在，相当于前面3个事件的一个抽象。

配置随后又创建了自动取消超时未完成作业的规则，语句描述了一个复杂事件：在 JobStartEvt事件发生后，读取事件中的estimateSeconds属性，在estimateSeconds秒后如果没有收到对应的JobFinishEvt事件，则认为作业超时未完成。EPL语法可参考Esper文档[5]，操作符"-＞"读作follow-by。超时未完成事件会触发绑定的响应动作：调用探针JobManageProbe中的操作 cancelJob。操作 cancelJob由MBeanInfo可知需要两个参数，规则中显式指定了uploadResult，而jobId并没有指定，就由EMMI从EPL select得到的结果中匹配。

事件规则除了编写监控动作外，也能进行信息统计，例如下面的规则每15分钟对节点汇报的信息统计一次，并将统计结果保存到数据库：

例2 利用复杂事件进行节点信息统计

4.2 实际管理界面

EMMI的探针管理界面分为左右两部分，左侧是节点探针选择区，右侧是选择区对应的功能界面。图9是左侧选择区的部分截图，列出了节点192.168.0.18在32100端口开放的探针平台中可以动态配置的探针。其中进程探针ProcessProbe有四个探针实例可以进行属性、操作和事件配置。此时右侧显示探针检测到的进程属性的信息列表。

图9 节点探针选择区的部分截图

EMMI的管理界面还可以对监控规则进行配置。图 10是规则配置中的事件响应面板，这里以前文例1的响应作为例子。在响应类型中可以选择调用事件决策探针，数据库更新，使用已定义的响应等类型。响应ID是响应的唯一标识，用于系统管理（如EPL绑定等）。可以选择当前在服务器上已有的决策探针和对应的操作。操作对应的参数会被动态的从MBeanInfo中获取并展示，以便配置。

图10 配置监控规则中事件响应的截图

5 结论

对分布式系统进行监控一直都是协同仿真计算的研究热点，为解决这个监控问题，本文提出了基于JMX的探针监控平台与基于复杂事件的规则处理相结合的监控框架。使用JMX技术不但有效解决了统一多节点多中间件的监控接口的问题，而且以事件驱动的方式使监控组件和仿真应用相分离，使系统更加具有可维护性。事件流引擎的引入，使监控规则可以利用时序关系、事件窗口等复杂事件处理语法，更容易的对基本监控事件进行抽象、提炼。除此之外，框架也引入了 Java流行框架中出现的新技术，如代码标注、资源注入、XML配置等，使监控探针的编写得到简化。

后续研究将以本文提出的监控框架为基础，主要从下面两步进行：

1. 可靠性问题。事件处理引擎除了具有响应度高的要求外，还需要保证系统的可靠性。当前 EMMI框架仅适用一个事件流引擎，很容易产生性能上的瓶颈和单点故障，进而导致整个监控架构甚者分布式系统瘫痪。为解决这个问题，可以使用冗余的事件流引擎进行并行处理。另外，由于事件流引擎对事件的处理都是实时的在内存中进行，组件故障或断电等异常情况发生时，需要避免数据丢失。解决方案是实施事件数据持久化，当引擎从故障中恢复时，能够迅速恢复，但是这还要考虑海量事件的存储问题。

2. 事件记录的可视化。对存储在数据库中的事件记录进行数据挖掘，并用可视化的形式表现，更有利于管理人员对系统进行管理和维护。

[1] Patterson D, Brown A, Broadwell P.et al. Recovery Oriented Computing (ROC): Motivation, Definition,Techniques, and CaseStudies [R] . Computer Science Technical Report UCB, U.C. Berkeley, 2002.

[2] David Luckham, Roy Schulte. Event Processing Glossary- Version 1.1[EB/OL] . Event Processing Technical Society,2008.http://complexevents.com/2008/08/31/event-processi ng-glossary-version-11/.

[3] Java Management Extensions (JMX) Specification, version 1.4 [EB/OL] . Sun Microsystems Inc, 2006.http://java.sun.com/javase/6/docs/technotes/guides/jmx/.

[4] Sullins Ben G, Whipple Mark B. JMX in Action [M] .Manning Publications Co. 2003

[5] Esper Reference Documentation, version 3.0.0 [EB/OL] .EsperTech Inc,2009.http://esper.codehaus.org/esper/documentation/documentation.html.

[6] Mansouri-Samani M. Monitoring of Distributed Systems[D] . Ph.D. Dissertation, University of London, 1995.

[7] Bates P. Debugging heterogeneous distributed systems using event-based models of behavior [J] . ACM Trans Computer System, vol.13, 1995: 1-31.

[8] Ehab Al-Shaer, Hussein Abdel-Wahab, Kurt Maly. HiFi: A New Monitoring Architecture for Distributed Systems Management [C] //19th IEEE International Conference on Distributed Computing Systems (ICDCS'99), 1999: 171.

[9] Giovanni Vigna, Steve T. Eckmann, Richard A. Kemmerer.The STAT Tool Suite [C] //DARPA Information Survivability Conference & Exposition, vol.2, 2000: 1046.

[10] Marcio S. Dias, Debra J. Richardson. Adaptable Analysis of Dependable System Architectures through Monitoring[C] //Architecting dependable systems III, Springer, 2005:122-147.

[11] Roberto S. Silva Filho, Cleidson R.B. de Souza, David F.Redmiles. Design and Experiments with YANCEES: a Versatile Event Notification Service [R] . Institute for Software Research, University of California, Irvine,UCI-ISR-04-1, 2004.200240, China; 2. R and D Center, China Academy of Launch Vehicle Technology, Beijing 100076, China)