Ceilometer架構分析
項目計劃用Ceilometer做監控和計費， 從前期部署及使用Ceilometer的情況來看，發現Ceilometer存在比較多的問題，如占用大量的內存、請求響應慢等。基於這些問題從代碼的角度分析一下Ceilometer的系統架構，跟進ceilometer社區的進展。
基本概念
Ceilometer 的主要概念包括：
- Meter：計量項
- Sample：某Resource 某時刻某 Meter 的值
- Statistics：某區間 Samples 的聚合值
- Alarm：某區間 Statistics 滿足給定條件後發出的告警
Ceilometer 運行的服務：
- ceilometer-api：提供查看計量數據、下發告警策略的API
- ceilometer-agent-central：統計Openstack其它模塊服務的運行狀態，如NovaServiceAlive、NeutronServiceLogPollster
- ceilometer-agent-collector：監聽消息隊列收集其它agent(如ceilometer-agent-compute和ceilometer-agent-nofication)發送的sample，將收到的sample寫入後端存儲
- ceilometer-agent-notification： 監聽消息隊列收集其它模塊(Nova/Neutron)發送的notification，notification轉換成sample發送給ceilometer-agent-collection，notification轉換成event寫入後存儲
- ceilometer-alarm-evaluator：對比數據庫中的告警策略和計量的統計結果，將被觸發的告警消息通過消息隊列發送給ceilometer-alarm-notifier
- ceilometer-alarm-notifier：監聽消息隊列收集ceilometer-alarm-evaluator觸發的告警，按照配置的告警形式發送告警信息
- ceilometer-agent-compute：統計本地虛機的資源使用情況，將統計結果發送給ceilometer-agent-collector
後端存儲數據的種類：Resource、Sample(帶有時間序列)、Event、Alarm。(Resource和Sample使用metric_connection的配置，Event和Alarm使用event_connection的配置)
數據處理流程：
系統架構
總體架構
瓶頸問題
後端存儲
在較大規模的場景下，Ceilometer監控采樣數據庫累積較多，顯示監控數據需要依賴後端存儲統計結果，後端存儲響應請求會明顯變慢。
參考方案1：後端使用支持時間序列的存儲，如SSDB、Influxdb
參考方案2：參見下面的Goncchi
消息隊列
Ceilometer服務之間的通信依賴消息隊列，監控資源過多會引起RPC請求超時。
參考方案1：減少同一個notification進入消息隊列的次數，如ceilometer-agent-notification直接將sample寫入後端存儲
參考方案2： 參見下面的Monasca
狂占內存
Ceilometer服務啟動後會占用較多的內存，如ceilometer-agent-computer將采到的sample放入內存，用於轉換采樣數據
參考方案：Ceilometer提供了比較全面的功能，在實際場景下修改配置文件僅初始化需要的實例進行采樣，如禁用 NeutronServiceLogPollster
社區動態
Gnocchi
Gnocchi (TDBaaS Time Series Database as a Service) 是Ceilometer下一個子項目，目的是優化Ceilometer後端存儲性能的方案，Aodh是獨立出來的告警模塊(分別為meter和event提供告警)，目前已發布三個版本。
Gnocchi 架構：
Ceilometer 整體架構：
詳情參見：https://wiki.openstack.org/wiki/Gnocchi
Monasca
Monasca用於整合Openstack支持多租戶、可擴展、高可用、可容錯的監控系統，HP已在公有雲helion部署，其性能比ceilometer高很多。
Ceilometer + Monasca = Ceilosca
Ceilosca整體架構：
Ceilometer與Ceilosca性能對比：
詳情參見：http://www.slideshare.net/FabioGiannetti/ceilosca
Ceilometer架構分析