API 无管道¶

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

Ceilometer API 服务器允许通过 API 发布新的样本数据。这些数据随后通过管道进行处理，然后根据需要进行分发。这意味着 API 服务器必须使用管道代码并拥有一个 pipeline.yaml 文件，从而增加了代码的复杂性以及 API 的测试和安装配置。另一种方法是让 API 服务器发布它接收到的计量数据的通知，然后由通知代理（它本身也拥有一个管道）处理这些通知，并最终进行分发。

问题描述¶

在 API 服务器中包含转换管道会至少在三个维度上增加创建样本（API 中一个不常用的功能）的复杂性。大多数样本是通过轮询代理和通知生成的。

使用管道会在代码、测试和安装中产生可以避免的依赖关系。在代码中，我们必须包含管道模块和类。在测试和安装中，我们必须有一个 pipeline.yaml 文件。

在安装的情况下，如果有多个 API 服务器，pipeline.yaml 文件必须在安装这些服务器的主机上保持同步。这是一个不必要的负担。

提议的变更¶

解决此复杂性的一种方法是在 API 服务器中完全不使用管道。相反，当发布新的样本数据时，将其格式化为通知并推送到通知总线，由通知代理检索。该代理中的管道将执行任何预期的转换。

为了方便测试，将添加一个可选标志，可以启用将样本直接发布到存储，从而避免通知代理进程。

替代方案¶

另一种实现相同目标的方法是

一个更复杂的解决方案是在总线上创建针对特定转换服务的通知。这样的服务将只监听 Ceilometer 生成的测量通知，根据管道描述对其进行转换，然后将其进一步分发到存储或其他处理过程。这种模式将完全跳过通知代理。

优点：扩展了长期分解为更小部分的计划。缺点：增加了此更改的复杂性，增加了完成时间并增加了出错风险。

其他相关的替代方案包括

API 测试需要 pipeline.yaml 的问题可以通过使用基于代码的管道默认设置来解决，这些默认设置在没有 pipeline.yaml 文件时使用（也可以用于生成默认 pipeline.yaml 文件）。

数据模型影响¶

该提案不会影响数据的结构，但会影响数据的流。需要进行测试以了解这对数据采集及时性的影响。

REST API 影响¶

通过 API 创建的样本将在 API 和其最终存储之间采取稍微不同的路径。

将向 post-samples API 添加一个可选的布尔参数“direct”，允许用户将样本直接发布到存储并避免通知代理处理（将跳过管道），这主要用于测试。

安全影响¶

除了现有的担忧之外，没有其他。

Pipeline 影响¶

之前发生在 api 服务器中的管道转换将在通知代理中发生。

其他最终用户影响¶

无。

性能/可扩展性影响¶

这可能会在样本发布到 API 和到达数据存储之间引入一些延迟。

其他部署影响¶

API 服务器的部署者不再需要在 API 服务器旁边部署 pipeline.yaml 文件。

并且部署者需要在 ceilometer.conf 中配置“notification_driver”，如果需要通过通知代理发布样本，例如

notification_driver = messaging

开发者影响¶

此更改可能会增加某些测试中的异步性。例如，发布样本和检索该样本之间的时间可能会变得更加不可预测。由于它已经不可预测，任何依赖于立即检索的测试本身就是不好的，因此我们应该修复它。

实现¶

负责人¶

主要负责人: liusheng
其他贡献者: chdent
持续维护者: liusheng, chdent

工作项¶

确保存在对通过管道转换的计量数据发布进行可靠测试。
用通知程序替换 API 代码中的基于管道的发布。
更新 API 测试以处理不再存在的模拟管道等问题。
API 选项，用于直接写入存储

未来生命周期¶

Telemetry 程序的成员将对该功能进行任何必要的持续维护。

依赖项¶

没有新的依赖项。

测试¶

除了 API 的现有单元测试外，还可以使用声明式 http 测试来确认发布的样本是否继续具有预期的转换。

文档影响¶

部署文档可能需要进行一些小的更新，以指示 API 服务器的配置文件要求的变化。

参考资料¶

无

API 无管道