PaaS 事件格式¶
https://blueprints.launchpad.net/ceilometer/+spec/paas-event-format-for-ceilometer
为新服务设置 Ceilometer 收集的通用机制是创建针对性代理或使用现有服务 API 来计量这些系统。虽然这种方法适用于现有的服务集合，但随着需要计量的 PaaS 和 SaaS 服务数量的增加，它将遇到一些问题。本蓝图提出了一种简化集成格式的方案，以便 Ceilometer 可以消耗任何符合标准的 PaaS 应用程序的计量数据，而无需进行任何自定义集成。
问题描述¶
目前正在开发许多 PaaS 服务，并且在 OpenStack 基础设施之上运行着越来越多的应用程序。这些新的应用程序中的许多都需要进行计量，原因有很多：内部系统管理、许可管理、最终客户计费。Ceilometer 当前支持收集许多基础设施级服务的计量信息，但是为 OpenStack 中可能托管的潜在数百（最终是数千）个服务进行自定义集成是不可行的。我们希望通过定义通用的 PaaS 通知负载来避免这个问题，以便 Ceilometer 可以消耗 PaaS 通知而无需进行大量的集成工作。
一些用例浮出水面：数据库即服务
数据库即服务 (DBaaS)，例如 Trove，具有一种架构，服务控制器代表客户管理特殊的 Nova 计算实例。从他们的角度来看，他们正在运行数据库实例，而不是计算实例。计量和计费将基于数据库运行的小时数，不一定基于托管实例的运行时间。这需要生成和存储一组唯一的计量记录，以启用对单个数据库实例的使用跟踪和计费。
DNS 即服务
DNS 即服务在与 DBaaS 类似的架构上运行。在这种情况下，需要计量的指标是 DNS 区域的存在以及已服务的 DNS 查询数量。再次强调，这些是应用程序级别的指标，与正在运行的宿主机没有直接关联。查询可以由各种主机提供，并且 DNS 区域的存在不依赖于特定的计算实例。DNS 服务必须跟踪应用程序级别的指标并报告出来，以便可以跟踪这些系统。
负载均衡即服务
负载均衡器是一个逻辑系统，由一些独立的后端组成，这些后端托管负载均衡软件。需要计量的指标包括负载均衡器 VIP 的存在、其成员以及通过系统传输的数据量。再次强调，这与底层基础设施没有直接关联，但必须在应用程序级别报告。
提议的变更¶
我们需要标准化 PaaS 负载的内容，以包含一组数据，这些数据将包括用于计量和计费所需的数据。这本质上构成了一个文档更改和一组用于验证关键字段的测试。
以下是建议的模式
[
{
"Field": "event_type",
"Type": "enumeration",
"Description": "for event type records, this describes the actual event that occurred",
"Compliance": "required for events",
"Notes": "depends on service, defaults to create, exists, delete"
},
{
"Field": "timestamp",
"Type": "UTC DateTime",
"Description": "timestamp of when this event was generated at the resource",
"Compliance": "required",
"Notes": "ISO 8859 date YYYY-mm-ddThh:mm:ss"
},
{
"Field": "message_id",
"Type": "String",
"Description": "unique identifier for event",
"Compliance": "required",
"Notes": ""
},
{
"payload": [
{
"Field": "version",
"Type": "String",
"Description": "Version of event format",
"Compliance": "required",
"Notes": ""
},
{
"Field": "audit_period_beginning",
"Type": "UTC DateTime",
"Description": "Represents start time for metrics reported",
"Compliance": "required",
"Notes": "Format ISO 8859 date YYYY-mm-ddThh:mm:ss"
},
{
"Field": "audit_period_ending",
"Type": "UTC DateTime",
"Description": "Represents end time for metrics reported",
"Compliance": "required",
"Notes": "Format ISO 8859 date YYYY-mm-ddThh:mm:ss"
},
{
"Field": "record_type",
"Type": "enumeration ",
"Values": {
"event": "events describe some kind of state change in the service",
"quantity": "quantity describes a usage metric value"
},
"Compliance": "required",
"Notes": ""
},
{
"Field": "project_id",
"Type": "UUID",
"Description": "Keystone project_id identifies the owner of
the service instance",
"Compliance": "required",
"Notes": ""
},
{
"Field": "user_id",
"Type": "UUID",
"Description": "Keystone user_id identifies specific user",
"Compliance": "optional",
"Notes": ""
},
{
"Field": "service_id",
"Type": "UUID",
"Description": "Keystone service_id uniquely identifies a service",
"Compliance": "required",
"Notes": ""
},
{
"Field": "service_type",
"Type": "String",
"Description": "Keystone service_type uniquely identifies a service",
"Compliance": "required",
"Notes": ""
},
{
"Field": "instance_id",
"Type": "UUID",
"Description": "uniquely identifies an instance of the service",
"Compliance": "required",
"Notes": "assuming instance level reporting"
},
{
"Field": "display_name",
"Type": "String",
"Description": "text description of service",
"Compliance": "optional",
"Notes": "used if customer names instances"
},
{
"Field": "instance_type_id",
"Type": "enumeration",
"Description": "used to describe variations of a service",
"Compliance": "required",
"Notes": "needed if variations of service have different prices or
need to be broken out separately"
},
{
"Field": "instance_type",
"Type": "String",
"Description": "text description of service variations",
"Compliance": "optional",
"Notes": ""
},
{
"Field": "availability_zone",
"Type": "String",
"Description": "where the service is deployed",
"Compliance": "optional",
"Notes": "required if service is deployed at an AZ level"
},
{
"Field": "region",
"Type": "String",
"Description": "data center that the service is deployed in",
"Compliance": "optional",
"Notes": "required if service is billed at a regional level"
},
{
"Field": "state",
"Type": "enumeration",
"Description": "status of the service at the time of record generation",
"Compliance": "optional",
"Notes": "required for existence events"
},
{
"Field": "state_description",
"Type": "String",
"Description": "text description of state of service",
"Compliance": "",
"Notes": ""
},
{
"Field": "license_code",
"Type": "enumeration",
"Description": "value that describes a specific license model",
"Compliance": "optional",
"Notes": "this field is TBD depending on dev_pay design work"
},
{
"metrics": [
{
"Field": "metric_name",
"Type": "String",
"Description": "unique name for the metric that is represented
in this record",
"Compliance": "required",
"Notes": ""
},
{
"Field": "metric_type",
"Type": "enumeration",
"Description": "gauge, cumulative, delta",
"Compliance": "required",
"Notes": "describes the behavior of the metric, from ceilometer"
},
{
"Field": "metric_value",
"Type": "Float",
"Description": "value of metric for quantity type records",
"Compliance": "required for quantities",
"Notes": ""
},
{
"Field": "metric_units",
"Type": "enumeration",
"Description": "describes the units for the quantity",
"Compliance": "optional",
"Notes": ""
}
]
}
]
}
]
注意：必需表示必须存在并且如规范中所述进行描述。可选表示可以存在或不存在，但如果存在，则必须如规范中所述进行描述。
替代方案¶
这种标准化的替代方法是允许 PaaS 服务提供商确定通知的内容以及相关的插件，需要通过补丁来解决实施后缺失的数据。
数据模型影响¶
这将需要哪些新的数据对象和/或数据库模式更改？
这种格式应该适合现有的模式。
将伴随此更改的数据库迁移是什么，分别处理 SQLAlchemy 和 NoSQL 的情况。
不需要 DB 迁移。
这是否会增加我们随着时间推移而积累的即席数据处理混乱？
此更改的目的是避免 PaaS 服务在实施通知负载变化时可能产生的混乱爆炸。
REST API 影响¶
API 应该透明地处理 PaaS 数据，不应有 API 影响。
安全影响¶
由于此 BP 仅指定 PaaS 样本的标准格式（并且与当前样本内容非常相似，即 Ceilometer 样本的当前内容），因此没有安全影响。
Pipeline 影响¶
PaaS 收集代理的实施在单独的 BP 中记录；这种标准化本身不需要管道更改。
其他最终用户影响¶
无。
性能/可扩展性影响¶
无。
其他部署影响¶
实施此标准应该对部署者产生积极影响：从一开始统一 PaaS 内容将降低下游处理所需的缺失数据的可能性。
开发者影响¶
在定义每个正在实施的 PaaS 服务的数据集以满足标准方面，会增加前期工作量。此外，还意味着该标准可能会演变，因此文档/测试也可能会演变。
实现¶
负责人¶
这与 PaaS 事件收集蓝图中的文档工作相关联，并且将与其并行实施。也就是说，如果对 PaaS 事件感兴趣的人，尤其是如果存在我们在此处未考虑的数据元素，那么将其开放给他们肯定是有益的。
- 主要负责人
nealph (phil.neal@hp.com)
- 其他贡献者
fabiog (fabio.gianetti@hp.com)
- 持续维护者
nealph (phil.neal@hp.com)
标准可能会扩展：这里的意图是定义和清楚地记录所需的核心元素。因此，我预计除了我自己之外的其他人也会对本文档做出贡献。
工作项¶
1. 识别对现有服务的影响（如果有）并提交适当的请求（通过 Launchpad）
创建文档更改
未来生命周期¶
我预计在未来的发布周期中会面临扩展规范的压力。
依赖项¶
无
测试¶
由于我们希望检查规范中定义的字段是否存在，因此对测试有一定的含义。
文档影响¶
此更改的文档是核心交付成果。虽然它不需要大量的文档，但文档的可读性和描述性至关重要。我们预计将利用 https://wiki.openstack.org/wiki/Ceilometer/blueprints/StandardPaaSEventFormat 中的大量内容，以及添加更新的事件负载示例。
参考资料¶
此更改的完整蓝图可在以下网址获取：https://wiki.openstack.org/wiki/Ceilometer/blueprints/StandardPaaSEventFormat
概述 PaaS 事件收集机制更改（受益于此标准到位）的相关蓝图可在以下网址获取：https://wiki.openstack.org/wiki/Ceilometer/blueprints/PaaSEventUsageCollection
