一、 Ceilometer
- 1. 概述
Openstack ceilometer主要用于监控虚拟机、服务（glance、image、network等）和事件。虚拟机的监控项主要包括CPU、磁盘、网络、instance。
针对一个计量和监控系统需要考虑到的问题，可能都有哪些，打算上这样一个系统的时候，主要有三个问题需要考虑，一个是数据收集的问题，计量和监控，收集很多可能各种各样数据；另外一个是存储的问题，这么大量的数据收集过来怎么存储，怎么有效的查询；第三个问题是报警，我收集过来这些数据之后，用这些数据做一些事情，比如报警，能够及时地通知到管理员。Telemetry（Ceilometer、Gnocchi、Aodh）这三个项目分别就是解决这三个问题的。
- 2. 基本概念
ceilometer 主要有下面几个概念:
- meter 是ceilometer定义的监控项，诸如内存占用，网络IO，磁盘IO等等
- sample 是每个采集时间点上meter对应的值
- statistics 一般是统计学上某个周期内，meter对应的值(平均值之类)
- resource 是被监控的资源对象，这个可以是一台虚拟机，一台物理机或者一块云硬盘
- alarm 是ceilometer的告警机制，你可以通过阈值或者组合条件告警，并设置告警时触发的action
- 3. 内部架构
3.1 ceilometer整体架构
3.2进程介绍
l A compute agent (ceilometer-agent-compute)
l A central agent (ceilometer-agent-central)
l A notification agent (ceilometer-agent-notification)
l A collector (ceilometer-collector)
l An alarm evaluator (ceilometer-alarm-evaluator)
l An alarm notifier (ceilometer-alarm-notifier)
l An API server (ceilometer-api)
3.3 Gathering the data
3.4 Notification Agents: Listening for data
3.5 Polling Agents: Asking for data
3.6 Processing the data
3.7 Transforming the data
3.8 Publishing the data
3.9 Storing the data
3.10 Accessing the data
二、 Gnocchi
- 1. 简述
Gnocchi的提出是为了解决Ceilometer性能问题，Ceilometer早期的时候数据模型设计的不是特别好，导致针对这几个数据库的性能都不太好。
Ceilometer因为当初提出得很早，又做过很多转变，导致他数据很灵活。但是性能有些下降。所以专门做了Gnocchi这样一个项目解决他这个问 题。这个是Gnocchi对解决问题的一个抽象，抽象出了Resource和Metric两个概念。刚刚提到Ceilometer是两种数据，一个是 Resource，一个是时间序列的数据，即Metric，Gnocchi主要就是来存储这些数据的，而Resource是索引，是Resoruce到 Metric的索引，这边是随着时间增长，对这些时间数据的索引，就是有哪些资源在Metric做这个事情。
- 2. 基本概念
2.1 Metric
指资源的某一项指标。如,主机的cpu，disk。
2.2 Measures
metric的检测的具体数据。
2.3 Resource
是被监控的资源对象，这个可以是一台虚拟机，一台物理机或者一块云硬盘
2.4 Resource Type
是用来管理resource的，只有预先定义resource的type，ceilometer collector注册资源的时候，才可以成功。Gnocchiclient没有提供创建type的cli。目前官方提供类型，请查看：http://docs.openstack.org/developer/gnocchi/resource_types.html
2.5 Archive Policy
metric的检测数据的存储规则。
l Granulariy 处理数据的时间粒度。多长时间metric处理一次聚合数据。
l Points 保存的数据数量。
l timespan = points x granularity
l back_window metricd只处理时间戳在未来或在最近一次处理聚合周期内的检测数据。如果需要处理比当前处理数据周期老的数据，需要去设back_window。
For example, if an archive policy is defined with coarsest aggregation of 1 hour, and the last point processed has a timestamp of 14:34, it’s possible to process measures back to 14:00 with a back_window of 0. If the back_window is set to 2, it will be possible to send measures with timestamp back to 12:00 (14:00 minus 2 times 1 hour).
l aggregation_methods 执行gnocchi capabilities list可以查看当前支持的聚合方法。在配置文件中，也可以配置default_aggregation_methods。
2.6 Archive Policy Rule
通过创建archive policy rule，模式匹配的方式把archive policy分配给metric
- 3. 整体架构
gnocchi的后端服务分成三部分：
l gnocchi-api
a HTTP REST API 以wsgi方式启动的api服务。（metric/resource resource type/archive policy/archive policy rule的操作+measures的保存）
l gnocchi-statsd
（udp数据接收，后续会支持tcp数据接收，当前没有通过udp发送数据，这里应该是空跑）
StatsD是用来收集数据的，收集完数据就发送到其他服务器进行处理，这里是存放到tmp目录下。
l gnocchi-metricd
MetricProcessor核心服务，处理数据的聚合，清理等动作。
- 4. 数据存储
4.1 简单介绍
将数据裂化成两部分（index和storage）：
l index driver：存资源索引值（resource）。
l storage driver：存时间时间序列上的数据值（metric）。
支持多种存储方式：
n File
n Swift
n Ceph (preferred)
n InfluxDB (experimental)
前三种，通过gnocchi的自己写的一个叫Carbonara（作者就是个吃货有没有）的类库支持
InfluxDB 本身就是一个时间序列的数据库，但是当前对接还处于试验阶段，bug较多
4.2 Data split
在Gnocchi 1.3之前，一个metric的数据是存储到一个对应的文件中（每一个聚合方法对应一个文件）。其实，就是从聚合方法的维度去划分数据。在2.0版本之后，在此基础上，通过配置point的大小，来划分块。增加了CRUD的并发。
4.3 Data compression
the suite of timestamps timestamps = [41230, 41235, 41240, 41250, 41255] is encoded into timestamps = [41230, 1, 1, 2, 1], interval = 5
To actually compress the values, I tried two
different algorithms:LZ4 XOR
4.4 Gnocchi aggregation mechanism
4.5 总结
1. 对存储的数据进行了分类处理。
2. 对数据进行压缩存储
3. 只存储处理后的聚合数据，原始数据删除。
4. 使用分布式存储，易于存储的扩展。
- 5. 性能提升
5.1 测试环境
硬件：2 台（2×Intel Xeon E5-2609 v3 (12 cores in total) 32 GB of RAM）
一个做gnocchi 一个client
软件：RHEL 7 disable OpenStack components
PostsgreSQL indexer
file storage driver
The OpenStack Keystone authentication middleware was not enabled in this setup
5.2 Metric CRUD operations
5.3 Sending and getting measures
5.4 Comparison with Ceilometer
Most Gnocchi operations are O(log R) where R is the number of metrics or resources, whereas most Ceilometer operations are O(log S) where S is the number of samples (measures). Since is R millions of time smaller than S, Gnocchi gets to be much faster.
三、 Aodh
1. Aodh把告警和事件分开处理，使告警的检测和响应更加及时。
l An API server (aodh-api). 为告警数据的存储和访问提供借口。
l An alarm evaluator (aodh-evaluator). 根据统计的数据，来评估是否需要触发告警.
l A notification listener (aodh-listener). 监听事件，触发事件相关的告警.
l An alarm notifier (aodh-notifier). 根据配置的告警方式，发出告警.
- Ceilometer-alarm
- 总结
Ceilometer-alarm有以下问题，而aodh正是解决了以下三个问题。
1） 目前有一个比较纠结的问题就是alarm和ceilometer的关系，虽然alarm的代码写在ceilometer的代码树中，其实，他们两个并没有紧密的关系，alarm是ceilometer api的消费者，把他们两个分开也是完全可以的。
2） 目前alarm是ceilometer api的消费者，每个alarm被检查的时间间隔是60s，当alarm数量很多的时候，会给api造成比较大的压力，所以有人提议让alarm直接访问数据库。
3） 目前，有的使用ceilometer作为billing服务，但是alarm和billing使用的同一个数据库，这无形中有了一些安全隐患，而且alarm和billing这两个对数据的时效性要求还不一样，alarm可能只需要最近一段时间的数据，而billing则要求数据保持较长的时间，所以这导致db-ttl也比较难做。
四、 多进程pdb调试
1.在代码中，添加下面的类：
import sys
import pdb
class ForkedPdb(pdb.Pdb):
"""A Pdb subclass that may be used
from a forked multiprocessing child
"""
def interaction(self, *args, **kwargs):
_stdin = sys.stdin
try:
sys.stdin = file('/dev/stdin')
pdb.Pdb.interaction(self, *args, **kwargs)
finally:
sys.stdin = _stdin
2. 在需要打断点的地方，添加ForkedPdb().set_trace()即可。
参考：