Prometheus 抓取间隔与时间序列基数爆炸的防范实践

背景

在小团队把业务指标接到 Prometheus 后，最常见的两类问题不是“怎么配 scrape”，而是抓取间隔过密，以及高基数标签把时间序列数量打爆。磁盘占用、compaction 压力和查询延迟都会跟着一起恶化，最后才表现为看板卡顿。

抓取间隔怎么选

默认 15 秒对很多业务过密。建议先按指标变化速度分层：

1. 基础设施与进程存活：30 秒到 60 秒通常足够。
2. 业务请求量、错误率、延迟分位：15 秒到 30 秒。
3. 日级或小时级批处理结果：用 Pushgateway，或单独配置更长间隔。

经验上，把全局默认改成 30 秒，再对关键 job 单独缩短，比“全局很密、个别再放宽”更省资源，也更容易治理。

基数爆炸的典型来源

高基数通常来自不该当标签的字段，例如：

• user_id、order_id、request_id、完整 URL path
• 未收敛的 pod 名、临时容器 ID、构建号
• 把错误信息原文直接塞进 label

一条看似无害的 counter，一旦带上百万级唯一 label 组合，TSDB 头部、内存和 compaction 都会被拖垮。问题往往不是单次 scrape 太大，而是序列数长期只增不减。

落地约束

1. 标签白名单：只保留 service、env、region、status_code 等低基数维度。
2. 用 recording rule 做预聚合，查询侧少做大范围 group by。
3. 为高基数指标设置更短 retention，或降采样进长期存储。
4. 上线前盯 prometheus_tsdb_head_series 与 scrape duration，而不是只看面板“有没有数”。

小结

Prometheus 的成本曲线对基数极其敏感。宁可少几个花哨维度，也要保住稳定的抓取和可预期的查询延迟。先把间隔策略和标签纪律定清楚，再谈告警规则与看板优化，后续运维会轻松很多。