ceilometer的进化之路

领导提出的需求：
  在不给云主机安装客户端的情况下，监控云主机的 cpui 内存 网络 io，并且能出图。
想了几个方案：
1、ceilometer取数据，存入mangodb，用zabbix来读mangodb数据绘图

2 ceilometer 取数据 ，gnocchi来聚合数据， grafana来出图
3 ceilometer 取数据，直接把取到的数据通过zabbix trapper 丢给 zabbix，由zabbix来维护数据

4 干脆跳过 ceiometer，直接用zabbix 调libvirt取数据
权衡了下 选择了方案4.

主要理由还是处于对于大规模情况下ceilometer的性能不信任，在加上我这zabbix的玩的比较熟，
实测数据和实例里面安装agent 数据差距不大。
代码参考了https://github.com/bushvin/zabbix-kvm-res 
代码放在 github 上面 
https://github.com/superbigsea/zabbix-kvm
安装方法参考github上面说明
目前只支持单网卡 单硬盘，等有空了加上硬盘和网卡的自动发现

ceilometer项目最初的创建目的是实现一个为openstack采集数据，然后为计量和监控以及其它服务提供数据支撑。而数据的收集和存储一直是ceilometer的大问题。

ceilometer-api的进化之路

WSGI（Web Server Common Interface）是专门为Python语言制定的web服务器与应用程序之间的网关接口规范，wsgiref则是官方给出的一个实现了WSGI标准的简单的Python内置库。ceilometer最初采用wsgiref+pecan作为api服务的实现基础。

其中wsgiref.simple_server作为WSGI Server，主要作用是接受client的http请求。它首先会在底层建立一个TCP连接，并把该TCP连接放到连接池中。当WSGI Server空闲时，它从连接池中取出http请求(TCP连接)并解析，然后经过路由发送给相应的应用进行处理，并将处理完成后的结果返回给client。

wsgiref.simple_server虽然易用，但是只能单进程运行，这意味ceilometers-api同时只能处理一个http请求。在实际应用中，外部应用与ceilometer-api经常交换大量的数据，所以会造成http请求的延时，一旦某个http请求阻塞了api进程，其他的请求将得不到及时响应，严重影响ceilometer-api的效率。

kilo版本中ceilometer使用werkzeug替换掉wsgiref.simple_server作为api服务的WSGI，支持多个worker同时运行。然而这只是减少了ceilometer-api响应超时的概率，并没有从根本上解决交换大量数据时的性能问题。

数据存储后端的进化之路

Ceilometer在openstack应用中会采集大量的数据，这些数据对计费、监控、Autoscalling、数据统计分析等有很大的价值。而这些数据会随着时间不断增长，如何在这些巨量数据中进行读写和检索等操作成为了ceilometer的一个性能瓶颈。

openstack其他组件都使用mariaDB(MySQL的一个开源社区分支)作为后端存储，为了不影响其他组件正常运行，ceilometer必须考虑到数据库的性能问题。openstack开源社区最初的解决方法是ceilometer单独使用mongoDB作为存储后端，这样有2个好处：一是与其他组件的数据库引擎分离，即使ceilometer还存在数据库的性能问题也不会影响到其他组件的正常运行；二是在数据量很大的情况下，mongoDB有着更优异的读写性能。

为了避免数据不断增长造成数据库性能下降的问题，实际应用中经常通过“ceilometer-expirer”来做数据库定时清理，这是以牺牲监控数据的持久化为代价的。还有一个比较“非主流”的解决方法，完全抛弃ceilometer的api和数据库，将采集的数据直接转存入elasticsearch，其他应用直接通过elasticsearch的restful API接口进行检索等操作。

在经历了alarm、event、sample分库后，似乎mongoDB还存在性能问题。也许是被数据库的性能问题搞的头大了，openstack社区在Liberty版本推出了一个新的组件gnocchi来管理数据存储的后端，alarm也从ceilometer独立出去成了一个新组件aodh。现在，ceilometer终于可以专心地做数据采集的工作了。

pipeline机制的进化之路

Pipeline是"管道"的意思，它是ceilometer一个重要的机制，是Agent和Message Bus以及外界之间的桥梁。Agent将收集来的数据发送给pipeline manager，在pipeline中，数据先经过transformer的处理，然后通过Publisher发送出去。

Ceilometer收集数据有三种方式：

1) agent-notification:Ceilometer接收OpenStack其它服务上报的notification消息，然后转换为ceilometer采样值。

2) agent-polling (compute/central):直接从Hypervisor或者openstack其他组件的REST API接口来获取数据。

3) RESTful API:外部使用Ceilometer的REST API创建samples。

Ceilometer在这三种方式中都包含了pipeline机制。Liberty版本以后ceilometer将pipeline机制从agent-polling和RESTful API中去除，agent-notification则保留了这个机制。agent-polling和RESTful API收集到数据后不再经过独立的transformer处理和Publish，而是通过AMQP发送给agent-notification统一处理。这个改动大大简化了ceilometer数据采集的框架结构。

未来进化之路

publish与dispatch的融合

pipeline机制中的publisher和collector服务中的dispatcher的具有相同的作用，可以通过file方式直接写到文件中，可以通过direct或database方式直接写到数据库中，也可以通过http发送到系统外部。gnocchi和kafka只要将接口调整一下，即可以做publisher又可以做dispatcher。

作者大胆猜测，将来publisher与dispatcher有可能融为一体，放在collector服务中，而pipeline机制也只做transformer处理。

与其他监控软件的融合

目前，ceilometer主要致力于compute、storage、network的计量监控。其中，对于compute的计量也集中在VM的性能监控，对Host的监控能力也略显不足，因此，Kilo版本中ceilometer在agent-central增加了对硬件资源的监控，通过snmp协议进行硬件性能数据的采集。

实际生产环境中，openstack需要借助第三方软件Mrtg，Cacti，Zabbix等来做为监控补充。ceilometer在自身功能不够强大的时候，也许会考虑与第三方软件的融合，比如打通与第三方软件监控数据的共享互通。

作者简介： 苏正伟，软件工程师，从事OpenStack相关的工作已有2年的时间，对ceilometer有深入的研究

出处：http://www.sohu.com/a/114363141_468741