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

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页