普罗米修斯的高基数标签有多危险？

Question

我正在考虑将一些指标导出到Prometheus，而我对打算做的事情感到不安。

我的系统由工作流引擎组成，我想跟踪工作流中每个步骤的一些指标。这似乎是合理的，使用的度量标准称为wfengine_step_duration_seconds。我的问题是我所有工作流程中都有成千上万个步骤。

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

然后，解决方案是步骤名称的标签。但是，这也带来了一个问题，因为此处和此处的文档强烈警告不要使用基数高的标签。具体来说，他们建议保持“指标的基数低于10”，对于基数超过100，“研究替代解决方案，例如减少维数或使分析脱离监视”。

我正在查看数量不多的标签值（1,000到10,000）。鉴于度量标准的数量不会很大，这是否适合普罗米修斯使用，还是我应该限制自己使用更通用的度量标准，例如单个汇总步骤持续时间，而不是每个步骤的单独持续时间？

Answer 1

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

示例：假设导出的指标有一个step_id包含 10K 个唯一值的标签。

如果指标没有其他标签（例如，如果导出为wfengine_duration_seconds{step_id="...}），那么它将生成 10K 活动时间序列（对于 Prometheus 来说是很小的值）。

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

现在假设导出指标的应用程序在 50 个主机（或 Kubernetes Pod）上运行。Prometheus 将抓取目标地址存储在instance标签中 - 请参阅这些文档。这意味着从 50 个主机收集的活跃时间序列总数跃升至50*1M=50M。对于单个 Prometheus 实例来说，这个数字可能太大了。还有其他系统可以在单节点设置中处理如此数量的活动时间序列，但它们也有上限。它只是N大了几倍（1 < N < 10）。

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

Answer 2

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

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