尾部采样是什么
尾部采样（tail sampling）先把一个 trace 的全部 span 缓存下来，等它「基本收齐」再决定保留还是丢弃：错误请求、慢请求全保留，其余按比例抽样。相比头部采样（请求一开始就决定），它能把最有价值的样本留住，代价是需要等待窗口与额外的内存与 CPU 资源。
基本信息
| 所在组件 | OpenTelemetry Collector（tail_sampling processor） |
|---|---|
| 决策时机 | trace 收齐后（decision_wait） |
| 常用策略 | status_code / latency / probabilistic / rate_limiting |
| 代价 | 等待窗口 + 缓存内存 |
| 部署要求 | 同一 trace 的 span 要落到同一实例 |
| 对比 | 头部采样决定早、成本低但可能丢关键样本 |
典型使用场景
- 高流量服务只保留错误与慢请求，降低存储成本同时保住排障样本
- 为关键业务链路设置更高的保留比例，普通链路降采样
- 用 rate_limiting 策略限制单位时间保留的 trace 总数
- 排查偶发问题：靠 status_code 策略确保异常样本不被抽掉
- 成本敏感环境中用概率策略做基线，再用规则策略补充关键样本
- 对比采样前后 trace 数量，评估存储与查询成本的改善
Collector 尾部采样策略示例
Collector 尾部采样策略示例
processors:
tail_sampling:
decision_wait: 10s # 等待 trace 收齐的时长
policies:
- name: errors
type: status_code
status_code: { status_codes: [ERROR] }
- name: slow
type: latency
latency: { threshold_ms: 500 }
- name: baseline
type: probabilistic
probabilistic: { sampling_percentage: 10 }常用策略
| 策略 | 依据 | 典型用途 |
|---|---|---|
| status_code | span 状态 | 保留所有错误请求 |
| latency | 耗时阈值 | 保留慢请求样本 |
| probabilistic | 百分比 | 基线降采样 |
| rate_limiting | 单位时间条数 | 限制保留总量 |
| string_attribute | 属性匹配 | 按业务标签定向保留 |
策略按序匹配：命中错误或慢请求即保留，其余落到基线比例，这是「保关键样本」最常用的组合。
尾部采样要求同一 trace 的 span 到达同一个 Collector 实例：多实例各自决策会让同一 trace 的 span 被拆分处理，需要按 trace_id 做负载均衡（如带 consistent hashing 的网关）。
decision_wait 太短会截断跨服务的慢 trace，太大会增加内存与延迟，应按实际调用链耗时分位数设置。
尾部采样会显著提高 Collector 的资源占用，部署前要评估内存上限，并把 memory_limiter 放在处理链前部。