何为 Prometheus 高基数？为何有时会有高基数峰值？
💡 导读：本文算是一个科普帖，原始作者：Mary Sitzenstatter, Stefan Kupstaitis-Dunkler，原文地址：https://grafana.com/blog/2022/02/15/what-are-cardinality-spikes-and-why-do-they-matter/ 本文不会逐字翻译，仅供参考。
在 Prometheus 生态里，“高基数” 是一个经常（如果你是一个监控重度用户或监控系统维护人员的话）听到的词，本文将探讨高基数的概念，分析其产生的原因，算是一个科普文章。
什么是基数？
基数的基本定义是给定集合中的元素数量。 在 Prometheus 和可观测性领域， 标签基数非常重要，因为它会影响监控系统的性能和资源使用。
简单来说：基数是一个标签的值总数。在上面的示例中，标签 status_code 的基数为 5， environment 的基数为 2，指标 server_responses 的总体基数就为 10。
一般来讲，基数如果是个位数，就认为是低基数，如果是几十个，就认为是标准基数，如果是上万个，就认为是高基数。当您具有高基数时，您和您的团队可能会开始面临可观测性系统的挑战，例如高资源使用率。
请记住，基数对应于指标系列的数量。因此，在这篇博文中，序列数、基数，基本可以看做是一个东西。
是什么导致基数峰值？
我们的客户经常提到基数突然峰值，即具有中等或较低基数的指标突然转换为具有高基数的指标。这种变化会对可观测性系统的性能和成本产生重大影响。
上图显示了基数突然飙升的样子。看到图表左侧的线是如何向下倾斜的吗？有人可能更改了一些 relabel 规则以删除不相关的标签。但随后您会注意到活跃的系列急剧增加。这里发生的事情是，也许有人引入了一个标签，它可以具有如此多的值，以至于序列的数量（也就是你的基数）正在迅速增加。这意味着该团队生成的监控数据比以前多得多，或者可能是偶然的，太多了。
那么这是什么时候发生的呢？检测代码并添加新指标时，有时会附加比您需要的更多的上下文。例如，如果您使用标签“user_id”：
- 用户 ID 将成为该指标的标签。
- 由于 Prometheus 为每个标签组合创建一个系列，因此如果您有很多用户，则最终会为单个指标提供大量系列。
基数峰值的影响
如果你使用云上的监控、可观测性系统，这些 SaaS 产品通常是按照指标系列数量来收费的，所以高基数会导致你的账单大幅增加。如果你使用的是自托管的 Prometheus 系统，基数峰值也会导致系统性能问题、更高的资源占用、更高的维护成本。
如何解决高基数需求
OK，我们知道高基数在 Prometheus 体系里很难搞了，但是技术是为业务服务的，如果我们从业务角度来考虑，就是有存储高基数的需求，那咋搞？
此时，建议尝试更换存储，不要使用 Prometheus、VictoriaMetrics、Thanos 这类 TSDB，而是换用 ClickHouse 这类 OLAP 的库，这些 AP 的库就是为高基数而生的。
最后
通常，只是监控操作系统、网络设备、各类中间件、数据库，不太会遇到高基数问题，如果你们要自埋点，采集业务指标，就要相当小心了，提前了解高基数这个概念，避免届时出问题。
