OpenStack学习笔记（三）测量服务Telemetry

我不是女神ヾ 2022-07-12 06:49 353阅读 0赞

PS：其实我自己因为工作关系比较关心的是这个测量服务。

Telemetry 模块最初是设计于支持 OpenStack 云资源的付费系统的。这个项目仅仅覆盖了付费所需过程中的计量部分。这个模块收集关于系统的信息，并将其以一个简单的格式保存，以提供任意需要付费的数据。

除了系统系统的度量之外，Telemetry 模块也会获取在 OpenStack 系统中执行的各种操作所触发的事件消息。这个数据会获取为 Events 并与计量数据一起保存。

计量的列表会持续增长，这使得将通过 Telemetry 收集的数据用于各种目的成为可能，而不仅仅是付费。例如，Orchestration 模块中的自动扩展特性会通过警告这个模块的配置来触发，然后获取 Telemetry 中的消息。

一、Telemetry架构

Telemetry模块使用了基于代理对架构。几个模块结合承担收集数据,样本存储在一个数据库,或者提供一个API服务来处理传入的请求等的责任。

Telemetry模块由下列代理和服务所构建。Telemetry包含三个项目：

*  Aodh，负责监控告警功能
 *  Ceilometer，负责数据采集和持久化存储功能，也向外提供REST API，供其他系统查询采集到的数据
 *  Gnocchi，多租户的时间序列化、度量、资源数据库（PS：目前对于gnocchi的了解还停留在官方文档的介绍上，没有实际的使用经历，先照抄官网关于gnocchi的介绍，等实际使用后再更新相关内容）

下图为架构图（取自百度图片）

![Center][]

1.1、 Ceilometer组成

数据采集是Telemetry的核心。可以为监控系统提供资源实时健康状态数据；可以给计费系统提供资源使用率等信息。ceilometer提供的数据采集覆盖了所有的openstack项目：

*  计算（nova），主要包含云服务器的使用情况数据
 *  存储（cinder、swift），块存储、对象存储数据
 *  网络（neutron），包含公网ip、带宽、路由等在内的所有网络相关数据
 *  认证、授权（keystone），用户管理、认证等相关的数据
 *  甚至还支持IPMI协议，采集物理环境的数据

**ceilometer-api**

聚合计量数据来消费(如计费引擎，分析工具等等)。

**`ceilometer-polling`**

通过使用以不同的命名空间注册的轮询插件(pollsters)来轮询不同类型的计量数据。

**`ceilometer-agent-central`**

轮询诸如计算服务和镜像服务等其它等OpenStack服务的公共的RESTful API，为了保持以存在资源的标签，通过使用在中心轮询命名空间中注册的轮询插件(pollsters)来实现。

**`ceilometer-agent-compute`**

通过使用在计算轮询命名空间中注册的轮询插件(pollsters)，轮询本地的hypervisor或libvirt守护进程来为本地实例收集性能数据，消息，然后发送数据到AMQP。

**`ceilometer-agent-ipmi`**

通过使用在IPMI轮询命名空间中注册的轮询插件(pollsters)，轮询拥有IPMI支持的本地节点，是为了收集IPMI传感器数据和Intel节点管理器的数据。

**`ceilometer-agent-notification`**

其它OpenStack服务所消费动AMQP消息。

**`ceilometer-collector`**

接收来自代理的AMQP通知，然后分发这些数据到对应的数据存储。

**`ceilometer-alarm-evaluator`**

决定当警报触发由于相关统计趋势超过阈值超过滑动时间窗口。

**`ceilometer-alarm-notifier`**

发起警告操作，例如调用一个带有警告状态转换描述的webhook。

除`ceilometer-agent-compute`和`ceilometer-agent-ipmi`服务之外，所有的其它服务都运行在一个或多个控制器节点中。

Telemetry的架构高度依赖于AMQP服务，既有消费来自OpenStack服务的事件，又有其内部的通信。

1.2、Telemetry支持的数据库

Telemetry关键的组件就是数据库了，存放事件，样例，警告定义和警告的地方。

后端支持的数据库列表：

1） ElasticSearch（仅事件，这个ELK技术栈的一部分，用户收集事件和日志）

2）MongoDB

3）MySQL

4）PostgreSQL

5）HBase

6）DB2

3、支持的Hypervisor

1）以下Hypervisor 是通过Libvirt来支持的：

KVM

QEMU

LXC

UML

这些Hypervisor可以采集的指标依赖Libvirt的API接口，详细可以查看下面url

http://libvirt.org/hvsupport.html。 下图截图自这个网址

![Center 1][]

这些API覆盖了操作和监控指标。

2）Hyper-v

3）XEN

4）VMWare vSphere

二、数据收集

数据收集主要由以下组成：

**通知**

处理来自其它OpenStack服务的通知，通过消费来自其它所配置动消息队列系统的消息。

**轮询**

使用SNMP直接从Hypervisor或主机获取信息，又或者是使用其它OpenStack服务的API。

**RESTful 应用程序接口**

通过Telemetry的RESTful API 发送实例。

2.1 OpenStack服务消费的事件类型

1）OpenStack Compute

scheduler.run\_instance.scheduled

scheduler.select\_destinations

compute.instance.\*

2）裸金属服务

hardware.ipmi.\*

3）OpenStack镜像服务

image.update

image.upload

image.delete

image.send

4）OpenStack 网络

floatingip.create.end

floatingip.update.\*

floatingip.exists

network.create.end

network.update.\*

network.exists

port.create.end

port.update.\*

port.exists

router.create.end

router.update.\*

router.exists

subnet.create.end

subnet.update.\*

subnet.exists

l3.meter

5）编排模块

orchestration.stack.create.end

orchestration.stack.update.end

orchestration.stack.delete.end

orchestration.stack.resume.end

orchestration.stack.suspend.end

6）OpenStack块存储

volume.exists

volume.create.\*

volume.delete.\*

volume.update.\*

volume.resize.\*

volume.attach.\*

volume.detach.\*

snapshot.exists

snapshot.create.\*

snapshot.delete.\*

snapshot.update.\*

2.2  轮询

对于一些数据，不会主动发送通知的，需要Telemetry 使用了另一个方法来收集这些数据，它通过选择基础设施，包括不同 OpenStack 服务的 API 和其他的断言，如 hypervisors。后者的情况需要与计算主机进行更亲密的交互。为了解决这个问题，Telemetry 使用一个基于代理的架构，以满足对数据采集的需求。

轮询的机制支持三种类型的代理，有计算代理，中心代理，以及IPMI代理。透过现象看本质，所有类型的轮询代理都是同一个`ceilometer-polling`代理，但是它们从不同的命名空间加载了不同的轮询插件(pollsters)来收集数据。下面的几个小节给出了这些组件的架构和配置细节的进一步信息。

2.3 发送样例给Telemetry

在Telemetry模块中大部分的数据收集都是自动化的，Telemetry提供通过REST API来提交样本的能力，这样就允许用户发送定制的样本到此模块中。

此属性让发送任何类型的样本成为可能，而且还无须写任何额外的代码或者是对配置作变更。

发送给Telemetry的样本还不限于实际存在的计量，有一种可能性，通过填写POST请求的所有必填字段，以提供数据的任何新的客户定义计数器。

如果样本对应的现有的计量，那么诸如 `meter-type`的字段以及计量名称须正确的匹配。

使用命令行客户端发送样本所需要的字段：

*  相应资源的ID。(`--resource-id`)
 *  meter. (`--meter-name`) 名称
 *  meter. (`--meter-type`) 类型
    
    预定义的计量类型：
    
     *  Gauge
     *  Delta
     *  累积
 *  计量单元。(`--meter-unit`)
 *  样例值。(`--sample-volume`)

要使用命令行客户端发送样本给Telemetry，需要调用下面的命令:

2.4  数据收集和处理

数据收集和处理的机制称之为管道。管道，在配置这个层次，描述数据的来源和相应的转化和发布的数据池之间的耦合。

来源是数据的生产者：样本或事件。事实上，它是pollster或事件掌控者发送数据点的集合，用来匹配计量和事件类型的集合。

每个源的配置囊括名称匹配，polling间隔决定，属性资源列举或发现，以及映射到一个或多个的发布池。

数据收集可以用于不同的目的，这会影响到它发布通知的频率。通常，一个计量是以付费目的发布的，需要每 30 分钟更新一次，而相同的计量可能需要每分钟进行性能调整。

应该避免快速轮询的节奏，因为它会在段时间内产生一个庞大数目的数据，这对 Telemetry 和底层数据库后端都有性能上的消极影响。因此我们强烈建议您不要使用小粒度值，如 10 秒。

2.5 数据恢复

提供了数据持久化和恢复功能

2.6 警报

警告提供了运行在OpenStack中用户导向的资源监控即服务。此类型的监控确保你可以通过编排模块自动的缩小和扩展实例组，但是你也可以使用警告用于你云资源的健康的通用目的。

这些警告有下面的三态模式：

**好**

规则管理警报已被评估为`False`。

**警报**

规则管理警报已被评估为`True`。

**数据不足**

在评估期间没有足够的数据点来决定警告的状态，意义不大。

2.7 测量

Telemetry模块在OpenStack部署中收集计量。本节讲述了关于计量格式以及其来源，甚至包括可用计量的列表的一些小结。

telemetry通过轮询基础设施元素来收集计量，而且也消费由其它OpenStack服务所发送过来到通知。关于轮询机制和通知的更多信息，请参阅[“数据收集”一节][Link 1]。由很多计量是由轮询和消费来收集的，下图列举了几个计量案例

![Center 2][]

![Center 3][]

整个模块的计量项目很多，大家可以自行查阅

![Center 4][]

2.8 事件

除了计量之外，Telemtry模块在OpenStack环境中收集所触发动事件

### 事件结构 ###

由Telemetry模块捕获的事件由五个关键属性：

**event\_type**

一个点串定义发生的事件，如`compute.instance.resize.start"`。

**message\_id**

事件的UUID。

**生成的**

当系统中由事件发生时的时间戳。

**特定**

描述事件的一个关键值对的扁平化映射。事件的特征包括了大多数事件的细节。特征类型，可以是字符串、整型、浮点型或日期时间。

**raw**

主要是审计的目的，全部的事件消息都被存储(未索引的)，为了将来的评估。

[Center]: /images/20220711/b5d5cf3be0264ba192734c4caf246ad3.png
[Center 1]: /images/20220711/2049f388af364d97b13427ed1ebcaa93.png
[Link 1]: http://docs.ocselected.org/openstack-manuals/kilo/admin-guide-cloud/content/section_telemetry-data-collection.html
[Center 2]: /images/20220711/a1aaaf05270f4b42b82dc6423217c105.png
[Center 3]: /images/20220711/5f45ca225a3c455f84697b297990df34.png
[Center 4]: /images/20220711/6fbac51ea4704041b3b1c42a5c0e049a.png