Ceilometer/blueprints/PaaSEventUsageCollection

简介

Ceilometer 必须能够有效地从服务中提取和处理使用信息，以便正确生成账单。为了能够有效地处理使用数据，Ceilometer 需要服务实现一致的接口。本文档描述了计量需求、用例，并提供了一个从平台即服务 (PaaS) 产品中收集使用信息的架构。

示例用例

数据库即服务

数据库即服务 (DBaaS)，例如 Trove，具有一种架构，服务控制器代表客户管理特殊的 Nova 计算实例。从他们的角度来看，他们运行的是数据库实例，而不是计算实例。计量和计费将基于数据库运行的小时数，不一定是托管实例运行的时间长短。这需要生成和存储一组唯一的计量记录，以启用对单个数据库实例的使用跟踪和计费。Ceilometer 必须能够从 DBaaS 服务控制器或适当的中间件中提取应用特定的记录。

DNS 即服务

DNS 即服务在与 DBaaS 类似的架构上运行。在这种情况下，需要测量的计量器是 DNS 区域的存在以及已服务的 DNS 查询数量。再次强调，这些是应用程序级别的计量器，与正在运行的主机实例没有直接关联。查询可以由各种主机提供，并且 DNS 区域的存在不依赖于特定的计算实例。DNS 服务必须跟踪应用程序级别的指标并将其报告出来，以便可以跟踪这些系统。Ceilometer 必须能够从 DNSaaS 服务控制器或适当的中间件中提取应用特定的记录。

负载均衡即服务

负载均衡器是一个逻辑系统，由一些托管负载均衡软件的计算实例组成。必须测量的计量器包括负载均衡器实例的存在以及通过系统传输的数据量。再次强调，这与底层基础设施没有直接关联，但必须在应用程序级别报告。Ceilometer 必须能够从 LBSaaS 服务控制器或适当的中间件中提取应用特定的记录。

集成模型

服务所有权

PaaS 服务托管在 Nova 虚拟机实例中。托管和所有权模型的变化对计费模型有很大影响。所有权有两种潜在模式：1. PaaS 服务拥有 VM 实例：在这种模式下，VM 实例对最终用户不可见。VM 的所有者是 PaaS 服务。Nova 生成的使用记录指的是 PaaS 服务控制器的 projectId。 2. 最终用户拥有 VM 实例：VM 实例可见且可以由最终用户控制。Nova 使用记录指的是实际的最终用户 projectId。需要某种机制来区分 PaaS Nova 实例和基础 Nova 实例。

计费模型

PaaS 服务有几种潜在的计费模型

1. 基础 Nova + 溢价：在这种模式下，用户支付与基础 Nova 实例相同的指标，但需加收溢价。计费过程必须能够识别每个 Nova 实例的 PaaS 类型。可以通过以下两种潜在方式进行此识别

嵌入式使用记录键：每个使用记录都包含一个标识实例为特定类型的字段。Windows Nova 实例就是一个例子。Nova 事件包含一个唯一标识操作系统类型的许可证密钥。计量聚合查找此密钥并相应地处理记录。此方法的主要缺点是许可证密钥必须由 Nova 插入，并且支持复杂的产品捆绑包将很困难。
PaaS 服务通过带外方法提供其服务的活动实例列表。这可以通过消息队列传递，或者通过 PaaS 服务控制器需要实现的专用 API 提供。

2. 应用特定指标：在这种模式下，用户不直接为计算实例资源付费，而是为一组 PaaS 服务/应用特定指标付费。PaaS 服务将生成使用记录并将其提供给计量系统。较低级别的 Nova 使用记录将被忽略或归因于 PaaS 服务。

应用特定集成架构

以下架构支持收集 PaaS 应用特定指标。请注意，此架构与涵盖事件格式本身的单独蓝图 (PaaS 事件格式) 相关。该架构由以下组件组成

PaaS 服务（控制器和实例）：PaaS 服务和实例在 Nova 虚拟机的一个或多个实例中运行。PaaS 服务控制器负责对系统进行工具化，以便生成 PaaS 应用特定的使用记录并将其传递到消息队列。
消息队列：消息队列基础设施提供 PaaS 服务和 Ceilometer 之间集成的关键点。每个 PaaS 服务将有一个专用的队列来传递事件/使用记录。消息队列基础设施本身可以通过多种方式部署：作为底层基础设施的一部分共享，作为共享的云内服务，或由 PaaS 服务本身拥有。Ceilometer 需要一种灵活的配置机制，将每个 PaaS 指标类型映射到要收集的某个端点和队列。
Ceilometer PaaS 事件监听器：提供 Ceilometer 组件，用于从消息队列收集 PaaS 事件/使用记录，将其转换为 Ceilometer 内部事件，然后将其放入 Ceilometer 消息总线。

下图显示了高级集成架构