用途：诊断线上 Prometheus 基数问题，即序列数量异常增长导致的性能、内存或成本问题。适用于 Prometheus 本地实例及 Mimir/Grafana Cloud Metrics 多租户环境。
主要能力：提供症状到成因的对照表（OOM、查询慢、远程写入滞后、429 Too Many Samples、账单飙升、序列频繁重置等）；分步排查流程，包括用 prometheus_tsdb_head_series 或 cortex_ingester_memory_series 获取活跃序列总数，调用 /api/v1/status/tsdb 查看按指标名、标签值数量、内存占用的排行；按指标下钻定位问题标签；对比近期变更与部署；诊断序列 churn。
核心规则：禁止在抓取时用 labeldrop 删除区分序列的标签（如 pod、instance），否则会合并不同序列，导致 rate()/increase() 结果错误、重复样本或乱序错误，且问题隐蔽。安全做法只有三种：整体丢弃不需要的指标（action: drop on name）、从源头修复应用、或使用 Adaptive Metrics 做摄入后聚合。
常见问题与修复：直方图 _bucket 指标基数约为 14 倍，应在埋点代码中减少标签或桶数，或考虑原生直方图；kube-state-metrics 需配置 --metric-labels-allowlist 和 --metric-annotations-allowlist；路径类标签应在应用层模板化（/users/:id），不可在抓取时归一化；调试指标应整体丢弃；应用自带的 instance 等标签与目标标签冲突时，仅可删除完全重复的目标标签（如 exported_instance）。
紧急处置：可在 metric_relabel_configs 中按 name 整体 drop 问题指标，Alloy 中对应 prometheus.relabel 组件。需先在测试环境验证，优先源头修复或 Adaptive Metrics。
限制：本技能为诊断与操作指南，不涉及模式设计与预防（应转 prometheus-label-strategy）；DPM 明细转 dpm-finder；成本优化转 adaptive-metrics；PromQL 编写转 promql。具体命令与配置示例以原文为准。