分布式链路追踪的采样策略：头部采样为何是主流

分布式链路追踪的采样策略：头部采样为何是主流

全链路压测时代，一次用户请求在微服务架构里要穿过 20~50 个服务，产生几百个 span。全量采集这些链路数据，存储成本会随流量线性增长——大促一天的数据量可能超过平时一个月。但采样又会带来灵魂拷问：出问题的那条链路恰好没被采样怎么办？本文把采样策略的选择讲透，并解释为什么业界最终收敛到了头部采样。

一、先看几种采样策略的本质区别

尾部采样（Tail-based）：请求完整执行完后，根据整条链路的结果决定是否保留——错误链路必留、慢链路按阈值留、正常链路按比例留。优点是精确：所有异常都有现场。缺点是所有 span 必须先集中到收集器等结果，收集器要维持全量数据的内存状态，成本高且是中心瓶颈。

头部采样（Head-based）：在链路的入口（trace 开始时）就决定采样与否，用 trace 透传标记告诉沿途所有服务「这条链路采/不采」。优点是去中心化、零额外基础设施成本，沿途服务看到标记直接决定上报或丢弃。缺点是听天由命：一条慢链路如果入口掷骰子没采中，现场就没了。

一句话对比：尾部采样是「先全收集再挑选」，头部采样是「入口掷骰子沿途服从」。前者精确但贵，后者便宜但会漏。

二、头部采样为何成为主流

从纸面看尾部采样全面占优，那为什么 OpenTelemetry、各大云厂商的默认方案都是头部采样？三个工程原因：

成本拐点。尾部采样的收集器要缓存每条在途链路的全部 span 直到链路结束。当 QPS 到达十万级，在途链路的内存状态轻松上百 GB，收集器本身成了新的稳定性风险——可观测性系统把自己变成了最需要观测的系统。头部采样没有这个问题，每个服务独立上报，天然水平扩展。

错误链路的补偿机制让头部采样的缺点可接受。头部采样的经典配置是「低比例正常采样 + 全量错误采样」：入口采样 1%~10%，但每个服务上报时对包含错误的 span 强制保留。配合本地持久化缓冲（agent 本地磁盘缓存错误 span，高峰过后补报），错误链路的丢失率可以压到接近零。剩下的缺口只有「慢但没错」的链路——这个缺口用 metrics 补：延迟分布靠指标（P99 直方图）无遗漏采集，发现某服务延迟异常后，临时把该服务的采样率调到 100% 复现问题。指标发现异常、链路定位根因，两者分工后，链路采样不需要全量。

工程成熟度。OpenTelemetry 的 SDK 把头部采样做成了标准能力，traceparent 头透传、采样标志位（sampled flag）沿途服务无条件服从，实现成本接近零。尾部采样至今没有统一标准，各家实现都是自研收集器，运维负担重。

三、落地配置建议

基础配置：入口服务头部采样 10%（常态流量），trace 上下文透传用标准 W3C Trace Context 头。错误 span 强制保留。这个配置下，链路存储成本是全量的 10% 加错误量，而典型业务的错误率在 0.1% 以下，成本可控。

分级采样：不是所有入口流量等价。核心链路（交易下单）入口采样 100%，边缘功能（内容浏览）采样 1%。头部采样在入口决定时可以按业务路由差异化配置，让预算集中在高价值路径。

动态调节：采样率不要写死在配置文件。运维链路（或控制台）支持运行时调整：平时 10%，排查某个问题时把相关服务的采样调到 100%，观察 10 分钟后调回。这个「临时放大」的开关是采样策略的救命稻草。

留个逃生口：对「被采样丢弃的链路」保留元信息——trace ID 和入口时间以日志形式低成本记录（不需要完整 span），排查时至少能知道「这条链路存在过」，配合客户端日志的 trace ID 串联，多数问题可以还原上下文。

四、什么时候才值得上尾部采样

两种场景：一是延迟敏感度极高的业务（交易链路要求所有超过 200ms 的请求都有完整现场），二是问题复现成本极高的场景（金融对账差异，事后必须看到链路）。这时尾部采样的折中方案是「缩小窗口」：只对核心链路组做尾部采样（该链路组内的服务 span 先缓存），边缘链路仍走头部采样。范围收窄后，收集器的内存状态可控，精确性和成本达到平衡。

结语

采样的本质是「用统计代表性换存储成本」。头部采样的聪明之处不是它更精确，而是它把可观测性拆成了三层：指标（无遗漏的统计）、日志（按需的细节）、链路（抽样的事故现场）。三层配合下，链路不需要全量也能完成定位使命。建可观测性体系时，先把指标的覆盖做满，再调链路采样率——顺序反了，就是把钱花在刀背上。