Ceilometer/blueprints/Ceilometer-specify-event-api

简介

此蓝图记录了 Ceilometer v2 API 的 API 扩展，用于支持事件。

API 的建模是通过审查 StackTach、Stacky 和当前的 Ceilometer v2 API 完成的，网址为

https://docs.openstack.org/developer/ceilometer/webapi/v2.html

以及 Ceilometer 度量，网址为

https://docs.openstack.org/developer/ceilometer/measurements.html.

下面是一个表格，显示了 Stack/Stacky 到 Ceilometer API 扩展的映射。由于我想确保方向看起来是合理的，因此尚未定义所有详细信息。我们可以使用该表来跟踪我们是否涵盖了所有重要内容。

总的来说，我们尝试尽可能地使此与当前的 Ceilometer API 保持一致。

1. 度量部分进行了一些补充，目前这意味着以下内容。对于每种新的事件类型，例如“compute.instance.create.start”，都与其关联一个计量器，该计量器将是一个计数器。对于新的事件对，例如 (compute.instance.create.start, compute.instance.create.end)，则有一个计量器，该计量器将是总累积时间。如果您有兴趣了解启动特定实例所花费的总时间，则需要提供带有指定 resource_id 的查询筛选器参数。我仅为 compute.instance.create 度量指定了此页面，但如果这看起来是合理的，其余的将很容易添加。
2. 有一个新的部分用于查询事件。查询筛选器参数可用于根据资源 ID、项目 ID 等过滤，类似于所有现有的查询筛选器。为了模拟 StackTach 中的 traits，对查询筛选器部分进行了一些补充，例如 event_type 和 request_id。已提供一些示例。
3. 对计量器部分进行了一些更改，例如“GET /v2/meters/statistics/”以及如何使用当前命令查询计量器以模拟 stacky 命令。
4. 有一些新的返回类型。

• EventType
• 事件

将此文档与上述链接进行比较，您应该可以看到它与当前的 Ceilometer v2 API 如何一致。

Stacky 与 Ceilometer 的映射

本节描述了从 StackTach/Stacky 到 Ceilometer 的提议映射。本节是从审查 stacktack/urls.py 和 stacky cli 的输出得出的。

StackTach	Stacky	Ceilometer	描述
部署	stacky deployments	不适用	列出环境名称，例如 rnd-a
事件	stacky events	GET /v2/event_types/	返回所有事件类型的列表。
宿主	stacky hosts	GET /v2/events/traits/(trait)/。	返回给定 trait 的值列表。
UUID	stacky uuid c0c0e50b-cdee-4fe9-9e4c-95ce6cf3fd94	GET /v2/events/	返回所有事件的列表。
计时	stacky timings compute.instance.create	GET /v2/meters/(meter_id)/	返回计量器的统计信息。
计时/实例 UUID			返回实例 ID 的计量器。
摘要	stacky summary	GET /v2/meters/statistics/	列出统计信息，例如计量器的数量、最小值、最大值和平均值
请求	stacky request req-0809cdd8-21f3-46c3-8803-4a2d9aa45436	GET /v2/events/	列出与指定请求 ID 关联的事件。
报告
reports/id
show/event_id	stacky show 1562333	GET /v2/events/(event_id)/	返回指定事件 ID 的详细信息。
watch/deployment_id
kpi/project_id
kpi/tenant_id

度量

本节描述了为支持 StackTach 功能而添加到 Ceilometer 的新计量器，通过扩展在 [Measurements](https://docs.openstack.org/developer/ceilometer/measurements.html) 中定义的表。

计算 (Nova)

姓名	类型	单位	资源	来源	注意
compute.instance.create.start	累积	纳秒	实例 ID	通知	创建开始通知的数量
compute.instance.create.end	累积	纳秒	实例 ID	通知	创建结束通知的数量
compute.instance.create	累积	纳秒	实例 ID	通知	创建实例的总时间
待完成此表。

• 注意：我们需要支持来自所有 <foo>.start 和 <foo>.end 事件对的时间差计量器。不确定这在 CM 中如何工作？
  • 如果我们将计量器名称截断以删除 .start 和 .end，但保留其余数据（请求 ID 等），则可以使用 /v2/meters/(meter_id)/statistics/ 中的正常持续时间计算来获取时间差。- dhellmann
    • 它们需要通过请求 ID 相关联并按时间排序……这有可能吗？- sandy
      • 是的，可以按请求 ID 分组。如果我理解 group-by，我们可以使用“g[0]=request_id”或类似的东西进行分组。--Roland
      • 按时间排序是可能的，但我只是想知道我们是否需要添加一个类似于 group-by 的“order-by”扩展。例如，“o[0]=timestamp”。--Roland
    • 我们需要实现“group by”查询选项。https://blueprints.launchpad.net/ceilometer/+spec/api-group-by - dhellmann
      • 同意。--Roland
• 注意：我们还需要支持来自“Service” == “api” -> *.end 事件对的时间差，这些事件对具有相同的请求 ID。同样，不确定 CM 如何处理？
  • 我认为我们只需要其他服务中的中间件来收集事件数据，尽管我可能遗漏了关于此问题的某些内容。- dhellmann
    • 是的，这不是中间件问题，而是时间排序问题。我们已经有了跨事件的统一请求 ID。-sandy
    • 好的，我认为这由 groupby 和现有的计量器处理，然后呢？- dhellmann
• 可能需要为每种事件类型添加一个新的计量器。
• 注意，所有事件至少都将有一个与之关联的计量器，例如计数器。但是，事件不是计量器。事件可能与多个计量器相关联，并且事件对（例如 start/end 对）可能会引入额外的事件。
• 待完成：根据通知完成事件列表。
  • 这个待完成是“列出通知”还是“列出有趣的通知”？有什么理由不收集所有通知吗？- dhellmann
    • 我们将收集所有事件，问题是是否应该从这些事件中推断出其他指标？-sandy
    • 明白了。- dhellmann

资源

GET /v2/resources/

返回所有资源的定义。StackTach 集成不需要任何新的更改。

GET /v2/resources/(resource_id)/

返回指定 resource_id 的详细信息。StackTach 集成不需要任何新的更改。

事件

这是 StackTach 集成的新的 api 部分。本节的主要目标是查询事件。

GET /v2/event_types/

返回所有事件类型的列表。事件类型的示例如下

• compute.instance.create.start
• compute.instance.create.end

返回类型

• list(EventType) - 事件类型列表。我们真的需要 EventType 还是可以直接返回 list(String)？

要模拟 stacky 命令“./stacky.py events”，http 请求 GET "/v2/event_types/" 将返回事件类型的列表。

GET /v2/events/

根据查询筛选器返回所有事件的列表。事件示例如下

• compute.instance.create.start
• compute.instance.create.end

使用此查询，可以请求特定资源、用户、项目、请求 ID、宿主或时间范围的所有事件。

要模拟 Stacky 命令“./stacky.py uuid c0c0e50b-cdee-4fe9-9e4c-95ce6cf3fd94”，http 请求“GET /v2/events”和查询筛选器

   {
       "field": "resource_id",
       "op": "eq",
       "value": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36"
   }

可以使用。

要模拟 Stack 命令“./stacky.py request req-0809cdd8-21f3-46c3-8803-4a2d9aa45436”，http 请求“GET /v2/events”和查询筛选器

   {
       "field": "request_id",
       "op": "eq",
       "value": "req-0809cdd8-21f3-46c3-8803-4a2d9aa45436"
   }

可以使用。

参数

• q (list(Query)) - 返回的事件名称的筛选规则。通过指定不同的查询筛选器，可以复制 StackTach 支持的所有查询。例如，要获取与特定资源 ID 关联的所有事件，可以定义以下查询筛选器

   {
       "field": "resource_id",
       "op": "eq",
       "value": "bd9431c1-8d69-4ad3-803a-8d4a6b89fd36"
   }

• 注意：我认为我们需要对查询筛选器进行一项修改。由于 traits 表基于对象的类型存储数据，因此我认为必须在查询中指定它，即“type”:“t_int”。您对如何解决此问题有其他想法吗？-JohnH

返回类型

• list(Events) - 事件列表。

GET /v2/events/(event_id)/

返回指定事件的详细信息，其中 event_id 是事件的 UUID。

待完成。填写事件的详细信息。

要模拟 stacky 命令“./stacky.py show 1562333”，可以使用 http 请求“GET /v2/events/1562333”。虽然事件 ID 将是 UUID"

Ceilometer 中有两种类型的 ID 用于事件，即消息 ID 和事件 ID（Event 表中的主键）。我们应该使用哪个？还有样本的消息 ID 概念，因此该术语在 Ceilometer 中似乎有些超载。据我了解，您指的是消息 ID，在这种情况下，我们可能应该将其暴露给 Event API，以便人们可以在 event-show (GET /v2/events/<message_id>) API 调用中查询它。您的想法呢？-Thomas

GET /v2/events/traits/

返回事件的所有 traits 的列表。traits 的示例包括以下内容

• resource_id
• project_id
• user_id
• request_id
• host
• event_type
• timestamp

计算此列表可能很昂贵。此数据的用例是什么？- dhellmann

• 应该只对 Traits 表执行 select distinct。不确定在 mongo 下这有多昂贵？-Sandy
• 我不确定这是否会在某些数据库中（例如 mongo）造成性能问题。我知道我使用的数据库 Vertica，如果数据组织得当，这种查询几乎是瞬间完成的。我希望我们能够从 mongo 获得类似的性能。作为一个用例，能够查询系统的整体 traits 列表很有用，但获取事件类型的 traits 列表，下一个，可能更有用。另一种选择是记录系统中的每个 traits。如果这样做，我们可以删除此请求。--Roland
• 我们可以以一种避免计算它（基本上，保留所有 traits 名称的集合）的方式在 Mongo 中组织数据。更大的问题是此信息有什么用？API 的消费者将如何使用它？- dhellmann

GET /v2/events/(event_type)/traits/

返回给定指定事件类型的所有 traits 的列表。

GET /v2/events/(event_type)/traits/(trait)/

返回指定事件类型和 trait 的所有值的列表。例如，要模拟 Stacky 命令“stacky hosts”，它返回所有宿主的列表，请使用“GET /v2/events/compute.instance.create.start/traits/host/”。

参数

• q (list(Query)) - 返回的事件名称的筛选规则。

计量

本节模拟了 https://docs.openstack.org/developer/ceilometer/webapi/v2.html#meters 中的 API 文档。只有一个新命令，但在某些情况下，我们包含了该部分以显示如何实现 StackTach 中的一个函数。

GET /v2/meters/

返回所有已知计量器，… StackTach/Stacky 不需要任何新的更改。

GET /v2/meters/statistics/

返回计量器的统计信息。这是解决 StackTach 集成的新的命令。

参数

• q (list(Query)) - 返回的事件名称的筛选规则。通过指定不同的查询筛选器，可以复制 StackTach 支持的所有查询。例如，要获取与特定资源 ID 关联的所有事件，可以定义以下查询筛选器

   {
       "field": "hostname",
       "op": "eq",
       "value": "hostname.domain"
   }

返回类型

• list(Statistics) - 统计信息列表。

要模拟 stacky 命令“./stacky.py summary”，可以使用 http 请求“GET v2/meters/statistics”。可以通过使用查询筛选器进一步细化。

这与现有的 /v2/meters/(meter_id)/statistics/ 查询有什么不同？只是您不必指定要汇总的计量器？是否会自动按计量器分组？- dhellmann

• 是的，这就是此查询所做的事情。按计量器分组将是自动的。此查询不是必需的。您想将其删除吗？--Roland
• 如果我们在实现 groupby 蓝图后确实是多余的，那么是的，我认为我们应该将其删除。- dhellmann

GET /v2/meters/(meter_id)/

返回指定计量器的样本。StackTach 集成不需要任何新的更改。

要模拟 Stacky 命令“./stacky.py timings compute.instance.create”，可以使用 http 请求“GET /v2/events”和查询筛选器

   {
       "field": "event_type",
       "op": "eq",
       "value": "compute.instance.create"
   }

如果未指定查询筛选器，将返回资源的计量器列表，该资源对于指定的 meter_id 有效。

GET /v2/meters/(meter_id)/statistics/

返回指定计量器的统计信息，例如最小值、最大值、平均值。StackTach 集成不需要任何新的更改。

参数

• q (list(Query)) - 返回的事件名称的筛选规则。通过指定不同的查询筛选器，可以复制 StackTach 支持的所有查询。例如，要获取与特定资源 ID 关联的所有事件，可以定义以下查询筛选器

   {
       "field": "hostname",
       "op": "eq",
       "value": "hostname.com.com"
   }

返回类型

• list(Statistics) - 统计信息列表。

样本和统计信息

计量器

一类测量。

• request_id：如果有效，则指定请求 ID 的可选字段。

样本

给定计量器和资源的单个测量。

• request_id：如果有效，则指定请求 ID 的可选字段。

统计信息

查询的计算统计信息。

• request_id：如果有效，则指定请求 ID 的可选字段。

过滤查询

StackTach 集成不需要任何更改。查询需要支持以下字段以进行 StackTach 集成

• resource_id
• project_id
• user_id
• host
• timestamp

为了解决 StackTach 集成，需要几个额外的字段，如下所示

• request_id
• event_type

事件

本节是 StackTack 集成的新的内容。

EventType

事件类型的描述。待完成。

• 我们真的需要 EventType 还是应该只使用 String？
  • 目前，EventType 只是一个 String。-Sandy

事件

事件的描述。需要指定事件的所有详细信息。请注意，事件可能非常具体。例如，VM 生命周期事件具有任务状态、构建状态……

注意：我们需要向 Event 添加一个非 Traits 属性 Source ID。目前，我们正在使用数据库 ID 作为唯一标识符，但需要更改为外部定义，以便标识重复事件（可能通过 AMQP 重新安排）并且数据库应阻止此列上的重复索引条目。