高基数通常来自把用户 ID、请求 ID、完整 URL 或异常消息放进标签。每个唯一标签组合都会创建新时间序列,内存、磁盘和查询成本随之增长。
找出增长来源
topk(20, count by (__name__) ({__name__!=""}))
topk(20, count by (job) ({__name__!=""}))
同时检查 Prometheus 的 head series、series created 和 WAL 增长。某个指标序列数突然上升时,对照最近发布和标签变更。
治理无界标签
请求路径应归一化为路由模板,把 /users/123 变为 /users/:id。错误信息改为有限的错误码;需要逐请求分析的数据放入日志或 trace,而不是 metrics。
在采集端止损
metric_relabel_configs:
- source_labels: [request_id]
action: labeldrop
删除标签前确认没有关键告警依赖它。对完全无用的指标使用 drop,减少网络和存储开销。
建立预算
为每个服务设置活跃序列预算和新增速率告警,将指标 schema 评审纳入发布流程。基数问题越早在测试环境发现,修复成本越低。