在应用与抓取目标层预防 Prometheus…

当你需要评估、审计、设计或改进 Prometheus 标签 schema，或想知道如何从源头防止高基数时使用。

适用场景

解决思路

1. 遵守唯一规则：绝不在抓取时删除任何使序列唯一的标签（如 pod、instance 等），包括 metric_relabel_configs 的 action: labeldrop 和 Alloy 的 prometheus.relabel；否则会静默破坏数据：计数器重置被混合导致 rate()/increase() 返回垃圾值、DPM 反而膨胀、聚合结果错误且事后无痕迹。
2. 按优先级使用正确工具：1) 首先在应用代码中不发出坏标签（这是唯一能安全移除标签的地方）；2) 对已进入 Grafana Cloud 且无法在源头修复的序列，使用 Adaptive Metrics 进行正确的、感知计数器重置的、可审计可回滚的聚合。
3. 用基数评分评估每个标签：env(2–5)、job(5–50)、cluster/region(数十)、namespace(数十到数百)、service/workload/container(数十到数百)为好；instance(数百到数千)需评估；pod(数千且高流失)必须保留以维持唯一性；path/route 仅在模板化时可用；version/image_tag/git_sha 谨慎使用；user_id/request_id/trace_id/customer_id/error_message/query/sql 绝不用作标签。

适用边界 · 注意事项

• 不要用 metric_relabel_configs 或 Alloy prometheus.relabel 丢弃区分序列的标签（pod、instance、user_id、path 等），这会静默破坏 rate()、膨胀 DPM、损坏聚合。
• 不要在抓取时规范化标签值（如将 status_code 折叠为 2xx），这会合并不同序列并产生重复样本错误；应在代码或 Adaptive Metrics 中做。
• 本技能只管策略与设计；诊断和运维修复由其他技能负责（如正在发生的基数火灾用 prometheus-cardinality-troubleshooter）。

经验正文