JMX 入门

 1.JMX：网络管理规范

JMX(Java Management Extension Instrumentation and Agent Specification) 是业界广泛合作创建一套规范的成果，它描述可扩展的体系结构、API 和一组使用 Java 编程语言用于网络管理的分布式服务，它利用了 Java 平台的网络管理能力。最新的规范是 1.4。

2.JMX 的体系结构和操作模型

JMX 的体系结构和操作模型旨在满足下列目标：

•可伸缩性：适应从管理少数设备或服务到管理因特网时代的企业可能拥有的数万个可管理端点的能力 

•旧系统集成和兼容性：与现有 NMS 或 EMS 解决方案以及与可能不支持 JMX 的旧的可管理端点协作的能力 

•低成本实现：无需大量设计和编码工作，即可轻松地将 JMX 兼容性设计到现有软件产品和设备中   

在 JMX 体系结构中，采用三级分而治之的体系结构化方法来降低可伸缩网络管理的复杂性。 

图1说明了这三个松散耦合的层。它们是：

•设备层(Instrumentation Level)  设备层的主要任务就是对资源进行封装，使之成为可管理资源。所谓封装，就是通过将资源用类似Java Bean的方式描述出来。当资源以这种方式被封装成为可管理资源后，就被称作MBean(Management Bean)。

•代理层(Agent Level)  代理层位于装配层和分布式服务层之间，包含 MBean服务器，代理服务，连接器和协议适配器。代理层的作用体现在内外两方面：对内它通过MBean服务器(Managed Bean Server)维护着MBean的生命周期(包括注册和注销MBean)，同时为所注册的MBean提供各类服务；对外通过连接器和协议适配器将已注册的MBean的管理接口暴露给外面的管理应用使用。

•分布式服务层(Distributed Service Level)  分布式服务层驻留着管理应用。管理应用通过连接器(Connector)与MBean服务器建立连接，并通过管理接口(Management Interface)去访问各个Mbean所包装的可管理资源。JMX Remote API Specification(JSR-166)对分布式服务层的应用给出了具体的规范。

图 1. JMX 体系结构的三层

      设备层

该层定义了如何实现JMX管理资源的规范。一个JMX管理资源可以是一个Java应用、一个服务或一个设备，它们可以用Java开发，或者至少能用Java进行包装，并且能被置入JMX框架中，从而成为JMX的一个管理构件(Managed Bean)，简称MBean。

管理构件可以是标准的，也可以是动态的，标准的管理构件遵从JavaBeans构件的设计模式；动态的管理构件遵从特定的接口，提供了更大的灵活性。 

该层还定义了通知机制以及实现管理构件的辅助元数据类。

4.MBean组件 

MBean是Management Bean的缩写，负责将可管理资源和服务封装成类似Java Bean的形式。通过MBean的特性可以访问可管理资源的各类信息。MBean对资源的封装体现在以下几个方面：

•能被接触的属性值

•能够执行的操作

•能发出的通知事件

•管理构件的构建器 

说明：JVM已经默认被封装成可管理对象。可通过它去访问内置的JVM，从而远程监控并管理JVM。

MBean在JMX的3层架构中位于设备层和代理层，这两层中的MBean有着不同的作用：位于设备层的MBean被用来封装可管理资源，而位于代理层的MBean被用来封装MBean服务器提供的代理服务(比如定时器服务和监视器服务)。

从MBean的实现上来看，MBean分为两种类型：标准(Standard)MBean和动态(Dynamic) MBean。其中动态MBean又进一步分为Open MBean和Model MBean，如图2所示。 

 

图2. MBean的分类 

a)标准(Standard)MBean 

标准MBean适用于描述那些数据稳定且可被事先准确定义的资源。标准MBean就是一个普通Java Bean，MBean服务器通过Java的内省(Introspection)机制来获知标准MBean的属性、事件和方法，只是这里内省所遵循的命名规定是JMX特有的命名约定。

这种类型的MBean最简单，它能管理的资源（包括属性，方法，时间）必须定义在接口中，然后MBean必须实现这个接口。而且这个MBean实现类中，必须至少有一个public的构造函数。 类中的getter和setter函数必须遵守命名标准。 类的命名也必须遵循一定的规范，例如我们的MBean为Hello，则接口必须为HelloMBean，而且是大小写敏感的。如果不这么做，可能会有javax.management.NotCompliantMBeanException抛出。

b)动态(Dynamic)MBean

动态MBean适用于描述那些要在运行时才可确切知道的数据结构的资源。与标准 MBean不同的是，动态MBean所暴露的管理接口不必事先确定，而是可根据运行时的情况，判断生成最终的管理接口。比如用以描述配置的MBean，可能需要通过对配置文件的分析来最终获得属性的名称和类型。

动态MBean的标志是实现了javax.manangement.DynamicBean接口。接口中的方法getMBeanInfo()所返回的就是要对外发布的管理接口。与标准MBean不一样的是，MBean服务器不是通过内省，而是通过getMBeanInfo()方法的返回值来获取动态Bean的管理接口。

   当在JMX agent里注册时候, dynamic MBean和standard MBean是同样被对待的。管理程序首先通过getMBeanInfo函数获得管理接口,得到属性和方法的名称.然后程序可以调用getters，setters和invoke方法.

    c)开放(Open)MBean

Open MBean是一类特殊的动态Mbean，它的特征是只针对特定对象，比如原始的数据类型(如int和float)和复合的数据类型。

  开发standard,dynamic和model MBean可以使用复杂类型。然而，为了让管理程序能够正确得到这些类型的状态，这些类的字节码必须让这些管理程序访问到。结果就是导致管理程序和被管理资源的耦合度很高。折衷的做法，就是要降低被管理的资源的可维护性。Open MBean的产生就是为了去掉这个需求。采用的方法是，Open MBean使用通用的数据类型。
管理程序和Open MBeans就可以共享和使用数据和方法，而不需要重新编译，重新组配或者动态链接。所以说，Open MBeans提高了管理系统的灵活性和可扩展性。

当管理程序无法访问agent的java classes的时候，就特别有用。即使管理程序和agent之间的连接不支持java序列化的时候，也是可以访问Open MBeans的。比如说，管理程序不是java开发的。 

d)模型(Model)MBean

  与标准和动态MBean相比，你可以不用写MBean类，只需使用javax.management.modelmbean.RequiredModelMBean即可。

RequiredModelMBean实现了ModelMBean接口，而ModelMBean扩展了DynamicMBean接口，因此与DynamicMBean相似，Model MBean的管理资源也是在运行时定义的。与DynamicMBean不同的是，DynamicMBean管理的资源一般定义在DynamicMBean中（运行时才决定管理那些资源），而model MBean管理的资源并不在MBean中，而是在外部（通常是一个类），只有在运行时，才通过set方法将其加入到model MBean中。Model MBean可以在MBean server中进行实例化,而且用户可以配置它来管理任何资源。

Model MBean可以被任何JMX兼容的agent来创建, 这是个很大的优势. 有很多特性:

• 持久化

通过使用它的持久化机制, Model MBean可以在它所在的JMX agent的生命周期中得到存活. 每当一个Model MBean被创建的时候,它会检查判断是否从指定的位置加载了状态. 当配置一个Model MBean,你可以设置保存自身状态的间隔时间.
这个持久化机制实现是在sun的参考实现中提供的, 通过java的对象序列化功能来把当前ModelMBeanInfo对象的状态写到一个文件中的. 当然其他比如jdbc的持久化机制也是可以实现的.

• 通知记录 Notification logging

这个特性允许Model MBean有能力对自己每个发出的通知进行记录. 当你需要对管理信息进行审计跟踪的时候,这个记录就很用.

• 属性值缓存

Model MBean拥有的ModelMBeanInfo对象规定了属性缓存的策略.
  比如说,策略可以这样规定,当一个属性第一次被获取的时候,可以保存在本地,下一次的访问需求可以用本地的缓存来满足. 本地的缓存值多长时间被重新更新,这个间隔时间是缓存策略规定, 用户可以来设置。
  这个能力极大提高了程序的性能. 例如,Model MBean如果管理的是一个远程资源,它就可以把属性值保存在本地,这样就避免了重复地进行远程调用来获取属性的值.

• 操作代理

Model MBean可以调用一个对象的接口方法,而不是直接调用被管理资源的接口.这个能力就可以让你提供方法来管理多个资源, 比如EJB, java远程对象, 或者其他对象的引用.

• 一般通知

Model MBean提供方法来发出一般的纯信息的通知.    

5.JMX消息模型 

Notification(消息)被用来特指JMX 应用中的事件。JMX消息模型所描述的是MBean之间交换信息的机制。JMX消息模型包括消息播发器、JMX消息、侦听器(Listener)和过滤器等对象。JMX消息经过过滤器的筛选，由消息播发器发送给消息侦听器。JMX消息模型如图3所示。

   消息播发器和侦听器可以是任意对象，只要它们实现了相应的接口，MBean和MBean服务器都可以充当消息播发器或侦听器的角色。侦听器需支持NotificationListener接口，这个接口定义了事件被触发时侦听器所要完成的操作。消息播发器则要求维护一个所要通知的消息侦听器的列表，它通常实现了接口 NotificationBroadcaster或NotificationEmitter。过滤器须实现NotificationFilter 接口，并通过实现接口中的方法isNotificationEnabled(Notification notification)来决定过滤哪些消息。

 

图3 JMX消息模型 

  JMX消息是Notification类或其子类的实例，它封装了播发器所要通知侦听器的内容和相关信息，参见表1。

定义了五种类型的通知对象，对象中包含了与特定通知类型相关的信息：

MBeanServerNotification：MBeanServer用于通知MBean的监听程序进行注册或取消注册。

AttributeChangeNotification：当一个属性值改变时，MBeans用于通知监听程序。

MonitorNotification：当满足一组特定条件时，由监视服务发出。

RelationNotification：当一个关系被增加、修改或删除时，由关系服务发出。

TimerNotification：当定时程序计时时间到时，由定时程序服务发出。 

属  性	说  明
Source	消息播发器的实例引用
message	对Notification的说明
SequenceNumber	Notification实例的唯一标识
TimeStamp	时间戳。Notification何时生成
Type	用点标注法表示的JMX消息类型。比如JMX.MBean.registered
UserData	具体的要传达的信息

代理层：

1.MBean服务器

MBean服务器位于JMX的3层架构中的代理层，它是代理层的核心，负责完成代理层的主要功能。

  MBean服务器管理着MBean的生命周期，即注册和注销，并向MBean提供各类服务，包括动态加载 (Advanced Dynamic Loading)服务、监视(Monitor)服务、定时器(Timer)服务和关联(Relation)服务。

  MBean服务器和它所代理的MBean所驻留的 Java虚拟机被称作代理端(Agent Side)，而管理应用所驻留的Java虚拟机被称作管理端(Manage Side)。管理端对代理端的访问多为远程访问，而MBean服务器对其代理的MBean的访问都是本地访问。  

a)Object Name  

Object Name是MBean的唯一标识，它在MBean向MBean服务器中注册时指定。管理应用可以通过这个标识来寻址MBean。Object Name体现了MBean服务器关于MBean的命名机制，这一机制是管理应用和MBean之间实现松耦合的关键。Object Name的语法如下：

 [domainName]:property=value[,property=value]*

  可以看到，Object Name由两部分组成：域名和一组关键属性，具体说明如下。

• 域名(Domain Name)

  关于域名的命名和Java包的约定一致，即“反向的DNS名 + 组织自定义的字串”。比如由网秦公司开发的MBean，其DNS名是netqin.com，则其域名格式是com.netqin.MyDomain。

• 关键属性(Key Properties)

  关键属性是一些Key-value对，通过它们可以为MBean在指定的域中添加包括名字、类型和说明等属性，但这些属性可以不是MBean的实际属性。

几个Object Name的实例：

  MyDomain:description=Printer,type=laser

  DefaultDomain:description=Disk,capacity=1 

b)协议适配器和连接器 

MBean服务器依赖于协议适配器和连接器来和运行该代理的Java虚拟机之外的管理应用程序进行通信。协议适配器通过特定的协议提供了一张注册在MBean服务器的管理构件的视图。例如，一个HTML适配器可以将所有注册过的管理构件显示在Web 页面上。不同的协议，提供不同的视图。

连接器还必须提供管理应用一方的接口以使代理和管理应用程序进行通信，即针对不同的协议，连接器必须提供同样的远程接口来封装通信过程。当远程应用程序使用这个接口时，就可以通过网络透明的和代理进行交互，而忽略协议本身。

适配器和连接器使MBean服务器与管理应用程序能进行通信。因此，一个代理要被管理，它必须提供至少一个协议适配器或者连接器。面临多种管理应用时，代理可以包含各种不同的协议适配器和连接器。

当前已经实现和将要实现的协议适配器和连接器包括：

RMI连接器

SNMP协议适配器

IIOP协议适配器：Internet Inter-ORB Protocol(互联网内部对象请求代理协议)，它是一个用于CORBA 2.0及兼容平台上的协议

HTML协议适配器

HTTP连接器 

c)代理服务(Agent Service)  

MBean服务器提供给注册MBean的服务被称作JMX代理服务，它们本身也被封装成MBean的形式。代理服务位于JMX架构中的代理层。

   代理服务主要包括四类：动态加载(Advanced Dynamic Loading)服务、监视(Monitor)服务、定时器(Timer)服务、关联(Relation)服务。

1)动态加载服务

动态类装载是通过m-let（management applet）服务来实现的，它可以从网络上的任何URL处下载并实例化管理构件，然后向MBean服务器注册。在一个M-let服务过程中，首先是下载一个m-let文本文件，该文件是XML格式的文件，文件的内容标识了管理构件的所有信息，比如构件名称、在MBean服务器中唯一标识该构件的对象名等。然后根据这个文件的内容，创建并注册该文件中所指定的每个 MBean 的实例。 

2)监视服务  

监视MBean的属性变化，当属性值的变化超出预定义的范围时，相应地发出通知。根据所监视的属性，JMX定义了三类监视器。

计数器监视器(Counter Monitor)：监视整型(Integer)类型的属性值，当数值变更幅度超出预设时触发事件。可以指定一个偏移量 值。当被观察值超过其阈值时，该阈值应按偏移量递增，或者按偏移量的倍数递增，以使其阈值足大于新的被观察值。

度量监视器(Gauge Monitor)：监视整型(Integer)或浮点类型(Floating)的属性值，当数值超出预设的上限或下限时触发事件。

字符串监视器(String Monitor)：监视字符串(String)类型的属性值，当字符串变更时触发事件。

   根据粒度周期指定的区间监视 observed 属性

每当派生的测量值的值超过配置阈值，Monitor MBean就产生一个JMX通知。这些通知使用一个MonitorNotification类的实例发送，该类是Notification类的子类。该类包含诸如通知类型、被观测的MBean名字、被观测的属性名字、派生的测量值以及触发通知的阈值。与正在使用的监视程序类型相关的监视程序的通知类型有：

jmx.monitor.counter.threshold：当CounterMonitor的派生的测量值达到或超过配置阈值时，产生该通知 。

jmx.monitor.gauge.high：当GaugeMonitor的派生的测量值达到或超过配置阈值上限时，产生该通知 。

jmx.monitor.gauge.low：当GaugeMonitor的派生的测量值减少到或低于配置阈值下限时，产生该通知 。

jmx.monitor.string.matches：当StringMonitor的派生的测量值第一次与所比较的配置字符串匹配时，产生该通知  。

jmx.monitor.string.differs：当StringMonitor的派生的测量值第一次与所比较的配置字符串不相同时，产生该通知 。

   当遇到特定的出错条件时，也会产生通知。错误类型的常见集合为：

   jmx.monitor.error.mbean：当被观测的MBeans之一未在MBean服务器上注册时，产生该通知。

    jmx.monitor.error.attribute：当被观测的属性在某个MBeans中不存在时，产生该通知 。

    jmx.monitor.error.type：当被观测的属性值是null或属性类型与正在使用的监视程序类型不匹配时，产生该通知 。

    jmx.monitor.error.runtime：当获取被观测属性值的过程中遇到其它错误时，产生该通知 。

    jmx.monitor.error.threshold：当配置的阈值参数与被观测属性类型不相同时，计数器监视程序或测量值监视程序产生该通知 。  

3)定时器服务 

时间服务可以在制定的时间和日期发出通告，也可以定期的周期性的发出通告，依赖于管理应用程序的配置。时间服务也是一个管理构件，它能帮助管理应用程序建立一个可配置的备忘录，从而实现智能管理服务。

  JMX Timer服务以两种不同的方式产生通知：

只产生一次的通知 。

在一段给定的时间内或给定的发生次数内于定期间隔发生的重复的通知。

与监视程序MBean类似，Timer MBean在MBeanServer上创建，并进行配置以产生这些定时通知。Timer MBean产生的通知使用TimerNotification类的实例进行发送。若要创建通知，可以使用Timer MBean的addNotification()方法，该方法需要以下的一些或全部参数：

type：用于表示通知类型的字符串 。

message：用于发送关于通知的详细信息的字符串。

  userData：可选的回传对象 。

  date：用于指定通知应当何时发生的日期类 。

  period：通知之间以毫秒为单位的时间间隔（0或null表示无重复的通知） 。

  nbOccurences：通知将要发生的总次数（0或null意味着，如果周期是0或null则该通知无限次地重复）。 

4)关系服务 

JMX规范定义了管理构件之间的关系模型。一个关系是用户定义的管理构件之间的N维联系。

   关系模型定义如下一些术语：

角色：就是是一个关系中的一类成员身份，它含有一个角色值。

角色信息：描述一个关系中的一个角色。

关系类型：由角色信息组成，作为创建和维持关系的模板。

关系：管理构件之间的当前联系，且必须满足一个关系类型的要求。

角色值：在一个关系中当前能满足给定角色的管理构件的列表。

关系服务：是一个管理构件，能接触和维持所有关系类型和关系实例之间的一致性。

  在关系服务中，管理构件之间的关系由通过关系类型确定的关系实例来维护。仅仅只有注册到MBean服务器上并且能被对象名标识的管理构件才能成为一个关系的成员。关系服务从来就不直接操作它的成员--管理构件，为了方便查找它仅仅提供了对象名。

关系服务能锁定不合理关系类型的创建，同样，不合理的关系的创建也会被锁定。角色值的修正也要遵守一致性检查。

由于关系是定义在注册的管理构件之间的联系，所以当其中的管理构件卸载时，就会更改关系。关系服务会自动更改角色值。所有对关系实例的操作比如创建、更新、删除等都会使关系服务发出通告，通告会提供有关这次操作的信息。

JMX关系模型只能保证所有的管理构件满足它的设计角色，也就是说，不允许一个管理构件同时出现在许多关系中。  

       分布式服务层：

        当前，SUN并没有给出这一层的具体规范，下面给出的只是一个简要描述。

该层规定了实现JMX应用管理平台的接口。这一层定义了能对代理层进行操作的管理接口和组件。这些组件能：

• l为管理应用程序提供一个接口，以便它通过一个连接器能透明和代理层或者JMX管理资源进行交互。
• 通过各种协议的映射（如SNMP、HTML等），提供了一个JMX代理和所有可管理组件的视图。
• 分布管理信息，以便构造一个分布式系统，也就是将高层管理平台的管理信息向其下众多的JMX代理发布。
• 收集多个JMX 代理端的管理信息并根据管理终端用户的需要筛选用户感兴趣的信息并形成逻辑视图送给相应的终端用户。
• 提供了安全保证。
• 通过管理应用层和另一管理代理和以及他的设备层的联合，就可以为我们提供一个完整的网络管理的解决方案。这个解决方案为我们带来了独一无二的一些优点：轻便、根据需要部署、动态服务、还有安全性。

 ref:http://www.cnblogs.com/sundaweixy/archive/2012/02/22/2363927.html