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進社區。