本部落格所有文章採用的授權方式為 自由轉載-非商用-非衍生-保持署名 ，轉載請務必註明出處，謝謝。

宣告：
本部落格歡迎轉發,但請註明出處，保留原作者資訊
部落格地址：孟阿龍的部落格
所有內容為本人學習、研究、總結。如有雷同，實屬榮幸

注: 本文基於當前Openstack的Q版本進行分析

1. 背景

ceilometer專案是openstack中用來做計量計費功能的一個元件，後來又逐步發展增加了部分監控採集、告警的功能。由於種種原因，ceilometer專案在Openstack中已經處於一種沒落的狀態，基本沒有什麼新的特性開發了，原本該專案的PTL也另起爐灶開始在做Gnocchi專案(ceilometer的後端儲存系統)。雖然該專案已經沒有前幾年活躍，但是還是在很多公有云場景中有比較多的應用，而生產環境中，可能很多公司還用的是M、N版本。

2. 基本概念

• meter：
  針對一個資源的某些測量值，比如，一個虛擬機器可以有多個meters：虛擬機器在一段時間內cpu的使用時間、磁碟的請求次數等。在ceilometer中針對這些meter定義了三種類型：
  • Cumulative(累積型): 隨著時間會不斷增長(eg. disk I/O)
  • Gauge(測量型):離散型的值(eg. floating IPs)和浮動的值(eg. swift物件的數量)
  • Delta(變化量)：一段時間內某個採集值的變化量(eg. 頻寬變化量)
• sample：
  針對一個特定的meter的具體資料結構
• event:
  在某個特定時間，發生的一個動作，比如：19:09:08 建立了一個虛擬機器
• resource：
  資源，比如instance(虛擬機器)、disk(磁碟）都是資源

3. High-Level 架構

ceilo-arch.png

如上，是當前Ceilometer的一個全域性概覽邏輯圖.
以上ceilometer的每一個服務都是基於可橫向擴充套件來設計的。實際生產環境中，可以根據系統的負載，決定來增加例項或者增加單個例項的worker數。當前Ceilometer主要提供兩個核心服務：

1. polling agent：輪詢agent，是一個deamon服務，通過週期性呼叫Openstack內部服務的介面或者一些外部介面獲取指定resource的meter資料
2. notification agent：一個deamon服務，通過監聽訊息佇列獲取相關資料，將其轉換為event和sample，並根據pipeline中定義的方法將資料傳送出去
   這和以前的版本相比，簡化了不少，以前ceilometer包含了(polling-agent,notification-agent,collector，ceilometer-api)
   通過Ceilometer收集到的資料可以被髮送到不同的後端。Gnocchi是用來提供對捕獲到的時間序列的測量資料的儲存和查詢。Gnocchi未來的趨勢是取代當前現存的metering資料儲存介面(當前儲存在mongodb、mysql等儲存後端)。Aodh是一個告警服務，在滿足使用者設定的告警條件時，可以傳送告警資訊，其後端可以對接不同的資料庫。Panko是用來獲取系統中的各類事件並將其儲存到對應後端資料庫。

4. 資料獲取的過程

4.1 資料採集

1-agents.png

上圖展示了ceilometer-agent怎樣從不同的資料來源獲取到資料
Ceilometer共有兩種方法來收集資料：

1. Notification agent，從notification bus上獲取訊息，將其轉換為ceilometer的sample或者event資料
2. Polling agent，週期性呼叫系統中的一些API或者外部工具來獲取資料。輪詢服務可能會對API服務帶來較大的影響，因此對應的API服務需要針對這種輪詢機制做一些優化。
   以上第一種方法是ceilometer-agent-notification提供的，他可以監控訊息佇列上的資訊。第二種方法是通過polling-agent實現，通過配置可以實現輪詢本地虛擬化層或者遠端API來獲取資料。

4.2 notification agent監聽資料

2-1-collection-notification.png

notification-agent可以消費來自不同服務上報的訊息資料。
這個系統的核心是notification-agent這個deamon服務，他可以監聽openstack元件(比如nova、glance/cinder/neutron/等)傳送到訊息佇列上的資料，以及ceilometer內部發送過來資料

notification-agent載入ceilometer.notification這個namespace下的一個或者多個外掛.每個外掛都可以監聽任何topic，預設的都會監聽notifications.info, notifications.sample,notifications.error.監聽程序從配置的topic抓取下來訊息之後，將其分發到合適的外掛處理成event和sample。

基於Sample的外掛提供了一個方法來獲取他們所關注的事件型別，然後據此呼叫對應的回撥方法來處理訊息。註冊的毀掉方法通過notification的pipeline來配置生效與否。通過外掛配置的事件型別對新進來的訊息進行過濾，因此回撥介面最終只會收到他們所關心的資料。

4.3 Polling Agent輪詢獲取資料

2-2-collection-poll.png

Polling-agent通過主動呼叫service介面查詢來獲取資料。
部署在計算節點上的polling-agent用來輪詢計算資源的資料(這樣agent可以更有效的和本地虛擬化層互動)，也被稱為compute-agent。通過服務API輪詢查詢非計算資源相關資料的agent部署在控制節點上，也被稱為central-agent。在all-in-one環境中，一個agent也支援同時提供以上兩種角色。相反的，也可以通過部署多個agent例項來分擔系統負載。Polling-agent程序可以載入ceilometer.poll.compute,ceilometer.poll.central,ceilometer.poll.ipmi這三個namespace中配置的外掛。

4.4 資料處理

4.4.1 pipeline manager

3-Pipeline.png

以上元件實現ceiloemter的pipeline。
ceilometer提供抓取資料的agent，控制資料、通過多重pipeline將資料傳送到多種後端的能力。這種功能通過notification-agent來實現。

4.4.2 資料傳送

5-multi-publish.png

上圖展示了一個sample資料怎樣被髮送到多個不同後端
當前處理過的資料可以被髮送到8種不同的後端

1. gnocchi, 傳送samples/event資料到Gnocchi-api
2. notifier, 傳送資料到訊息佇列，最終可以被內部系統消費
3. udp, 通過UDP包將資料傳送出去
4. http, 傳送資料到REST介面
5. file, 傳送資料到指定的檔案
6. zaqar, 一個用於web和移動開發者的多租戶雲訊息和通知服務
7. https, 通過SSL加密的REST介面HTTP服務
8. prometheus, 傳送samples資料到 Prometheus Pushgateway

5. 儲存/訪問資料

Ceilometer是設計用來單純的生產和序列化雲資料。Ceilometer生產的資料可以被髮送到通過pipeline-publishers中定義 的多重後端。推薦的方法是將資料傳送到Gnocchi用於有效的時間序列儲存以及資源生命週期的追蹤。

參考：
https://docs.openstack.org/ceilometer/latest/contributor/architecture.html

以上我們可以看出，ceilometer關鍵的元件包含：ceilometer-agent-compute，ceilometer-agent-notification，外掛採集資料這幾個核心，後邊會分別對其進行分析：

1. ceilometer-agent-compute原理和程式碼分析(已完成)

2. ceilometer外掛採集原理和程式碼分析(已完成)

3. ceilometer-agent-notification原理和程式碼分析(待開展)