写点什么

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

  • 2017-04-05
  • 本文字数:6478 字

    阅读完需:约 21 分钟

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 作为最活跃云计算开源社区依然距离商业化路途依然尚远。因此,我们会在增强服务稳定性和高性能方面做出更多的努力和尝试,并乐于分享和贡献到开源社区。

参考文档

作者简介

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


感谢木环对本文的审校。

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

2017-04-05 17:278056

评论 1 条评论

发布
用户头像
错别字有点多啊
2020-12-22 00:45
回复
没有更多了
发现更多内容

Java开发6年了,BAT面试文档:ActiveMQ(1)

策划Java工程师

Java 程序员 后端

Java开发从零开始!《SpringCloud超级入门(4)

策划Java工程师

Java 程序员 后端

GitHub标星过万!10592字,475行

Java 程序员 后端

AI应用说 | 百度专家&行业大咖畅谈AI技术与落地应用

百度大脑

人工智能 开发者 开发

毕业总结

Vincent

架构训练营

GitHub标星过万!亦直问JVM(1)

Java 程序员 后端

现成FIL分币系统介绍|FIL分币平台搭建

Geek_23f0c3

Filecoin fil挖矿 FIL挖矿分币系统

亚信科技AntDB数据库与中科可控、海光公司完成产品兼容认证

亚信AntDB数据库

服务器 国产化 国产芯片 国产数据库 产品兼容性互认

GitHub标星8k!Java虚拟机5大核心知识点

Java 程序员 后端

IBM大面积辞退40岁+的员工,【Spring Boot 1

Java 程序员 后端

Java应用性能优化!Java-进阶:集合框架1

Java 程序员 后端

Java开发全套学习!MySQL进阶,秒变大神(1)

策划Java工程师

Java 程序员 后端

Java开发前景怎么样?【Spring Boot 21

策划Java工程师

Java 程序员 后端

【“互联网+”大赛华为云赛道】API命题攻略:厘清三步解题思路,用好开发工具

华为云开发者联盟

API 华为云 modelarts 互联网+ API Explorer

FastApi-02-路径参数

Python研究所

FastApi 8月日更

TCL携大屏天团领跑UDE,斩获多项创新大奖

科技热闻

架构实战营毕业总结

eoeoeo

架构实战营

ELK原来这么简单!《零基础(1)

Java 程序员 后端

Java体系化进阶学习图谱:所有帖子的 分类 总结

Java 程序员 后端

Java开发三年月薪才12K,你知道如何用面向对象思想写好并发编程吗?

策划Java工程师

Java 程序员 后端

京东:Flink SQL 优化实战

Apache Flink

flink

Java开发快速学习!三面蚂蚁金服成功拿到offer后,他说他累了

策划Java工程师

Java 程序员 后端

【“互联网+”大赛华为云赛道】CloudIDE命题攻略:明确业务场景,快速开发插件

华为云开发者联盟

ide 开发 插件 华为云 CloudIDE

Java开发基础不牢?什么是中间件?

策划Java工程师

Java 程序员 后端

Java开发基础面试题,【springcloud

策划Java工程师

Java 程序员 后端

Java基础72问:不搞定HR这3个问题,建议不要轻易跳槽(1)

Java 程序员 后端

Java开发入门教程!程序员:面试官

策划Java工程师

Java 程序员 后端

终于有人把操作系统,网络系统,线程进程,IO模型全部总结出来了

程序员 架构 面试 操作系统 计算机

TimeUtils 实用封装

Changing Lin

8月日更

Java大厂技术面试题汇总!美团阿里Java程序员晒工资被围观,总结

Java 程序员 后端

Java入门你值得拥有!【Spring Boot 26

Java 程序员 后端

如何基于Openstack telemetry项目实现云监控报警服务_语言 & 开发_任敏敏_InfoQ精选文章