Ceilometer + Aodh + Gnocchi 介绍

1、  Ceilometer

1. 1.    概述

Openstack ceilometer主要用于监控虚拟机、服务（glance、image、network等）和事件。虚拟机的监控项主要包括CPU、磁盘、网络、instance。

针对一个计量和监控系统须要考虑到的问题，可能都有哪些，打算上这样一个系统的时候，主要有三个问题须要考虑，一个是数据收集的问题，计量和监控，收集不少可能各类各样数据；另一个是存储的问题，这么大量的数据收集过来怎么存储，怎么有效的查询；第三个问题是报警，我收集过来这些数据以后，用这些数据作一些事情，好比报警，可以及时地通知到管理员。Telemetry（Ceilometer、Gnocchi、Aodh）这三个项目分别就是解决这三个问题的。

1. 2.    基本概念

ceilometer 主要有下面几个概念:

• meter 是ceilometer定义的监控项，诸如内存占用，网络IO，磁盘IO等等
• sample 是每一个采集时间点上meter对应的值
• statistics 通常是统计学上某个周期内，meter对应的值(平均值之类)
• resource 是被监控的资源对象，这个能够是一台虚拟机，一台物理机或者一块云硬盘
• alarm 是ceilometer的告警机制，你能够经过阈值或者组合条件告警，并设置告警时触发的action

1. 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

 

2、  Gnocchi

1. 1.   简述

Gnocchi的提出是为了解决Ceilometer性能问题，Ceilometer早期的时候数据模型设计的不是特别好，致使针对这几个数据库的性能都不太好。

Ceilometer由于当初提出得很早，又作过不少转变，致使他数据很灵活。可是性能有些降低。因此专门作了Gnocchi这样一个项目解决他这个问 题。这个是Gnocchi对解决问题的一个抽象，抽象出了Resource和Metric两个概念。刚刚提到Ceilometer是两种数据，一个是 Resource，一个是时间序列的数据，即Metric，Gnocchi主要就是来存储这些数据的，而Resource是索引，是Resoruce到 Metric的索引，这边是随着时间增加，对这些时间数据的索引，就是有哪些资源在Metric作这个事情。

1. 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

 

1. 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核心服务，处理数据的聚合，清理等动做。

 

 

1. 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.   使用分布式存储，易于存储的扩展。

1. 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.

3、  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). 根据配置的告警方式，发出告警.

 

 

 

 

 

 

 

 

 

1. Ceilometer-alarm

 

1. 总结

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也比较难作。

4、  多进程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()便可。

 

参考：

http://www.lygrzs.com/?p=797

https://www.ustack.com/blog/telemetry/

http://www.lygrzs.com/?p=826

https://wiki.openstack.org/wiki/Telemetry