💡 导读：本文算是一个科普帖，原始作者：Mary Sitzenstatter, Stefan Kupstaitis-Dunkler，原文地址：https://grafana.com/blog/2022/02/15/what-are-cardinality-spikes-and-why-do-they-matter/ 本文不会逐字翻译，仅供参考。
在 Prometheus 生态里，“高基数” 是监控重度用户和监控系统维护人员经常听到的概念。它表面上是标签值数量的问题，本质上会影响指标序列数量、监控系统资源消耗，以及云上可观测性产品的费用。
核心摘要
- 在 Prometheus 语境中，基数通常可以理解为指标序列数量；标签值组合越多，序列越多。
- 高基数常见于把
user_id、订单号、请求 ID 这类高变化字段放进指标标签。 - 基数峰值是原本低基数或中等基数的指标，突然因为标签变化生成大量新序列。
- 高基数会带来更高的存储、查询、计算和维护成本；使用云上可观测性产品时，也可能直接推高账单。
- 如果业务确实需要分析高基数数据，可以考虑使用 ClickHouse 这类 OLAP 存储，而不是把所有高基数字段都塞进 Prometheus 体系。
什么是基数？
基数的基本定义是给定集合中的元素数量。 在 Prometheus 和可观测性领域，标签基数非常重要，因为它会影响监控系统的性能和资源使用。
简单来说，基数是一个标签的值总数。上图示例中，标签 status_code 的基数为 5，environment 的基数为 2，指标 server_responses 的总体基数就是 10。
可以把 Prometheus 的基数理解为“指标名 + 标签组合”形成的序列数量。通常来说：
- 个位数标签值，可以视为低基数；
- 几十个标签值，可以视为标准基数；
- 上万个标签值，就属于高基数。
当一个指标进入高基数状态时，团队可能开始遇到可观测性系统的性能和资源挑战。本文后面提到的“序列数”和“基数”，基本可以看作同一类问题。
什么是基数峰值？
基数峰值指的是：一个原本基数较低或中等的指标，在短时间内突然生成大量新序列，变成高基数指标。
上图展示了基数突然飙升的样子。图表左侧的线向下倾斜，可能是有人修改了 relabel 规则，删除了不相关标签；随后活跃序列急剧增加，则可能是有人引入了一个取值非常多的新标签。
这意味着该团队生成的监控数据比以前多得多。这个变化可能来自业务增长，也可能只是一次不小心的指标设计变更。
为什么会出现高基数？
高基数经常出现在业务自定义埋点阶段。开发人员为了让指标更“有上下文”，会给指标附加更多标签，但并不是所有上下文都适合放进 Prometheus 标签。
典型例子是使用 user_id 作为标签：
- 每个用户 ID 都会成为该指标的一个标签值；
- Prometheus 会为每个标签组合创建一个时间序列；
- 用户数量越多，单个指标生成的序列就越多；
- 如果再叠加接口、状态码、地区、设备类型等标签，序列数量会继续膨胀。
因此，高基数问题不是“标签越多越好”的问题，而是“哪些维度适合成为时序指标标签”的问题。
基数峰值有什么影响？
高基数会直接影响监控系统的成本和稳定性。
如果使用云上的监控或可观测性 SaaS 产品，很多产品会按照指标序列数量计费。基数峰值意味着序列数量暴涨，账单也可能随之上升。
如果使用自托管 Prometheus 系统，基数峰值也不会消失。它会表现为更高的资源占用、更慢的查询、更大的存储压力，以及更高的维护成本。对于负责监控平台的团队来说，高基数最终会变成一个容量和治理问题。
如何判断某个标签不适合放进 Prometheus？
一个简单判断方法是看标签值是否会无限增长，或者是否接近“一次请求一个值”“一个用户一个值”“一个订单一个值”。
不太适合放进 Prometheus 标签的字段包括：
user_id；- 请求 ID；
- 订单号；
- 会话 ID；
- 原始 URL 参数；
- 高变化的业务唯一标识。
更适合放进标签的字段，通常是有限枚举值，比如环境、服务名、状态码、接口类别、集群名等。
如果业务确实需要高基数分析怎么办？
Prometheus 体系不擅长承接任意高基数字段，但技术最终要服务业务。如果业务上确实需要分析高基数字段，就不应该简单地把所有高基数信息都塞进 Prometheus 标签。
更合理的方式是根据查询场景选择存储。对于高基数字段分析，可以考虑 ClickHouse 这类 OLAP 数据库。OLAP 存储更适合高维度分析和明细查询，而 Prometheus、VictoriaMetrics、Thanos 这类 TSDB 更适合稳定标签维度下的时序指标监控。
换句话说，监控指标和分析明细应该分层处理。Prometheus 用来回答“系统是否健康、趋势是否异常、是否需要告警”，ClickHouse 这类系统更适合回答“具体是哪些用户、订单、请求造成了问题”。
结论
通常，只是监控操作系统、网络设备、中间件、数据库，不太会遇到严重高基数问题。真正容易踩坑的是业务自埋点，尤其是把用户 ID、订单号、请求 ID 等高变化字段放进指标标签。
提前理解 Prometheus 高基数和基数峰值，可以帮助团队在指标设计阶段避开资源和成本问题。需要高基数分析时，也应该把这类需求交给更合适的分析型存储，而不是强行让 Prometheus 承担所有工作。
FAQ
Q1：Prometheus 高基数和序列数是什么关系？ A：在本文语境里，两者基本可以看作同一类问题。标签值组合越多，Prometheus 生成的时间序列越多，基数也越高。
Q2：为什么 user_id 不适合作为指标标签？
A：因为用户数量通常很多，而且会持续增长。Prometheus 会为每个标签组合创建序列，把 user_id 放进标签后，单个指标就可能生成大量序列。
Q3：高基数一定不能采吗？ A：不是。业务上确实可能需要高基数分析，但这类需求更适合放到 ClickHouse 这类 OLAP 存储中处理，而不是直接作为 Prometheus 标签。
