高度分布式协调通知¶

https://blueprints.launchpad.net/ceilometer/+spec/disributed-coordinated-notifications

在 Kilo 版本中，添加了对协调通知代理的支持。这使得用户可以部署多个通知代理，并确保管道内的相关消息被引导到同一个代理，以便进行正确的聚合计算。

问题描述¶

在最初的实现中，与管道相关的所有数据都被引导到一个管道的单个队列中。虽然这确保了所有相应的数据被发送到相同的位置，但它去除了横向扩展的能力，因为管道队列只能有一个消费者监听它。这意味着虽然可以使用多个代理/处理程序从主 OpenStack 队列中提取数据，但一旦数据到达管道处理阶段，它就被限制为单个工作进程。

即使在管道级别，数据也可以并行处理。例如，如果没有转换器，数据点不需要按顺序处理。此外，当存在转换器时，不同资源的数据点彼此无关，可以并行处理。

提议的变更¶

为了并行化和扩展处理能力，我们将创建每个管道的多个副本。当一个数据点到达时，我们将根据哈希分组键对每个数据点进行分组。每个转换器都将分配一个分组键，以记录任何依赖性要求（例如，处理资源 ID 的转换器）。在设置管道时，管道中所有转换器的键将被组合起来，以确保相关的数据点将一致地发送到同一个管道进行处理。

基本工作流程如下

* on notification agent startup, create a listener for main queue
* for each pipeline definition, we create x queues and x listeners where x
  corresponds to the number of notification agents registered to group
* when a datapoint is received, agent builds sample.
* after sample is built, we hash fields defined by transformer requirements
  and mod by number of agents.
* using mod value we push datapoint to corresponding pipeline queue.
* same processing steps here on out (listener grabs data -> pipeline -> pub)

此解决方案无法处理管道中的多个分组键。为了正确处理管道中的多个分组键，我们需要在每次转换后重新排队。逻辑将是：主队列 -> 构建样本 -> pipe1.transform1 队列 -> pipe1.transform2 队列 -> 等 -> 发布。

研究现有的转换器

* Accumulator - this does not really have any grouping requirements, it just
                batches samples.
* Arithmetic - this is grouped by resource_id
* RateOfChange - this is grouped by name+resource_id. but it can more
                 be more generally grouped by just resource_id
* Aggregator - this is grouped by name+resource_id+<custom> but can also be
               more generally grouped by just resource_id

基于以上，似乎 resource_id 始终是一个有效的通用分组键，并且转换器可以执行更细粒度的分组。因此，似乎可以安全地假设我们不需要支持多个分组键（目前）。

替代方案¶

一个简单的修复方法是检测管道是否具有转换器。如果没有，它可以被任意数量的消费者消费，因此我们可以将多个监听器分配给这些队列。这无助于分配具有转换器的管道的负载，但允许跨资源进行转换。
我们实现一个共享内存/存储机制，以便任何工作进程都可以发现历史上下文。这很困难。我觉得我最终会重新创建 Storm/Spark
魔法

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

无

Pipeline 影响¶

从用户角度来看，没有任何变化。在内部，我们将拥有更多的管道队列。

其他最终用户影响¶

没有。除非我们决定添加定义管道队列副本数量的选项。

性能/可扩展性影响¶

积极的。它将在协调模式下分配管道处理。消息队列始终如一地与数千个队列一起使用，因此创建管道队列的副本（相对较小的集合）不应该成为问题。

其他部署影响¶

无

开发者影响¶

无

实现¶

负责人¶

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

工作项¶

为每个转换器添加分组键以定义数据点分组 * 将只是 resource_id
添加支持从上述分组键构建管道哈希
添加功能以创建每个代理的管道队列和分发逻辑。

未来生命周期¶

支持管道中的不同分组键。

依赖项¶

无

测试¶

测试已经存在。只需要验证我们是否创建了适当数量的副本。

文档影响¶

没有。也许是开发文档。

参考资料¶

https://docs.google.com/presentation/d/1QgjDOLRnKDboqP8P1LvV0kR5aQEv_VJsDtMlh6u7tIY/edit?usp=sharing

高度分布式协调通知