Openstack Ceilometer介绍

1.概述

Ceilometer是OpenStack中的一个子项目，它像一个漏斗一样，能把OpenStack内部发生的几乎所有的事件都收集起来，然后为计费和监控以及其它服务提供数据支撑。Ceilometer的核心架构图如下：

 图1 Ceilometer的核心架构图

 

图2 Ceilometer架构模型

2.基本概念

ceilometer 主要有下面几个概念:

• meter 是ceilometer定义的监控项，诸如内存占用，网络IO，磁盘IO等等
• sample 是每个采集时间点上meter对应的值
• statistics 一般是统计学上某个周期内，meter对应的值(平均值之类)
• resource 是被监控的资源对象，这个可以是一台虚拟机，一台物理机或者一块云硬盘
• alarm 是ceilometer的告警机制，你可以通过阈值或者组合条件告警，并设置告警时触发的action

3.采集机制

ceilometer的各个服务中，与采集相关的服务是ceilometer-collector、ceilometer-agent-central、ceilometer-agent-compute、ceilometer-agent-notification。我们可以通过下图了解一下他们之间的关系:

agent-*服务负责采集信息，采集的信息可以通过三种方式publish出来，包括RPC、UDP、File。RPC是将采集的信息以payload方式发布到消息队列，collector服务通过监听对应的queue来收集这些信息，并保存到存储介质中；UDP通过socket创建一个UDP数据通道，然后collector通过bind这个socket来接收数据，并保存到存储介质中；File方式比较直接，就是将采集的数据以filelog的方式写入log文件中。

至于使用哪种方式publish，那么就要看你的pipline文件是如何配置的了，具体可以查看/etc/ceilometer/pipline.yaml中的publishers配置。

agent-*三个采集组件分别负责采集不同类型的信息，agent-notification负责收集各个组件推送到oslo-messaging的消息，oslo-messaging是openstack整体的消息队列框架，所有组件的消息队列都使用这个组件；agent-compute只负责收集虚拟机的CPU内存IO等信息，所以他需要安装在Hypervisor机器上；agent-central是通过各个组件API方式收集有用的信息；agent-notification只需监听AMQP中的queue即可收到信息，而agent-compute和agent-central都需要定期Poll轮询收集信息。看下图来了解一下:

信息通过agent-*采集并由collector汇总处理，最终需要持久化到存储介质中，ceilometer目前支持的存储包括mysql、DB2、HBase、mongoDB，从支持的数据库来看，监控数据持久化的压力还是相当大的。

采集项

 

agent-*组件在启动时候，通过stevedore的插件机制来加载采集项，包括每个采集项对应的执行程序。stevedore的插件配置是利用了setuptools的entry_points，所以我们可以通过查看entry_points的配置信息，来确定有哪些采集项。

4.ceilometer组件

Ceilometer作为OpenStack内部 notification的最大消费者，OpenStack内部发生的一些事件都会发出对应的notification消息，比如说创建和删除instance，这些 信息是计量/计费的重要信息，因此第一种方式是Ceilometer第一数据来源，但是有些计量信息通过notification消息是获取不到的， 比如说instance的CPU的运行时间，或者是CPU的使用率，这些信息不会通过notification消息发送出来，因此Ceilometer增加了第二种 方式，周期性的调用相关的API去获取这些信息。

Ceilometer由5个重要的组件以及一个Message Bus组成，简单介绍一下各个组件以及他们之间的关系:

(1) Compute Agent

该组件用来收集计算节点上的信息，在每一个计算节点上都要运行一个Compute Agent，该Agent通过Stevedore管理了一组pollster插件， 分别用来获取虚拟机的CPU, Disk IO, Network IO, Instance这些信息，值得一提的是这些信息大部分是通过调用Hypervisor的API来获取的， 目前，Ceilometer仅提供了Libvirt的API。

(2) Central Agent

Central Agent运行在控制节点上，它主要收集其它服务(Image, Volume, Objects, Network)的信息，实现逻辑和Compute Agent类似，但是 是通过调用这些服务的REST API去获取这些数据的。

(3) Collector

这个应该是最为核心的组件了，它的主要作用是监听Message Bus，将收到的消息以及相应的数据写入到数据库中，它是在核心架构中唯一一个 能够对数据库进行写操作的组件。除此之外，它的另一个作用是对收到的其它服务发来的notification消息做本地化处理，然后再重新发送到 Message Bus中去，随后再被其收集。

目前，通过上面三个组件可以收集到的数据，参看这里。

(4) Storage

数据存储现在支持MongoDB, MySQL, Postgresql和HBase，现在H3又新增加了对DB2的支持，其中MongoDB是支持最好的。

(5) REST API

像其它服务一样，Ceilometer也提供的是REST API，API是唯一一个能对数据库进行读操作的组件，虽然后来加入的Alarm API能够直接对数据库 进行读写，但是Alarm应该是一个较为独立的功能，并且它的读写量也不大

(6) Message Bus

Message Bus是整个数据流的瓶颈，所有的数据都要经过Message Bus被Collector收集而存到数据库中，目前Message Bus采用RabbitMQ实现。

(7) Pipeline

 

Pipeline虽然不是其中一个组件，但是也是一个重要的机制，它是Agent和Message Bus以及外界之间的桥梁，Agent将收集来的数据发送到pipeline中， 在pipeline中，先经过一组transformer的处理，然后通过Multi Publisher发送出去，可以通过Message Bus发送到Collector，或者是发送到其它的 地方。Pipeline是可配置的，Agent poll数据的时间间隔，以及Transformers和Publishers都是通pipeline.yaml文件进行配置。