Pollsters No Transform¶
https://blueprints.launchpad.net/ceilometer/+spec/pollsters-no-transform
Ceilometer 轮询代理目前执行两个角色：它们轮询各种服务以生成样本，并可选地使用 pipeline.yaml 中定义的流水线来转换这些样本，从而组合其他样本并最终将其发布为度量。 后者转换功能增加了 pollster 代码的复杂性。 一种替代方案是让 pollsters 为其创建的计量器发送通知，并由通知代理（拥有自己的转换流水线）处理这些通知，然后发布。
问题描述¶
在 pollsters 中包含转换流水线会增加 pollsters 的复杂性，并复制了通知代理中已有的功能。
提议的变更¶
解决此复杂性的一种方法是不在 pollsters 中进行转换。 相反，当轮询到新样本时，将其格式化为通知并推送到通知总线，由通知代理检索。 该代理中的流水线将执行任何必要的转换。
除了明确轮询代理的重点之外，这种改变很可能会使代码和部署中的测试和性能改进更容易实现。 这是一种模糊的推测，但没有实际操作就很难验证这个理论。
我们还有机会审查和审计轮询代码，这是一种定期执行的有用操作。
替代方案¶
主要的替代方案是保持现状。 显然，如果我们这样做，我们将失去上述好处。
数据模型影响¶
该提案不会影响数据的结构，但会影响数据的流向。 需要进行测试，以了解这对数据采集及时性的影响。
REST API 影响¶
对 API 呈现的资源没有直接影响。
安全影响¶
除了现有问题之外，没有其他问题。
Pipeline 影响¶
描述流水线影响有些复杂，因为“流水线”一词可以用来
描述收集和转换一系列样本的整体过程
标识
pipeline.yaml文件中source与sink的配对指向文件
pipeline.yaml，该文件配置了收集、转换和发布样本的许多方面，以及转换和发布从通知生成的样本。
在此更改中，转换和发布将本地化在通知代理中。 轮询代理将完成样本的收集和生成，API 服务器（通过发布计量器）和通知代理也将参与。
为了方便迁移，轮询代理将继续使用 pipeline.yaml 文件来配置它们将轮询的源以及轮询的间隔。 可以使用相同的文件，也可以使用不包含任何 sink 的新文件。 想法是两者都应该有效。
最显著的区别是，现有的确认 source 和 sink 之间存在配对的验证将被删除。 轮询代理可以轮询任何它们想要的东西。 如果通知代理不想要生成的样本，它可以简单地将其丢弃。 这提供了两个好处
它使轮询侧的流水线更简单
它将权限集中在通知代理中
其他最终用户影响¶
无。
性能/可扩展性影响¶
希望这能减少 pollsters 的占用空间，使其更容易部署许多 pollsters，从而提高轮询系统的整体性能。
另一方面，这可能会增加消息传递和通知代理的负载，但可以通过以下方式进行补偿
让 pollsters 在自己的主题甚至总线上发布它们的通知。
部署更多的通知代理（以水平方式）。
其他部署影响¶
部署者需要了解他们部署足够数量的通知代理的选项。
开发者影响¶
从样本创建点到存储点的样本转换测试将变得更加复杂，因为它将遍历多个服务。 随着树内功能测试的出现，这是一个可以并且应该进行测试的地方。 尽管最初设置起来很痛苦，但拥有这些测试在长期来看将非常有帮助。
实现¶
负责人¶
- 主要负责人
chdent
- 其他贡献者
你和你的所有朋友
- 持续维护者
chdent
工作项¶
确保轮询和通知代理都有强大的测试。
用更简单的读取 pipeline.yaml 中源描述来替换 pollster 代码中的源和 sink 处理（留下未来使用不同文件的选项）。 创建的样本将被重新发布为通知。
更新文档以反映新的架构。
未来生命周期¶
Telemetry 程序的成员将对该功能的任何必要的持续维护负责。
依赖项¶
没有新的依赖项。
测试¶
如上所述进行测试。
文档影响¶
部署文档需要更新，以反映轮询和通知代理之间的连接、使用自定义消息总线的选项以及其他定制机会。
参考资料¶
目前没有。
