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

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

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

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

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

一、Telemetry架构

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

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

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

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

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。 下图截图自这个网址

这些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服务所发送过来到通知。关于轮询机制和通知的更多信息，请参阅“数据收集”一节。由很多计量是由轮询和消费来收集的，下图列举了几个计量案例

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

2.8 事件

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

事件结构

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

event_type

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

message_id

事件的UUID。

生成的

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

特定

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

raw

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