Prometheus 基数爆炸（内存飙升/查询变慢/账单暴涨…

当 Prometheus 出现 OOM、查询变慢、Active Series 或 DPM 账单飙升、429 Too Many Samples 等基数相关故障时，系统化定位问题指标与标签并安全处置。

适用场景

解决思路

1. 先记住唯一铁律：绝不要在抓取时用 labeldrop 删除任何使序列唯一的标签（pod、instance 等）。这样做会合并不同序列的计数器重置，导致 rate()/increase() 返回垃圾值、产生重复样本与乱序错误、DPM 反而升高，且故障是静默的、事后无迹可查。唯一安全的三条路是：整条丢弃不需要的指标（对 __name__ 做 action: drop）、从源头修复（让应用停止发出坏标签）、或使用 Adaptive Metrics 做摄入后聚合。
2. 按症状对照表定位方向：Prometheus OOM 或内存线性增长→做 Active Series 分诊；单条 PromQL 慢或打爆 querier→做单指标下钻；remote write 滞后/WAL 增长→查序列数或抓取间隔变化；429 Too Many Samples→找新增的元凶指标；Grafana Cloud Active Series 账单飙升→单指标下钻加 churn 检查；DPM 涨但 Active Series 平→转 dpm-finder；部署后出现 series_limit_per_user 错误→做近期变更 diff；序列数增长后每次重启归零→做 churn 诊断。
3. 第一步 Active Series 分诊：用 prometheus_tsdb_head_series 查本地总活跃序列数，Mimir/Grafana Cloud 用 cortex_ingester_memory_series{user="<tenant>"}；用 deriv(prometheus_tsdb_head_series[7d]) * 86400 看 7 天增长速率，稳定应用集上日增超过几个百分点即为红旗。
4. 调用 TSDB status 端点获取内置基数分解：curl -s http://prometheus:9090/api/v1/status/tsdb | jq，返回 seriesCountByMetricName（按序列数排名的指标）、labelValueCountByLabelName（按唯一值数排名的标签）、memoryInBytesByLabelName（按内存占用排名的标签）、seriesCountByLabelValuePair。Grafana Cloud 用带认证的同一端点：curl -s -u "<user>:<token>" "https://prometheus-prod-XX.grafana.net/api/prom/api/v1/status/tsdb" | jq。
5. 第二步读输出：若 seriesCountByMetricName 顶部是直方图（_bucket），几乎总是元凶，它有约 14 倍乘数（桶数+3），修法是在埋点代码里减少底层直方图的标签（不是在抓取时剥离，也不要动桶本身）；若前 5 名有你不认识的指标，去代码库 grep，多半是新功能开关或误上生产的调试指标；同一指标以 _total/_count/_sum 多个变体出现时要把它们合并计算真实影响。
6. 第二步读标签：labelValueCountByLabelName 中任何唯一值超过 1 万的标签几乎肯定是 bug（唯一例外是超大规模集群中有意设置的 per-target 标签）；trace_id、request_id、session_id、query、email、path、url 这类绝不应作为标签，它们属于 exemplars、日志或链路追踪；pod 有数千个值时要看 churn 诊断，近期 churn 常抬高这个数字。
7. 第三步单指标下钻：用 count by (__name__) (count by (__name__, label_name_here) (http_request_duration_seconds_bucket)) 统计某指标上每个标签的唯一值数；或用 HTTP API 脚本遍历：curl -s "http://prometheus:9090/api/v1/labels?match[]=http_request_duration_seconds_bucket" | jq -r '.data[]' 后逐个查 /api/v1/label/${label}/values 并统计长度，排序取前 20。
8. 第三步找某标签的头部取值：topk(20, count by (path) (http_requests_total))；若头部出现 UUID、哈希、时间戳或数字 ID，说明该标签在源头是无界的。
9. 第三步按实例分组看序列数：sum by (job, instance) ({__name__=~"my_metric.*"})，若分布不均说明某个实例行为异常。
10. 第四步近期变更 diff：用 group by (__name__) ({__name__!=""}) 与 group by (__name__) ({__name__!=""} offset 7d) 对比当前与一周前的指标列表，外部做 diff，新出现在 seriesCountByMetricName 顶部的指标就是元凶；用 prometheus_tsdb_head_series 叠加 changes(app_build_info[1d]) 与部署时间对齐，序列数出现与部署同步的垂直台阶即可定论。
11. 第五步 churn 诊断：用 rate(prometheus_tsdb_head_series_created_total[5m]) 与 rate(prometheus_tsdb_head_series_removed_total[5m]) 看创建/移除速率，用 prometheus_tsdb_head_series_created_total / prometheus_tsdb_head_series 看 churn 与存活比；创建率持续显著高于移除率意味着基数单向上涨。常见成因与特征：Pod 滚动发布发出 pod 标签（churn 峰值与部署时间对齐）；每个指标带 version/git_sha/image_tag 标签（每次部署多指标同时 churn）；instance 里是临时主机名（与云自动扩缩容事件对齐）；动态标签名的 bug（churn 永远上涨不收敛）；应用 bug 发出新 UUID 作为标签（线性无界增长，与部署无关）。
12. 第五步看 churn 的内存影响：prometheus_tsdb_head_chunks 与 go_memstats_heap_inuse_bytes{job="prometheus"}；重启 Prometheus 会丢掉 churned 序列但不是修复，修复要在源头。
13. 常见元凶一：直方图爆炸。特征是 *_bucket 指标位于 seriesCountByMetricName 顶部，乘数约 14 倍。修法依次为：先在源头减少直方图标签（每去掉一个标签省 14 倍序列，在埋点代码里裁剪 path/method/status_code，不要在抓取时 labeldrop，那会合并不同直方图并破坏桶；对已在 Grafana Cloud 中无法改的序列用 Adaptive Metrics 聚合）；再酌情减少桶数（自定义桶 vs 默认桶）；高分辨率延迟追踪可考虑原生直方图（Prometheus 2.40+），用单个稀疏序列替代整个桶族。
14. 常见元凶二：kube-state-metrics 标签爆炸。特征是 kube_pod_labels 或 kube_pod_annotations 位于顶部，由 label_*/annotation_* 标签驱动基数。修法是配置 --metric-labels-allowlist 与 --metric-annotations-allowlist，因为它默认把所有标签和注解都发成序列，例如 --metric-labels-allowlist=pods=[app,team,version] 与 --metric-annotations-allowlist=pods=[checksum/config]。
15. 常见元凶三：新端点导致 path/route 爆炸。特征是 http_requests_total 一夜增长 10 倍以上，topk(20, count by (path) (http_requests_total)) 出现成百上千个 /users/123456 式取值。真正的修法是在应用代码里做路径模板化（/users/:id），转 prometheus-label-strategy；对已在 Grafana Cloud 的序列用 Adaptive Metrics 正确聚合掉 path。绝不要用 relabel 的 replacement 规则去“归一化” path——把 /users/123、/users/456 折叠成一个值会在抓取时合并不同序列，产生重复样本错误和坏掉的 rate()；合并必须发生在源头（模板化）或摄入后（Adaptive Metrics），绝不能在抓取时。若必须立刻止血而模板化还来不及上线，唯一安全的抓取时动作是整条丢弃该指标（在代码修复前完全失去它，这是有意的取舍而非静默损坏）：metric_relabel_configs 中 source_labels: [__name__]、regex: http_requests_total、action: drop。
16. 常见元凶四：应用在生产发出调试指标。特征是前 10 名出现不认识的指标，grep 源码常发现是开发者忘了加开关的 _details 或 _per_request 调试指标。修法是整条丢弃：metric_relabel_configs 中 source_labels: [__name__]、regex: my_app_request_details、action: drop，并给对应团队开单从代码中移除。
17. 常见元凶五：应用发出的标签与 target 标签冲突。特征是某个 job 的序列数是应有值的数倍，单条序列上同时出现应用发出的 instance 与 target 的 instance 冲突（Prometheus 把冲突的那个重命名为 exported_instance）。正确修法是在应用里停止从代码发出 instance/node/host，它们属于抓取目标；确认 honor_labels 为 false（默认值）让 target 标签胜出。若需要抓取时临时补救，只能删除与 target 标签完全重复的标签——这是唯一安全的 labeldrop，因为 target 标签仍提供唯一性；要严格限定在重复的名字上，绝不包含 pod（或任何唯一性来源标签）：metric_relabel_configs 中 regex: exported_(instance|node|host)、action: labeldrop，之后 relabel_configs 的 target 标签会干净生效。优先修应用。
18. 常见元凶六：联邦放大基数。特征是联邦 Prometheus 或 Mimir 全局视图的序列数远超预期，每个源带自己的 cluster/region 标签相乘。这通常是预期行为（联邦按设计保留源标签）；若序列数过高，只联邦聚合后的 recording rules 而非原始指标：job_name: federate、honor_labels: true、metrics_path: /federate、params 的 match[] 用 '{__name__=~".*:.*"}'（仅 recording rule 命名约定）。
19. 按修复决策树执行：需要立刻止血（生产 OOM、摄入 429）→用 metric_relabel_configs 对 __name__ 做 action: drop 整条丢弃元凶指标（Alloy/Agent 语法相同），绝不 labeldrop 区分性标签，之后再安排正式修复；是 Grafana Cloud Active Series 账单问题而非性能问题→若基数结构性且改不了应用转 adaptive-metrics，若想看逐指标 DPM 分解转 dpm-finder；是可修的应用 bug（无界标签、生产调试指标）→短期整条丢弃或经 Adaptive Metrics 聚合，长期改代码并转 prometheus-label-strategy；是直方图基数→在源头减少底层直方图标签（每标签 14 倍收益）、酌情减桶、考虑原生直方图；是部署驱动的 churn→停止从应用代码发出 version/git_sha/instance（版本用 info 指标），保留 pod 绝不丢弃（pod 级序列太贵就用 Adaptive Metrics），并检查 K8s SD relabel 规则没有映射进 uid 等临时字段。
20. 紧急丢弃模板（可直接复制）：Prometheus scrape_configs 中 metric_relabel_configs 用 source_labels: [__name__]、regex: bad_metric_name、action: drop 丢弃单个坏指标，或用 regex: debug_.*、action: drop 按前缀丢弃一组调试/临时指标；Grafana Alloy 用 prometheus.relabel 组件，forward_to 指向 prometheus.remote_write.default.receiver，rule 中 source_labels = ["__name__"]、regex = "bad_metric_name"、action = "drop"。务必先在预发环境测试，并优先修源头或用 Adaptive Metrics 而非任何抓取时丢弃。
21. 按交接边界分流：要设计标签策略防止复发→prometheus-label-strategy；要保留指标但降成本→adaptive-metrics；要问哪个指标 DPM 最贵→dpm-finder；要写查找用的 PromQL→promql；要在 Alloy 中配置→alloy；Loki 慢→loki-label-analyzer。本技能只负责压力下的诊断。

适用边界 · 注意事项

• 不适用于基数问题的预防与标签体系设计（应转 prometheus-label-strategy）
• 不适用于摄入后的成本聚合优化（应转 adaptive-metrics）
• 不适用于 DPM 专项分析（应转 dpm-finder）