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

最新推荐文章于 2024-08-21 08:08:51 发布

虎纠卫

最新推荐文章于 2024-08-21 08:08:51 发布

阅读量6.3k

点赞数

分类专栏： OpenStack 文章标签： OpenStack ceilometer

本文链接：https://blog.csdn.net/csolo/article/details/55192836

版权

OpenStack 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

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的字段以及计量名称须正确的匹配。

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