Prometheus 中的高基数标签有多危险？

Posted 2023-02-15

【中文标题】Prometheus 中的高基数标签有多危险？

【英文标题】：How dangerous are high-cardinality labels in Prometheus?

【发布时间】：2018-03-04 13:09:22

【问题描述】：

我正在考虑将一些指标导出到 Prometheus，但我对我打算做什么感到紧张。

我的系统包含一个工作流引擎，我想跟踪工作流中每个步骤的一些指标。这似乎是合理的，有一个称为wfengine_step_duration_seconds 的度量指标。我的问题是我的所有工作流程都有数千个步骤。

根据文档here，我不应该以编程方式生成名称的任何部分。因此，这就排除了使用诸如 wfengine_step1_duration_seconds 和 wfengine_step2_duration_seconds 之类的名称，因为步骤名称是程序化的（它们会不时更改）。

解决方案是步骤名称的标签。不过，这也带来了一个问题，因为文档here 和here 非常强烈地警告不要使用具有高基数的标签。具体来说，他们建议将“指标的基数保持在 10 以下”，对于超过 100 的基数，“研究替代解决方案，例如减少维度数量或将分析从监控中移开”。

我正在查看数以千计（1,000 到 10,000）的标签值。鉴于指标的数量不会非常大，这是对 Prometheus 的适当使用，还是我应该将自己限制为更通用的指标，例如单个聚合步骤持续时间而不是每个步骤的单独持续时间？

【参考方案1】：

最大指标保持在 100 基数以下的准则假定您有 1000 个服务副本，因为这是一个相当安全的上限。如果您知道使用此代码的每个人都将始终拥有较少数量的副本，那么就可以在检测中拥有更高的基数。

话虽如此，成千上万的标签仍然需要小心。如果已经是几万了，还要多久才能达到几十万？考虑到基数，从长远来看，您可能必须将此数据移动到日志中，因此您可能希望现在就这样做。

【讨论】：

如果不区分这些带有标签的副本，那么有多少副本有什么区别？

那么 Prometheus 不适合监控超过 100 台（或 10 台）机器吗？

单个 Prometheus 可以监控数千到数万台机器，具体取决于设置。

我不确定你的意思。考虑到什么数字？

@Mark 我认为建议是指标的基数不应超过 10,000 或 100,000，包括 instance 标签（您假设的 hostname 标签），但我有一个强烈的印象，没有人完全确定什么是安全的或从未测量过它

【参考方案2】：

高基数标签（例如具有大量唯一值的标签）本身并不危险。危险在于active time series的总数。 根据https://www.robustperception.io/why-does-prometheus-use-so-much-ram，单个 Prometheus 实例在内存大于 100GB 的主机上运行时可以处理多达千万个活动时间序列。

举个例子：假设导出的指标有一个 step_id 标签，其中包含 10K 个唯一值。

如果指标没有其他标签（例如，如果它导出为wfengine_duration_secondsstep_id="...），那么它将生成 10K 活动时间序列（Prometheus 的小值）。

如果指标包含另一个标签，例如具有 100 个唯一值的 workflow_id，并且每个工作流有 10K 个唯一步骤，则导出的时间序列总数会飙升至 100*10K=1M。对于 Prometheus 来说，这仍然是非常少的活动时间序列。

现在假设导出指标的应用在 50 个主机（或 Kubernetes pod）上运行。 Prometheus 将抓取目标地址存储在 instance 标签中 - 请参阅 these docs。这意味着从 50 个主机收集的活动时间序列总数跳转到50*1M=50M。这个数字对于单个 Prometheus 实例来说可能太大了。还有其他系统，which can handle such amount of active time series in a single-node setup，但它们也有上限。它只是 N 的两倍 (1 < N < 10)。

所以经验法则是考虑活动时间序列的数量，而不是每个标签的唯一值数量。