可扩展集成化云平台监控机制的设计

　　1 引 言

　　过去几年，随着云计算技术的不断发展，对于云平台监控的需求越来越迫切. 作为云计算数据中心的运维人员，需要随时关注服务器的性能指标，避免服务器性能降低甚至当机的风险.。通过云平台资源的特点，可以知道云平台监控的主要难点集中在被监控的资源的多样性、动态性及规模巨大这几个方面:

　　1) 资源的多样性—云平台上的资源是多种多样的，从操作系统上分，包括 windows，linux，unix 等不同的操作平台; 从系统架构上分，包括如 cpu、内存、硬盘等底层的硬件; 还包括如 mysql 数据库、apache 等各种应用程序和服务. 如何将这些复杂的资源进行抽象分类，从而简化监控任务，是云平台监控的一个重大挑战.

　　2) 资源的动态性—云平台上的资源不是固定不变的，云平台的节点可以动态的增加或减少，云平台上的应用及服务也可以动态的安装或卸载. 如何让云平台监控动态适应云平台变化，是云平台监控一个重大挑战.

　　3) 资源的规模巨大—云平台往往包括成千上万计算节点，而每个节点上运行着各种应用软件和服务，造成云平台资源规模巨大，这就给监控系统带来很大的负担，同时影响云平台的性能. 如何提供一种对云平台影响较小，且监控效率较高的系统，是云平台监控的一个重大挑战.单一的监控软件往往无法满足云平台被监控资源的动态性、多样性以及资源规模巨大的需求. 为全面监控云平台资源，往往需要安装多种监控软件，在查询时需频繁切换不同软件，不利于实时监控，同时增加了运维人员的工作量. 文献[2]提出一种基于 Ganglia 与 MDS 结合的网格监控体系研究，但该体系不具备可扩展接口，当现有软件需要升级或需要增加新的监控软件时，只能通过手工修改代码来完成. 针对上述问题，提出一种可扩展集成化云平台监控机制，可以灵活集成多种监控软件，以满足对云平台资源的监控需求，并有效减轻运维人员的工作压力，提高工作效率.

　　2 相关工作

　　随着云平台的发展，人们越来越关注云平台上资源的运行和使用情况，以满足云平台监控使用者及时掌握云平台的运行状态，因此，对云平台监控的研究也逐渐发展起来. 下面从学术界和工业界两方面讨论云平台监控的相关工作.学术研究方面，在云计算技术发展之前，集群技术以其高性价比、易于扩充与易于裁减等诸多优点已经成为高性能计算常见的解决方案，对集群监控的研究也逐渐受到研究人员的重视. 随后对网格计算的研究，研究人员针对于网格环境中的监控问题做了大量的研究工作，. 集成化云平台监控机制针对在云平台监控中遇到的被监控的资源的动态性、多样性及规模巨大等难题，提出了一种可扩展集成化云平台监控机制，下面将从监控系统框架、监控模型和监控软件集成方法三个方面进行介绍.

　　3. 1 监控系统框架

　　我们提出一种可扩展集成化云平台监控体制，可以在云平台监控系统的底层动态的增加监控软件，以适应云平台资源的多样性和动态性的特点，这些操作对于使用者来说是透明的. 图 1 是监控系统框架图，将从云平台资源、监控数据的提取及存储、监控服务这三个方面介绍系统的框架.

　　3. 1. 1 云平台资源根据云平台资源的特点，可以知道云平台被监控节点具有多样性，根据不同的划分方法对被监控节点进行分类，具体分类如下:

　　1) 操作系统不同—根据操作系统的不同分类可以将监控节点分为 window 系统监控节点和类 linux 系统监控节点.2) 应用和服务不同—由于被监控节点上运行着不同的应用程序及服务，如对 mysql 数据库、apache 等应用服务以及hadoop 分布式框架进行监控，不同的监控软件对于服务和程序的支持不同.

　　3. 1. 2 监控数据的提取及存储首先对监控数据的完整性进行定义: 监控数据的完整性是指对监控软件的数据进行即时保存，并保证对所有的监控数据进行准确保存，而不淘汰任何老数据.一般情况下，监控软件会将监控数据存放在监控服务端的 RRD 数据库中，RRD 数据库最大的特点是以循环格式来存储数据，在持续插入新数据的过程中不断淘汰老数据，因此RRD 文件大小保持在一定的范围内. 这样不利于监控数据的完整保存，所以需要采用一定的方法将监控数据存储到可保证数据完整性的数据库( 如 mysql，mongodb 等) 中，并进行持久存储.

　　1) 读取特定端口取数据—被监控的节点将监控数据通过特定的端口传输到服务节点，按照一定的时间间隔去读该端口并获取 xml 数据，然后利用解析工具取得监控数据，最终存入可保证数据完整性的数据库.2) 通过脚本转存数据—对于不易通过端口获取数据的监控软件，则需要通过执行 python 或 shell 脚本将监控数据从RRD 数据库转存到可保证数据完整性的数据库中，相比于上一种方法，这种转存方式效率较低，实时性较差.

　　3. 1. 3 监控服务在介绍监控服务之前首先要明确监控服务的使用者，使用者定义如下:

　　监控服务的使用者主要包括运维人员以及最终使用者.运维人员是需持续关注云平台资源的使用情况，并根据监控数据进行作业调度，任务迁移等操作的相关人员，另外运维人员还负责添加监控软件，并进行相应配置. 最终使用者是指需要查看云平台资源的状态，以及需要关注特定资源使用情况的相关人员.基于监控数据完整性保存模块，云平台监控系统提供了配置引擎、查询引擎、统计引擎和报警引擎四种功能引擎，并向上提供相应的功能接口.1) 配置引擎: 当现有的监控系统无法满足着云平台资源的监控需求时，则可部署新的满足条件的监控软件，并通过配置引擎建立或修改监控软件指标集与监控类属性集间的映射关系.2) 查询引擎: 系统默认向用户提供给定时间段的查询;另外系统还提供用户自己定义时间段，监控系统通过一定的算法实现在这个时间段内的监控状态查询.3) 统计引擎: 系统向用户提供了监控集群以及自定义子监控集群整体负载的统计.4) 报警引擎: 系统向用户提供系统设定阈值的报警，也提供用户自定义指标的监控报警.

　　3. 2 监控模型

　　定义 1. 监控模型. 可扩展集成化的云平台监控模型可以定义为一个三元组: MM = ( MC，MS，MR) ，其中:1) MC 表示监控类，监控类可定义为一个二元组: MC =( ON，OP) ，其中:( a) ON 表示监控类的名称( b) OP 表示监控类的属性集2) MS 表示监控软件，监控软件可定义为一个二元组:MS = ( SN，SV) ，其中:( a) SN 表示监控软件的名称( b) SV 表示软件监控的指标集3) MR 表示映射关系，定义如下:

　　设 mc 是集合 MC 中一个监控类，对于p1 ∈mc. OP，ms∈MS，v∈ms. SV，mr∈MR，满足 mr( p1) = v，且对于p2∈mc. OP，p1≠p2，满足 mr( p2) ≠v.定义 2. 监控对象 MO = ( ON，OP，OV，OT，MN) ，其中:

　　( a) ON 表示监控类的名称( b) OP 表示监控类的属性集( c) OV 表示监控对象的属性值( d) MT 表示取得监控数据的时间( e) MN 表示监控数据属于哪个节点定义 3. 监控类实例化. 设 mc 为集合 MC 中一个监控类，mo 为集合 MO 中一个监控对象，对于p1∈mc. OP，p2∈mo. OP，且 p1 = p2，对于p3∈mo. OP，p4∈mc. OP，且 p3= p4，则可称 mo 是 mc 的实例化，记为 mo≤mmc.定理1. 如果某个监控类的属性与某监控软件的指标之间存在映射关系，且一个监控对象是这个监控类的实例化，则这个监控对象的属性与该监控软件的指标之间存在映射关系.证明: 设 mc 为集合 MC 中一个监控类，mo 为集合 MO 中一个监控对象，根据定义 3，mo≤mmc，对于 p1 ∈ mo. OP，p2∈mc. OP，则 p1 = p2，又根据定义1，v∈ms. SV，ms∈MS，满足 mr( p2) = v，所以 mr( p1) = v; 又根据定义 3，p3∈mo. OP，且 p1≠p3，p4 ∈mc. OP，则 p3 = p4，p1 ≠p4 ，p2 ≠p4. 根据定义 1，mr( p4) ≠v，所以 mr( p3) ≠v.通过定义抽象的监控类以及监控类和监控对象之间的实例化关系，使运维人员只需对监控类属性和监控软件指标之间的映射关系进行配置，不需要配置每个监控对象属性与监控软件指标之间的映射关系. 定义了监控类实例化后，可以根据实例化关系自动生成监控对象与监控软件之间的映射关系，大大减少了运维人员的工作量，也保证了映射关系的准确性.

　　3. 3 监控软件集成方法

　　对于云平台来说，决不能假设它是一成不变的，对于云平台资源的动态变化或资源出现故障的情况，需要云平台能及时采取措施，做到对高层用户透明或者尽可能减少用户的损失. 当现有的监控系统无法满足云平台资源的动态增加而产生有些监控指标监控不到的时候，则需要考虑集成新的监控软件，结合使用多种监控软件对云平台资源进行监控.添加新的监控软件时，首先将要增加的软件注册并部署到云平台，在软件集合 MS 中增加 ms. 通过配置引擎建立或修改监控类属性集 OP 与 ms 指标集 SV 间的映射关系 mr. 对于原监控软件监控不到，而新增加的软件可提供的指标项，直接增加新的软件的指标项; 对于原软件与新软件都可提供的指标项，可以从监控数据的实时性和准确性等角度综合考虑是否要调整原有的映射关系. 映射关系确定后，可推导得到监控对象的属性与监控软件指标集里的元素形成的一对一映射关系. 监控数据提取模块将根据新的映射关系提取监控数据，完成监控软件的集成. 监控数据存放在保证监控数据完整性的存储模块，用来向上层提供业务服务.

　　通过上述对集成化的云平台监控机制的论述可表明，该机制的创新性主要体现在可以灵活的增加、删除多种监控软件，运维人员只需对监控类属性和监控软件指标之间的映射关系进行配置，继而根据监控对象的实例化关系自动生成监控对象与监控软件之间的映射关系，提高了监控软件接入效率，也保证了映射关系的准确性. 该机制还可将监控数据提取到可保证数据完整性的数据库中进行持久存储，以及封装成相应的接口，以方便运维人员更好的对云平台进行监控管理.

　　4 实验及分析

　　4. 1 实验环境设置

　　为了验证这种可扩展集成化的云平台监控机制是否适应云平台的资源的多样性、动态性及规模巨大的特点，我们搭建了一个云平台监控实验系统.该实验选择 4 台服务器组成小型集群，其中一台 win-dow s server 08 的服务器，三台 centos 5. 7 的服务器，软件采用Ganglia-3. 1. 7，Cacti-0. 8. 8a. 硬件环境均为 2G 内存，20G 硬盘. 一台 centos 的服务器作为监控头结点，剩余三台服务器作为实验系统的代理节点. 通过数据完整性提取方法将监控数据存到 mysql 数据库中，并向使用者提供业务服务，实验系统物理部署如图 3 所示，其中.1) 代理节点 a: w indow s 服务器，开启了 snmp 服务.2) 代理节点 b: Linux 服务器，开启了 snmp 服务，且部署了 hadoop 分布式框架.3) 代理节点 c: Linux 服务器，开启了 snmp 服务，且安装了 mysql 数据库服务.

　　4. 2 实验结果与分析

　　实验环境配置完成后，需要代理节点 b 上的 hadoop 框架进行监控，而 Cacti 对 hadoop 的指标监控不完整，所以需要集成 Ganglia 这款新的监控软件，通过实验系统提供的配置引擎，并遵循监控软件的集成方法，将 Ganglia 集成到实验系统并进行实验.对 Ganglia 和 Cacti 共同监控的节点 b 进行实验，每隔 5分钟记录一次数据，并于实验开始 15 分钟后执行计算任务以增加负载和内存使用，35 分钟后结束任务，50 分钟后结束实验. 其中，系统真实值是调用 linux 的系统命令 uptime、free 得到的.图4，图5 和图6 是从监控的实时性，准确性方面进行对比的. 图4 和图5 中的纵坐标表示1 分钟和 15 分钟的平均负载，单位是个. 图6中的纵坐标是空闲内存的容量，单位是KB. 从实验结果可以看出，云平台监控系统的监控数值与系统真实值更为接近，说明云平台监控系统的实时性和准确性较高.同时，我们还对监控指标的完整性进行了比较，在监控指标的完整性方面，云平台监控系统比 Ganglia、Cacti 单独监控的指标更完整，从而保证了监控指标的完整性.通过以上的比较，可以发现搭建的云平台监控实验系统在实时性、准确性及监控指标完整性方面要优于 Ganglia 或Cacti 单独监控，该云平台监控系统可以在一定程度上适应云平台资源规模巨大，动态性和多样性方面的特点.

　　5 结 语

　　提出一种可扩展集成化的云平台监控机制，确定了添加新监控软件的流程，并定义了两种监控数据完整性提取和存储方法. 根据这种机制搭建了集成 Ganglia 和 Cacti 的云平台监控实验系统，实验表明，该系统具有良好的可扩展性，满足对云平台动态变化资源的监控，可以有效减轻运维人员的工作压力，提高工作效率. 同时也验证了该机制可以适应云平台表现出的特点，是解决云平台监控难题的一种有效途径.