Ceilometer-批量消费

Launchpad 条目: bulk-message-handling
创建时间: 2014年1月9日
贡献者: John Herndon <john.herndon@hp.com>

总结

目前，Ceilometer 一次处理一个通知。单个事件被插入到存储后端，单个通知被处理为计量数据，等等。在许多情况下，批量处理通知会更有效率。本蓝图提出了一种实现方法。

发布说明

原理

用户故事

前提条件

此功能将是可配置的。如果操作员不想使用批量处理，则可以将其关闭。
依赖于 https://review.openstack.org/#/c/57457/

设计

目标是创建所有消息收集管道都能够使用批量处理（如果需要）。初始实现将专注于通知收集。

这张（粗略的）图示说明了消息在批量配置下通过 Ceilometer 的流程。

建议的数据流

oslo.messaging 将调用 process_notificaions，传入单个通知
如果配置了批量处理，则通知将被传递到通知批次。Message Batch 类将管理通知，并确定批次是否已满足以传递。 “已满足以”将基于批处理消息的数量，或提供的超时时间。将提供超时时间，以防止消息无限期地停留在批次中。
创建批次时，将为其分配一个“处理程序”。处理程序将控制如何处理该批次。对于通知，该批次必须传递给事件存储驱动程序和计量管道。我建议更改处理通知的顺序（当前实现先将通知传递给计量管道，然后再将其处理为事件。这是为了防止计量管道中发生重复。如果 Ceilometer 收集器发生错误导致一批消息被重新排队，则重复是一个问题。当消息被重新排队时，收集器将在下一次运行中再次处理它们（或在故障转移时，新的收集器将处理这些通知）。重复对于计量管道来说是不可接受的，因为它们会扭曲数字，并且基本上无法检测到。对于事件收集，可以检测到重复，因为通知的 message_id 将被存储。如果事件解析器在计量之后处理通知，并且事件遇到导致通知被重新排队的问题，则计量管道将第二次处理该通知。但是，如果先进行事件处理，则计量管道将不受影响，因为它尚未处理这些通知。
批量通知处理程序会将批次传递到事件处理代码，该代码将每个通知解析为事件。如果无法解析通知（例如，无效的 json 有效负载），它将由一段新代码（称为 message_recovery，将在单独的 bp 中定义，可能）处理，该代码会将原始通知存储在某个位置，直到人工查看并可能更正生成无效通知的内容。请注意，此消息不会被重新排队，因为这样做会导致其无限次地被重新处理。此通知不会传递给计量管道，因为它无效。
将批处理的事件发送到存储驱动程序。此时，如果存储驱动程序不可访问，则将中止批处理，重新排队事件，并且收集器将停止从消息队列轮询事件，直到可以恢复到后端的连接。一旦连接恢复，就可以恢复收集。
返回失败的消息。对于单个拒绝的事件（例如，由于无效的数据类型），将再次使用 message_recovery 接口，如上所述。但是，此通知将传递给计量管道（也许计量可以处理它？）。
批量通知（没有来自步骤 4 的错误）由计量管道处理。

实现

UI 变更

无

代码变更

主要的代码更改将发生在 notification.py 类中。将添加 Batch 类，并定义 BatchHandler 接口。禁用批量处理将作为直接调用批处理处理程序并传入单个通知来处理。

迁移

无

测试/演示计划

这不必在规范接近 Beta 之前添加或完成。

未解决的问题

这应该突出显示需要在进一步的规范中解决的任何问题，而不是规范本身的问题；因为任何存在问题的规范都无法获得批准。

BoF 议程和讨论

使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。