Ceilometer 插件介绍

1. Ceilometer简介
OpenStack 作为一个开源的IaaS平台，发展迅速，越来越多的公司基于OpenStack做自己的公有云平台，而计量和监控则是必不可少的基础服务。由于OpenStack初始并不提供这两种服务，所以许多公司需要自行开发，为了顺应需求以及避免重复的工作，Ceilometer作为OpenStack的一个子项目孕育而生，它像一个漏斗一样，能把OpenStack内部发生的几乎所有的事件都收集起来，然后为计费和监控以及其它服务提供数据支撑。
在 Ceilometer建立之初，它的定位专注于计量，计费，随着需求不断的增长，但是除了计费之外，像监控、Autoscalling、数据统计分析等都需要这些数据。所以Ceilometer逐渐转变了它的Mission：No repreat，various data。
由于 Ceilometer收集的是OpenStack内部各个服务(nova, neutron, cinder等)，而将来还会有很多未知的服务的信息，所以可扩展性则是需要为未知服务保证的，Doug Hellmann调研了很多项目的扩展机制，最终开发了Python的一个基于setuptools entry points三方库Stevedore，并且使用Stevedore设计了Ceilometer的插件机制，现在Stevedore已经被OpenStack中的很多新的项目使用。
在H版中，不仅添加了Alarm功能，而且通过POST meter API打破了Ceilometer只局限在OpenStack内部服务的限制，通过该API 向Ceilometer写入数据，而不用去写plugin，完成了Ceilometer由poll向poll+push的转变。另外One Meter per Pollster Plugin方式则简洁和规范化了Ceilometer的插件机制
2. Ceilometer架构

3. Ceilometer两种数据收集方式：触发收集，轮询收集
最初采用这两种消息收集方式原因以及当前情况：
当OpenStack内部发生的一些事件时，都会发出对应的notification消息，比如说创建和删除instance，这些信息是计量/计费的重要信息，因此第一种方式是Ceilometer第一数据来源，但是有些计量信息通过notification消息是获取不到的，比如说instance的CPU的运行时间，或者是CPU的使用率，这些信息不会通过notification消息发送出来，因此Ceilometer增加了第二种方式，周期性的调用相关的API去获取这些信息。但是随着alarm的应用，也由于轮询机制的消耗比较大（由于不需要的数据而带来的数据了的叠加），触发机制基本可以代替轮询方式。
4. Ceilometer各种机制以及具体流程
4.1 Ceilometer之Alarm
警报机制，相对ceilometer是独立的一块，只是放在了ceilometer的代码树里面。
4.1.1 Ceilometer两种方式Alarm服务（evaluation_service配置项）
● Threshold：根据监控指标的阈值来判断alarm的状态，只针对某一个监控指标建立的alarm。
● Combination：根据多个alarm的综合状态来判断，多个alarm间可以是OR/AND的关系
Threshold Evalute代码流程：

4.1.2 Ceilometer两种方式Alarm服务（evaluation_service配置项）
● SingletonAlarmService：在一个进程中去检查所有的alarm，当量稍微大的时候，就会有延时，不能够高可用
● PartitionedAlarmService：通过rpc实现了一套多个evaluator进程之间的协作协议(PartitionCoordinator)，使得可以通过水平扩展来不断增大alarm service的处理能力，这样不仅实现了一个简单的负载均衡，还实现了高可用
4.1.3 PartitionCoordinator协议
PartitionCoordinator允许启动多个ceilometer-alarm-evaluator进程，这多个进程之间的关系是互相协作的关系，他们中最早启动的进程会被选为master进程，master进程主要做的事情就是给其他进程分配alarm，每个进程都在周期性的执行三个任务：
● 通过rpc，向其它进程广播自己的状态，来告知其他进程，我是活着的，每个进程中都保存有其他进程的最后活跃时间。
● 争抢master，每个进程都会不断的更新自己所维护的其它进程的状态列表，根据这个状态列表，来判断是否应该由自己来当master，判断一个进程是否是master的条件只有一个，那就是看谁启动的早。
● 检查本进程负责的alarm，会去调用ceilometer的api，来获取该alarm的监控指标对应的监控数据，然后进行判断，发送报警等。

4.2 Ceilometer之Agent-central
运行在控制节点上，它主要通过调用相关模块的REST API，通过访问相关模块的客户端，从而实现主动收集相关模块（Image,Volume,Objects,Network）的监控数据，需要定期Poll轮询收集信息。
主要完成的功能：
● 遍历任务（通道），获取每个任务指定获取的监控项的采样数据；
● 针对每个监控项的采样数据，实现发布监控项采样数据样本到消息队列，其中实现采样数据发布的方式有三种，即RPC/UDP/FILE；
需要初始化时完成的操作：
● 根据指定参数获取命名空间ceilometer.poll.central，获取与ceilometer.poll.central相匹配的所有插件，并加载；ceilometer.poll.central所指定的插件描述了如何获取收集相关模块（Image,Volume,Objects,Network）的监控数据。
● 获取管理员操作的上下文环境类的初始化对象；
● 建立线程池，用于后续服务中若干操作的运行；
4.3 Ceilometer之Agent-compute
负责收集虚拟机的CPU，内存，IO等信息。（定期Poll轮询收集信息）
我们提供的Ceilometer compute插件即为此模块
主要完成的功能：
● 遍历任务（通道），获取每个任务指定获取的监控项的采样数据；
● 针对每个监控项的采样数据，实现发布监控项采样数据样本到消息队列，其中实现采样数据发布的方式有三种，即RPC/UDP/FILE；
需要初始化时完成的操作：
● 根据指定参数获取命名空间ceilometer.poll.compute，获取与ceilometer.poll.compute相匹配的所有插件，并加载；ceilometer.poll.compute所指定的插件描述了如何获取收集所监控的虚拟机实例相关的监控采样数据；
● 根据指定参数获取命名空间ceilometer.discover，获取与ceilometer.discover相匹配的所有插件，并加载；ceilometer.discover所指定的插件描述了如何发现主机上的监控的虚拟机。 ceilometer.discover = local_instances = ceilometer.compute.discovery:InstanceDiscovery
● 获取管理员操作的上下文环境类的初始化对象；
● 建立线程池，用于后续服务中若干操作的运行；
● 加载命名空间ceilometer.compute.virt，描述了获取虚拟机实例的信息（实例数据，CPU数据，网卡数据和磁盘数据等）的方式；

4.4 Ceilometer之Agent-notifiaction
负责收集openstack各个组件推送到messaging bus上的消息，notification守护进程会载入一系列的plugin来监听各种topic。
主要完成的功能：
● 监听AMQP中的queue以便收到信息
需要初始化时完成的操作：
定义所要监听序列的host和topic，建立线程池，用于后续服务中若干操作的运行。

4.5 Ceilometer之collector
collector的守护进程收集被Notification和polling agent获取的event以及meter data，并将这些数据持久化到数据库中
主要完成的功能：
● 针对UDP的消息发布方式：
● 获取socket对象，一直循环任务通过UDP协议实现接收消息数据data，保存数据data到数据存储系统（不同的实现后端）


4.6 Ceilometer之API
将Publisher发布的消息（Meter Message）存储到DataStore。通过触发或者轮询收集到的数据被存入数据库后，由于所使用的数据库可能是随着方案的改吧而改变的，所以提供了REST API来对收集的数据进行查询而不是直接进入数据库中查询

参考文档：
http://blog.csdn.net/violet_echo_0908/article/details/52023137