首页 > 代码库 > Ceilometer架构分析
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架构分析