Ceilometer分析报告
1Ceilometer简介
Ceilometer：也称为OpenStack Telemetry，OpenStack监控服务。
该项目开始于2012年，初始的目标是为了向基础设施提供一种收集所需信息的方式，然后对资源的使用进行评级，将开销转换成事件记录到计费项目中去。
Ceilometer主要实现以下几个目标：
-提供有效的计量数据（CPU和网络的开销）的收集方式
- 允许部署者直接整合计量系统或者更换部件
- 数据既可以是通过监听消息通知收集，又可以通过查询基础设施收集
- 允许部署者配置收集的数据类型，以满足他们操作的需求
- 计量系统收集到的数据可以通过REST API来展示给一些用户看
2整体架构
Ceilometer提供5个核心服务：
- polling agent：守护进程，既运行在控制节点上，又运行在计算节点上，查询OpenStack服务和创建Meters
- notification agent：守护进程，运行在控制节点上，用于监听消息队列中的消息和将其转化成样本数据（不同的Notifications 通过event_type进行过滤）- collector：守护进程，收集和记录event及由notification和polling agent 创建的计量数据，并将结果记录到数据库中。
-api：查看由collector service记录下的数据的服务
-alarming：守护进程，基于定义的规则来进行评估和发出通知（当一个计量达到某个门限值的时候，就会触发）
下面，根据上图，对Ceilometer机制进行介绍。
2.1 采集数据
Ceilometer中数据主要有三种：
- Sample：纯数值型的数据；
- Meter：Sample随时间的变化量；
- Event：OpenStack服务中的主体在某个时刻（发生了某事）的状态，包含非数值的数据。
Ceilometer项目提供了两种收集数据的方式：
- Bus listener agent：监听消息总线，获取所需要的信息，然后将其转换成Events和Samples。
（这是Ceilometer首选的数据收集方式）
- Polling agent：该方式通过定期查询一些API来收集数据。
2.1.1Bus listener agent
这种方式是靠ceilometer-notification-agent 来提供支持的，这个组件实现访问消息总线，通过访问消息总线来获取notifications。
具体的实现步骤是：
1) 若干参数初始化，建立线程池，用于后续服务中的若干操作。
2) 当ceilometer-notification-agent启动的时候，先加载一系列的插件。
这些插件是监控项对应的通知中相关监控信息的获取形式。
3) 同时在系统Service中定义要监听的序列所在的主机（host）和初始化队列的类型（topic），通过RPC通信连接到消息总线。
4)遍历2) 中的所有插件，对每个插件，分别获取其插件的ExchangeTopics 序列（描述了用于连接到所监听队列的交换器exchange和队列的类型topics）。
5) 建立一个topic类型的消息消费者，监听topic指定的消息队列。
当进行消息消费操作的时候，根据不同的监控项调用不同插件中关于消息处理的方法，实现将接受到的通知转化成样本数据。
2.1.2 Polling agent
这种方式是由ceilometer-central-agent 和ceilometer-compute-agent 提供支持的。
--- ceilometer-central-agent组件通过调用OpenStack其它服务中相关模块的APIs来获取样本数据的。
具体实现是：
1) 初始化ceilometer-central-agent，加载该组件中指定的，关于如何收集相关模块（Image、V olume、Object、Network）的监控数据的插件，建立线程池。
2) 创建轮询的任务，周期地进行：遍历任务，获取每个任务指定获取的监控项的样本数据。
--- ceilometer-compute-agent 通过调用虚拟机监视器提供的APIs 来获取样
本数据。
具体的实现方法与ceilometer-central-agent 实现数据采集的方法相似，不同点在于：
初始化时需要定义获取虚拟机实例信息的方式；然后加载加载该组件中指定的，关于如何收集虚拟机实例相关的监控数据的插件；接着再加载关于如何找到主机上的监控的虚拟机的插件。
之后的步骤与上述ceilometer-central-agent 步骤2)就是一致的了，只不过其中获取到的任务不同而已。
2.2 数据处理
2.2.1 数据转换
OpenStack-Ceilometer中的数据转换过程只发生在
ceilometer-notification-agent 组件中。
因为该组件从消息总线上得到的是通知（Notification）类型的数据，而另外两个组件获取到的都是其它相关模块已经处理好的样本（Sample）类型的数据了。
因此数据处理的过程，实际上就是将Notification 数据转换成Sample 数据。
上面数据采集的方式中说到ceilometer-notification-agent 采集数据的最后一步是监听指定的消息队列，当有消息消费操作时，也就是组件接收需要的通知信息时，即将该通知转换成样本数据。
但是，Ceilometer并没有将Notification直接转换成Sample的机制。
它是根据一个映射列表（Event Type）中定义的处理策略，将Notification先转换成Event，再从Event中获取样本数据。
具体的转换过程如下：
1)获取到notification，根据event的定义，对notification进行分解，找出其中与event相关的元素；
2)根据Event Type映射列表，将上述的notification 转换成event；
3) 在将数据发送到pipeline中之前，将event转换成初始的样本数据。
2.2.2 数据整合
不论是通过Polling agents获取到的样本数据还是通过Bus listener agent 获
取并转换后得到的样本数据，都属于初始的样本数据，它们属于是能直接反应OpenStack中各种资源在某时刻的具体状态的数据，如cpu在T时刻已使用的时长。
这些数据会有很多，且相同的监控项往往采集到的数据反应的是同一类事情，这些事情可以经过整合，得到一个结果。
Ceilometer中的pipeline机制提供一个这样的数据整合的方式。
数据整合的方式有以下5中：
1) 累加：这种方式仅仅是将指定个数的样本数据缓存起来。
2) 聚合：根据样本中的某些属性，计算到来的样本数据的总数。
3) 算数计算：将样本中的数字经过一定的算数表达式计算得到结果。
4) 变化率：当初始监测到的数据是不连续的、但有波动的样本数据的时候，就可以使用这种方法将其转化成百分比的形式。
5) 单位转换：当初始样本数据的值很大的时候，可以通过乘以给定的比例来得到合适的数字。
2.3 数据发布
数据的发布是Ceilometer-pipeline机制中最后的操作，也即是当数据的整合完成之后，pipeline就会将这些样本数据通过3中方式发布到信息队列中去：
1) File log：直接将样本数据发布到一个指定的日志文件中去。
2) RPC
a) 从若干样本数据Samples中提取数据形成信息格式meters。
b) 将meter包装成msg，根据匹配的topic，将msg添加到相应的本地队列当中。
c) 将本地队列中的的所有数据发布（循环发布、远程发布，不返回任何值）到信息队列metering中。
3) UDP
a)从若干样本数据Samples中提取数据形成信息格式meters。
b) 将meters包装成UDP数据包。
c) 通过UDP协议，将数据包发送到远程信息队列中。
2.4 数据存储
Ceilometer将数据存储到数据库中，是通过ceilometer-collector组件实现的。
该组件通过监听对应的metering信息队列来获取队列中的样本数据，然后将其写入到数据库中。
具体的实现方法是：
1) 初始化相关参数，定义要监听的主机host和队列topic
2) 根据不同的发布数据的方式，Collector收集数据的方式也不同：
a) 针对UDP的消息发布方式：Collector首先获取socket对象，然后循环任务（需要获取的数据列表），通过UDP协议获取相关数据。
b) 针对RPC的消息发布方式：首先建立RPC连接，指定一个topic 的消费者，然后监听信息队列。
当需要消费信息时，循环遍历任务，获取队列中的相关信息。
3) 将获取到的数据保存到存储系统中（File log或Database）。
