Prometheus 的基数爆炸（cardinality explosion）是什么？如何预防和治理？

结论：Prometheus 中每个不同的标签组合是一条独立时间序列，标签取值无界（user_id、请求 path 含 ID、container_id）会让序列数从千级飙到千万级，内存与查询性能崩溃，这叫基数爆炸。单条序列约占用若干 KB 内存，千万级即可吃掉数十 GB。

展开：预防守则：1）标签值必须来自有界集合——方法、状态码、端点模板（/users/{id} 而非 /users/123）是好的；用户 ID、会话 ID、时间戳、完整 URL 永远不行；2）高基数维度留给日志和 tracing，metrics 只做聚合视角；3）客户端埋点 review 时盯 label 来源，http_requests_total{path=...} 要确认框架给的是路由模板。治理手段：1）定位——count by (__name__)({__name__=~".+"}) 或 Prometheus 2.14+ 的 TSDB 状态接口 / cardinality 分析 UI 找出爆炸的指标与标签；2）止血——relabel 规则 labeldrop/replace 在抓取侧丢弃问题标签，短期可用 metric_relabel_configs 直接 drop 整个指标；3）回收——删序列需要 admin API（delete_series）+ 等 compaction 或重启清理。易错点：Go 客户端默认进程指标、kubelet/cAdvisor 的 container 标签、Istio sidecar 注入的遥测都是常见高基数来源，接入时先评估。

# 找出序列数最多的指标
topk(10, count by (__name__)({__name__=~".+"}))

追问方向：VictoriaMetrics/Mimir 对高基数的架构优化、exemplar 如何以低开销把 metrics 关联到 trace。