Monasca 事件监听器¶

https://storyboard.openstack.org/#!/story/2003023

Monasca 事件 API 1 的开发旨在将事件数据存储在 Elasticsearch 中。新的应用程序可以使用 Monasca 事件 API 直接发布事件以进行处理和存储。然而，需要一个通用的收集服务来捕获 OpenStack 服务已经生成的现有 OpenStack 通知，并将其传递给 Monasca 进行存储和处理。本规范提议创建一个新的 Monasca 事件监听器来捕获事件并将其传递给 Monasca 服务。

问题描述¶

所有 Openstack 服务都会生成大量通知或事件，其中包含有关服务及其资源的大量操作和状态信息。Nova 14 等服务已经发布到 RabbitMQ 主题。此通知数据目前在 Monasca 中不可用。

Ceilometer 数据处理管道 3 提供了一种使用自定义发布器发布样本和事件的可扩展机制。Ceilometer 样本表示可测量的数量（例如，卷的大小），事件表示事件的发生且没有关联的数量（例如，卷已创建）。遥测项目还有一个 Panko 5 服务用于索引和存储这些事件。

此前创建了一个规范，用于指定对 Ceilometer 的增强，以允许将收集到的事件发布到 Monasca 事件 API。然而，随着 Ceilometer 事件功能最近的弃用 13，这不再是一个长期选择。

本规范旨在创建一个新的 Monasca 服务，该服务将监听 OpenStack 事件消息（通常称为通知），并通过消费 RabbitMQ 消息并向 Monasca 事件 API 发布该事件来通过 Monasca 处理它们。

此服务可以使用 Ceilometer、Vitrage、Watcher 或其他服务作为如何监听来自 OpenStack 服务（如 Nova 14）的通知的示例。

建议将 Monasca 事件监听器服务作为 Monasca Agent 代码库的一部分，并重用代码，包括现有的 monasca_setup 脚本和配置。

用例¶

Openstack 通知数据将通过 Monasca 服务存储在 Elasticsearch 中

示例序列
1. Nova 完成 VM 创建
2. Nova 向 oslo.messaging 生成通知消息
3. oslo.messaging 将消息发布到 RabbitMQ
4. Monasca 事件监听器从 RabbitMQ 接收通知消息
5. Monasca 事件监听器根据配置验证通知并将其转换为 Monasca 事件 API 格式
6. Monasca 事件监听器将格式化的通知发布到 Monasca 事件 API
7. Monasca 事件 API 接收并验证格式化的通知
8. Monasca 事件 API 将事件通知存储在配置的 Elasticsearch 实例中

提议的变更¶

Monasca 事件监听器将是一个新服务，可以通过在云中的每个控制器节点上运行 Monasca 事件监听器实例来实现高可用配置。每个节点将监听 RabbitMQ 中的 OpenStack 通知，并将通知转换为对 Monasca 事件 API 的发布。然后，Monasca 事件 API 将通知作为 Kafka 消息传递到“monevents”主题，Monasca 持久化器将在此处接收并存储它们。根据 RabbitMQ 客户端的特性，负载将分布在 Monasca 事件监听器实例之间（只有一个监听器将处理每个 RabbitMQ 消息）。
Monasca 事件监听器将根据要收集的 event_types 规范过滤来自 OpenStack 服务的消息。这将减少“噪音”并将事件收集集中在那些被认为有价值的事件上。此过滤规范可以来自配置文件，也可以选择通过作为 Monasca 事件 API 服务一部分实现的新 API 进行控制。

OpenStack 通知由信封和有效载荷字段组成。有关示例，请参阅 15 和 16。

OpenStack 通知数据格式示例

{
    "_context_auth_token": "42630b3ea13242fcad20e0a92d0207f1",
    "_context_domain": null,
    "_context_instance_lock_checked": false,
    "_context_is_admin": true,
    "_context_project_domain": null,
    "_context_project_id": "a4f77",
    "_context_project_name": "admin",
    "_context_quota_class": null,
    "_context_read_deleted": "no",
    "_context_read_only": false,
    "_context_remote_address": "192.168.245.4",
    "_context_request_id": "req-5948338c-f223-4fd8-9249-8769f7a3e460",
    "_context_resource_uuid": null,
    "_context_roles": [
        "monasca-user",
        "admin",
        "KeystoneAdmin"
    ],
    "_context_service_catalog": [
        {
            "endpoints": [
                {
                    "adminURL": "http://192.168.245.8:8776/v2/a4f77",
                    "internalURL": "http://192.168.245.8:8776/v2/a4f77",
                    "publicURL": "http://192.168.245.9:8776/v2/a4f77",
                    "region": "region1"
                }
            ],
            "name": "cinderv2",
            "type": "volumev2"
        },
        {
            "endpoints": [
                {
                    "adminURL": "http://192.168.245.8:8776/v1/a4f77",
                    "internalURL": "http://192.168.245.8:8776/v1/a4f77",
                    "publicURL": "http://192.168.245.9:8776/v1/a4f77",
                    "region": "region1"
                }
            ],
            "name": "cinder",
            "type": "volume"
        }
    ],
    "_context_show_deleted": false,
    "_context_tenant": "a4f77",
    "_context_timestamp": "2015-09-18T20:54:23.468522",
    "_context_user": "be396488c7034811a200a3cb1d103a28",
    "_context_user_domain": null,
    "_context_user_id": "be396488c7034811a200a3cb1d103a28",
    "_context_user_identity": "be396488c7034811a200a3cb1d103a28 a4f77 - - -",
    "_context_user_name": "admin",
    "_unique_id": "ff9699d587bf4283a3c367ab88be1541",
    "event_type": "compute.instance.create.start",
    "message_id": "c6149ba1-34b3-4367-b8c2-b1d6f073742d",
    "payload": {
        "access_ip_v4": null,
        "access_ip_v6": null,
        "architecture": null,
        "availability_zone": null,
        "cell_name": "",
        "created_at": "2015-09-18 20:55:25+00:00",
        "deleted_at": "",
        "disk_gb": 1,
        "display_name": "testeee",
        "ephemeral_gb": 0,
        "host": null,
        "hostname": "testeee",
        "image_meta": {
            "base_image_ref": "df0c8",
            "container_format": "bare",
            "disk_format": "qcow2",
            "min_disk": "1",
            "min_ram": "0"
        },
        "image_name": "glanceaaa3",
        "image_ref_url": "http://192.168.245.5:9292/images/df0c8",
        "instance_flavor_id": "1",
        "instance_id": "abd2ef5c-0381-434a-8efc-d7b39b28a2b6",
        "instance_type": "m1.tiny",
        "instance_type_id": 4,
        "kernel_id": "",
        "launched_at": "",
        "memory_mb": 512,
        "metadata": {},
        "node": null,
        "os_type": null,
        "progress": "",
        "ramdisk_id": "",
        "reservation_id": "r-1ghilddw",
        "root_gb": 1,
        "state": "building",
        "state_description": "",
        "tenant_id": "a4f77",
        "terminated_at": "",
        "user_id": "be396488c7034811a200a3cb1d103a28",
        "vcpus": 1
    },
    "priority": "INFO",
    "publisher_id": "compute.ccp-compute0001-mgmt",
    "timestamp": "2015-09-18 20:55:37.639023"
}

所有带有“_context”前缀的字段都是信封字段，其他有趣的字段是
1. “message_id” - 通知标识符
2. “payload” - 包含 JSON 格式的大部分相关和有用信息
3. “priority” - 通知优先级
4. “publisher_id” - 通知发布者
5. “timestamp” - 通知时间戳
Monasca 事件监听器将 OpenStack 通知转换为 Monasca 事件格式。此格式将适用于 Kafka 消息传递，并将匹配 Monasca 持久化器预期的_数据_字段。此转换和验证应在 Monasca 事件监听器和 Monasca 事件 API 之间通用。
Kafka 客户端连接将根据需要处理重新连接和重新发送等通信问题。

Monasca 事件 API 允许一个名为“payload”的字段，它可以是任意嵌套的 JSON 格式。

Monasca 事件格式示例

events: [
{
  dimensions": {
        "service": "compute.ccp-compute0001-mgmt",
        "topic": "notification.sample",
        "hostname": "nova-compute:compute
  },
  event: {

          "event_type": "compute.instance.create.start",

          "payload": {
               "access_ip_v4": null,
               "access_ip_v6": null,
               "architecture": null,
               "availability_zone": null,
               "cell_name": "",
               "created_at": "2015-09-18 20:55:25+00:00",
               "deleted_at": "",
               "disk_gb": 1,
               "display_name": "testeee",
               "ephemeral_gb": 0,
               "host": null,
               "hostname": "testeee",
               "image_meta": {
                   "base_image_ref": "df0c8",
                   "container_format": "bare",
                   "disk_format": "qcow2",
                   "min_disk": "1",
                   "min_ram": "0"
               },
              "image_name": "glanceaaa3",
              "image_ref_url": "http://192.168.245.5:9292/images/df0c8",
              "instance_flavor_id": "1",
              "instance_id": "abd2ef5c-0381-434a-8efc-d7b39b28a2b6",
              "instance_type": "m1.tiny",
              "instance_type_id": 4,
              "kernel_id": "",
              "launched_at": "",
              "memory_mb": 512,
              "metadata": {},
              "node": null,
              "os_type": null,
              "progress": "",
              "ramdisk_id": "",
              "reservation_id": "r-1ghilddw",
              "root_gb": 1,
              "state": "building",
              "state_description": "",
              "tenant_id": "a4f77",
              "terminated_at": "",
              "user_id": "be396488c7034811a200a3cb1d103a28",
              "vcpus": 1
              }
         },
    publisher_id: "compute.ccp-compute0001-mgmt",
    priority: "INFO"
 }
]

Monasca 事件数据中的以下字段可能在 OpenStack 通知数据格式中不可用
- “service”
- “dimensions.topic”
- “event.priority”
我们建议从 Monasca 事件格式中删除这些字段（这将作为单独的规范/实现过程完成），原因如下

“service”：目前 OpenStack 通知未以一致的方式指定生成通知的服务。可以创建一个外部映射文件，将事件名称映射到服务，但长期维护此类映射很困难。

“dimensions.topic”：此字段在源 OpenStack 通知中不可用。然而，Monasca 事件监听器可能能够保存收集通知的 RabbitMQ 主题。在这种情况下，应使用此字段。

“event.priority”：此字段目前在 Ceilometer 事件格式中不可用。它在源 OpenStack 通知中可用。注意：如果我们认为此字段可能有用，我们可以建议将其添加到 Monasca 事件监听器格式中。
以下新字段将作为维度添加到 Monasca 事件数据中
- “dimensions.publisher_id”：生成事件的发布者标识符。
- “dimensions.user_id”：生成事件的用户标识符。
- “dimensions.project_id”：生成事件的项目标识符。
“hostname”在事件有效载荷中可用，但其位置可能因事件而异。
提议的新 Monasca 事件监听器将能够以批处理方式和可配置的频率提交事件数据（类似于当前的样本发布器）。如果当前批处理中的项目达到其最大大小（配置设置）或者自上次发布以来已过去一定时间间隔（配置设置），则将发布事件数据。这将确保批处理不会变得过于庞大，同时在将事件发布到 Monasca 事件 API 时也没有明显的延迟。
Monasca 事件监听器将有一个配置文件，用于配置 RabbitMQ 和 Monasca 事件 API 的连接信息。
通知中“tenant_id”和“user_id”的关联信息在通知的“payload”部分可用，并且这些通知由每个服务本身生成。

不需要额外的“OpenStack-operator-agent”之类的组件或功能来从服务获取该数据并代表原始租户发布到 monasca 事件 API。（Ceilometer 发布管道只是从“payload”中提取这些“tenant_id”和“user_id”字段，并将这些字段作为“tenant_id”和“user_id”特征提供，然后将其映射到 monasca 事件格式中的“dimensions.project_id”和“dimensions.user_id”字段。）

换句话说，原始的“tenant_id”和“user_id”值在通知的有效载荷中可用，并将进入 Monasca 事件中的“dimensions.tenant_id”和“dimensions.user_id”。

问题/待办事项
- 问：我们是否需要做任何特殊处理来处理 monasca-events api 中的多租户，就像处理指标 9 一样？维度中的“dimensions.user_id”和“dimensions.tenant_id”字段中的原始 user_id 和 tenant_id 是否能达到此目的？
  - 答：Monasca 事件监听器可以开始将所有事件发送到一个“admin”租户，如果将来需要，其他进程可以将选定的指标复制回租户项目。
- 问：在 Ceilometer V2 API（已弃用并删除）中，当查询数据时，“admin”角色可以访问所有租户的数据，而具有“ceilometer-admin”角色的用户只能访问特定租户的数据。我们是否可以为 monasca-events api 在查询数据时实现类似的功能？
  - 答：在 Monasca API 中，每个请求都限定在项目范围内，因此没有相当于 Ceilometer 的“admin”角色来查询所有项目的数据。因此，将所有事件放入“admin”项目可能是最好的方法。
- 问：对于生成通知但不包含 tenant_id 的服务，应如何处理？例如 Keystone 16。Ceilometer 如何处理此类事件？
  - 答：如果所有事件都在“admin”项目中，那么可以将来宾指标（如共享 ceph 集群负载或提供者网络负载）复制回租户，以便他们可以了解基础设施如何影响其工作负载。
- 注意：Elasticsearch 集群的配置不属于本规范的范围。如果需要，可以为事件 API 分配一个单独的 Elasticsearch 集群以避免过载。

替代解决方案¶

重用 Ceilometer 功能以收集事件并将其发布到 Monasca 事件 API。虽然这在最初可能工作量较小，但 Ceilometer 已在 Stein 版本中弃用了事件功能。13
提出了另一个事件监听器，它将监听 RabbitMQ 事件，然后直接将其发布到 Kafka 中的“monevents”主题。有关此内容的讨论可在本文档的 git 历史记录和 IRC 日志 18 中找到。

优点
- 一种更简单的方法，比通过另一个服务进行 HTTP 跳转更高效。
- 服务中无需批处理，因为 RabbitMQ 和 Kafka 客户端将处理快速吞吐量和短时网络中断。
缺点
- Nova Cells v2 都有自己的 RabbitMQ 实例。虽然大多数部署可能都有一个集中的 RabbitMQ，但在文档的架构中这不是必需的。
- 区域也可能导致需要监控的 RabbitMQ 实例分离。
- 虽然可能在每个 Cell 中都有一个服务/代理直接发布回集中的 Kafka，但我们的 Kafka 认证和网络设计不支持这一点。
OpenStack Panko 5 是 Ceilometer 的事件存储和 REST API，可以代替 Monasca 解决方案使用。

优点
- 遥测项目中的一个“官方”子项目，因此获得了一些社区认可。
缺点
- 它的主要存储在关系数据库中，这在规模方面存在问题。
- 它不活跃维护且尚未准备好用于生产。11
- 它最终将被弃用。12

数据模型影响¶

无

REST API 影响¶

我们建议通过删除和添加上述“提议的更改”部分中提到的字段来调整 Monasca 事件数据格式。

删除字段或使其可选（JSON 路径表示法）：“service”、“dimensions.topic”、“dimensions.hostname”和“event.priority”

添加字段（JSON 路径表示法）：“dimensions.publisher_id”、“dimensions.user_id”和“dimensions.project_id”

此更改将对 Monasca 事件 API 产生影响。

安全影响¶

提议的 Monasca 事件监听器将收集 OpenStack 事件（通知）数据并将其发布到 Monasca 事件 API。OpenStack 通知数据不包含任何敏感数据，如“令牌”。通知确实包含“user_id”和“project_id”字段，但不包含用户的任何个人身份信息 (PII) 或项目。

其他最终用户影响¶

无。

性能影响¶

不同服务生成的通知（事件）数量将取决于云的容量以及用户创建的资源数量。

例如，如果创建或销毁了大量的计算 VM，可能会导致需要发布的通知（事件）数量激增。必须记录与事件批处理大小和事件批处理间隔相关的最佳配置选项，以减少对性能的任何不利影响。
提议的 Monasca 事件监听器是一个新服务，因此性能未知。然而，Monasca API 已被证明具有高吞吐量性能。
如果 Monasca 通知管道的任何部分出现故障，通知可能会在 RabbitMQ 中积压并导致集群崩溃。通过为通知使用单独的 RabbitMQ 实例可以缓解此风险。

其他部署者影响¶

提议的 Monasca 事件监听器将引入一些新的配置选项，例如
- RabbitMQ 连接信息
- Monasca 事件 API 端点 URL
- 事件批处理间隔
- 事件批处理大小
- 事件重试间隔
- 用于获取令牌的 Keystone 凭据
- OpenStack 通知到 Monasca 事件格式的转换选项。这可以存储在单独的管道配置文件中，类似于 Monasca Transform 中配置转换规范的方式。
作为开发新的 Monasca 事件监听器的一部分，devstack 插件将更新以添加上述配置更改。

开发者影响¶

对 Monasca 事件格式的提议更改将对现有的 Monasca 事件 API 产生影响，因为 Monasca 事件格式必须进行调整。（参见上面的 REST API 影响部分）

实现¶

负责人¶

主要负责人: joadavis, aagate
其他贡献者: <launchpad-id 或 None>

工作项¶

实现新的 Monasca 事件监听器。
- 连接到 RabbitMQ 以获取 OpenStack 通知
- 为配置的 event_types 添加通知过滤
  - 配置文件中的规范
  - （可选）创建新的 API 以配置 event_type 订阅
- OpenStack 通知数据和格式验证
- 数据格式转换为满足 Monasca 事件要求
- 发布到 Monasca 事件 API
- 每个事件类型的转换规范配置
实现 monasca devstack 插件更改以部署新的事件监听器服务。
为 Monasca 事件监听器实现单元测试。