OpenStack的Ceilometer组件详解

一：简介

一、背景

1. 为什么要有Ceilometer

1. 通常云的计算层次

1. 计量（Metering）：收集资源的使用数据，其数据信息主要包括：使用对象（what）, 使用者（who）, 使用时间（when）和用量（how much）。

2. 计费（Rating）：将资源使用数据按照商务规则转化为可计费项目并计算费用。

3. 结算（Billing）：收钱开票

2. Ceilometer 的目标是计量（Metering）方面，为上层的计费、结算或者监控应用提供统一的资源使用数据收集功能。

2. 历史

1. 项目始于2012年四五月份，10月份发布第一个版本，实现对一些重要数据的计量，包括Compute, Network, Memory, CPU, Image, Volume等，并且提供了REST API。

2. 2013年作为OpenStack发行版的计量计费功能的项目，后来逐步发展增加了部分监控采集和告警等功能。

3. 但是由于种种原因，Ceilometer项目在Openstack中已经处于一种没落的状态，基本没有什么新的特性开发了，原本该项目的PTL也另起炉灶开始在做Gnocchi项目(ceilometer的后端存储系统)。

4. 虽然该项目已经没有前几年活跃，但是还是在很多公有云场景中有比较多的应用，而生产环境中，可能很多公司还用的是M、N版本。

二、概念

1. Meter

1. 概念：资源使用的某些测量值(计量项，监控项)，如内存占用、网络IO、磁盘IO等。

2. 属性：名称（name）、单位（unit）、类型（cumulative：累计值；delta：变化值；gauge：离散或者波动值）以及对应的资源属性等。

2. Sample

1. 概念：每个采集时间点上meter对应的值（某时刻某个 resource 的某个 meter 的值），收集数据具有时间间隔。

2. 属性：测量值（meter）、采样时间（timestampe）和采样值（Volume）。

3. Statistics：某个周期内（Period）的Samples聚合值，包括计数（Count）、最大（Max）、最小（Min）、平均（Avg）、求和（Sum）等

4. Resource：被监控的资源对象，如虚拟机、磁盘等

5. Alarm

1. 概念：告警机制，可以通过阈值或者组合条件告警，并设置告警时触发的action，但是相对ceilometer是独立的一块，只是放在了ceilometer的代码树里面。

2. 类型

1. 阈值告警（Threshold Alarm）：根据一个监控项的阈值去判断Alarm的状态，它包括几个要素：

1. 一个静态阈值和比较方法（a static threshold value & comparison operator）

2. 指定的 meter statistic （against which a selected meter statistic is compared）

3. 比较的时间窗（over an evaluation window of configurable length into the recent past.）

2. 组合告警（Combination Alarm）：根据多个监控项建立一个Alarm，多个alarm之间是or/and的关系。

3. 属性

1. name: 告警名称

2. meter-name：meter 名称

3. threshold: 阈值

4. comparison_operator: 比较方式，有6个可选：lt, le, eq, ne, ge, gt，默认是eq

5. statistic: 比较方式，有5种可选：max, min, avg, sum, count，默认是avg

6. period: 获取该监控指标的监控数据的时间周期

7. evaluation_periods：统计次数

8. alarm-action：告警产生后的动作

4. Action（动作）

1. 'log://'：Alarm 被写入 Log 文件

2. Webhook URL：这是一个 HTTP(S) endpoint 的URL，例如 'http://130.56.250.199:8080/alarm/instances_TOO_MANY'。Alarm 的内容会以 JSON 的格式被 POST 到该URL 中。

三、组件

1. 控制节点

1. Central Agent：调用OpenStack其它组件api采集指标

2. Notification Agent：接收其它组件主动上报的通知消息

3. Collector：基于AMQP接收消息，并记录到DataStore

4. API：运行在管理节点，提供接口访问Data Store

2. 计算节点

1. Compute Agent：采集本节点性能指标

二：数据处理

一、数据收集

1. Poller方式

1. Compute agent （ceilometer-agent-compute）运行在每个 compute 节点上，以轮询的方式通过调用 Image 的 driver 来获取资源使用统计数据。

2. Central agent （ceilometer-agent-central）运行在 management server 上，以轮询的方式通过调用 OpenStack 各个组件（包括 Nova、Cinder、Glance、Neutron、Swift 等）的 API 收集资源使用统计数据。

2. Notificaiton方式

二、数据处理

1. Pipeline（处理器）

1. Meters 数据的处理使用 Pipeline 的方式，即Metes 数据依次经过（零个或者多个） Transformer 和（一个或者多个）Publisher 处理，最后达到（一个或者多个）Receiver。其中Recivers 包括 Ceilometer Collector 和外部系统。

2. Ceilometer 根据配置文件 /etc/ceilometer/pipeline.yaml 来配置 meters 所使用的 transformers 和 publishers。以 cpu meter 为例：

 1 sources: A source is a producer of samples
 2 ......
 3   - name: cpu_source
 4     interval: 600  ## Poller 获取 cpu samples 的间隔为 10 分钟
 5     meters:
 6         - "cpu"
 7     sinks:
 8         - cpu_sink
 9 
10 ......
11 sinks: A sink on the other hand is a chain of handlers of samples
12 ......
13   - name: cpu_sink
14     transformers:  ## 转换器
15       - name: "rate_of_change"
16         parameters:
17                 target:
18                     name: "cpu_util"
19                     unit: "%"
20                     type: "gauge"
21                     scale: "100.0 / (10**9 * (resource_metadata.cpu_number or1))"
22      publishers:  ## 分发器
23          - notifier://

2. Transformer （转换器）

1. unit_conversion：单位转换器，比如温度从°F 转换成°C

2. rate_of_change:：计算方式转换器，比如根据一定的计算规则来转换一个sample

3. accumulator：累计器，如下图所示

3. Publisher（分发器）

三、数据保存

1. Ceilometer Collector 从 AMQP 接收到数据后，会原封不动地通过一个或者多个分发器（dispatchers）将它保存到指定位置。目前它支持的分发器：

1. 文件分发器：保存到文件 - 添加配置项dispatcher = file 和 [dispatcher_file] 部分的配置项

2. HTTP 分发器：保存到外部的 HTTP target - 添加配置项 dispatcher = http

3. 数据库分发器：保存到数据库 - 添加配置项 dispatcher = database。

2. Ceilometer 支持同时配置多个分发器，将数据保存到多个目的位置。比如在 ceilometer.conf 中做如下配置使得同时使用 file 和 database dispatcher：

1 [DEFAULT]
2 dispatcher = database
3 dispatcher = file
4 
5 [dispatcher_file]
6 backup_count = 5
7 file_path = /var/log/ceilometer/ceilometer-samples
8 max_bytes = 100000