Ceilometer在生产环境应用可行性分析

背景：

Ceilometer是Openstack的开源项目，项目本身聚焦提供系统操作维护功能，包括监控、告警、事件。Ceilometer的框架具备高可扩展性，方便第三方系统以插件形式进行能力增加，例如新增监控指标等。同时，Ceilometer的基本能力可被第三方系统集成，包装出计费、动态资源调度等其他功能。

我们知道，一个系统能否应用于生产环境，系统框架的可扩展性只是一个因素，还需综合考虑系统的功能、性能、安全、可靠性等因素。以下结合对ceiometer的理解，综合评估Ceilmeter应用于生产环境的可行性。

Ceilometer架构简介：

Ceilometer包括以下部件：

Collector：数据汇总及处理进程，各种方式采集的数据，最终会汇总到此进程，进行统一处理。此进程部署一个实例，和controller部署在一个节点或者单独部署在一个服务器/VM。处理采用pipeline机制（包括transformer和publisher），类似生产线一样，transformer负责对数据进行转换（例如指标单位转换）、再加工（例如通过磁盘读字节指标，计算出磁盘iops）等，publisher将数据发布到第三方，例如DB、file等

Compute agent：部署在各个compute节点的指标采集代理进程，周期性执行pollster（获取指标的具体python脚本），获取VM监控指标，然后通过MQ发布给Collector

Central agent：中心代理进程，部署一个实例，一般和Collector部署在一起，周期性执行pollster（获取指标的具体python脚本），从其他模块（例如nova API）获取指标，并通过MQ发布给Collector

Notify：各个模块（例如nova API）通过MQ发布notify消息（例如虚拟机启动）到Collector。Collector调用Notify process插件对Notify进行处理，转换成event。Event接下来被作为指标通过pipeline重新发布到Collector，同时也支持被发布到第三方，DB、file等

Alarm：部署两个进程，alarm-evaluator和alarm-notify，alarm-evaluator支持定义告警规则，周期性执行告警规则产生告警

Ceilometer监控功能：

1. 指标支持情况：

（1）支持虚拟机相关指标，例如虚拟机CPU占用率

（2）H版本不支持主机相关指标，I版本支持基于SNMP协议的主机相关指标，例如CPU占用率

  具体可参见：http://docs.openstack.org/developer/ceilometer/measurements.html

2. 可扩展性

（1）支持通过在compute-agent模块、central-agent模块通过扩展pollster，增加新的指标项

（2）支持通过在compute-agent模块、central-agent模块通过pipeline增加新transformer，扩展指标的处理，或者产生新指标；通过增加publisher，扩展发布指标方式

3.性能

（1）指标采集：

         compute-agent模块模块通过定时任务，周期调用pollsters获取指标，pollsters的调用采用遍历方式。故pollster越多，一次执行过程越长。测试发现在华为E6000服务器运行30个左右pollster，大概需要10s左右，指标存在一定延迟

         central-agent模块部署一个进程，周期调用pollsters获取指标，当前指标较少且调用基于服务API，后续在I版本提供服务器指标获取功能后，如果仍按现有方式，周期使用SNMP协议从各个服务器获取指标，可能性能会较差

（2）Collector处理指标：所有指标都要通过Collector进行处理，处理方式为对每个收到的指标，通过pipeline进行处理。如果环境服务器/VM多时，Collector可能存在性能瓶颈（此处仅理论分析，未详细测试）

（3）DB处理：ceilometer支持mongoDB、mysql等DB存放指标。数据老化机制依赖DB本身机制，未从管理层面做特殊处理。MongoDB环境测试从2，700，000条sample数据中查询一条sample数据，耗时13s左右。性能极差

4.bug情况

（1）对I版本测试，发现使用postgresql（mmsql使用相同sqldriver），resource-list API，statisc相关API不可用。问题已定位并在I版本解决

社区互动：针对以上问题，已在社区发送邮件咨询，社区并未明确反馈是否认可测试结果。 但说明性能问题是后续PTL重点关注的问题，无其他建议

Ceilometer告警功能：

1. 告警支持情况：

（1）支持阈值告警，例如某虚拟机CPU占用率高于80%则告警

（2）不支持主机故障、nova等关键进程故障的告警。但通过以下大致步骤实现此功能

         1. 扩展监控指标（或第三方watchdog软件），提供监控主机故障、进程故障的能力，并将监控结果以指标形式发布到collector并入库

         2. 通过告警API定义告警规则，关注以上故障类指标

         3. 系统周期性执行告警规则，产生故障告警

2. 可扩展性

（1）支持通过定义灵活的告警规则，采集对应指标，并判断是否需要产生告警

3.性能

（1）系统一般需要监控所有对象，当对象故障时产生告警。则假设一个系统有1000个VM，关注每个独立VM的CPU占用率，当CPU占用率超过80%时产生告警，则需要定义1000*1条规则。告警处理流程为alarm-evaluator进程周期依次执行每条告警规则，根据告警规则的定义从ceilometer获取统计指标，判断是否符合定义的告警规则。基于以上监控部分性能分析结果，则告警可能存在性能瓶颈

社区互动：针对以上问题，已在社区发送邮件咨询，社区反馈告警的机理正如上所述，告警是否存在性能问题仍在和社区讨论确认中

业界Openstack解决方案OM功能考虑：

1. Redhat

    通过集成nagios开源软件，提供当前Openstack所不支持的主机监控、进程监控、故障告警功能。

综述

理论及验证结果说明

1. Ceilometer当前架构及实现，确实存在一些功能待补齐的地方，所以redhat等厂商的解决方案集成第三方软件增强能力

2. 性能存在待改进的地方，社区虽并未明确反馈是否认可测试结果。 但说明性能问题是后续PTL重点关注的问题

3. 大规模生产环境应用下仅使用原生功能存在一定风险