监控中如何处理“高基数标签”（High Cardinality）问题？

“高基数（High Cardinality）”是 Prometheus 内存被撑爆的最常见元凶之一，也是监控方案设计时必须正视的问题。

问题是怎么来的

像 user_id、email、request_id 这类字段，它们的取值可能有成千上万甚至更多。如果你把它们当作指标的 Label，Prometheus 会为每一种取值组合创建一条独立的时间序列。

例如 http_requests_total{user_id="123"}、{user_id="124"}……取值越多，时间序列呈乘积级爆炸，内存和磁盘瞬间被耗尽，查询也变得极慢。

最佳实践

对于这类动态、高离散度的数据：

• 不要作为指标 Label；
• 应该作为日志内容来处理（用 Loki / ELK 去做检索），而不是塞进时序数据库。

简单说：Label 放“有限枚举”的维度（如 namespace、pod、method），日志放“无限离散”的具体值（如 user_id）。

小结

高基数的本质是“用错了存储模型”。把动态值从 Label 移到日志，Prometheus 的内存焦虑就解了一半。