获课：shanxueit.com/12015/

踩坑总结：Prometheus 高基数指标问题个人优化方案

说起 Prometheus 的高基数问题，我的第一反应不是技术方案，而是“疼”。那种监控面板突然卡死、查询转圈半分钟、告警延迟到业务方先找上门的无力感，我经历过不止一次。这篇总结不讲大道理，只讲我踩过的坑和想明白的事。

第一次出事：我以为是机器挂了

那是个平常的周二上午，Grafana 突然大面积出图失败，刷新后直接超时。我第一反应是 Prometheus 进程 OOM 了，登上去一看，内存涨到了平时的 4 倍，tsdb 的 head 块膨胀得离谱。查了半小时才定位到根因：两周前上线了一个接口耗时监控，其中 path 标签取了完整的 URL 路径，而那个接口的路径包含随机生成的订单号。两周时间，时间序列从几十万暴涨到几千万。

那一刻我才真正理解什么叫“标签爆炸”。不是机器不够，是设计监控的人没想清楚标签的基数边界。

我总结的三条红线

经过这次事故，我给自己立了几条规矩，后来每次加指标都先过一遍这个清单：

第一条：标签值必须可枚举。 path 用 /order/123 就是找死，用 /order/:id 才是正解。如果业务方说“我们需要看具体订单的监控”，那就把详细日志留给 ELK，Prometheus 只负责聚合层面的观测。

第二条：复合标签要慎重。 method 和 status_code 单独看都没问题，但 method+status_code+path 组合起来基数就可能失控。每增加一个标签维度，序列数是指数级增长的，这不是加法，是乘法。

第三条：时间维度不是挡箭牌。 很多人说“高基数没关系，反正只保留 7 天”。但 Prometheus 的内存占用和 WAL 写入压力是实时的，和历史数据量关系不大，该爆的时候七天保留也救不了。

我的实战优化思路

出事之后，我分三步做了系统性整改，没有动代码，全是配置和流程层面的调整：

第一步是削减存量。 我用了 Prometheus 自带的 prometheus_tsdb_head_series 指标配合 topk 查询，把 series 数量排名前十的指标逐个拉出来审。发现有两个业务指标完全是为了“万一需要”加的，实际没人看，直接下线。另有一个指标的 cluster 标签永远只有一个值，属于无效维度，果断去掉。这一步砍掉了大约 40% 的序列数。

第二步是限制增量。 我在 Recording Rules 里做了聚合预计算，把高基数的原始指标收敛为低基数的汇总指标。比如原来按 user_id 维度监控的活跃连接数，改成按 机房 和 服务 维度聚合后提供给大盘使用，原始指标只保留给单用户问题排查场景，且通过降低采集频率来缓解压力。

第三步是建立护栏。 我加了两个告警规则：一个是 prometheus_tsdb_head_series 超过阈值就告警，另一个是采集侧新增指标时必须在 MR 描述里标注预估的标签基数上限。技术问题最终还是要落到流程上，不然迟早重蹈覆辙。

最深的体会

这套方案谈不上多高明，但确实让我的 Prometheus 集群安稳了大半年。回头想，高基数问题本质上是可观测性建设里“贪婪”的代价——我们总想采集更多维度、保留更多细节，却忽略了监控系统的生理极限。

优化 Prometheus，说到底是在业务洞察力和资源成本之间找平衡。 这个平衡没有标准答案，只能靠一次次踩坑来校准。如果你现在正被高基数困扰，别急着加内存、加节点，先冷静下来，把你所有的指标和标签列在纸上，问自己一句：这些维度，我真的都需要吗？

很多时候，少即是多。