CloudStack 4.2 版本发布在即,相信不久后对 4.2 版本新功能(共有13个)的介绍会逐渐多起来。因为无论是从架构底层的重构还从构建更灵活的IAAS功能上,CloudStack又上了一个新台阶。在这诸多的更新中,我想介绍一下CloudStack对事件机制的增强,使用SNMP协议对CloudStack进行监控。可能这个改进比较小,或者对SNMP机制的支持还不够彻底,以至于4.2版本的ChangeLog里都没有提及它。毕竟对云平台运维的监控无论怎么强调其重要性都不过分,多一个监控视角就多一分运维保障。
在CloudStack 4.2之前的版本中事件/警告是在CloudStack内部完成生产和消费的,通过CloudStack Dashboard 和 Events菜单查看(如下图)。由于功能耦合度太高,不能把事件输出到CloudStack以外第三方监控系统中。在CloudStack支持插件机制后,与第三方监控系统的集成就能很方便实现了,目前CloudStack默认实现事件对SNMP和Syslog的输出。
SNMP基础原理介绍:SNMP(Simple Network Management Protocol的简称)是Internet协议家族的标准成员,工作在TCP/IP模型的应用层。几乎所有的主流监控软件(Zenoss,Cacti)都内置了对SNMP的支持,国内做监控服务很好的监控宝甚至提供了在线SNMP测试:http://www.jiankongbao.com/labs/snmp 。
一个SNMP管理系统的有以下必备组件(如下图):
1、被监控管理的设备;
2、SNMP Agent 运行在被监控设备上的代理软件;
SNMP Agent 使用UPD协议在161端口上接收请求。
3、SNMP Manager 运行在管理服务设备上的软件:
Network management system (NMS)
SNMP manager可以使用任意端口向Agent发出请求。SNMP Manager使用162端口接收请求。
SNMP监控网络中各角色的通信方式如下(如下图):
1、Manager可以对Agent发起:GET/SET请求(读/写)
2、Agent可以对Manager发起: GET/SET请求
3、Agent可以对Manager发起:Trap请求 (异步方式)
以上三种通信方式有不同的使用场景。
在日常运维监控系统中一般使用SNMP的GET(读)请求了解被监控方的内部运行数据,也就是第一种通信方式中的GET请求,由监控系统把数据Pull拉过来。其实也可以使用第二/三种通讯方式,由被监控方主动把数据Push推到管理服务器中。
CloudStack使用SNMP向监控系统提供事件类非连续的字符消息事件,最合适的通信方式是使用第三种Trap方式,当有事件发生时主动把事件Push推到外部第三方监控系统中。
由于被管理设备种类繁多,每个设备可以有不同的被管理对象,并且生产设备是一种市场行为,这导致SNMP协议本身不可能预先指定被管理设备对象的识别代码。因此SNMP把设备识别的标准定义工作外包给了第三方机构IETF和IEEE 。这就是MIB数据库(management information base)。
MIB是树状结构组成的,在最末端的叶子节点是OID( object identifiers ),每一个OID对应唯一的变量名。SNMP网络中的管理方和被管理方就是靠这些唯一的变量名进行交换数据的。既然MIB是一个数据库,自然可以对预先指定的被管理对象进行浏览,查询。推荐给大家一个工具:snmpB http://sourceforge.net/projects/snmpb/ 。
CloudStack使用的MIB分支是:1.3.6.1.4.1.18060.15 ,其中 18060 是分配给apache的代码,15是分配给CloudStack的根代码,所有CloudStack的SNMP OID代码都在1.3.6.1.4.1.18060.15 分支下 。
CloudStack中Trap事件的SNMP映射定义:
在CloudStack发送的事件消息中每个Trap消息都包含以下共同的数据:
message
podId
dataCenterId
clusterId
generationTime
在CloudStack 4.2中共定义了如下trap消息:(所有数据都以全局配置阈值为基准)
availableMemory : 可用内存
availableCpu : 未分配的cpu
availableStorage : 可用存储
remainingStorageAllocated : 保留的未分配存储
unallocatedVirtualNetworkpublicIp : 未分配的public IP数量
unallocatedPrivateIp :未分配的私有IP数量
availableSecondaryStorage : 二级存储中可用量
host : 与主机相关的警告
userVmState : 用户虚拟机异常停止
domainRouterVmState : Domain Router 虚拟机异常停止
consoleProxyVmState : CPVM异常停止
routingConnection : 与默认路由的链接丢失
storageIssueSystemVms : 系统虚拟机中存储有问题
usageServerStatus : usage server未运行
managmentNode : 管理网络CIDR没有配置
domainRouterMigrate : Domain Router 虚拟机迁移不成功
consoleProxyMigrate : CPVM迁移不成功
userVmMigrate : 用户虚拟机迁移不成功
unallocatedVlan : 未分配的VLan数
ssvmStopped : SSVM异常停止
usageServerResult : Usage job failed
storageDelete : 删除存储池失败
updateResourceCount : 更新资源计数失败
usageSanityResult : 使用合理性检查
unallocatedDirectAttachedPublicIp :未分配的共享网络IP数
unallocatedLocalStorage : 剩余的未分配本地存储
resourceLimitExceeded : 超过限制的资源数
以availableMemory为例,SNMP OID的原始消息描述如下:
availableMemory NOTIFICATION-TYPE
OBJECTS {
dataCenterId,
podId,
clusterId,
message,
generationTime
}
STATUS current
DESCRIPTION
“Available Memory below configured threshold”
::= { csAlertTraps 1 }
详情查看:https://cwiki.apache.org/confluence/download/attachments/30747160/CS-ROOT-MIB.mib?version=1&modificatiOnDate=1362442825000
CloudStack SNMP 事件机制的设计需求(原文):
- 生成可被外部监控系统识别的SNMP
traps,外部设备包括SCOM/OpenView等 。
- 生成的traps要兼容SNMP
v1、v2,优先支持v2。
- 提供必须需的MIB信息
- 能够指定trap消息发送的接收方,即trap
listener。
- traps消息包含事件严重级别和SNMP
警告的条件实体。
- 可指定多大20个外部traps listener 。
- 支持根据事件严重级别,配置相应的traps
listener。
- 支持通过api进行注册traps
listener和警告类型。
CloudStack中cloud-plugin-snmp-alerts项目介绍:
eclipse中项目名称:cloud-plugin-snmp-alerts
代码文件路径:[GITDIR]/cloudstack/plugins/alert-handlers/snmp-alerts/
SNMP相关类:
SnmpHelper
CsSnmpConstants
SnmpEnhancedPatternLayout
SnmpTrapInfo
SnmpTrapAppender
以上五个Java类的关系是:
1、根据log4j中appender的配置,由SnmpTrapAppender
接收Log4j的LoggingEvent日志事件;
2、根据SnmpEnhancedPatternLayout的描述转换成SNMP需要的SnmpTrapInfo格式;
3、使用SnmpHelper发送给外部的SNMP Manager;
4、CsSnmpConstants是辅助类,提供静态的MIB OID配置信息;
CloudStack中的事件输出是由日志驱动的,对log4j日志文件的修改如下:
文件名:log4j-cloud.xml
修改内容:
本文从SNMP运行原理的角度介绍了CloudStack使用SNMP把事件输出到第三方外部监控系统的集成方法。希望能对关心CloudStack运维关心的朋友有所帮助。下一篇将介绍SNMP监控的实例演示。