OTel processor 按成本采样：LLM 可观测性账单省下 1.2 万美元/月
生产里跑 LLM 服务的人都知道：可观测性账单在爆炸。每次 GPT-4o/Claude/Gemini 调用都生成 trace，典型 AI 网关每天几百万 span。按 Datadog $0.30/GB、Grafana Cloud $0.50/百万 span 算，真金白银——而其中大多是价值 $0.001 的缓存命中。
随机采样的毛病
标准做法是 1% tail sampling：随机保留 1/100 trace。问题在于随机采样对成本无感：
- GPT-4o 思维链 50K token（成本 $2.50）：99% 概率被丢弃，你永远看不到最贵的调用；
- 结账流 500 错误（$0.15）：99% 被丢，PagerDuty 响了却没 trace 可查；
- 15 秒 embedding 超时（$0.08）：99% 被丢，用户投诉了你无法复现；
- 健康检查 ping（$0.001）：没人关心，但 1% 却可能留下它。
$2.50 的 trace 比 $0.001 的值钱 2500 倍，随机采样不知道这一点。
为什么不直接用 OTTL 条件
OTel tail sampling 支持 OTTL 条件，可以写 span attributes["gen_ai.usage.cost_usd"] > 0.10。两个问题：
- 无聚合：OTTL 按 span 评估、不按 trace——5 个 $0.03 的 span（合计 $0.15）因单个 span 都不超 $0.10 被整体丢弃；
- 复杂度：要组合 cost+error+duration，得写多个 policy、composite evaluator 和决策策略。
TraceShrink：一个配置块搞定
作者构建的 TraceShrink 是按整条 trace 聚合成本采样：总成本超阈值就保留，顺带合并 error/duration 条件。用 OpenTelemetry Collector Builder 组一个自定义 collector（github.com/timurrakhmatullin86/traceshrink v0.1.0）即可。数据：每天 50M span 的场景下从 $750–4,000/月降到 $15–80/月——大部署的"$12k/月"就来自这里。代码 Apache-2.0。
实践建议
- LLM 可观测性采样按 trace 聚合成本，别按 span 阈值或纯随机——贵 trace 才是要留的；
- 采样策略同时看 cost/error/duration，合并成一个判定而非多层 policy；
- 先用自建探针对比 tail sampling 与成本采样，再决定切换。
来源：I Built an OTel Processor That Can Save You $12k/Month on LLM Observability - DEV Community