现场是这样的。给 LLM 调用 span 打上 user_id 与 session_id 两个标签，一个月后指标存储涨到 40GB，查询面板超时，后端提示 series 数量过多。
中间走过弯路，把「trace 与 metrics 混用同一批属性」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。高基数字段直接作为指标标签；标签被用于聚合，每个取值生成一条时间序列；没有做标签白名单，随手加字段。
动手时先统计各标签的取值数量
python -c "import json,collections;rs=[json.loads(l) for l in open('spans.jsonl')];print({k:len({r.get(k) for r in rs}) for k in ['user_id','session_id','model']})"然后把高基数字段从指标标签挪到 trace 属性
python otel_conf.py --metrics-allow model,status --trace-keep user_id给指标标签加白名单校验
python -c "print({'allowed':['model','status','tenant_tier']})"末了清理已产生的历史序列并观察存储增长
python metrics_cli.py --drop-series-prefix llm_ --dry-run排查用的命令都是临时敲的，没有写成脚本，事后才整理。
恢复的判定其实很直接。指标序列数量回到千级，存储增长趋缓，需要按用户排查时仍能在 trace 里查到对应属性。
指标的每个标签组合都是一条序列，用户级字段放进去必然爆炸，排查维度交给 trace，指标只留低基数维度。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。