标签基数为什么会拖垮 Prometheus

Prometheus 最怕的不是单条指标多，而是标签组合过多。因为每一组标签值都会形成一条独立时间序列，标签一失控，内存、磁盘、查询和告警链路都会一起变重。

先说结论

• 高基数问题的本质是时间序列数量爆炸
• 用户 ID、订单号、URL 全路径、Trace ID 这类字段，通常不适合直接做标签
• 指标设计要先考虑聚合维度，再考虑排障便利，不能反过来

为什么会拖垮 Prometheus

每组标签都是一条新序列

一个指标如果有 method、status、instance 三个低基数标签，通常还能接受；但如果再加上 user_id 或完整 URL，序列数会迅速膨胀。

写入和查询成本都会上升

序列越多，抓取、压缩、索引、查询都更重。线上表现往往是 Prometheus 内存上涨、抓取变慢、查询超时、Grafana 面板卡顿。

告警也会被放大

如果告警规则基于高基数标签展开，同一类问题可能瞬间炸出成百上千条告警，值班同学根本处理不过来。

实战里怎么治理

先禁掉明显危险的标签

动态 ID、随机值、完整异常信息、完整 SQL、完整路径参数，这类内容优先排查。它们最容易造成基数失控。

再做标签规范

团队最好明确哪些标签可以上报，哪些只能写日志不能写指标。比如实例、机房、接口模板通常可以保留，用户和订单维度应更多依赖日志或 Trace。

最后建立预算和巡检

高基数问题不能靠出事后再查。应该定期巡检 top N 指标、序列数增长最快的 job、最重的查询语句，把治理做成常规动作。

常见误区

为了排障方便，把能想到的信息都打成标签

指标的职责是聚合观察，不是替代日志。

只关注单个指标值，不关注序列数量

很多系统看起来 QPS 不高，但 Prometheus 已经被数百万序列压得很吃力。

出现高基数后只想着扩容

扩容只能缓一阵，标签设计不收敛，问题还会回来。

一句话总结

Prometheus 拖垮的根因通常不是“采集太多”，而是“标签太散”。指标负责聚合，日志和 Trace 负责细节，这条边界一定要守住。