分布式追踪的采样策略选型

可视化演示

追踪基础概念

把全市监控系统再搬出来：一条街道上一个行人的完整移动轨迹，就是一条 Trace——从摄像头 A 看到他进商场，到摄像头 B、C 记录他上下电梯，再到商场出口，这段连续录像就是“一次请求的完整调用链”。而 Trace 里的每一个节点，比如“进商场门”“刷电梯卡”“柜台结账”，都叫一个 Span，代表这次调用链中的一个具体步骤。

在微服务系统里，一次用户点击“提交订单”，会被网关服务接收，接着调用认证服务验证身份，再调库存服务锁库存，最后调支付服务扣款。每一步都由不同的进程处理，但它们通过一个共同的标识——TraceID——串联起来，就像同一部电影被分成多个分镜片段，每个分镜上有统一的编号。把这些 Span 按时间线拼起来，就是一条完整的 Trace。

问题来了：一个高并发系统每秒可能有几万次请求，每一次请求都产生十几条 Span。全量保存意味着每秒钟要写入几十万条记录，存储成本、查询成本、网络开销全部失控，就像给城市每个人从早到晚每一秒都录像，硬盘几天就爆。这时候，“有损采样”就成为一种必然选择——我们要主动丢掉大部分数据，只留下最有价值的那部分录像，这就是采样策略存在的意义。

采样核心原理

采样率（Sampling Rate）就是“保存多少比例”——比如 1%，意思是一百条请求里只留一条。那么存储成本怎么估算？有一个简单的公式：

其中 $S$ 是每秒产生的追踪存储量（MB/s），$R$ 是每秒请求数，$p$ 是采样率，$m$ 是每条 Trace 的平均大小（KB）。假设每秒请求 10 万次，每条 Trace 平均 5KB，采样率 100% 时每秒存储量是 500MB——一小时就是 1.8TB。而采样率降到 1%，每秒只有 5MB，一天才 432GB。这就是“全量不可行”的数学原因。

但采样率调低了，数据质量就会下降。想象你是刑侦队长：录像只保留 1%，意味着 99% 的案发现场没有记录。问题是，你并不知道哪一秒会出事。所以采样的核心矛盾是——采样率越高，数据越全面，但成本越高；采样率越低，成本越省，但越容易漏掉关键线索。于是就有了下面几种侧重点不同的采样策略，它们像不同类型的摄像头布控方案，各有各的取舍。

固定采样

固定采样（Fixed Sampling）是监狱大门摄像头用的老办法：每经过 100 个人，只保存第 1 个人的录像，剩下的直接抹掉。实现方式很简单——在请求入口维护一个计数器，每 N 条请求保存 1 条。代码大概就是一行判断：if (counter % N == 0) { 保存 }。它最大的优点是实现成本极低，不需要任何复杂算法，也不需要跨服务协商，单个节点就能决定。

但固定采样有一个致命的缺陷：周期性漏采。假设系统每 15 分钟有一波定时任务高峰，恰好每第 100 条请求都落在高峰期的“惊群”时刻，而你的采样规则是每 100 条留 1 条，那就等于把高峰期的流量全部存了下来，把低峰期的流量全部丢光——存储波动大，且低峰期的异常完全看不见。反过来，如果高峰期的请求序号恰好永远落在“被丢”的区间，那高峰期的性能问题就永远留不下证据。

所以固定采样只适合请求量极低、流量曲线很平稳的小系统。一旦你的系统有明显的周期性波动，或者你关心的是那些“低概率但高影响”的故障，固定采样就像“每隔 100 分钟才看一眼监控”的保安，该出事的时候他恰好睡着了。它的价值在于“极简”，代价是“盲目”。

概率采样

概率采样（Probabilistic Sampling）比固定采样聪明得多。它不数人头，而是给每个人发一个随机号码，说“号码以 3 结尾的人，你的录像被保存”。在分布式追踪里，这个“随机号码”就是 TraceID——一个全局唯一的 64 位或 128 位整数。怎么做？

其中 $\text{Hash}(\text{TraceID})$ 是对 TraceID 取一个稳定的哈希值，$N$ 是预设的分桶数（比如 10000），$h$ 落在哪个桶决定了这条 Trace 是否被采样。如果 $h$ 小于阈值 $T$（比如 10），就按 0.1% 的概率采样。关键点是：这个哈希计算在整条调用链的所有服务里都相同，所以无论请求经过几个服务，大家都会得出同一个决定——要存一起存，要丢一起丢，不会出现“网关存了但业务层丢了”的数据割裂。

概率采样在统计意义上有很好的代表性：只要采样率不是极端低，样本基本能反映整体流量的分布。但它的最大短板是——它不会因为你这条请求“出错了”就高看你一眼。一个概率为 0.5% 的隐藏 Bug，在 1% 采样率下，被捕获的概率几乎为零。概率采样适合用来做容量规划、性能趋势分析这类“宏观统计”问题，但不适合用来“查找特定错误”。

头部采样

头部采样（Head-based Sampling）的思路是“先决策，后执行”。就像演唱会入口的检票员：每个观众进场时，他直接在票上盖一个章——“录”或“不录”。后面的机位看到章，就知道该不该把这个观众放进镜头。这个“章”就是传播在请求头里的 Sampling Decision 标记。

入口服务（通常是网关）一旦决定“这条 Trace 保留”，就把决策结果放进请求的 Header 里，例如 X-Trace-Sampled: 1。下游所有服务只需要读取这个标记：标记为 1 就照常上报 Span，标记为 0 就直接跳过追踪上报。这样一来，决策只在入口做一次，全链条统一执行，效率极高，几乎不影响正常请求路径的性能。

头部采样最大的优势是成本可控、响应快，因为它不需要等请求执行完就能决定是否保存。但代价也明显：决策时并不知道这次请求将来的结果。一个请求可能在执行到 500ms 时抛出异常，但入口的决策早已在 2ms 时宣判了它的命运——而当时看来，它和所有正常请求没什么两样。所以头部采样对“已知特征”（比如某类 VIP 用户、某些特定接口）做优先级保留很好用，但对“未知错误”几乎没有感知力。

尾部采样

尾部采样（Tail-based Sampling）恰恰相反：不慌不忙，等整条 Trace 走完，再根据“结局”决定要不要保存。就像商场保安的做法——不预设机位，而是等每天闭店后看哪台收银机出现了异常，再调出那台收银机全天对应的录像保存。这是一个“事后算账”的模型。

实现上，尾部采样需要一个缓冲区：把正在执行的请求的 Span 数据先暂存在内存或局部存储里，等 Trace 结束信号到达，再结合结果元数据（比如 HTTP 状态码、错误消息、耗时）计算一个“保存优先级分数”。打分规则可以设计成：

$I(\text{error})$ 是指示函数——请求出错时取 1，否则取 0；$I(\text{latency} > T_{慢})$ 同理，请求耗时超过阈值（比如 2 秒）时为 1。$\alpha$ 和 $\beta$ 是权重系数。只要分数超过保存阈值，就说明这条 Trace“值得存”。

尾部采样解决的是“错误定位”这个痛点——它能确保 100% 的错误 Trace 都被留存（前提是缓冲区不溢出），这是头部采样和概率采样都做不到的。但它的成本也更高：需要维护一个缓冲区和等待机制，在极端高并发下缓冲区可能塞满，丢掉还没决定命运的 Trace。它适合请求量大、错误率低、但对错误分析要求高的系统——比如支付、模型推理这类不能放过任何一次失败场景的服务。

强制采样

强制采样（Mandatory Sampling）是一刀切里的“豁免条款”：某些请求无论概率采样怎么抽、尾部采样怎么打分，永远被保留。就像城市中心的金库、幼儿园、危险品仓库——这些点位不分昼夜、不管有没有事件，24 小时录像一刻不停，因为一旦出事，代价是不可承受的。

在业务代码里，强制采样通常以“预先规则”的方式实现：比如请求路径包含 /api/v1/payment、请求用户 ID 属于白名单、请求带有 X-Force-Sample: true 标记，或者请求来自安全审计系统——只要命中规则，直接跳过采样逻辑，百分之百保存。这不需要复杂的加权计算，只是一个简单的 if 判断，但它在整个采样体系里的位置非常特殊：它是“底线保障”。

强制采样的代价是它打破了成本预算——你必须为这部分请求预留额外的存储空间，不能简单用概率来算总账。它的使用原则是：高价值、低频、必须可审计。比如一笔资金交易可能只占请求总量的 0.01%，但每一笔都要能回溯；比如 AI 系统里触发安全审核的 prompt 虽然极少，但影响重大。把全量保存储在这些“关键点”上，成本可控，收益巨大。

选型实践

面对这五种策略，怎么选？答案是：没有最优策略，只有最优组合。实际生产环境中，很少只用一种策略，而是像布控城市监控一样，把多种方案组合覆盖不同场景。一个典型的组合是这样设计的。

先算第一笔账：每天能承受多少追踪存储量？假设你的预算只够存每天 100GB，根据前面公式反推，就能确定一个基线采样率——比如整体采样率 3%。这是“概率采样”的舞台：它保证基础数据覆盖，用于宏观趋势分析和容量规划。然后加一层“尾部采样”：所有错误 Trace 不参与概率抽取，直接进入保存队列——这保证了你永远能查到错误现场。再设几组“强制采样”规则：订单支付、模型推理超时、安全风控命中这些关键路径，无论概率如何，全量保存。最后，如果某个新上线的服务还不太稳定，可以在入口处临时提高“头部采样”的保留比例，比如从 3% 临时调整到 20%，等功能稳定之后再降回来。

选型实践中还有一条容易踩的坑：多服务协商一致。如果网关按哈希取模决定保留，但订单服务又按自己的规则再筛一遍，就会出现“网关注定要存、下游没存”的半截 Trace——数据支离破碎。所以采样策略必须沿全链路统一传播决策标记，要么所有服务共用同一个哈希逻辑，要么像头部采样那样显式传递标记，绝不能各干各的。

AI 应用场景

Python 演示

import hashlibimport randomimport time  class TraceSampler:    """Trace 采样决策器：概率采样 + 尾部感知兜底"""     def __init__(self, base_rate=0.01, force_save_code=500):        self.base_rate = base_rate        self.force_save_code = force_save_code        self.sampled_count = 0        self.kept_count = 0     def hash_sample(self, trace_id):        """标准概率采样：稳定哈希 + 阈值比较"""        h = int(hashlib.md5(trace_id.encode()).hexdigest()[:8], 16)        threshold = int(self.base_rate * 10000)        return (h % 10000) < threshold     def should_save(self, trace_id, status_code, latency):        """最终决策：错误优先 + 慢请求兜底"""        # 尾部兜底：错误或高延迟一律保存        if status_code >= self.force_save_code or latency > 2000:            return True        # 默认按概率采样        return self.hash_sample(trace_id)     def simulate(self, total=10000):        random.seed(42)        start = time.time()        for i in range(total):            trace_id = f"trace-{i}-{random.randint(1, 100000)}"            status_code = random.choices(                [200, 500], weights=[98, 2]            )[0]            latency = random.gauss(500, 200)            self.sampled_count += 1            if self.should_save(trace_id, status_code, latency):                self.kept_count += 1        elapsed = time.time() - start        print(f"总请求数: {self.sampled_count}")        print(f"保存数: {self.kept_count}")        print(f"采样率: {self.kept_count / self.sampled_count:.2%}")        print(f"模拟耗时: {elapsed:.4f}s")  if __name__ == "__main__":    sampler = TraceSampler(base_rate=0.01)    sampler.simulate()

1. h = int(hashlib.md5(trace_id.encode()).hexdigest()[:8], 16)对 TraceID 做哈希并截取前 8 位十六进制转成整数，保证同一 TraceID 在不同服务中得到一致结果。
2. threshold = int(self.base_rate * 10000)把采样率换算成 0-9999 的阈值，便于后面用取模结果比较。
3. return (h % 10000) < threshold对哈希值取模 10000 后与阈值比较，桶号小于阈值则保留。
4. if status_code >= self.force_save_code or latency > 2000:尾部兜底逻辑：状态码 500 或耗时超 2 秒的请求，无论概率多大都保存。
5. random.choices([200, 500], weights=[98, 2])[0]模拟 2% 的错误率，让样本中出现足够的错误请求来体现尾部兜底的价值。

常见误区

面试题