根本原因是标签组合爆炸导致基数过高，如用user_id、request_id等高基数字段作标签会使时间序列数指数增长，引发OOM。
为什么 statsd 或 prometheus_client 的指标打多了会 OOM？
根本原因不是数据量大，而是标签组合爆炸——也就是 cardinality 过高。比如用 user_id、request_id、trace_id 甚至 ip 作为标签，一个请求就生成一个新时间序列，内存和存储会指数级增长。
真实场景里，你可能只看到 MemoryError 或 Prometheus 报 target is unhealthy: context deadline exceeded，但没意识到是指标本身在“自我繁殖”。
- 避免把高基数字段当标签：如
user_id、email、url_path（含参数） - 聚合优先于打点：能用
counter.inc()统计总数的，别拆成counter.labels(status="200", user_id="u123").inc() - 用直方图（
Histogram）代替带状态码+路径的多维Gauge：比如 HTTP 延迟用http_request_duration_seconds_bucket，而不是为每个path+status单独建指标
prometheus_client 中哪些标签写法实际在造坑？
很多人以为只要不写 user_id 就安全，但其实 request_id、uuid4()、甚至 datetime.now().isoformat() 都是隐形高基数陷阱。
关键判断标准是：这个值的取值空间是否随请求线性增长？如果是，它就不该进 .labels()。
立即学习“Python免费学习笔记（深入）”；
- 危险写法：
metrics_counter.labels(method="GET", path=request.path, status=str(resp.status_code)).inc()——path含动态 ID 时，cardinality ≈ 请求量 - 可接受写法：
metrics_counter.labels(method="GET", path="/api/users/{id}", status="200").inc()，前提是path是预处理过的模板字符串 - 更稳做法：用
re.sub(r"/\d+", "/{id}", request.path)规范化路径，再塞进labels()
用 statsd 时怎么防 cardinality 爆炸？
statsd 本身不存标签，但客户端（比如 dogstatsd 或 statsd-client）支持 tags，一不小心就把 tags=["user_id:123", "host:web-01"] 当成常规操作了。
问题在于：tag 组合 = 新 metric key，服务端（如 Datadog、StatsD server）会为每组唯一 tag 创建独立计数器，内存占用直接翻倍。
- 禁止在循环或请求处理中动态拼 tag：比如
statsd.increment("http.requests", tags=[f"user_id:{uid}"]) - 只允许有限白名单 tag：如
env:prod、service:auth、method:POST，且值必须来自枚举 - 用采样降频：对非核心维度加
rate=0.01，比如statsd.gauge("user.balance", balance, tags=["currency:usd"], rate=0.01)
如何快速发现已存在的高基数指标？
别等报警，先查指标本身的 series 数量。Prometheus 提供 count({__name__=~".+"}) 是总时间序列数，但更实用的是定位具体指标：
- 查 top 10 高基数指标：
count by (__name__) ({__name__=~".+"}) | sort_desc（在 Prometheus 表达式浏览器里跑） - 看单个指标的 label 组合数：
count by (job, instance) (rate(http_requests_total[1h]))，如果结果 > 1000，说明 job/instance 维度已经过细 - 用
curl http://localhost:9090/api/v1/status/tsdb | jq '.data.seriesCount'监控总量，超过 100 万要警觉
最常被忽略的一点：cardinality 不是静态的，它会随着业务增长缓慢爬升。今天 500 个 path 标签，下个月可能变成 5000 —— 没有自动化监控的话，等发现时往往已经拖垮了整个监控链路。
