分布式系统监控:通过JMX看对象模型的优势

在Java的圈子里面,任何一个技术产品,一般会先公开一系列的接口定义,然后推出对这个接口的一系列实现软件,这种做法,是一个对软件开发非常有益的进步。因为这让使用这些的程序员,仅仅学习一份接口的定义,就能完成自己想要的功能,至于选择不同的实现软件,完全无需修改代码。比如JDK中的java.sql.*,就让JAVA程序员无需去学习各家SQL数据不同的API写法;javax.servlet.*规定了JAVA的Web应用程序的使用接口,使用者可以按照这个接口编写程序,在Apache Tomcat、Caucho Resin、Weblogic、甚至是Google App Engine上无需修改的运行。同样,JMX也是这样的一种技术,他带有一系列的编程接口定义,以及在JDK中实现的一套运行代码。

那么,JMX到底是什么东西呢?它其实是Java Management eXtensions的缩写。大家在运营实际项目的过程中,特别是服务器端项目,往往都会有这种经验:盯着自己写的那个 Java进程,心里在想,它到底在什么?为什么用了这么长的时间?于是我们常常会想用JDK自带的诊断工具jmap或者jstack来一探究竟,但是又很担心影响性能。所以那些有经验的程序员,在编写程序的时候,往往会预先嵌入一些程序,专门用来反馈程序的运行状态。这些后门有时候简单的只是打一下日志,又有时候会是一些不断统计的运行时数据,比如在线连接数、请求的平均消耗时长……。但是这些代码,不同的程序员有不同的做法,记录的数据也是五花八门,由于这些功能实际上往往缺乏文档(这些基本上是技术需求,少有产品人员参与),如果要交接给其他程序员,一般都很难掌握。因此就时常会出现这种情况,一个程序出问题,当前的维护人员查了半天没找出原因,找来原作者后,他翻了翻日志就发现了原因。这种事情的原因就是,我们的系统对于“监控”功能缺乏规划,没有规范或者框架所导致的。而JMX,正是一套用于监控JAVA程序运行时状况的规范。

很多时候我们查看监控数据,都是在简陋的字符命令行界面查询日志,但是如果我们使用了JMX就不同了,按这个规范编写的监控数据,能很简单的通过网络传递,并绘制到图形程序上,甚至JDK就自带了一个这样的监控界面程序:jconsole。我们在大型的分布式系统运营的时候,不可能一个个服务器去查看监控数据,一般都需要通过网络把监控数据集中处理,通过图形来显示。有很多系统都是程序员自己去预埋监控代码、编写监控数据的网络收发模块,然后再编写运维监控的集中处理界面。这种监控在不同的应用里面,往往各自都有一套,实际上这些代码中,有很多功能是重复的。JMX为这种通过网络搜集监控数据的功能,提供了一套良好的接口定义和底层网络实现。

我们在运营一些游戏服务器、聊天服务器这类在线服务系统的时候,往往需要对这些在线服务进程发送一些特殊命令,比如踢某个用户下线、封某个IP禁止访问,或者其他很多业务相关的功能。然而,在Linux下,对于运行时进程进行控制的手段,是非常有限的,比较常用的有发送信号,预埋共享内存消息队列服务,通过socket通信端口插入特殊控制包这几种。然而,信号的个数有限,单独使用能表达的含义太少;使用共享内存、socket来对进程控制,编程复杂度又大大的提升。所以很多游戏服务器开发团队,都会开发一个叫GM系统的后门系统,提供给客服或运营人员使用,用socket或者共享内存发送“管理命令”到目标进程,执行预定的管理逻辑。不过如果你开发了多个这样的系统,可能你会对反复的写GM系统非常厌烦。能不能有一种更通用而简单的方法,来写这种“后门”系统呢?JMX正是这样的一种框架:它不但可以用来输出监控数据,还可以作为操作的入口,对运行中的程序执行各种自定义的逻辑命令。

上面说了很多JMX的功能,其实核心只有三个:数据监视、控制命令、网络传输。一个需要展示的数据,会通过:数据搜集代码、网络传输代码、显示绘制代码三个部分。一个需要产生操作的控制命令,会通过:显示预设命令操作并绘制面板界面、网络命令传输、预设命令执行三个部分。因此JMX对这三个层次的功能,进行了定义和实现:

  1. Resources层,这部分包含了一系列JavaInterface定义,用户按照这些接口编写的代码,就能成为JMX资源,嵌入到JAVA进程中,随时提供服务
  2. JMX核心层,这部分是JDK实现的代码,它为Resources接口的实现者对象,提供注册、发现、远程调用的功能,同时也包含了网络传输的功能。
  3. Management System层,这一层主要是用户自己编写的监控程序。由于JDK提供了JMX的实现,因此JAVA程序能很方便的通过“JMX核心”对“Resources层”的对象通过网络操作,比如读取这些对象的属性、执行某些预定的方法。

在JMX中,Resources对象被称为MBean对象,这种对象需要符合MBean的一些形式。而JMX核心由两个子层次实现:AgentLevel代理层,由JDK中的MBean Server类实现,主要提供对MBean的各种管理;Connector Level连接层,主要负责网络部分功能,实现一个MBean对象在网络上传输。这部分JDK实现了一些,比如RMI Adapter使用的是JAVA RMI的远程调用连接,又或者HTTP Adapter使用标准HTTML协议传递MBean对象。但是也可以通过继承Connector的接口自己实现,比如你可以建立SNMP协议的Adapter,或者用UDP协议来传输……。MBean对象、MBean Server、各种Connector Adapter,都是在一个JAVA Server进程中运行,在此之外,我们针对各种Adapter,编写各种通过网络来操控MBean的监控界面程序,这些程序统称为Remote Manager程序,其中有JDK提供的标准JMX Manager程序,这个程序使用的JDK自带的RMI Adapter;也可以直接使用Web浏览器访问HTTP Adapter提供的数据等等。

JMX的核心接口是MBean形式,。由于Java有反射的能力,所以编写MBean无需继承任何预定的接口,而仅仅是要符合几个约定即可:

  • 接口名字以MBean结尾
  • 属性符合JavaBean规范,带getter或者setter方法
  • 方法是publicvoid的

只要一个Interface符合以上的约定,其实现者对象,就能成为一个MBean对象,被MBean Server所接受,其中带getter/setter方法会被认为是用以监视、修改的变量属性,而public void的方法则可以被直接远程调用以产生控制命令。MBean对象可以是任何功能的代码,比如这个对象中包含了对在线用户的统计数据,对恶意用户的踢下线、封IP功能等等……

一旦我们编写好一个MBean接口和它的实现类,我们就能在任意的Java进程中插入代码,向MBeanServer注册这个MBean对象,注意注册时可以输入一个字符串作为这个对象的“名字”,MBeanServer可以利用这个“名字”在显示界面(Remote Manager)程序那里,用来做筛选、树状显示、标签等任何功能。比如JDK自带的JMX Manager就使用形式如:”myapp:type=webserver, name=Port 8080”的字符串,用来展示myapp/webserver/Port8080的树状对象。

JDK自带的 JConsole软件,能连接到任何一个本地的JAVA进程或远程网络JAVA进程。我们能看到你注册的MBean的对象,以及好多JDK自己注册的MBean对象。这些对象以ObjectName字符串的“名字:type=…, name=…”的格式放在树里面供检索。任何一个对象都可以在Attribute页对其属性进行读写,对于方法还可以在Operations页进行按钮操作。

JMX协议,对于被管理的“后门对象”而言,就是一个接口的约定形式——MBean形式。这个形式非常简单,只有三条规则,很容易实现。这个接口的三类约定方法,最后会被塑造成三种监控行为接口:属性(读、写);调用;监听(这个刚才的例子没有提及)。然而,如果你已经写了一大堆监控代码,回头想接入到MBean这个规范里面,JMX也贴心的提供了方案:DynamicMBean接口。你的监控代码需要实现这个接口,然后通过Object getAttribute(String attribute) 这个方法返回你所有的属性对象;通过MBeanInfogetMBeanInfo()返回对于这个监控对象的MBean信息,比如名字什么的。

当然我们不可能仅仅靠JConsole就能管理任何的服务进程,所以我们常常要自己编写很多RemoteManager系统。我们可以通过实现一系列“Manager接口”来实现:

  • JMXServiceURL –支持多种协议的JMX连接
  • JMXConnector –实现JMX连接
  • MBeanServerConnection –提供具体MBeanServer
  • NotificationListener –接收MBean的通知和属性变化
  • JMX.newMBeanProxy() –构造一个远程MBean对象的本地代理对象,用以直接操作MBean对象
  • 通过ObjectName来定位:”type=… name=…”
  • 通过MBean接口来调用方法

现在越来越多的软件,都自带了 Web协议的MBeanServer功能,可以直接通过浏览器来做监控,比如Tomcat/JBoss/ZooKeeper等等。现在市场上,也有很多企业,专门利用那些软件中的MBean,编写各种漂亮、好用的MBeanServer/Remote Manager来赚钱。

我们可以对比一下JMX和其他监控系统的思路的差别:

  • 一般监控系统只有对某些数据进行内部采样统计,然后提供读取功能;JMX提供了基于属性的读、写两个能力;同时还有监听器的能力,可以自动一直的搜集采样数据。
  • 一般监控系统使用类似命令行命令的方式进行操控,而JMX提供了基于方法函数的控制操作接口,还有“通知“的模型接口。
  • 一般的监控系统其网络通信协议五花八门,而JMX提供了标准的JAVA RMI实现,同时也可以扩展HTTP和其他任何的协议。
  • 一般的监控系统的操作界面程序,需要专门针对某个业务系统去开发,非常繁琐和重复;而JMX采用反射方法,可以开发通用的监控系统界面,也可以使用叫Proxy的接口,定制专用的界面。

总体来说,JMX所有的功能,都是装载一个标准化的盒子里面。而这个盒子的基础,正是面向对象的思路:

  • 对象具备属性和方法,匹配成监控系统中的“属性”和“操作”
  • 使用Connector接口来集成多种不同的监控通信协议
  • MBean对象约定和Manager接口提供了对监控系统的基本约束,也提供了巨大的自定扩展空间

MBean Server完成了监控系统的主体功能,而各种接口规范了监控系统的细节差别。

因此,以监控系统这种需求多变的业务领域来看,利用面向对象的思想,是能提供非常好的解决方案。即便是我们以前很习惯用Linux命令、信号、脚本这些运维工具来监控服务器系统,现在看到JMX这种高度规范化的监控框架,也应该认真考虑拥抱面向对象的软件思想吧!

由于阿发狗很火,所以最近被交待了在研究关于游戏AI技术的任务,也许往后会和大家分享这方面的新知识,敬请关注。

感谢大家的阅读,如觉得此文对你有那么一丁点的作用,麻烦动动手指转发或分享至朋友圈。如有不同意见,欢迎后台留言探讨。

原文发布于微信公众号 - 韩大(handa1740168)

原文发表时间:2016-04-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏知晓程序

开发微信小程序,看这篇文章就够了 | 官方文档解读

993
来自专栏蛋未明的专栏

myweb框架简单说明

1113
来自专栏跟着阿笨一起玩NET

原创C# 各种通用类集合 终于出炉了,觉得有用尽管拿去吧

已经开源,欢迎 Fork    https://github.com/chrisyanghua/MyHelper.git

322
来自专栏小古哥的博客园

网站性能优化概要

一、复用(维护性、开发成本) 1、前端复用   a:文件复用:Js、css、Html、媒体文件等   b:模块复用:通过js来维护一个整体模块,包括动态引入cs...

1943
来自专栏杨建荣的学习笔记

迁移式升级的新方案测试 (r10笔记第30天)

之前写了一篇文章分析了目前存在的一个问题和改进思路。迁移式升级的一点思考 (r10笔记第27天) 当前的硬件环境是Solaris,Oracle 10gR2 单实...

3013
来自专栏Elasticsearch实验室

基于Elastic Stack搭建日志分析平台

(本次课程是通过小程序对外推广的,所以PPT是竖版的。电脑端浏览体验可能不太好,望大家见谅)

1532
来自专栏xiaoheike

多个DispatcherServlet有什么用处.md

有看到一些应用在 web.xml 文件中配置了多个 DispatcherServlet,例如:

693
来自专栏码农阿宇

ElasticSearch入门 附.Net Core例子

Elasticsearch是基于Lucene的搜索引擎。它提供了一个分布式,支持多租户的全文搜索引擎,它具有HTTP Web界面和无模式JSON文档。 Elas...

261
来自专栏菜鸟致敬

【Lua菜鸟①】初识Lua

简介 Lua 是一种轻量小巧的脚本语言,用标准C语言编写并以源代码形式开放, 其设计目的是为了嵌入应用程序中,从而为应用程序提供灵活的扩展和定制功能。 特性 轻...

3559
来自专栏java一日一条

一篇文章了解RPC框架原理

RPC(Remote Procedure Call)–远程过程调用,通过网络通信调用不同的服务,共同支撑一个软件系统,微服务实现的基石技术。使用RPC可以解耦系...

694

扫描关注云+社区