topk(5, count by (__name__, path) ({__name__=~".+"}))
curl -X POST 'http://prom:9090/api/v1/admin/tsdb/delete_series?match[]={path=~"/api/order/.*"}'
上线后 Prometheus 内存从 6G 涨到 16G 被 OOMKilled，重启加载 WAL 要 12 分钟。/api/order/20260301/8842 这种路径被原样当成 label，series 从 12 万涨到 300 万。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：histogram 的 label 里放了原始 path，每个订单号都是一条新时间序列。series 数量上去后倒排索引和 head block 都跟着涨，内存按 series 数线性增加。抓取间隔 15 秒，一小时就能造出上百万条。
「路径变量指标基数」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
处理上按这个顺序：查 topk 的 label 组合 找出基数最大的那个；在采集端把 path 归一化成 /api/order/:id 再打标签；把订单号用户 ID 这类高基数维度从 label 挪到日志；改完删掉旧 series 用 admin 接口清一次。
确认没问题再收工，series 总数回到 15 万以内，Prometheus 内存稳定在 4G 以下，重启加载在 1 分钟内完成。