理解可观测性中的高基数（High Cardinality）问题

基数（Cardinality）指某个标签下不同取值的数量，高基数问题是指标签取值过多（如 user_id、request_id）导致时序数据库索引膨胀、查询变慢甚至崩溃的现象——它是指标系统设计中最容易被低估的陷阱：一个 user_id 标签就能让百万用户的系统产生百万条时间线，把 Prometheus 类系统直接打垮。

核心要点速览

• 基数 = 标签取值数；维度 = 标签个数。时间线总数 ≈ 各标签基数的乘积；
• 时序数据库为每个唯一标签组合建索引，高基数组合会让内存与索引爆炸；
• 高基数数据（user_id、session_id、URL 全路径）应放日志/链路，而不是指标标签；
• 排障需要高基数细节，存储需要低基数聚合——两者靠「指标聚合 + 日志明细」分层解决。

什么是基数（Cardinality）？

在可观测性语境中，基数指一个标签字段有多少个不同的取值：

• status_code：低基数（约几十个取值）；
• http_method：低基数（7-9 个）；
• user_id：高基数（百万级）；
• request_id / session_id：极高基数（接近无限）。

什么是维度（Dimensionality）？

维度是标签的个数。一条带 5 个标签的指标是 5 维数据。高维度本身是好事——它意味着你可以从更多角度切片分析。

基数与维度如何共同制造问题？

关键在于时间线的计算方式：时间线总数 = 各标签基数的乘积。

假设指标 http_requests_total 带三个标签：method（7）× status_code（30）× service（20）= 4200 条时间线，完全可控。一旦有人加上 user_id（100 万用户），时间线瞬间变成 42 亿条——时序数据库为每条时间线维护索引与状态，内存和磁盘都会被撑爆。

这就是为什么 Prometheus 官方文档明确警告：不要把高基数字段放进指标标签。

为什么高基数在时序指标里行不通？

时序数据库的设计假设是「时间线数量有限且长期稳定」，每条时间线的元数据会被缓存在内存索引中以支撑毫秒级查询。高基数破坏了这个假设：索引膨胀 → 内存耗尽 → 查询超时 → 写入拒绝。

但排障恰恰需要高基数：「哪个用户、哪个实例、哪个版本出错了」——这类问题的答案天然是高基数的。

高基数数据的正确归宿：日志与列式存储

业界的解法是信号分层：

• 指标（低基数聚合）：service、status_code 级别的聚合数据，用于告警与趋势；
• 日志/链路（高基数明细）：完整记录每个请求的全部字段，存储在列式数据库中，按需检索。

列式存储（ClickHouse 类）不按「时间线」组织数据，高基数字段只是普通列，检索时按列过滤即可——这就是「结构化日志 + 列式存储」成为排障主力组合的原因。

观测云落地：基数治理实践

1. 指标侧：DataKit 与 Pipeline 支持在采集/处理阶段丢弃或改写高基数标签（如把 URL 中的动态路径归一化为 /api/user/{id}），防止基数爆炸；
2. 日志侧：观测云日志基于高性能列式存储，user_id、trace_id、request_id 任意检索，不受基数限制；
3. 链路侧：Span 属性天然支持高基数，链路详情按 trace_id 精确检索；
4. 监控侧：监控器对指标做聚合告警，发现异常后下钻日志查看器按高基数字段定位具体用户/请求。

常见问题（FAQ）

Q：怎么判断一个标签会不会造成高基数？ 估算取值数量级：几十到几百是安全的（如状态码、机房）；上万就要警惕；百万级以上（user_id、订单号、完整 URL）绝对不要放进指标标签。

Q：已经有人把 user_id 写进指标标签了怎么办？ 短期在采集侧用规则丢弃该标签止血；长期改造代码，把用户维度移到日志与链路中，指标只保留聚合维度。

Q：Prometheus 的 recording rules 能缓解高基数吗？ 能把高基数原始指标预聚合成低基数派生指标，但原始数据写入的内存压力依然存在，治标不治本，采集侧控制才是根本。

Q：观测云的指标对标签基数有限制吗？ 观测云对指标标签有合理的基数保护机制；建议在设计埋点时遵循「指标低基数、日志高基数」的分层原则，既控成本又保留排障细节。

系列阅读

• 上一篇：《分布式追踪详解》
• 下一篇：《Jaeger 分布式追踪实战》
• 相关：《日志、指标、链路的区别与联系》 · 《返回索引》