> 本文由 苏州市天智教育培训中心 技术团队整理，基于真实生产故障复盘，面向一线运维与开发同学，可直接用于排障参考。

一、问题现象

Prometheus 进程内存从 4GB 涨到 32GB 被 OOM Kill，重启后半小时又涨回去。查下来是"指标基数"出了问题，一条标签爆炸式增长。

二、排查思路速览

先按下面的路径走，每一步都有明确的判断分支，避免"上来就重启"这种无效操作。

Prometheus · Prometheus 内存暴涨与 OOMPrometheus 内存暴涨 / 被 OOM开始看 TSDB 状态与 series 数量series 是否异常多？判断是基数爆炸：查高基数指标与标签否看查询是否产生超大范围聚合用 topk 查基数最高的指标定位是哪个标签引起的（如 user_id / trace_id / path 全量）把高基数标签从指标中剔除或改直方图限制采集与查询，重启并观察内存稳定，series 数量可控结束

三、先看清链路：Prometheus 的典型架构

动手之前先明确"请求经过了哪些环节"，把问题定位到具体一层，排查效率会成倍提升。

Prometheus 监控链路采集ExporterServiceMonitorPushgateway存储本地 TSDB远程写入VictoriaMetrics计算Recording RuleAlert Rule展示GrafanaAlertmanager夜莺

四、根因分析

结合现场日志、监控与配置，逐条核对，绝大多数情况都能收敛到下面这几类原因：

  1. 业务把 user_id / order_id / 完整 URL 当标签，基数无限增长
  2. histogram 的 bucket 标签配置不当，产生海量 series
  3. 查询用了超大时间范围 + 高基数聚合，内存瞬间打满
  4. Recording Rule 计算量大且频繁

五、处置过程

处置原则：先止血、再根治。先让业务恢复，再回头解决根因，不要在故障中做长期改造。

  1. 先定位高基数指标，这是 90% 的内存问题根因
  2. 标签只能放"低基数"维度：状态码、方法、区域等
  3. 高基数需求改用日志或链路，不放进指标
  4. Prometheus 加内存限制与告警，避免影响整机

六、关键命令与配置

下面这些命令/配置可以直接在生产上核对（执行前请确认环境与权限）：

# 查基数最高的指标
 topk(10, count by (__name__)({__name__=~".+"}))

# 查同一指标下某个标签的取值数量（定位爆炸标签）
 count by (path)(http_request_duration_seconds_count)

# 正确做法：把高基数维度改成"桶"，不要逐值建 series
# 错误: http_requests{path="/order/detail?id=123456"}
# 正确: http_requests{route="/order/detail", status="200", method="GET"}

七、复盘

故障恢复后必须做复盘，重点不是"谁的责任"，而是"哪个机制缺位"：

  1. 根因是某接口把完整 URL（含参数）当指标标签，基数上百万
  2. 复盘发现没有 series 数量监控，涨到爆炸才发现
  3. 团队对"指标基数"概念普遍缺乏认知

八、预防建议

  1. 建立 series 数量与增长速率监控
  2. 制定标签规范：禁止高基数维度进入指标
  3. 代码评审关注指标定义，必要时提供 SDK 封装
  4. Prometheus 独立部署并设内存上限

九、官方版本动态（自动同步）

以下内容由官方发布渠道自动同步（最近同步 2026-10-11），用于提醒你：同一个问题在不同版本上的表现与处置方式可能不同，动手前先确认线上实际版本。

  • Prometheus Release v3.13.4（2026-10-02 发布）：3.13.4 / 2026-09-29 官方说明
  • Prometheus Release v3.15.0（2026-09-25 发布）：3.15.0 / 2026-09-24 官方说明
  • Prometheus Release v3.15.0-rc.1（2026-09-22 发布）：3.15.0-rc.1 / 2026-09-21 官方说明

> 版本升级前务必先在测试环境验证，特别是标注了「破坏性变更」或「停止维护」的版本。

十、写在最后

上面这套排查方法，是 Prometheus 在生产环境中最常见的一类问题，也是运维方向岗位面试里经常被追问的场景题。很多人搜「苏州运维」或者关心「苏州运维哪个好」，真正想确认的其实是：课程讲不讲真实的线上故障。我们在云计算运维工程师课程里，会把这类故障做成实战演练——从监控曲线、日志、命令输出一路推到根因，再动手恢复，而不是背命令。苏州校区面授 + 线上同步，主打包就业的运维培训，就业推荐覆盖江浙沪。如果你正在做运维方向、或者想转行进入运维领域，可以了解一下我们的课程（苏州运维、苏州运维哪个好、包就业的运维培训），也可以直接联系我们做一次免费的职业与技术评估。

十一、延伸阅读