分布式链路追踪的尾部采样：成本与问题定位的平衡

头部采样丢的，恰好是你要的 trace

链路追踪最大的矛盾：全量采集成本不可承受（通常 5%~10% 的请求开销与数 TB 存储），而头部采样（入口处按比例丢弃）会把你最需要的慢请求、错误请求几乎全部丢掉——因为它们是小概率事件。尾部采样（Tail-based Sampling）把采样决策推迟到一条 trace 完整结束之后，按「结果」决定保留谁，是当前大厂的主流方案。一、尾部采样的保留策略设计

按优先级叠加多条规则，命中即保留：

1. 错误请求全保留：任何 span 出现 5xx、异常、超时，整条 trace 保留——这是排障的第一现场；
2. 慢请求全保留：trace 总耗时超过 P99 阈值（如 2 秒）保留，或按服务分档（网关 1s、内部服务 500ms）；
3. 特殊流量配额保留：新版本灰度流量、特定用户/租户、特定接口（如支付回调）按标签强制保留 N%；
4. 正常流量低比例抽样：剩余正常请求按 1%~5% 采样，用于容量分析与基线对比。

二、落地架构：Collector 链路

尾部采样需要看到完整 trace 才能决策，因此采集架构要变：

1. Agent 只做转发：业务侧 OpenTelemetry Agent 不做丢弃，全量上报到网关层；
2. 网关层缓冲等待：尾部采样器（OTel Collector tail_sampling processor）按 traceID 聚合 span，等待窗口（建议 30~60 秒，覆盖最长 trace）结束后统一决策；
3. 按 traceID 分区是关键：同一 trace 的 span 必须路由到同一个采样器实例（按 traceID 哈希分流），否则决策不完整——Kafka 按 traceID 分区是常见做法；
4. 内存与降级：等待窗口内的 trace 都驻内存，流量高峰按 traceID 数量限流，超限的 trace 退化为头部采样并打点记录。

三、成本与效果的量化

某支付平台的数据（供参考）：全量采集日均 8TB trace 存储；改尾部采样后，错误+慢请求保留 100%，正常流量采 2%，总量降到 380GB（约 5%），而排障时关键 trace 的完整率从头部采样的 31% 提升到 98%。算总账：存储省 95%，排障效率反而提升——尾部采样不是「少存点」，是「存对的」。

四、避坑清单

1. 等待窗口别拍脑袋：窗口小于最长 trace 时长会出现「半条 trace」，决策依据不完整；
2. 时钟偏移：跨机房 span 时间戳偏移会影响耗时计算，collector 侧要容忍时钟偏差；
3. 袋鼠指标：采样率本身要成为监控指标——错误 trace 占比突变可能是上游故障，也可能采样器自己挂了；
4. 与日志联动：trace 采样后，确保对应的日志也带 traceID 且可检索，否则「trace 保留、日志找不到」依然排不了障。

尾部采样的本质：把「存储成本」从均摊改成按价值分配。异常与慢请求是最贵的信息，一个字节都别丢；正常请求的重复样本，95% 都是冗余。这套平衡做对，链路追踪才真正用得起来。