事件管道¶

https://blueprints.launchpad.net/ceilometer/+spec/notification-pipeline

问题描述¶

目前，当通知代理接收到通知时，所有通知都会被导入到一个单一的端点，使用 event_definition 进行过滤，然后推送到调度器，通常是一个数据库。缺乏灵活性来转换、扩展、触发这些事件，以及将数据发布到多个消费者。

提议的变更¶

与样本数据一样，事件也有一个管道。与样本数据一样，我们定义了源和接收器。与样本数据不同，源中没有定义时间间隔。

这将允许将不同的数据（例如，审计数据）发布到不同的存储，并允许完全忽略通知（目前，我们为所有通知捕获一个 shell 事件）。

建议的模式是

---
sources:
    - name: eventA_source # any unique name for source
      events: # list of event_types, same wildcard technique in samples
          - "*"
      sinks:
          - sink1
          - sink2
sinks:
    - name: sink1 # any unique name for sink
      transformers:
          # one or many transformers that work on an Event.
      triggers:
          # potential for triggering (short term inline actions). i'd
          # envision a trigger that built performance samples. ie time
          # between corresponding start/end events and republish as a sample
          # alternatively, that same work could send an alarm if it didn't
          # meet a certain threshold
      publishers: # we will not support rpc it isn't great for performance
          - notifier://

发布者在这里可以有所不同。我们目前直接将事件发布到数据库，绕过了收集器。在这个规范中，我们将继续提供这种方式，同时提供 notifier、udp、file 选项。收集器除了将任何同步任务从通知代理转移到收集器之外，没有明显的优势。由于我们已经为每个管道重新排队项目，这种同步瓶颈仅存在于具有同步任务的管道中，不会减慢其他管道的速度。

替代方案¶

改为发布到收集器，让它持久化数据。
将其放在与样本数据相同的 pipeline.yaml 文件中。

数据模型影响¶

无。

REST API 影响¶

目前没有，但它会影响数据库中的管道工作。

安全影响¶

与当前发布者相同的安全问题。

Pipeline 影响¶

这是一个全新的管道，所以肯定有影响：一个新的 pipeline.yaml

其他最终用户影响¶

你需要另一个 pipeline.yaml；你需要对其进行适当的配置。

性能/可扩展性影响¶

默认情况下，这不会造成任何差异。由于能够过滤掉事件，可能会减少数据量。由于转换器和多个发布者，可能会增加数据量。我们有通知代理协调，它会将管道和数据拆分到不同的代理中以处理扩展。

其他部署影响¶

添加一个用于新 pipeline.yaml 的配置选项

开发者影响¶

如果他们还不了解，请了解管道的工作原理。

实现¶

负责人¶

主要负责人: chungg
持续维护者: chungg

工作项¶

创建 event_pipeline.yaml
将当前的事件端点重定向以使用此管道
添加事件的发布者支持

未来生命周期¶

构建转换器。构建触发器。构建发布者。

依赖项¶

无。

测试¶

扩展管道测试以包含 event_pipeline

文档影响¶

重写管道说明，以包含新的 event_pipeline 及其差异

参考资料¶

https://blueprints.launchpad.net/ceilometer/+spec/notification-pipelines

事件管道