运动随着近几年来云计算技术的飞速蓬勃发展, 云计算技术已经发展成熟^[1], 云基础设施也融入到各行各业当中, 例如政府服务部门的政务云^[2,3]、教育服务行业的教育云^[4,5]、公共卫生事业的医疗云^[6,7]等. 为了实现气象部门信息化、现代化的快速发展, 集约化管理气象信息基础设施和业务应用, 江西省气象部门已经建设了省级气象云平台. 但是因为气象云的物理设备数量和业务应用数量的迅速增加, 传统的集群监视技术已经无法满足当下气象云监控运维的需要^[8]. 传统的集群监视技术只能对物理服务器的资源利用情况进行简单的监视, 一方面无法对气象云的虚拟机实例和运行在气象云上的云应用进行监视, 另一方面无法对监视到的故障问题进行报警及自动应急处理.

江西省气象云主要分为物理基础设施层、虚拟化层、气象应用层. 物理基础设施层主要包括物理服务器、路由器、交换机等等, 其中物理服务器经常出现硬盘损坏、CPU负载过高等问题. 虚拟化层主要是基于KVM虚拟化技术生成的虚拟机实例, 虚拟机经常出现假死无响应、存储空间不够等问题. 气象云应用层主要运行的是气象服务应用, 例如气象数据传输存储类应用、气象数据统计分析类应用、气象公众Web服务类应用, 这些云应用经常会出现突然中断退出、性能变低等问题.

为了建立面向气象云的监控运维系统, 实现对气象云的三层监控, 及时对发生的故障和问题进行通知和自动处理, 减轻值班运维人员的日常维护负担, 本文基于Zabbix开源系统设计了一种气象云监控运维系统(Meteorological Cloud Monitoring and Maintenance System, MCMMS).

1 相关工作

Cacti是一种网络流量监视图形分析开源工具, 它是基于PHP、MySQL、RRDTool等开发的^[9]. 它通过SNMP的snmpget命令和snmpwalk命令去远程获取网络设备相关信息, 然后基于RRDTool工具绘制监视设备的性能状态图. Cacti具备精准的流量监视能力, 但不支持分布式集群监控, 缺乏报警功能, 不适应目前云环境下的监控需求.

Nagios是一种监视系统运行和网络设备信息的开源监视系统^[10,11]. 它能够有效监视各类操作系统的状态以及路由器、交换机等网络设备的状态. 当监视对象出现异常时, 它能够以邮件和短信的方式发出警报. 虽然它告警功能强大, 但是它的数据收集机制不强, 在当下云环境虚拟机众多的情况下, 添加配置监视对象也很繁琐, 不宜进行维护.

Ganglia是一种可扩展的分布式监控系统, 它是主要为高性能计算集群设计的^[12,13]. 它可以监视高性能计算集群各个节点的状态信息, 通过gmond代理采集各项性能指标, 通过gmetad进程进行监视数据的汇总, 最后通过PHP展示机器的性能数据. 但是这个系统对应用的监视比较薄弱.

Zabbix为分布式系统和网络监视功能提供了一种基于Web应用的企业级开源解决方案^[14,15]. Zabbix的监控方式如图1所示, Zabbix可以通过代理、JMX、SNMP等多种方式对服务器和网络进行监控数据收集, 能够支持包括Linux、Windows在内的各种系统平台. Zabbix既解决了Cacti没有报警的不足, 也解决了Nagios配置繁琐的问题. Zabbix另外的一个优点在于能够允许用户对监视功能进行自定义扩展.

2 系统的体系结构

江西省气象云主要分为物理基础设施层、虚拟化层、气象应用层^[16]. 物理基础设施层主要包括物理服务器和网络设备. 虚拟化层主要包括运行在物理基础设施层上的各类虚拟机. 气象云Hypervisor是运行在物理基础设施层和虚拟化层之间的软件, 它可以对物理基础设施进行硬件资源抽象, 然后为虚拟化层供给共享的计算、存储、网络等资源. 用户可以通过Hypervisor对虚拟化层进行一定程度的性能监视以及对虚拟机进行生命周期管理. 气象应用运行在虚拟机的操作系统上, 为用户提供气象信息技术服务.

基于Zabbix的气象云监控运维系统体系结构如图2所示, 主要分为气象云监控代理和气象云监控运维Web系统两部分.

气象云监控运维系统需要在物理服务器和虚拟机中部署监控代理. 部署在物理服务器中的监控代理主要是监视物理服务器以及运行在其上所有虚拟机的CPU资源、内存资源、网络资源、硬盘资源的实时使用情况. 部署在虚拟机中的监控代理主要监视运行在虚拟机上气象应用的运行情况. 这些部署在气象云上的监控代理会将监视数据通过网络发送给气象云监控运维系统. 另外, 这些监控代理还会接收来自监控运维系统的操作指令, 自动对气象云进行应急运维操作.

气象云监控运维Web系统自下而上主要分为4层, 分别是业务数据库层、数据访问层、业务逻辑层、展示层.

业务逻辑层使用的是MySQL数据库, 数据库中存储着各种资源历史使用情况、设备实例的详细信息、监视规则、触发报警规则、报警事件等.

数据访问层采用的是ORM框架, 它向上为业务逻辑层提供了数据库的访问接口, 向下使用面向对象的形式对数据库中的表进行了映射操作.

业务逻辑层是气象云监控运维系统的核心部分, 它分为两大部分, 一部分是继承原有的Zabbix监视业务逻辑, 另一部分是在Zabbix数据库基础上对Zabbix进行了可视化以及报警、应急操作的扩展. 继承原有的监视业务逻辑主要包括数据收集模块、主动监视模块、数据处理模块, 扩展的业务逻辑主要包括可视化模块、报警模块、应急操作模块. 数据收集模块的作用是接收从气象云监控代理发送过来的数据, 主动监视模块的作用是监控运维系统通过一些常用协议去主动监视Java应用、网络设备、硬件设备, 数据处理模块主要是对监视数据进行处理、读取. 报警模块的作用是根据报警触发规则为用户推送告警信息, 应急操作模块的作用是对运维过程中出现的问题进行及时的简单处理, 可视化模块是将监控的相关信息展示到前台页面. 业务服务视图负责对前台的模型及页面进行渲染.

展示层需要为PC Web桌面和智能手机(IOS、Android)提供信息展示功能. 值班人员的PC Web桌面是基于HTML5开发, 采用了BootStrap4、Jquery等技术, 为用户提供了监控报警信息的页面展示以及和监控有关的配置页面. 面向智能手机的展示层主要是用于接收浏览报警信息, 报警信息会根据重要等级分别通过值班平台、短信平台、微信平台推送给值班运维人员.

3 关键技术 3.1 Agent监视方法

本系统采用在操作系统中部署监视代理(Agent)的方式对气象云的物理服务器、虚拟机、关键应用进行监视, Agent在获取到监视信息后, 会将这些信息发送给MCMMS Server. Agent按照与MCMMS Server交互方式分为主动类型和被动类型.

主动类型的Agent与MCMMS Server交互的流程如图3所示. 主动类型的Agent与MCMMS Server交互分为准备期和运行期这两个阶段. 首先Agent发出与MCMMS Server建立TCP连接的请求, 建立与MCMMS Server的TCP通信通道. 然后Agent会向MCMMS Server发送请求监视项目表的申请, Zabbix会根据请求返回相应Agent所需监视项目表. Agent在获取到自己的监视项目表后会对返回的监视项目表进行处理, 处理完毕后断开TCP连接. 接下来, Agent进入运行期, 首先会建立与MCMMS Server发送监视信息的TCP连接通道, 然后会根据配置文件中预定义的时间间隔发送监视信息给MCMMS Server. MCMMS Server在收到监视信息后会对监视信息进行处理, 并且存入到数据库中.

被动类型的Agent与MCMMS Server交互的流程如图4所示. 对于被动类型的Agent, MCMMS Server首先会发出与Agent建立TCP连接的请求, 获取与Agent数据传输通信的通道. 然后MCMMS Server会向Agent发送相关数据请求, 该数据请求主要是需要监视项目的名字. Agent在收到MCMMS Server发来的数据请求后, 会读取相应的监视数据, 然后将获取的监视信息返回给MCMMS Server. MCMMS Server收到返回的监视信息后会进行数据处理, 然后存储到数据库中, 最后断开TCP连接.

两种类型的Agent都会按照设计约定的数据传输协议与MCMMS Server进行通信, 该数据协议采用JSON数据格式, 但是会在每条数据之前加上头部标识符和数据长度标识符, 格式顺序如下所示: <头部标识><数据长度标识><监视数据>. 头部标识一共是5个字节, 数据长度标识一共是8个字节, 每一条数据量大小不能超过64 M, 这是为了防止内存消耗过快.

3.2 面向基础云资源的监视

江西省气象云虚拟化资源是基于libvirt进行监视的, libvirt是一款用于虚拟化平台管理的开源API库. libvirt提供了针对不同虚拟化平台的监视功能, 对于不同的虚拟化平台都提供了该平台的驱动, 并且为不同语言提供了统一的编程接口, 通过调用接口可以实现对气象云的虚拟化操作. 对基础云资源的监视主要包括对计算资源的监视、对存储资源的监视、对网络资源的监视.

对于计算资源的监视就是对物理服务器和虚拟机的CPU利用率进行监视. 开源库libvirt虽然没有提供接口让外部系统直接获取CPU利用率, 但是外部系统可以通过计算CPU Time间接获取CPU利用率, CPU利用率获取算法如算法1所示.

算法1. CPU利用率获取算法

输入: 虚拟机实例集instanceList

输出: 虚拟机使用率集合cpuMapList

1. forinstanceininstanceList:

2. gettime₁, time₂ fromsystem time

3. getCPUTime₁, CPUTime₂, cores_nums, uuidfromQemu

4. //计算CPU时钟差

5. ∆CPUTime = CPUTime₂ – CPUTime₁

6. //计算自然时间差

7. ∆time = time₂ – time₁

8. //计算CPU使用率

9. CPU_usage = ∆CPUTime×100/(Δtime×cores_nums×109)

10.  cpuMapList ← map<uuid, Cpu_usage>

11. return cpuMapList

对存储资源的监视就是对物理服务器和虚拟机的内存资源和硬盘资源进行监视. 内存资源的使用情况获取比较简单, 只需要获取宿主机上每个实例的Domain基础信息, 然后从基础信息中提取与该实例相关的最大内存大小和已使用内存大小. 硬盘资源的总量和使用量首先需要通过libvirt接口获取Domain的情况及XML配置文件, 然后通过XML可以获取每个机器的名称, 最后再通过Domain的设备块信息接口blockinfo获取需要监测的数值. 另外, 获取硬盘的I/O情况与获取硬盘的使用量过程类似, 但是在调用接口获取设备信息时需要调用设备快查询接口blockstats获取需要监测的数值.

对于网络资源的监视就是对虚拟机的虚拟网卡数据流入流出量进行监视. 首先需要使用libvirt的API获取Domain的情况, 然后将虚拟网卡设备的名称作为参数传递给libvirt的API, 通过interfaceStats接口去获取虚拟网卡设备的属性字段值, 这些值便是虚拟网卡流入流出的数据量. 对于网络设备如路由器和交换机的监视, 需要使用SNMP功能进行监视. 使用SNMP首先需要使用snmpwalk命令对对象标识符(OID)值进行遍历, 然后再根据具体的OID值使用snmpget命令获取该设备的网口状态和流量.

3.3 面向关键云应用的监视

对于运行在气象云上的云应用主要监视常用的基础软件MySQL数据库和Tomcat Web容器的性能以及C/S架构和B/S架构的应用软件.

MySQL数据库是目前主流的关系型数据库管理系统应用软件. 本系统将使用被动类型Agent模式对Zabbix的监视进行扩展. Agent将会对MySQl的存活状态、更新类SQL执行个数、查询类SQL执行个数、插入类SQL执行个数、删除类SQL执行个数、慢查询语句个数进行监视. 首先需要在Agent的配置文件中进行自定义监视命令的配置. 自定义的监视命令需要遵循Zabbix的规范, 按照UserParameter=key,command的形式进行定义, 这里监视命令基于Mysql自带的mysqladmin命令进行编写.

由于Tomcat Web应用容器是基于JAVA语言开发的, 所以MCMMS Server可以通过JMX对Tomcat的性能进行监视. JMX是Java管理的扩展, 给应用程序提供了监控管理功能的接口. 使用JMX不需要在Tomcat代码中增加新的机制和代码, 只需要在启动Tomcat服务器前修改相关的配置文件开启支持JMX接口的服务端口即可. 通过JMX监视用户便可以监视到Tomcat服务占用CPU的情况、并发线程数量、内存分配情况等. 修改配置文件可以开启JMX支持.

对于用户部署在气象云上的应用, 系统无法入侵式的监视应用程序应用情况, 只能通过监视应用的日志达到监视应用运行状态的目的. 监视应用日志的Agent工作流程如图5所示. Agent会定时扫描应用的日志目录, 对该日志目录下的日志文件进行文件名正则表达式匹配, 当匹配到文件名相符的日志文件, Agent会去数据库中读取该日志文件的字节计数器和更新时间计数器. 如果日志文件的大小小于字节计数器, 那么Agent将会从日志头部开始读取日志文件, 计数器也会重置为0. 如果日志文件大小大于字节计数器, 那么Agent将会从最新的位置开始读取文件. Agent逐行读取文件时, 会按照自定义的应用错误关键字检查日志文件内容, 如果发现应用错误信息, Agent会将该信息发送给MCMMS Server. Agent每次结束一个日志文件检查时, 会将数据库中该日志文件的计数器更新. 另外, 对B/S架构的Web应用软件, MCMMS Server可以对自定义的Web网页URL进行定时扫描, 收集访问该网页的下载速度、响应时间以及返回的HTTP网页状态码. 如果发现响应时间超时或者返回的状态码是404等错误码, 那么将会触发对该Web应用的告警.

3.4 报警运维技术

在收集的监视数据基础上, 系统会对监视数据进行处理, 为值班人员提供报警功能和故障自动化处理功能. 报警控制流程如图所示. 报警运维主要分为两个模块: 触发器和应急操作.

触发器是当监视数据不满足自定义的约束条件时, 会发出触发某个操作的指令. 每一台物理设备实例或者虚拟机实例都对应多条触发器. 每个触发器都会定义一个逻辑表达式, 该逻辑表达式是监事数据的约束条件. 逻辑表达式按照约定的格式进行定义, 约定的基本格式如下. {<实例名>: <监视项>. <函数>(<参数>)}<逻辑运算符><约束量>, 其中实例名是监视系统中物理设备或者虚拟机的名字, 监视项是所需要监视项目的名称, 包含参数的函数是用来返回该函数指定的监视项数据, 逻辑运算符是用来判断监视数据是否满足约束量. 表达式中的函数一共有5种, 分别是avg、count、last、min、max, 具体的作用如表1所示. 触发器的表达式由满足约束到不满足约束或者由不满足约束到满足约束, 触发器的状态会由正常变为异常或者由异常变为正常, 每次触发器状态的变化都会生成一个事件. 事件按照问题的重要性会分成5个等级, 等级从轻到重分别是提示(Information)、警告(Warning)、一般(Average)、重要(High)、灾难性(Disaster).

当触发器的约束条件不被满足后, 系统会针对该触发器采取应急操作. 应急操作主要包括两个部分, 一是将产生的报警信息告知值班人员以及系统运维人员, 二是对产生的问题执行相应的应急指令. 发送报警提示的方法主要包括发出警报声音、短信通知、微信通知、邮件通知. 对于一线24小时值班人员, 一般采用直接发出警报声音的方式进行通知. 对于二线运维人员, 由于不在值班室, 会采用短信通知和微信通知两种方式, 短信通知主要通知重要和灾难性的问题, 微信通知主要通知一般性及以下的问题. 对于产生的问题执行相应的应急指令主要是指通过远程SSH和IPMI连接到问题设备实例上, 执行一定的系统恢复命令. 在运维过程中, 常见的需要恢复场景如表2所示.

4 实验测试 4.1 系统平台部署

系统的平台部署环境如图6所示, 一台服务器部署了MySQL监控数据库, 一台服务器部署了Zabbix服务器, 扩展Zabbix功能的Web应用部署在另外一台服务器上. 用户可以通过Web桌面访问Zabbix服务应用和扩展服务应用. 值班运维人员的智能手机会从扩展应用服务上获得监控运维信息.

4.2 系统平台展示

图7是对监控告警信息的总览, 图7上部分是各类告警个数的统计和当天值班人员的信息. 图7下部分是滚动的详细告警信息和产生告警信息来源的区域告警. 图8和图9是按照服务器以及虚拟机在实际环境中的机柜、网段分布信息绘制的告警分布图, 对于不同的告警信息系会用不同的颜色进行标注. 图10是监控运维系统通过短信平台和微信平台推送到智能手机上的监控告警信息.

5 结束语

本文基于Zabbix设计了一套面向气象云的监控运维系统, 为气象云环境中的物理基础设施、虚拟机以及运行在其上的云应用进行了实时监控. 如果在气象云中出现了故障, 该系统能够快速发现问题, 通知值班运维人员, 并且会根据预定义命令自动进行先行维护. 这保障了气象云的平稳运行, 减轻了值班运维人员的工作量. 目前系统对云应用的监控种类少、粒度粗, 下一步将会研究扩展云应用监控的种类以及优化云应用监控的方法.