OpenTelemetry 采样策略：让重要请求留下完整证据

背景

只做小比例入口采样，最想排查的错误请求也可能被丢掉。尾部采样可以根据已接收的 trace 内容决策，但需要付出缓存与等待成本。

核心判断

1. 错误、慢请求和基础概率策略分别配置，给普通请求保留代表性样本。
2. 同一 trace 的 spans 必须汇聚到同一尾采样实例。
3. 按请求速率与决策窗口估算内存，监控缓存压力和丢弃情况。

最小示例

下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。

processors:
  tail_sampling:
    decision_wait: 10s
    num_traces: 50000
    policies:
      - name: errors
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: slow
        type: latency
        latency:
          threshold_ms: 1000
      - name: baseline
        type: probabilistic
        probabilistic:
          sampling_percentage: 5

边界与误区

示例是 Collector contrib 的处理器片段，需接入 traces pipeline。入口已经丢弃的 spans 无法被尾采样恢复，决策窗口也不能保证迟到 span 完整保留。

验证方式

发送成功、ERROR 状态和高延迟三类 trace，核对实际留存比例。扩容 Collector 时检查 trace 分片和完整性，而不只看导出吞吐。

小结

基础比例采样之外，应优先保留错误、超时和高价值业务请求。