介绍重处理 API

本规范提出一个 API 以启用重处理。

问题描述

有时，由于评级规则的错误配置，或者由于收集器后端（Gnocchi、Prometheus 或其他）中的数据回填，操作员需要重新处理 CloudKitty 数据。通常采取的重处理流程如下。

  • 停止所有 CloudKitty 处理器，

  • 重置 MySQL 数据库中所有需要重处理的 scope 的 状态（最后处理/评级的时间戳），

  • 清理/删除处理数据后端（例如 InfluxDB）中受影响时间范围内的所有已处理/评级数据，

  • 重启 CloudKitty 处理器。

CloudKitty 已经有一个 API 可以重置 scope 的处理/评级状态 [1]。但是，此 API 仅重置 MySQL 数据库中的状态。因此，重要的是要有一个 API 来实现操作员在需要重处理时通常执行的手动步骤。

提议的变更

为了避免重处理过程中的人为错误，并使其更容易供非 CloudKitty 专家执行，我们建议引入一个重处理 API，该 API 会安排重处理，并从后端（例如 InfluxDB）中删除受影响时间范围内的已处理/评级数据。

为此，我们将使用一个新的表来存储 scope 的重处理进度，建议的表名为 storage_scope_reprocessing_schedule。

+------------------------------+--------------+------+-----+-------------------+----------------+
| Field                        | Type         | Null | Key | Default           | Extra          |
+------------------------------+--------------+------+-----+-------------------+----------------+
| id                           | int(11)      | NO   | PRI | NULL              | auto_increment |
| identifier                   | varchar(256) | NO   | MUL | NULL              | FK             |
| start_reprocess_time         | datetime     | NO   |     | -                 |                |
| end_reprocess_time           | datetime     | NO   |     | -                 |                |
| current_reprocess_time       | datetime     | yes  |     | NULL              |                |
| reason                       | text         | NO   |     | NULL              |                |
+------------------------------+--------------+------+-----+-------------------+----------------+

安排重处理 API 的端点将是

  • POST /v2/task/reprocesses

    • scope_id：要安排重处理的 scope ID 列表。

    • start_reprocess_time：开始重处理的时间戳。

    • end_reprocess_time：结束重处理的时间戳。

    • reason：重处理的原因

  • GET /v2/task/reprocesses/<scope_id> – 检索单个 scope 的重处理计划。

  • GET /v2/task/reprocesses - 检索多个 scope 的重处理计划

/v2/task/reprocesses 端点将接收类似于以下内容的 POST 请求

{
  "scope_id": ["scope_id_one", "scope_id_two", ...],
  "start_reprocess_time": "2021-05-01 00:00:00",
  "end_reprocess_time": "2021-05-30 23:00:00"
  "reason": "The reason why this reprocessing is scheduled."
}

reason 字段是必需的，以强制用户解释为什么安排重处理。我们强制用户记录他们采取如此严厉措施的原因，例如重处理。因此，我们保留了已安排的重处理及其各自的原因/解释的历史记录。

如果在通过 scope_id 告知的 scope ID 之一不存在，我们将引发一个异常，告知操作员请求中存在无效的 scope ID。

只能为已经处理过的 scope 的时间戳安排重处理。因此，如果 end_reprocess_time 晚于给定资源的最新处理时间戳，API 中将抛出错误。

不能安排重叠的重处理。因此，只有当先前安排的重处理完成时（如果有开始/结束时间戳重叠），才能重新处理 scope 的重处理。

创建计划后，CloudKitty 处理器将清理给定资源的受影响时间范围，然后继续进行重处理。每次重新处理时间戳时，都会更新 current_reprocess_time，类似于当前处理工作流程。

当 current_reprocess_time 等于 end_reprocess_time 时，表示安排的重处理已完成。因此，重处理工作程序将对该条目不执行任何操作。

我们还将引入一个端点来咨询已安排重处理的状态。

  • 列出所有计划：GET /v2/task/reprocesses

    • scope_id：可选字段，用于过滤已安排重处理的 scope。如果未提供 scope，我们将列出所有 scope。

备选方案

手动执行先前描述的重处理步骤。

数据模型影响

将在数据库中添加一个新表 (storage_scope_reprocessing_schedule)。

REST API 影响

将引入一个新的 API：/v2/task/reprocesses。

安全影响

只有管理员才能访问此新 API

通知影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

无

开发人员影响

无

实现

负责人

主要负责人

工作项

  1. 提出、讨论和合并规范

  2. 执行如描述的实现。

  3. 实现 CloudKitty 客户端中的更改以支持新的 API

依赖项

无

测试

单元测试

文档影响

无

参考资料