Ceilometer简介

1.1 历史和任务

1.1.1 历史

l Ceilometer项目开始于2012年的4,5月份，由 Julien Danjou, Dreamhost 和 Canonical等发起。

l 通过6个月的开发，在2012年的10月份，伴随着Folsom的发布，Ceilometer也发布了它的v1.0版本，在 第一个版本中，Ceilometer主要实现了对一些重要数据的计量，包括Compute, Network, Memory, CPU, Image, Volume等，而且提供了REST API。

l 在2013年的2月份，Ceilometer完成了由Incubation到Integrated的转变，这意味着Ceilometer将做为OpenStack 发行版的一部分而发布。

l 在Grizzly版中，Ceilometer添加了对Swift的支持，增长了SQLAlchemy做为Storage Backend，开发了Multi Publisher， 而且发布了V2版本的API。

l 如今Havana中，Ceilometer已经发布了2个milestone，主要增长了HBase做为Storage Backend，Alarm功能也基本完成， 而且增长了UDP Publisher做为取代RPC发送消息的第二选择，更加高效。正在开发的havana-3，一个重要的新功能是 又增长了DB2做为Storage Backend.

 

1.1.2 任务

Ceilometer的使命通过一次变化，在项目提出之初，对它的定位就只是专一于计量，为计费而生。咱们能够从它 v1.0的Mission看出。

可是Ceilometer收集的是有用的数据，咱们都知道数据的价值，因此随着Ceilometer的发展，对它的需求也在不断的增加， 除了计费以外，像监控、Autoscalling、数据统计分析、benchmarking等都须要这些数据。因此从Grizzly开始，Ceilometer 扩展了它的目标，不只仅局限在计量和计费上，又因为Ceilometer的扩展性很强，很容易经过扩展去知足这些需求。

1.2 核心架构

Ceilometer收集的是OpenStack内部各个服务(nova, neutron, cinder等)，以及未来不少未知的服务的信息，这个基本的 需求决定了它的架构必须是灵活可扩展的，所以，Ceilometer采用了一种“微内核”的架构，经过插件的机制来实现扩展。

这里不得不说一下它的设计者Doug Hellmann为此作出的努力，可扩展能够说是软件设计的一个基本特征，不一样的项目 有不一样的实现方法，Doug Hellmann花了一年的时间，调研了不少项目的扩展机制，包括Sphinx, Nose, Django,SQLAlchemy, Nova等，最终开发了Python的一个基于setuptools entry points三方库Stevedore， 而且使用Stevedore设计了Ceilometer的插件机制，如今Stevedore已经被OpenStack中的不少新的项目使用， nova中也有用到。

下面是Ceilometer的核心架构图：

 

Ceilometer使用了两种收集数据的方式，一种是消费OpenStack各个服务内发出的notification消息(对应上图中的蓝色箭头)，一种 是经过调用各个服务的API去主动的获取数据(对应上图中的黑色箭头)。

为何会须要两种方式呢？

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文件进行配置。

总体上看，Ceilometer对数据流的处理，给人一种大禹治水的感受。

 

1.3 Roadmap and status

可能因为Ceilometer的PTL Julien Danjou比较强悍，Ceilometer从一开始就保持着很是好的项目进度，这也是它可以在很短的时间内，就由孵化项目 成为OpenStack Core项目的缘由之一，在Havana Release中，已经发布了2个Milestone，分别实现了10, 11个Blueprints，修复了60多个bug，正在进行 的Havana-3，有27个Blueprints，其中大部分都保持着很好的进度。

l 在H版中，一个重量级功能是给Ceilometer添加了Alarm功能，该Alarm的实现几乎跟AWS的CloudWatch Alarm如出一辙。

l 在H-1中，添加的POST meter API是一个重要的API，它的实现实际上是打破了Ceilometer只局限在OpenStack内部服务的限制。能够直接经过该API 向Ceilometer写入数据，而不是去写plugin，完成了Ceilometer由poll向poll+push的转变。

l 在H-2中，实现的One Meter per Pollster Plugin简洁和规范化了Ceilometer的插件机制。

l 在H-3中，也有不少BP会被实现，对API进行查询优化的Implements GROUP BY operations in API，Pipeline的Mutiple dispatcher enablement, 以及db2 support, Enable/Disable/Configure a pollster in runtime，还有一个Monitoring Physical Devices 的BP，它的实现会使 Ceilometer向监控迈出重要一步，可是该BP中间换过一个Assignee，如今进度比较慢。

1.4 计量或监控

这个问题相信不少人都比较关心，并且也常常在邮件列表中被争论，在Ceilometer的Mission中清晰的写着Its primary targets are monitoring and metering， 可是到底Ceiometer能用来作什么，为何会有这些争论，先不忙下结论，先来看看别人是如何使用它的。

Ceilometer的PTL Julien Danjou是一个自由职业者，在不少的开源社区作太重要贡献，有不少公司雇佣他作技术Leader，近期的包括eNovance, DreamHost, Talligent 和 EISTI，而这些公司都使用Ceilometer来作billing systems，accounting solution for openstack，我想这应该是最有力的解释了。

Ceilometer在G版改变了它的Mission以后，在Monitoring方面作了一些努力，曾想和其它一些开源监控项目合并，好比三星的synaps，还有Healthnmon，可是最后因为各类缘由都不了了之。G版为这个Misson作的比较重要的工做集中在数据流的导入导出上，直到H版Ceilometer才为Monitor作了一些实际工做，包括Alarming, Monitoring Physical Devices ,Ceilometer CloudWatch API，可是目前，只有Alarm的大部分代码被Merge进代码仓库中。

虽然计量和监控他们的数据类似，可是对数据的要求却 截然不同，前者重点在Allocated，然后者重点在Utilization，Allocated这些信息可以很容易经过消费其它服务的notification消息来得到，好比经过 捕获compute.instance.create.start, compute.instance.delete.end这些Event能够比较准确的知道一个instance是否建立成功，是否删除失败，可是像Instance 的Memory Utilization, Disk Space Utilization这些数据是监控很是关心的，然而想获取这些数据却不容易，没有现成的API可使用，写Agent，兼容性是个头疼的问题， 这也是虚拟化平台监控的难点之一，目前Ceilometer在这方面仍是空白，由此在邮件列表中也引起的一次不愉快的争论。可是关于OpenStack的监控，Mirantis给出了一个解决方案，使用sFlow 来解决虚拟资源监控的难点，有兴趣能够阅读一下。

因此，最终的结论是Ceilometer作计量系统已经比较成熟，可是若是有能力hack它，使用它作监控也是能够的，毕竟它已经作了一些工做，并且有很好的扩展性，相信在 I版会在这方面投入更多精力的。

1.5 UnitedStack’s Effort

咱们使用Ceilometer来作基础监控服务。从如今Ceilometer的测量指标来看，它根本不能知足咱们的需求，数据来源太少，并且大部分的数据对监控来讲，没有多大的价值，若是经过写插件的形式去主动的poll数据，不能知足众多应用程序通用性的需求，而且Ceilometer对虚拟资源的监控有着难以规避的问题。这些问题迫使着咱们须要再次扩展Ceilometer的Mission，将它的Within OpenStack扩展到Out of OpenStack，让Ceilometer更加的开放，更加的通用。

因而，咱们给Ceilometer添加了Ceilometer CloudWatch API，一是解决了数据来源的问题，不少应用程序都会提供基于AWS CloudWatch  API的监控数据，咱们能够无痛的收集到这些数据；二是将Ceilometer由poll模式，改形成了push+agent模式，变得更加的通用，可使它不只仅局限在OpenStack内部的服务，使它能够面对更多的未知的服务；三是CloudWatch API为Heat基于Ceilometer作AutoScalling提供了接口支持。

早在G版的时候，Ceilometer就想和三星公司开源的synaps合并，它是一个OpenStack的监控项目，提供CloudWatch API，可是后来因为种种缘由做废了，因此，咱们的patch一提出，就受到了社区的热烈欢迎，而且很快给出了修改的意见。目前，该patch仅仅实现了三个接口，还有一些问题须要修改，但愿最迟在I版能Merge进社区。