尾部采样的内存账：65% 的降幅不是免费的，CPU 翻倍是代价

分布式追踪的生产成本主要由两部分构成：处理开销和存储成本。采样是维持追踪价值同时控制成本的自然手段，但头部采样和尾部采样解决的是不同的问题。头部采样在 trace 开始时就做决定，那时候你还不知道这条 trace 会不会出错、会不会很慢。尾部采样在稍后阶段有条件地做决定，让错误和慢事务这类高价值 trace 更有可能被保留。

尾部采样的代价藏在一个容易被忽略的地方：它需要缓冲 100% 的入站 trace，等 decision_wait 时间到了、所有 span 都到齐了，再应用采样策略、转发被选中的子集。缓冲是内存占用的主要来源，而内存占用随 span 量线性增长。decision_wait 设成一分钟，意味着一条 trace 的所有 span 要在一分钟内到齐，才能做出完整决策；如果 trace 比一分钟慢，决策会在 span 缺失的情况下做出。num_traces 限制了同时缓冲多少条 trace。这两个参数共同定义了“数据丢失”和“内存占用”之间的权衡，而且它们需要对 trace 的形状做假设：能有多慢、包含多少 span、每个 span 多大。

Elastic 向上游 OpenTelemetry Collector 的尾部采样处理器贡献了两个改进，把内存占用降低了最多 65%。第一个是 sampling_strategy: span-ingest，让采样决策在摄入时就能发生，在 decision_wait 结束之前释放 trace。第二个是 Pebble 尾部存储扩展，把 trace 缓冲移到磁盘上的 LSM 数据库，让存储随磁盘容量扩展，而不是随 RAM 扩展。这意味着运维者可以提高 decision_wait 和 num_traces，而不用担心 OOM kill。

但代价必须说清楚：大约 2 倍的 CPU 开销。磁盘支撑的缓冲把内存压力转移到了 I/O 和序列化上，每一次 span 的写入和读取都要经过磁盘路径，CPU 用来做编解码、压缩、LSM 合并。这不是一个“免费的降本”，是一个用 CPU 换内存的交易。对于内存是瓶颈、CPU 有余量的 Collector 实例，这个交易是划算的；对于 CPU 已经饱和的实例，换过去可能只是把瓶颈从内存搬到了 CPU。

一个务实的调优顺序是：先确认瓶颈确实是尾部采样缓冲导致的 OOM 或频繁 GC，而不是采样策略本身太宽松；再评估 CPU 余量，如果 CPU 已经吃紧，先优化策略（减少不必要的保留策略、收紧 decision_wait）而不是换存储后端；然后才考虑磁盘支撑的缓冲，并且在上线后同时盯内存和 CPU 两个指标。尾部采样的目标不是“保留所有 trace”，是“保留值得保留的 trace，同时不让 Collector 自己成为故障源”。65% 的内存降幅是一个真实的工程收益，但它写在 CPU 翻倍的账单背面。