论文部分内容阅读
摘要: 阐述基于JAVA语言的可扩展插件监控平台,定义监控数据采集的个性化插件,以及基于动态数据分析和动态加载的监控数据展现的插件,利用标准化的监控数据结构和自定义的远程协议,实现可热部署的监控数据采集插件和可热部署的监控数据分析和采集插件,组成一套监控数据分析和报表展现平台。
关键词: 插件;分布式;监控;热部署
0 引言
如今的应用都是部署在集群环境中的,但是集群中各台服务器的负载情况,对使用者来说往往都是盲点,只有在服务器宕机,服务不可用或者服务响应慢等异常情况出现时,才会被发现,于是大家都纷纷采用各种监控技术,如预先在各台服务器部署脚本,定时运行脚本等方式来获取每台服务器的负载情况,并及时通知给使用者,这种方式的缺点很明显,就是脚本升级是个麻烦的事情,扩展脚本的功能也很困难,又由于服务器部署的应用不同,采集的监控数据不同,就得另行设计一套监控,无法跟机器监控合二为一。于是本文采取一种动态的,可热插拔的,且可自定义的监控平台,为管理大量服务器提供简便,以及提供个性化的监控服务功能。
1 概述
监控平台分为两部分,一部分是数据收集器,另一部分是数据分析和展现平台。
如上模型图所示,左边是数据收集器,右边是数据分析器和数据展现平台,中间是底层运行收集器和数据展现平台的容器,收集器和数据分析与展现平台都是基于插件容器的,插件容器实现了热部署。
数据收集器的作用是,收集各台服务器上的数据项,例如CPU使用情况,内存使用情况等,在该监控系统设计中会默认提供一些数据收集插件,比如当前线程数据、cpu、io、内存等基础数据,使用者也可以依据自己需要,根据约定的接口和数据格式来定义插件并动态增加数据收集插件。数据展现平台的作用是,分析数据收集器收集到的数据,然后展现分析结果,当然分析器是可选的,系统也可以根据用户需要以不同形式展现收集到的数据。
2 插件设计
插件的实现方式有很多种,考虑到实现代码的轻量级以及实现的简易性,选择自定义插件服务;自定义插件必须实现平台统一的插件服务接口,通过自定义的类加载模型动态加载插件,插件可以在应用启动前部署在指定的路径下,或者服务器启动后上传到指定的目录下。应用启动后会运行一个线程,轮询检查指定目录是否有修改,如果有修改就重新加载插件,所以当插件上传后就会被加载到插件容器中。
3 数据收集器设计
收集器部署在业务系统中,作为客户端存在,其包括两部分功能,一部分是采集插件,用来采集服务机器上的监控数据,另一部分是数据推送服务,把采集到的数据推送到数据展现系统。
收集器插件需要实现收集器接口,并且会在数据收集器服务启动时或插件重新加载时被加载到收集器容器中。
收集器服务数据会启动收集数据的线程,该线程中会完成以下几项任务:
1)收集器插件加载线程,用于加载收集器插件以及检查是否需要重新加载。
2)建立一个线程池,让收集器按照优先级定时运行,优先级的排序是按下一次运行时间从近到远排序。
3)建立一个守护线程,判断加载收集器插件的线程和线程池是否正常,若出现异常则重启异常的线程。
4)启动一个线程,定时将收集器采集到的监控数据,推送到监控数据展现平台中。
5)启动一个让服务端心跳检查的服务。
线程池会根据收集器自定义插件的运行周期及执行次数进行定时执行,收集器收集到的数据会被存放到内存中,并定时或定量持久化到本地磁盘,这种内存缓冲的设计是为了减少监控插件的运行对系统正常运行带来的影响。
4 监控数据展现平台设计
当数据被采集并且推送到监控数据展现平台后,会被持久化到数据库中,当监控数据需要展现的时候,才从中取出,从数据被取出到展现前,会经过数据分析器,对数据进行过滤和分析,结果会被传给展现插件,展现插件会把输入的数据包装成报表对象,该对象包含了展现的必要信息,如展现类型:饼图,柱状图,折线图或表格,展现的数据等。
展现插件是一系列的插件,由展现插件容器加载,展现插件容器会在监控数据展现平台启动时加载服务,展现插件容器会启动2个线程:
1)展现插件加载线程,用于加载展现插件和分析器插件以及检查是否需要重新加载。
2)建立一个守护线程,判断展现插件和分析器插件轮询线程是否正常,出现异常则重启该线程。
在加载展现插件的同时加载分析器插件,因为展现插件依赖对应的分析器插件的分析结果。展现层的插件化是为了能够以自定义报表展现,以适应多样的监控数据展现,可以对收集到的同一份数据,自定义产生多份报表。
数据库中的数据,会被监控平台包装成通用的数据源接口,提供统一的查询方法,通过插件名称和时间参数等搜索监控数据。
5 数据分析器设计
数据分析器类似于一个过滤器的管道,跟servlet中的filter很像。当展现一个页面时,会首先指定一个展现插件,展现插件会关联到一个分析器管道,数据就会在这个管道中流转,在管道中,上一个分析器插件的输出是下一个分析器插件的输入,最后的结果会被传送给展现插件。
分析器不能单独动态的增加,只能随着展现插件一起修改或者增加,所以分析器插件的生命周期完全由展现插件决定。
6 服务发现和远程交互
监控数据收集器是部署在集群的各台服务器上的,数据收集器需要知道服务端的地址,才能够把监控数据推送过来。本系统的实现是在数据收集器配置服务端地址,启动成功后通知监控数据展现平台,并注册到展现平台的客户端列表中,监控数据展现平台会定时启动心跳检查,根据客户端列表逐个进行检查。
当收集器和数据展现平台建立好关系后,收集器就可以把监控数据推送到监控数据展现平台。推送的过程涉及到远程服务,远程过程调用的协议有很多,考虑到平台的最小依赖原则,即让使用监控数据收集器的业务平台尽量少的引入间接的包,本系统自定义RPC协议,通过socket服务进行远程交互。
自定义协议包括head和body两个部分,格式如下:
整个数据都会被序列化成byte数据传送到监控数据展现平台,展现平台会把数据反序列化后并持久化。
7 系统展现
8 总结
整个监控平台包括客户端和服务端两部分,客户端是监控数据收集器,部署在需要监控的应用服务中,启动一个独立的线程;服务端是监控数据展现平台,把收集器推送过来的数据持久化并自定义展现。
客户端提供了自定义插件的功能,通过实现相应的插件规范并存放到指定的目录下,即可被动态加载到容器中,容器会根据配置启动插件来收集监控数据。
服务端也同样提供了自定义插件功能,通过选择监控器提供的展现方式来展现数据,展现方式包括平台提供的饼图,折线图,柱状图等类型,展现的数据可以通过自定义数据分析器来进行管道式计算和过滤,使得同样的监控数据展现不同的报表功能。
参考文献:
[1]朱涛江、林剑译,java网络编程,中国电力出版社,2005.11.
[2]Bruce Eckel,Java编程思想,机械工业出版社,2007.4.
[3]林昊、曾宪杰,OSGi原理与最佳实践,电子工业出版社,2009.8.
[4]王辉、张晓辉等译,JavaXML编程指南,电子工业出版社,2001.4.
[5]Allan Vermeulen、ScottW.Ambler等,Java编码规范,人民邮电出版社,2003.7.
关键词: 插件;分布式;监控;热部署
0 引言
如今的应用都是部署在集群环境中的,但是集群中各台服务器的负载情况,对使用者来说往往都是盲点,只有在服务器宕机,服务不可用或者服务响应慢等异常情况出现时,才会被发现,于是大家都纷纷采用各种监控技术,如预先在各台服务器部署脚本,定时运行脚本等方式来获取每台服务器的负载情况,并及时通知给使用者,这种方式的缺点很明显,就是脚本升级是个麻烦的事情,扩展脚本的功能也很困难,又由于服务器部署的应用不同,采集的监控数据不同,就得另行设计一套监控,无法跟机器监控合二为一。于是本文采取一种动态的,可热插拔的,且可自定义的监控平台,为管理大量服务器提供简便,以及提供个性化的监控服务功能。
1 概述
监控平台分为两部分,一部分是数据收集器,另一部分是数据分析和展现平台。
如上模型图所示,左边是数据收集器,右边是数据分析器和数据展现平台,中间是底层运行收集器和数据展现平台的容器,收集器和数据分析与展现平台都是基于插件容器的,插件容器实现了热部署。
数据收集器的作用是,收集各台服务器上的数据项,例如CPU使用情况,内存使用情况等,在该监控系统设计中会默认提供一些数据收集插件,比如当前线程数据、cpu、io、内存等基础数据,使用者也可以依据自己需要,根据约定的接口和数据格式来定义插件并动态增加数据收集插件。数据展现平台的作用是,分析数据收集器收集到的数据,然后展现分析结果,当然分析器是可选的,系统也可以根据用户需要以不同形式展现收集到的数据。
2 插件设计
插件的实现方式有很多种,考虑到实现代码的轻量级以及实现的简易性,选择自定义插件服务;自定义插件必须实现平台统一的插件服务接口,通过自定义的类加载模型动态加载插件,插件可以在应用启动前部署在指定的路径下,或者服务器启动后上传到指定的目录下。应用启动后会运行一个线程,轮询检查指定目录是否有修改,如果有修改就重新加载插件,所以当插件上传后就会被加载到插件容器中。
3 数据收集器设计
收集器部署在业务系统中,作为客户端存在,其包括两部分功能,一部分是采集插件,用来采集服务机器上的监控数据,另一部分是数据推送服务,把采集到的数据推送到数据展现系统。
收集器插件需要实现收集器接口,并且会在数据收集器服务启动时或插件重新加载时被加载到收集器容器中。
收集器服务数据会启动收集数据的线程,该线程中会完成以下几项任务:
1)收集器插件加载线程,用于加载收集器插件以及检查是否需要重新加载。
2)建立一个线程池,让收集器按照优先级定时运行,优先级的排序是按下一次运行时间从近到远排序。
3)建立一个守护线程,判断加载收集器插件的线程和线程池是否正常,若出现异常则重启异常的线程。
4)启动一个线程,定时将收集器采集到的监控数据,推送到监控数据展现平台中。
5)启动一个让服务端心跳检查的服务。
线程池会根据收集器自定义插件的运行周期及执行次数进行定时执行,收集器收集到的数据会被存放到内存中,并定时或定量持久化到本地磁盘,这种内存缓冲的设计是为了减少监控插件的运行对系统正常运行带来的影响。
4 监控数据展现平台设计
当数据被采集并且推送到监控数据展现平台后,会被持久化到数据库中,当监控数据需要展现的时候,才从中取出,从数据被取出到展现前,会经过数据分析器,对数据进行过滤和分析,结果会被传给展现插件,展现插件会把输入的数据包装成报表对象,该对象包含了展现的必要信息,如展现类型:饼图,柱状图,折线图或表格,展现的数据等。
展现插件是一系列的插件,由展现插件容器加载,展现插件容器会在监控数据展现平台启动时加载服务,展现插件容器会启动2个线程:
1)展现插件加载线程,用于加载展现插件和分析器插件以及检查是否需要重新加载。
2)建立一个守护线程,判断展现插件和分析器插件轮询线程是否正常,出现异常则重启该线程。
在加载展现插件的同时加载分析器插件,因为展现插件依赖对应的分析器插件的分析结果。展现层的插件化是为了能够以自定义报表展现,以适应多样的监控数据展现,可以对收集到的同一份数据,自定义产生多份报表。
数据库中的数据,会被监控平台包装成通用的数据源接口,提供统一的查询方法,通过插件名称和时间参数等搜索监控数据。
5 数据分析器设计
数据分析器类似于一个过滤器的管道,跟servlet中的filter很像。当展现一个页面时,会首先指定一个展现插件,展现插件会关联到一个分析器管道,数据就会在这个管道中流转,在管道中,上一个分析器插件的输出是下一个分析器插件的输入,最后的结果会被传送给展现插件。
分析器不能单独动态的增加,只能随着展现插件一起修改或者增加,所以分析器插件的生命周期完全由展现插件决定。
6 服务发现和远程交互
监控数据收集器是部署在集群的各台服务器上的,数据收集器需要知道服务端的地址,才能够把监控数据推送过来。本系统的实现是在数据收集器配置服务端地址,启动成功后通知监控数据展现平台,并注册到展现平台的客户端列表中,监控数据展现平台会定时启动心跳检查,根据客户端列表逐个进行检查。
当收集器和数据展现平台建立好关系后,收集器就可以把监控数据推送到监控数据展现平台。推送的过程涉及到远程服务,远程过程调用的协议有很多,考虑到平台的最小依赖原则,即让使用监控数据收集器的业务平台尽量少的引入间接的包,本系统自定义RPC协议,通过socket服务进行远程交互。
自定义协议包括head和body两个部分,格式如下:
整个数据都会被序列化成byte数据传送到监控数据展现平台,展现平台会把数据反序列化后并持久化。
7 系统展现
8 总结
整个监控平台包括客户端和服务端两部分,客户端是监控数据收集器,部署在需要监控的应用服务中,启动一个独立的线程;服务端是监控数据展现平台,把收集器推送过来的数据持久化并自定义展现。
客户端提供了自定义插件的功能,通过实现相应的插件规范并存放到指定的目录下,即可被动态加载到容器中,容器会根据配置启动插件来收集监控数据。
服务端也同样提供了自定义插件功能,通过选择监控器提供的展现方式来展现数据,展现方式包括平台提供的饼图,折线图,柱状图等类型,展现的数据可以通过自定义数据分析器来进行管道式计算和过滤,使得同样的监控数据展现不同的报表功能。
参考文献:
[1]朱涛江、林剑译,java网络编程,中国电力出版社,2005.11.
[2]Bruce Eckel,Java编程思想,机械工业出版社,2007.4.
[3]林昊、曾宪杰,OSGi原理与最佳实践,电子工业出版社,2009.8.
[4]王辉、张晓辉等译,JavaXML编程指南,电子工业出版社,2001.4.
[5]Allan Vermeulen、ScottW.Ambler等,Java编码规范,人民邮电出版社,2003.7.