事件告警评估器

https://blueprints.launchpad.net/ceilometer/+spec/event-alarm-evaluator

该蓝图建议添加一个新的告警评估器，用于处理来自其他 OpenStack 服务传递的事件告警，提供事件驱动的告警评估机制，从而在 Ceilometer 中将基于事件的告警处理与现有轮询型告警评估器处理的其他类型告警分离，并实现向最终用户即时发送告警通知。

问题描述

作为最终用户，我需要在 Ceilometer 捕获到触发告警的事件后立即收到告警通知，以便能够及时执行恢复操作，缩短服务的停机时间。典型的用例是，最终用户在“compute.instance.update”上设置告警，以便在实例状态更改为“shutdown”或“error”时触发恢复操作。在检测到故障后 1 秒内收到通知应该是可行的，就像其他健康检查机制在某些情况下可以做到的那样。

现有的告警评估器会定期查询/轮询数据库，以独立于其他进程检查所有告警。这对于评估在特定时间段内存储的样本上的告警来说是一种很好的方法。但是，对于由其他 OpenStack 服务器偶尔发出的事件告警进行评估来说，这种方法效率不高。

周期性评估会导致向用户发送告警通知的延迟。评估周期的默认时间是 60 秒。建议操作员设置比底层指标配置的管道间隔更长的间隔，并且足够长，以便在考虑到资源、用户和告警的数量的情况下评估所有定义的告警。

提议的变更

该建议是添加一个新的事件驱动的告警评估器，该评估器接收来自通知代理的消息，找到相关的告警，然后评估每个告警；

  • 新的告警评估器通过添加一个专门的通知器来发布事件到新的主题来接收来自通知代理的事件通知。主题名称是“alarm.all”。

  • 当新的告警评估器收到事件通知时，它会通过事件通知中编写的项目 ID 查询告警数据库。为了减少 Ceilometer API 的负载，该告警评估器会将通过项目 ID 查询的告警定义在特定时间段内缓存起来。

  • 通过参考事件通知评估找到的告警。

  • 根据评估结果，这些告警将通过告警通知器触发，就像现有的告警评估器一样。

该提案还添加了新的告警类型“event”和“event_rule”。这使得用户可以创建基于事件的告警。与其它告警类型（例如“threshold”类型）的分离旨在显示不同的评估时机和不同的条件格式，因为新的评估器将在收到每个事件通知时对其进行检查，而“threshold”告警可以评估从多个样本计算出的特定时间段内的平均值。

新的告警评估器处理“event”类型的告警，因此我们必须更改现有的告警评估器，以将“event”类型的告警从评估目标中排除。

事件的项目 ID 将通过告警评估器从名为“project_id”和“tenant_id”的 traits 中检索，因为没有通用的字段来保存它。并非所有事件都有项目 ID；像 VM 实例这样的虚拟资源的所有事件都应该具有所属的项目 ID，但像主机这样的物理资源的事件没有项目 ID。由于这些原始的基础设施事件必须对最终用户隐藏，因此它们将被标记为 PROJECT_NONE（API 中的空字符串），只能由管理员在告警定义中设置。

替代方案

有一个类似的蓝图提案“基于通知的告警类型”，但方法不同。旧的提案是在每次从其他 OpenStack 服务接收到事件时，在通知代理中添加一个新的步骤（告警评估），而该提案旨在在另一个组件中执行告警评估，从而最大限度地减少对现有管道处理的影响。

另一种方法是通过添加通知监听器来增强现有的告警评估器。但是，存在两个问题；1) 当它接收到大量通知时，这种方法可能会导致周期性评估停滞，以及 2) 这可能会破坏告警分区，即当告警评估器接收到通知时，它可能必须评估未分配给它的某些告警。

缓存所有告警定义可以减少每个周期对 API/DB 的查询次数，并减少其他项目中的评估时间，但它可能会导致第一次查询的时间更长以及缓存的占用空间更大，因为项目数量可能很大，而项目中的告警数量可能受到配额的限制。

可以使用项目 ID 代替告警查询中的事件 ID，但它不能保证从 DB 检索到的告警数量，并且难以在允许用户在告警定义中的“event_type”中使用通配符时获取所有告警，正如本规范中建议的那样。

可以将资源 ID 作为可选属性添加到告警数据模型中。这将帮助新的告警评估器在查询告警时过滤掉不相关的告警，否则它必须评估项目中的所有告警。为了专注于创建事件告警的基本框架，我们决定在本蓝图中不处理资源 ID。

数据模型影响

无

REST API 影响

告警 API 将扩展如下；

  • 将“event”类型添加到告警类型列表中

  • 将“event_rule”添加到“alarm”中

    • “event_rule”具有“event_type”，可以包含“*”，以指示要对告警评估的事件类型

    • “event_rule”具有“query”，它是一个由 AND 组合的条件列表，与 AlarmThresholdRule 相同

基于通知类型的告警示例数据

{
    "alarm_actions": [
        "http://site:8000/alarm"
    ],
    "alarm_id": null,
    "description": "An event alarm",
    "enabled": true,
    "insufficient_data_actions": [
        "http://site:8000/nodata"
    ],
    "name": "InstanceStatusAlarm",
    "event_rule": {
        "event_type": "compute.instance.update",
        "query" : [
            {
                "field" : "traits.instance_id",
                "type" : "string",
                "value" : "153462d0-a9b8-4b5b-8175-9e4b05e9b856",
                "op" : "eq",
            },
            {
                "field" : "traits.state",
                "type" : "string",
                "value" : "error",
                "op" : "eq",
            },
        ]
    },
    "ok_actions": [],
    "project_id": "c96c887c216949acbdfbd8b494863567",
    "repeat_actions": false,
    "severity": "moderate",
    "state": "ok",
    "state_timestamp": "2015-04-03T17:49:38.406845",
    "timestamp": "2015-04-03T17:49:38.406839",
    "type": "event",
    "user_id": "c96c887c216949acbdfbd8b494863567"
}

安全影响

由于默认事件通知可能包含原始的基础设施信息，因此当允许最终用户操作此事件告警 API 并可以接收事件告警通知时，操作员/管理员应仔细配置事件定义。

Pipeline 影响

此更改需要将新的通知器添加到事件管道中，以便将事件传递给新的告警评估器。

其他最终用户影响

无

性能/可扩展性影响

当 Ceilometer 在短时间内从其他 OpenStack 服务接收到大量事件时，此告警评估器可以继续工作，因为事件排队在消息队列系统中，但它可能会导致向用户发送告警通知的延迟，并增加对告警数据库的读取和写入访问次数。

项目中的所有事件告警都将在每次评估器接收到事件时进行评估。可以通过在告警数据模型上添加新参数（例如资源 ID）并在告警查询时设置过滤器来减少要评估的告警数量。

其他部署影响

必须配置通知代理，以将事件发布到新的主题“alarm.all”，该主题专门用于此事件告警评估器，与当前存储事件的消息不同（即在 event_pipeline.yaml 中添加“notifier://?topic=alarm.all”）。请注意，当新的事件告警评估器在部署中运行时，应完成此配置，否则可能会填满队列。

必须运行新的服务进程（此告警评估器）。

部署者可以运行多个评估器以扩展事件告警评估过程。所有事件将以轮询方式分发到侦听主题的所有评估器。

开发者影响

开发人员应注意，事件可能会通知给最终用户，并避免将原始的基础设施信息传递给最终用户，同时定义事件和 traits。

所有与虚拟资源相关的事件都应具有项目 ID 和用户 ID。

实现

负责人

主要负责人

r-mibu

其他贡献者

lianhao-lu edwin-zhai

持续维护者

无

工作项

  • 添加新的告警类型“event”以及 AlarmEventRule

  • 修改现有的告警评估器以过滤掉“event”告警

  • 新的事件驱动的告警评估器

  • 使新的评估器缓存告警定义

未来生命周期

该提案是向最终用户提供云资源信息的关键功能，从而能够与用户端管理器或编排器有效地集成，而目前这些信息被认为是供管理端工具或服务使用的。基于此更改，我们将寻求编排场景，包括故障恢复以及添加有用的事件定义和额外的 traits。

此功能将来可以通过以下方式增强；

  • 启用此评估器获取上一个周期内告警定义的 delta，以便减少更新缓存的流量。这需要告警存储保存已删除的告警和告警 API 修订。

  • 采用与通知代理相同的协调过程，以提高此评估器的效率，例如减少告警定义的缓存。分区键可能是“project_id”、“event_type”或“resource_id”。为了这种协调，所有主题名称都将具有相同的“alarm.”前缀，以便评估器可以使用主题='alarm.*'来侦听所有事件告警评估的消息。这就是为什么在本规范中使用“alarm.all”的原因。

  • 更新缓存中告警定义的机制；在分配的告警定义已更新的评估器上使缓存失效等。

  • 利用优雅的管道更新机制在通知代理中过滤掉不感兴趣的事件，并反映最终用户配置的告警定义。

在创建事件对象中的通用字段之后，我们可以重构检索项目 ID 的函数，这需要 DB 和 API 更改。

依赖项

无

测试

此更改需要新的单元/场景测试。

文档影响

  • OpenStack 手册中的管理员指南和安装指南应更新，以描述新的告警类型和规则以及所有部署者影响。

  • 将在开发人员文档中描述建议的评估器。

参考资料