每个 token 建一个 span 一次请求 800 条

现场是这样的。给流式输出每块建一个 span，一次 3000 token 的请求产生 800 多个子 span，Collector 内存涨到 6GB 开始丢数据，面板也变慢。

中间走过弯路，把「采样率设成 100%，没有区分链路重要性」当成主因，改完现象没变。

真正麻烦的地方在于，几个原因的现象几乎一样。流式回调里逐块建 span，没有聚合；span 属性里带了完整文本，体积过大；批量处理器队列积压后开始丢弃。

动手时先看单次请求产生的 span 数

python span_stats.py --trace trace.jsonl --group trace_id --top 5

再往下把流式块聚合成一个 span 记录首包和总时长

python patch_instr.py --stream-span-summary --keep-first-token-latency

去掉属性里的完整文本，只留长度和哈希

span.set_attribute('gen_ai.output.length', len(text))

等前面都确认过，再按链路类型设采样率

sampler = ParentBased(TraceIdRatioBased(0.1))

怎么算真的好了，看的是同一批现象。单次请求的 span 数降到二十条以内，Collector 内存回落到 1GB 以下，首包延迟指标仍然可查。

提醒一点。span 是按排查价值花的，不是越细越好，流式输出聚合成一条带首包时间的 span 信息量更大。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。