计量架构提案 1

目标

提供高效的计量数据收集，包括 CPU 和网络成本。
允许部署者直接与计量系统集成，或通过替换组件来实现。
数据可以通过监控现有服务发送的通知或通过轮询基础设施来收集。
允许部署者配置收集的数据类型，以满足其运营需求。
计量系统收集的数据通过 REST API 对某些用户可见。
计量消息已签名且不可否认 (http://en.wikipedia.org/wiki/Non-repudiation)

高级描述

该系统有 4 个基本组件

一个代理在每个计算节点上运行并轮询资源

 utilization statistics. There may be other types of agents in the
 future, but for now we will focus on creating the compute agent.

收集器运行在一个或多个中央管理服务器上，以

 monitor the message queues (for notifications and for metering data
 coming from the agent). Notification messages are processed and
 turned into metering messages and sent back out onto the message bus
 using the appropriate topic. Metering messages are written to the
 data store without modification.

数据存储是一个能够处理并发的数据库

 writes (from one or more collector instances) and reads (from the
 API server).

API 服务器运行在一个或多个中央管理服务器上，以

 provide access to the data from the data store. See
 EfficientMetering#API for details.

这些服务使用标准的 OpenStack 消息总线进行通信。只有收集器和 API 服务器可以访问数据存储。

详细描述

这些细节仅涵盖计算代理和收集器，以及它们通过消息总线的通信。在数据存储和 API 服务器的设计可以记录之前，还需要更多的工作。

插件

虽然我们已经描述了 Ceilometer 应该收集的指标列表，但我们无法预测部署者想要衡量其客户使用的资源的所有方式。这意味着 Ceilometer 需要易于扩展和配置，以便可以针对每个安装进行调整。基于 setuptools entry points 的插件系统将使添加收集器或轮询的子代理中的新监视器变得容易。

每个守护进程提供基本的必要服务，作为插件共享的框架，插件执行专门的工作。通常，插件应该被要求尽可能少地工作。这将使它们作为 greenlets 更加高效，最大限度地重用代码，并使其更易于实现。

安装插件会在 Ceilometer 守护进程下次启动时自动激活它。可以使用全局配置选项来禁用已安装的插件（例如，作为 Ceilometer 包的一部分提供的“默认”插件集中的一个或多个）。

插件可能需要配置选项，因此在加载插件时，会要求它将选项添加到全局标志对象，并将结果提供给插件，然后再要求它执行任何工作。

插件可以通过配置设置（例如，用于轮询 libvirt 的插件在系统配置为使用其他虚拟化工具时将不会运行）基于其他组件定义的配置设置在运行时禁用自身，而不是运行和报告错误或仅仅消耗周期进行无操作。插件将在启动时被询问一次，在加载并获得配置设置后，是否应该启用。插件不应定义自己的标志来启用或禁用自身。

每个插件 API 由命名空间和插件实例的抽象基类定义。插件不需要从 API 定义类继承，但鼓励这样做，作为发现 API 更改的一种方式。

注意：目前正在进行将通用插件系统添加到 Nova 的工作。如果它作为通用库的一部分实现，我们应该尝试使用它（或根据我们的需要进行调整）。如果它仍然是 Folsom 的 Nova 的一部分，我们可能不应该依赖它，因为使用 setuptools 加载插件是微不足道的。

轮询

计量数据来自两个来源：通过内置于现有 OpenStack 组件中的通知，以及通过轮询基础设施（例如通过 libvirt）。轮询由在计算节点上运行的代理处理（与超visor 通信更有效）。

代理守护进程配置为使用 `ceilometer.poll.compute` 命名空间运行一个或多个轮询器插件。代理定期要求每个轮询器提供 `Counter` 对象实例。代理框架将 Counter 转换为计量消息，然后对其进行签名并通过计量消息总线进行传输。

轮询器插件不应直接与消息总线通信，除非为了收集它们正在轮询的信息而必须这样做。

所有轮询都以相同的频率进行，由代理的全局设置控制。如果我们需要支持以不同的速率轮询不同的计量器，我们可以在未来的版本中进行调查。

处理通知

该系统的核心是收集器，它监视消息总线，以获取轮询器通过代理提供的数据以及来自其他 OpenStack 组件（例如 nova、glance、quantum 和 swift）的通知消息。

收集器加载一个或多个监听器插件，使用 `ceilometer.collector` 下的命名空间。命名空间控制监听器订阅的交换机和主题。例如，`ceilometer.collector.compute` 侦听 `nova` 交换机上的 `notifications.info` 主题，而 `ceilometer.collector.image` 侦听 `glance` 交换机上的 `notifications.info`。

插件提供一种列出它想要事件类型的方法，以及用于处理传入消息的回调函数。注册的回调名称用于使用收集器守护进程的全局配置选项启用或禁用它。传入的消息将根据其事件类型值进行过滤，然后传递给回调函数，以便插件仅接收它表示有兴趣看到的事件。例如，在 `ceilometer.collector.compute` 下要求 `compute.instance.create.end` 事件的回调函数将在 `nova` 交换机上使用 `notifications.info` 主题上为这些通知事件调用。

回调函数应返回一个包含零个或多个 `Counter` 实例的可迭代对象，该对象基于传入消息中的数据。收集器框架代码将 `Counter` 实例转换为计量消息并在计量消息总线上发布它们。虽然我们将提供一个默认存储解决方案与 API 服务一起工作，但通过在计量消息总线上重新发布，我们可以支持希望处理自己的数据存储的安装。

处理计量消息

计量消息的监听器也在收集器中运行。它验证传入的数据，然后（如果签名有效）将其写入数据存储。（注意，因为此监听器不同，它可以直接在收集器代码中实现，而不是作为插件。事实上，我们可能会决定将其放在自己的守护进程中，但目前看来将其保留在收集器进程中是可以的。）

计量消息使用 Python 标准库中的 hmac 模块进行签名。可以在 Ceilometer 配置设置中提供共享密钥值。通过将消息键名和值按排序顺序馈送到签名生成器来对消息进行签名。非字符串值转换为 unicode 然后编码为 UTF-8。消息签名包含在消息中，以便收集器进行验证，并存储在数据库中，以便通过 API 访问数据的消费者将来进行验证。

RPC

在 RPC 服务移动到 openstack-common 库之前，我们将使用 nova 中的版本。

实施概要

这些最终应移动到工单或蓝图。

实现一个 Counter 类
1. 使用 namedtuple？
2. 将 Counter 实例转换为计量消息的库代码
3. 对计量消息进行签名的库代码
4. 验证计量消息签名的库代码
5. 发布计量消息的库代码
创建在计算节点上运行的代理守护进程的框架。
1. 启动服务
2. 加载插件并确定哪些插件处于活动状态
3. 安排定期任务以轮询插件
4. 发布轮询插件返回的数据的计量消息
创建在管理节点上运行的收集器守护进程的框架。
1. 启动服务
2. 加载插件并确定哪些插件处于活动状态（与轮询插件不同的规则吗？)
3. 为每个监听器和事件类型建立回调函数
4. 发布监听器插件返回的数据的计量消息
更新收集器以处理计量消息
1. 侦听计量消息（这些只是通过 RPC 的“cast”调用吗？)
2. 收到消息后，检查签名并“存储”它（现在，只是将其写入日志）

EfficientMetering/ArchitectureProposalV1