文章目录
文章目录
1. OpenStack-Ceilometer项目简介
2. Ceilometer项目架构
1. OpenStack-Ceilometer项目简介
OpenStack通过Telemetry项目提供计量与监控服务，该项目旨在针对组成已部署云的物理和虚拟资源，可靠地收集并保存各类使用数据，以便对这些数据进行后续检索和分析，并在满足已定义条件或者规则时触发操作(如报警)。
Telemetry项目中包含许多子项目，其中包括以下几个:
Ceilometer：数据采集服务，提供一个获取和保存各种使用数据的统一框架
源码 https://github.com/openstack/ceilometer Bug列表 https://bugs.launchpad.net/ceilometer 文档 https://docs.openstack.org/ceilometer/latest/ 压缩包 http://tarballs.openstack.org/ceilometer/ Aodh：告警服务，根据已保存的使用数据定义规则并触发操作
源码 https://github.com/openstack/aodh Bug列表 https://github.com/openstack/aodh 文档 https://docs.openstack.org/aodh/latest/ 压缩包 http://tarballs.openstack.org/aodh/ Gnocchi：开源时序数据库服务，保存基于时间序列的数据，并对其提供索引服务
源码 https://github.com/gnocchixyz/gnocchi Bug列表 https://github.com/gnocchixyz/gnocchi/issues 文档 http://gnocchi.xyz/ 压缩包 https://pypi.python.org/pypi/gnocchi Panko：事件数据库服务，用来保存事件Event信息，并对其提供索引服务
源码 https://github.com/openstack/panko Bug列表 https://bugs.launchpad.net/panko 文档 https://docs.openstack.org/panko/latest/ 压缩包 http://tarballs.openstack.org/panko/
其中，Ceilometer项目处于核心位置，OpenStack Telemetry的源头就是Ceilometer项目。该项目始于2012年，最初的目的是获取和保存计量信息以支持对用户收费，随着项目的发展，很多OpenStack项目都需要获取和保存多种不同的测量值，所以Ceilometer增加了第二个目标：成为收集和保存各种测量数据的标准框架。后来由于Heat项目的需要，Ceilometer项目又增加了利用已保存的测量值进行报警的功能。
为了满足客户更加灵活且可供选择的部署Ceilometer项目的各个功能，在Openstack Liberty版本中，报警功能从Ceilometer项目中剥离，产生了一个新的项目Aodh。在Openstack Newton版本中，事件Event信息的保存功能也被剥离，产生了新项目Panko。
早期Ceilometer项目使用MongoDB保存计量数据，性能十分差劲，为了解决这个问题Telemetry社区开发了Gnocchi项目，用于保存时序数据，并作为Ceilometer项目的数据保存后端。
这些从Ceilometer项目剥离和衍生出来的项目与Ceilometer项目一起，构成了Telemetry项目。
2. Ceilometer项目架构
Ceilometer的主要功能是
高效轮询与OpenStack服务相关的计量数据 通过监听消息总栈获取事件和计量数据 将收集到的数据发布到多个目的地
2.1 整体架构
Ceilometer的每个服务都支持横向扩展，可根据负载情况，增加节点或者增加单个节点的worker数。Ceilometer提供两个核心服务:
Polling Agent：轮询OpenStack 服务并生成meter数据的守护进程 Notification Agent：监听Notification Bus上的通知信息，并将通知信息转换为事件Event和取样Sample数据，也是一个守护进程。
从上图架构能够看出，Ceilometer收集和处理的数据，可发往多个target，比如通过Gnocchi-API发给Gnocchi，实现数据保存；发给Panko用户储存Event和其他元数据；也可以发给外部系统使用；Aodh服务通过已保存的数据，制定规则触发报警等。
2.2 数据收集
Ceilometer项目通过两种方式收集数据：
Notification Agent：第三方的数据发送者将数据以消息的形式发送至Notification Bus，Notification Agent会监听这些通知事件，并从中提取Sample或者Event数据。
所有的OpenStack服务都会发送已执行操作或系统状态的通知，这些通知数据的发送者可能是Openstack项目的其他组件，如Nova, Glance, Cinder, Neutron, Swift, Keystone, and Heat，当然也可能是来自Ceilometer内部。
Notification Agent 加载「ceilometer.notification」命名空间下的一个或者多个插件，每个插件可以监听任何topic。一般默认监听
notifications.info
,notifications.sample
, 和notifications.error
。监听进程从配置的topic抓取下来消息之后，将其分发到合适的插件处理成event和samplePolling Agent：定期主动地通过各种API或者其他通信协议收集远端或者本地的不同服务实体中的测量数据。
虽然我们可以使用Notification Agent收集和整理出许多可计量数据信息，但是有些信息不会直接发出，例如VM实例的资源使用情况，因此我们还需要使用Polling Agent来获取更多数据。
目前主要有三种不同的Polling Agent。Compute Agent部署在Nova Compute服务的计算节点上，主要用来和Hypervisor通信，轮询获取计算资源相关数据(Hypervisor相关的测量值)，要求部署在计算节点上，也是为了更高效地和本地Hypervisor进行通信。Central Agent部署在控制节点上(也可以被部署在任何其他节点上)，用于和远程各种不同实体和服务进行通信，获取不同的非计算资源数据(如通过轮询公共的REST API检索未通过通知显示的OpenStack资源的附加信息，还负责通过SNMP获取硬件资源信息)。IPMI Agent，它需要部署在支持IPMI的节点上，用于获取本机IPMI的相关测量值。
由于Polling Agent采用轮询的方式主动获取数据，可能会对服务器造成负载，可以同时部署多个Central Agent实例，Compute Agent和IPMI Agent主要和本地进行通信，不能使用部署多个相关实例。
2.3 数据处理
Ceilometer获取到的测量数据，会把它转化为符合某种标准的采样数据并通过内部总线发送给Notification Agent，然后Notification Agent会根据用户定义的Pipeline来对采样数据进行转换(Transform)和发布(Publish)。
Ceilometer处理数据的机制即为Pipeline，Pipeline的引入使得管理员很方便的定义某个测量数据的采样频率和发布方式，在Ceilometer中，同时允许有多个Pipeline，每个Pipeline都是由源(source)和目标(sink)两部分组成。源中定义了需要测量的数据，数据的采样频率，在那些Endpoint上进行数据采样以及这些数据的目标(sink)。目标则定义了数据需要经过哪些Transformer进行转换，并且最终交由哪些Publisher进行数据发布。下图展示了数据的处理流程：
数据发布流程如下：
该图显示了采样数据可发送给多个target，如通过Gnocchi和oslo.messaging的方式同时将同一采样数据发布给不同的数据接受者。
目前已有多种Publisher，具体如下：
Gnocchi ，发布samples/events 给Gnocchi API； Notifier，基于消息通知的Publisher，向通知总线上发送info级别的通知消息，采样数据(Sample)作为通知消息的数据载荷(payload)； UDP，将采样数据封装在UDP包内，然后向某个管理员可配置的UDP地址和端口发送； HTTP，发布采样值到REST接口； File，将采样数据内容以log形式保存在某个管理员可配置的文件中； Zaqar，将采样数据发给Zaqar服务； HTTPS，通过SSL发送给REST接口； Prometheus，发送给prometheus接收网关； Monasca，将采样数据发送给 Monasca API。
