如何基于 Openstack telemetry 项目实现云监控报警服务

1、OpenStack Telemetry 简介

OpenStack Telemetry 项目是 OpenStack big tent 下负责计量统计的组件，目前 Telemetry 是包含了四个子项目，Ceilometer、 Aodh、Gnocchi 和 Panko。其中的 Ceilometer 项目是最早 OpenStack 项目中负责计量统计的服务，但是由于云平台数据收集越来越多造成 CCCeilometer 越来越复杂，因此在 Mitaka 版本开始 ceilometer 项目开始分解为不同项目，并统称为 OpenStack Telemetry。

云监控告警服务，主要包括三个部分: 计量数据收集、计量数据存储、告警服务。

OpenStack Telemetry 的架构如图所示（Mitaka 版本），其中 Ceilometer 是负责数据收集，Gnocchi 则负责 meter 数据存储，Aodh 项目负责告警服务，Panko 负责 Event 数据存储。由于 Event 和 Meter 两种数据类型不同，CCCeilometer 社区将两种数据分开处理。由于 Panko 项目到 newton 才有 release，而笔者采用的 mitaka 验证环境，本文中不涉及 Panko。

图 1 Telemetry 逻辑架构

2、数据收集服务

Ceilometer 服务主要用于数据收集，并提供两类数据的收集 meter 和 Event。

• Meter 数据由 Ceilometer 的 polling agent 主动获取。

• Event 数据来源是 OpenStack service 的 notification，例如 instance/volume/network 等创建更新删除等等。

Ceilometer 服务主要包含:

a) polling agent：定期轮询获取监控数据并将数据发送给 CCCeilometer notification agent 做进一步处理，通过 libvirt 接口或者 snmp 或者 OpenStack service API。

Polling agent 又根据 namespace 做了 metering 的区分，分别对应不同的 agent

• Central polling agent，主要是通过 OpenStack API 进行云平台的数据收集
• Compute polling agent 则是通过与 hypervisor 的接口调用定期获取统计数据
• Impi polling agent 则是通过 ipmi 协议收集数据

图 2 central polling agent 获取监控数据

图 3 OpenStack services notification 数据收集

b) notification agent：在 Mitaka 版本中，notification agent 通过监听 message queue，将 message 转化为 event 和 sample 并且执行 pipeline 处理，如图所示。例如虚拟机的 CPU 利用率，libvirt 目前只提供 CPUTIME 的查询，如果为用户展示 CPU 利用率要做数据转换，notification agent 就会根据 pipeline 中的定义执行数据转换，并将处理后的数据，通过 message queue 发送给 CCCeilometer collector

图 4 pipeline Manager 数据处理

c）Ceilometer collector：ceilometer collector 的作用就是将收集到数据存储到存储系统中，CCCeilometer 支持多种存储后端：

• 文件系统

• 数据库

Driver

API querying

API statistics

MongoDB

Yes

Yes

MySQL

Yes

Yes

PostgreSQL

Yes

Yes

HBase

Yes

Yes, except groupby & selectable aggregates

• Gnocchi
• HTTP

对与存储系统的选择是非常关键的，公有云环境中会随着用户和资源的增长数据也会持续增长，这是对云监控服务来说是一个非常大的挑战。下小节，将为描述，我们是如何考量存储系统的。

3、监控数据存储系统抉择

对于计量统计服务来说，存储服务的性能是非常关键的，其中一个要求就是对它的存储量有很大的要求，公有云平台数量很大，每时每刻不断的有数据往系统里面塞。对数据库的吞吐能力要求很高，然后就是对查询性能要求很高。CERN 作为 OpenStack 最大的规模的实践，也采用了 MongoDB 去做 meter 数据存储，但是一直以来 MongoDB 的也一直被诟病，一个存储空间占用，一个随之数据量增多响应时间变大的问题。

3.1 Gnocchi 简介

Gnocchi 是 OpenStack Telemtry 的 Metric serivce，开始与 2015 年，目的在与解决 CCCeilometer 的监控数据存储的性能问题。Gnocchi 支持的存储 driver 有文件系统、Swift、s3、Ceph

官方建议使用 ceph，gnocchi 对 ceph 的数据存储做了很多优化。

Gnocchi 架构如图所示，包含两部分 index 和 storage。Gnocchi API 提供 restful API 接口，接受到数据存储请求时，会创建 index 在数据库中，并把数据写入临时待处理区，并加入时间戳。

Metricd 服务则从待处理数据区获取带有时间戳的数据，将数据追加到统计数据文件中。gnocchi 为了节省存储空间在最新版本中加入了压缩算法支持。

对于 MongoDB 和 Gnocchi 的选择，我们做了实际的测试，主要关注两项指标存储空间需求和查询数据响应时间。

3.2 两种方案的测试及分析

方案一：Gocchi + Ceph vs. MonogDB

a) 测试方法

Ceilometer 支持配置多个存储后端，修改 ceilometer.conf

meter_dispatchers=gnocchi
meter_dispatchers=database

数据收集时间：5.5 小时

数据收集量：1 个 compute 节点

数据收集频率：1 秒

资源：2 个 vm，1 个 loadbalancer，1 个 router

测试环境： all-in-one

Step1：停掉所有的 CCCeilometer

Step2：gnocchi 清除所有的 resource

Step3: 从 ceph pool 中删除所有的 gnocchi 相关的 objects

rados -p gnocchi rm *Step4: 从 MMMongoDBDBDB 中清除 CCCeilometer 的 collection

 
mongodb
> use ceilometer
> db.meter.drop()
> db.resource.drop()

Step 5: 修改 ceilomter 配置文件 ceilometer.conf

 
[default]
meter_dispatchers=database
Meter_dispatchers=gnocchi
[database]
metering_connection = mongodb://ceilometer:ceilometer@127.0.0.1:27017/ceilometer

Step 6: 设置数据采集周期为 1 秒

 
Pipeline.yaml 中设置 interval 参数为 1
/etc/neutron/metering-agent.ini
# Interval between two metering measures (integer value)
measure_interval = 1
# Interval between two metering reports (integer value)
report_interval = 1

Step 7: 创建存储数据的 Archive policy，并设置粒度为 1s

 
gnocchi archive-policy create -d granularity:1s,points:86400 1days_per_sec 
 
+---------------------+-----------------------------------------------------------------+
| Field               | Value                                                           |
+---------------------+-----------------------------------------------------------------+
| aggregation_methods | count, max, sum, min, mean                                      |
| back_window         | 0                                                               |
| definition          | - points: 86400, granularity: 0:00:01, timespan: 1 day, 0:00:00 |
| name                | 1days_per_sec                                                   |
+---------------------+-----------------------------------------------------------------+

b）测试结果分析

Ceilometer sample 查询时间，跟获取的数据量成正比，当需要查询较多的历史数据时，MongoDB 的检索时间会变得更长。

而 Gnocchi 检索时间稳定在 3~4s，因为 Gnocchi 的检索时间主要是读取 ceph obj，以及解析 obj 格式

 
[root@server-31 ~]# time ceilometer sample-list --meter cpu_util -q 'resource_id=0fd02865-c5af-4b86-958c-10fe0ba6f8d5' -l 1000
real    0m2.157s
user    0m1.166s
sys     0m0.102s
[root@server-31 ~]# time ceilometer sample-list --meter cpu_util -q 'resource_id=0fd02865-c5af-4b86-958c-10fe0ba6f8d5' -l 10000 |wc -l
9127
real    0m16.168s
user    0m3.455s
sys     0m0.272s
 
[root@server-31 ~]# time gnocchi  measures show 1dbba325-84cf-4af2-98b8-19e1b8033dd2 |wc -l
9070
real    0m3.202s
user    0m2.169s
sys     0m0.128s
Gnocchi 数据存储量 40MB+

Ceilometer 数据存储量 3GB+

这是一个非常大的数据差距，MongoDBb 的数据存储采用的预分配的方式，初始情况下 MongoDB 的数据空间是 128M，当数据量增大时，就会申请 256MB 空间，以此类推。

而 GGGnocchi 不同，GGGnocchi 对 CCCeilometer 存储数据做了优化。我们对比了 Ceilometer MongoDB 存储和 Gnocchi 存储数据。MongoDB 中将 CCCeilometer 的 sample 作为 value 存储在 db 中。而 Gnocchi 则采用了不同的方法，仅存储关键的数据：时间戳和 sample 的 value，而对于 meter 的 projectid，userid，start time end time 等等，作为 index 存储在 index 数据库中。这就大量的节省了存储空间。在存储空间 gnocchi 表现出来了非常大的优势。

但是非常不幸的事情发生了，我们发现 Ceph 的读写请求变得延迟非常大。通过我们的分析发现，ceph 系统存在大量的小文件读写，影响了 ceph 系统的性能。Ceph 是基于对象的存储系统，并不擅长小文件存储；而 gnocchi 的数据存储正是产生了大量的小文件。

于是我们又进行了新一轮的测试，即 Gnocchi 采用本地文件系统。

方案二：Gocchi + filesystem vs. Monogdb

a) 测试方法

Step1: 停止所有 ceilometer 服务

for i in notification collector polling;do systemctl stop openstack-ceilometer-$i;doneStep2: 清除 ceilometer database

>use ceilometer
>db.dropDatabase()

Step3: 删除所有 gnocchi 存储的数据

for i ingnocchi resource list | awk '{print $2}';do gnocchi resource delete $i;doneStep4: 停止 gnocchi 服务

systemctl stop openstack-gnocchi-metricdStep5: 修改 gnocchi.conf 使用本地存储

mkdir /tmp/gnocchi-datapath
Chown gnocchi:gnocchi -R /tmp/gnocchi-datapath
[storage]
driver=file
file_basepath=/tmp/gnocchi-datapath

Step6: 重启 CCCeilometer 和 GGGnocchi 服务

数据收集时间 2 小时 44 分钟

数据收集量：1 个 compute 节点

数据收集频率：1 秒

资源：2 个 vm，1 个 loadbalancer，1 个 router

b) 测试结果

查询响应时间与上次测试结果接近，gnocchi 对与大量数据查询具有很强的优势，在这里没有再列出来。

Mongo db 占用总空间约 2GB（图中 filesize 的值）

gnocchi 占用空间 19MB+

对与存储空间占用，gnocchi 文件系统存储采用与 ceph object 存储一样的存储方式因此在存储空间也非常有优势。

3.3 选型总结

Gnocchi 不论是请求响应时间还是存储空间相较于 mogodb 都有很大的优势，测试结果对比见表格。

采样频率

采样时间

空间占用

查询响应时间

Gnocchi + ceph pool

1s

5.5 小时

40MB+

3~4s

mongodb

1s

5.5 小时

3GB+

16s+

Gnocchi + filesystem

1s

2 小时 44 分

19MB+

3~4s

mongodb

1s

2 小时 44 分

2GB+

16s+

根据 Gnocchi 官方文档说明，Gnocchi 的统计数量是根据云平台要求估算出来的。

目前开放云平台中最低数据收集频率为 1 分钟，提供 30 天的数据查询根据官方算法：

粒度: 1 分钟

1 天 points: 60*24

30 天: 60*24*30 = 43200points

每个 points 是 8 个字节即 43200 * 8 = 345600 B 约为 337KB 一个 metric 数据（也就是收集 30 天之后才能达到的），而对与 Ceph 等对象存储服务来讲，并不是很好的选择，尽管 gnocchi 项目已经针对 Ceph 做了很多的优化。因此，文件系统模式的存储是比较合适的，对于数据存储可以采用定期备份的方式。

4、 遇到的“坑”

由于数据收集服务在云平台上随着用户量及资源的增多而造成比较大的服务压力，因此 OpenStack telemetry 必须能满足性能需求。如果与 OpenStack 其他服务采用相同的 message queue 和 db 等服务，将有可能会影响到 OpenStack 关键服务的性能。

因此采用了独立的 message queue 用于 OpenStack telemetry 消息通讯。

然后，我们采用了采用压力测试，监控 telemetry 数据收集服务状态及 message queue 的状态。经过压力测试发现 gnocchi 服务是 CPU 消耗型，在压力测试的情况下，gnocchi metricd 进程会达到单个 cpu100%+，单节点 CPU 达到 80%+。

为保证共有云平台服务的质量的稳定性，采取了独立节点部署 gnocchi 服务。

并对 CCCeilometer 和 GGGnocchi 服务做了参数调整，

ccceilometer.conf 下列参数避免 ceilometer polling agent 在同一时间爆发式发送统计数据到消息队列造成队列阻塞。

 
[DEFAULT]
shuffle_time_before_polling_task = 100 

Gnocchi.conf 下列参数可以使得 metricd 进程不会持久占用 CPU。

 
[storage]
metric_processing_delay = 60
metric_reporting_delay = 120

根据官方文档说明，ceilometer notification agent 如果想要是多节点的 HA 模式，需要采用 tooz 做分布式协同，笔者基于项目维护复杂度考虑并未加入 tooz 作为分布式协同处理，而是采用了单节点的模式并由 pacemaker/corosync 做 resource 管理，CCCeilometer 提供了 batch message 处理的方式，那么可以大量减少消息处理带来的性能问题。通过检测 message queue 中的阻塞数据，在 1 秒的数据采集间隔中基本上都保留在 500 以内。

但是一切并不如想象中那么顺利，很快遇到了新的问题，即使 notification agent 采用了单节点模式，在做 VM CPU 压力测试时发现，收集到数据并不正确。通过分析 ceilometer notification agent code 发现。ccceilometer notification 的 data transform，是采用的进程内存做历史数据存储，也就是说即使是单节点多进程的情况，历史数据也是分别处理的，在这里简单介绍一下 CPU 利用率计算方法。libvirt 不支持 CPU 利用率的直接获取，只能获取 CPU time 来计算出实际使用率。计算的公式为：

首先得到一个周期差：CPU_time_diff = cpuTimenow — cpuTimet seconds ago

然后根据这个差值计算实际使用率：%CPU = 100 × CPU_time_diff / (t × nr_cores × 109)

这就意味着间隔 1 秒的数据并未能正确被对应的 notification agent 获取到并转化出 CPU 利用率。所以关于 notification agent 在不启用协同 tooz 的情况下只采用单进程的方式工作，要么就要放弃所有的数据转化部分，只使用CCCeilometer 的收集和存储能力。

5、告警服务

aodh 是从 CCCeilometer 中独立出来的仅负责用于告警服务。Aodh 也支持了基于 gnocchi 统计数据的告警设置。

Aodh 支持如下类型的告警触发协议类型：

• HTTP: 发送 http request 到指定的 URL
• HTTPS: 发送 https request 到指定的 URL
• LOG：notification 日志
• TEST：测试用处
• Trust + HTTP/HTTPS：加入了 keystone 身份认证

告警通知可以采用 Webhook 去实现，从而达到可以发送邮件，短信，微信等方式的用户实时告警。

6、我们的改进

作为公有云平台服务，单单功能实现是不足以满足需求的，需要考虑到应对公有云大规模场景的性能问题。对此，云极星创针对 OpenStack Telemetry 做个部分定制功能。

首先，我们对数据量做了优化，云监控的目标是为云平台用户提供对用户资源监控和告警。因此我们通过定制 polling agent 的 pollster list，减少数据量处理和传输。

Message Queue 和 Database 是云平台核心的支撑组件，为了避免大量数据计量服务影响到云平台核心业务性能，我们采用了单独的 Message Queue 和 Database 用于云监控服务。

为了保证云监控服务运行，我们从运维层面也做了监控，例如对云监控服务健康状态、服务响应时间、消息队列状态、数据库慢查询、服务节点 CPU、内存、磁盘、网络流量等进行监控。

Gnocchi 服务开发时间尚短目前位置没有大规模使用的用例，我们在云监控平台开发中也遇到功能不满足需求的情况，例如，监控数据获取 gnocchi 目前仅支持针对单个 metric 的数据获取，也就是说如果想要做成面板模式的展示意味着要同时发送多个 API 请求去获取数据，这对于 UI 是有性能影响的。云极星创对这些问题做了二次开发，也会计划把代码回馈给社区。

7、写在最后

云极星创通过 Openstack Telemetry 项目实现云监控平台过程中遇到的各种“坑”，越发觉得即使是 Openstack 作为最活跃云计算开源社区依然距离商业化路途依然尚远。因此，我们会在增强服务稳定性和高性能方面做出更多的努力和尝试，并乐于分享和贡献到开源社区。

参考文档

• Ceilometer 监控指标
• Gnocchi 文档
• Aodh API
• Aodh DB 支持
• CERN 参考架构
• Installation and turial guide
• Telemetry admin guide

作者简介

任敏敏，云极星创高级开发工程师，专注云平台开发工作，在 OpenStack 领域有多年开发经验， OpenStack 社区项目的开发人员，具有较丰富的 OpenStack 开发和运维经验，原 IBM 云计算部门软件开发工程师。

感谢木环对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。