高标签基数但低度量/标签计数和不频繁采样是 Prometheus 可接受的用例吗？

Question

我有一个监控用例，但我不完全确定它是否好用 是否匹配普罗米修斯，我想在我深入之前征求意见 更深。

我要存储的数量：

只有 1 个指标。 该指标有 1 个标签，其中包含 1,000,000 到 2,000,000 个不同的值。 这些值是量规（但如果它们是计数器会有所不同吗？） 采样率为每 5 分钟一次。将数据保留 180 天。

如果我有 100 万个不同的标签值，估计存储大小：

（根据 Prometheus 文档中的公式：retention_time_seconds * ingested_samples_per_second * bytes_per_sample)

(24*60)/5=288 5-minute intervals in a day.

(180*288)           * (1,000,000)       * 2 = 103,680,000,000 ~= 100GB
samples/label-value   label-value-count   bytes/sample

所以我假设需要 100-200GB。

1. 这个估计正确吗？

2. 我在多个地方读到过关于避免使用高基数标签的文章，我会 想问这个。 考虑到我一次只查看一个时间序列 高基数标签有问题吗？或者 有大量的时间序列？由于每个标签值都会产生另一个 时间序列？我还在普罗米修斯可以处理的多个地方阅读 一次有数百万个时间序列，所以即使我有 1 个标签和 100 万个 不同的值，在时间序列计数方面我应该没问题，我必须 在这种情况下担心标签具有高基数？我知道 这取决于服务器的强度，但假设平均容量，我 想知道 Prometheus 的实现是否有问题处理这个 有效的案例。

3. 而且，如果这是时间序列计数的问题，我的假设是否正确 它不会对以下内容产生重大影响 选项？

   1. 1 个指标，1 个标签，包含 1,000,000 个不同的标签值。
   2. 10 个指标，每个指标有 1 个标签，包含 100,000 个不同的标签值。
   3. X 指标，每个指标都有 Y 个不同标签值的 1 个标签。 其中 X * Y = 1,000,000

感谢您的帮助！

Answer 1

这可能有效，但这不是 Prometheus 的设计目标，您可能会遇到问题。你可能想要一个数据库而不是一个监控系统，这里可能是 Cassandra。

基数在指标之间的拆分方式不会影响摄取性能，但是在查询中读取 1M 系列会相对较慢。

Answer 2

请注意，Victoria Metrics 是一个易于配置的 Prometheus 后端，可显着降低存储需求。