存在度指标弃用¶

https://blueprints.launchpad.net/ceilometer/+spec/deprecate-existence-meters

问题描述¶

随着 Ceilometer 扩展以捕获来自 OpenStack 消息生态系统中更多的通知，它生成的样本数量也随之快速增长，因为许多样本源自单个通知或轮询请求。

我们存储在样本数据库中的“xyz 的存在”指标占据了我们存储数据的很大一部分。然而，这些指标本身不提供有用的测量值，其真正价值在于捕获资源在给定时间的状态——这个值也可以在与存在度指标一起生成的指标中找到。此外，“volume=1”的值对于数据使用者来说非常令人困惑，因为 Horizon 曾经将该值用作总值，用户经常想知道为什么实例、网络、端口等总是只有 1 条记录…

随着我们转向更侧重于时间序列的样本存储，我们收集的“volume=1”指标不仅影响存储大小，还增加了对如此琐碎和无意义的常数 1 进行汇总和计算统计数据的开销。此外，样本的汇总将降低这些指标作为有效审计数据的价值。

从高层来看，样本是事件的子集。样本是事件的派生子集。因此，我们创建的样本应该捕获事件中感兴趣的明确数据点，而不仅仅是事件的影子。

提议的变更¶

“xyz 的存在”和“volume=1”指标可以更好地表示为它们实际的含义：事件。核心事件功能在之前的周期中已经实现，应该扩展以更好地涵盖这些非测量指标。

这将提供更好的事件数据查询，减少总体数据存储，并减少对样本中 volume 属性含义的困惑。

建议的解决方案是

1. Mark 'volume=1' meters as available as Events in the documentation and
   add them to the event_definitions file. The vast majority of them are
   created from notifications so no work needs to be done aside from adding
   them to event_defintion. **COMPLETED IN KILO**
2. Change default pipeline to not enable these meters. NOTE: this does not
   affect existing solutions nor will it break anything. An option was added
   in Kilo to enable/disable meters. **COMPLETED IN KILO**
3. Some meters such as network related meters (LBaaS, VPNaaS, SDN,
   etc...) come from pollsters. We will need to convert these pollsters to
   republish information as events.  An example would be health check polls
   made for network meters[5]. Instead of creating a sample, it would create
   an event.
4. Henceforth, Samples will be measurements which can be aggregated and
   rolled up in meaningful ways (within gnocchi). Events will be the raw
   base that Samples come from and they should be stored accordingly. Both
   are time series driven data.

可以找到一个要删除的指标的大致列表，请参阅对应的 bug[1]。

替代方案¶

无。我们可以将步骤 3 作为可选步骤，因为它们本质上是健康检查或存在事件。我们还可以支持一个工具，将“非指标”指标迁移到事件，但这可能并不重要。

数据模型影响¶

无。事件已经存在。这可能对在事件上添加告警以保持功能对等性产生副作用。

REST API 影响¶

无。我们可能希望扩展事件，但这里没有任何东西会受到直接影响。

安全影响¶

审计数据。这已经存在的问题，将从样本迁移到事件。应该能够将一个标签添加到 event_definition 文件中，以将数据标记为审计数据。从技术上讲，可以使用事件管道[4]将审计数据重定向到单独的数据库。

Pipeline 影响¶

无。

其他最终用户影响¶

用户仍然可以选择保留这些指标，但我们应该建议他们使用事件。从 Liberty 开始，这些指标将默认禁用，并在 M* 中完全删除。这已经在文档中记录了。

性能/可扩展性影响¶

更少的样本数据。事件中更少的等效数据（由于 trait 过滤）。事件在设计上更具可扩展性（可能不是 SQL 后端）。

其他部署影响¶

我们应该默认启用 store_events 选项。这可能需要部署者使用 event_connection 选项，因为将样本和事件数据一起存储可能不是明智之举，但他们可以这样做。

开发者影响¶

学习事件。改进事件。

实现¶

负责人¶

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

工作项¶

将 pollster 添加到事件功能
默认启用 store_events

未来生命周期¶

向事件添加告警。[3]

依赖项¶

无。

测试¶

无。

文档影响¶

将测量中的指标标记为事件可用，并添加指向事件的链接。

参考资料¶

[1] https://bugs.launchpad.net/ceilometer/+bug/1384874 [3] https://blueprints.launchpad.net/ceilometer/+spec/notifications-triggers [4] https://bugs.launchpad.net/ceilometer/+bug/1376915 [5] https://github.com/openstack/ceilometer/blob/master/ceilometer/network/services/fwaas.py

存在计量弃用