分布式追踪的采样策略如何选择？
简化版
Head Sampling 在入口早决策，成本低但看不到最终错误；Tail Sampling 先记录并汇聚候选 span，再按错误、长尾和业务属性决策，诊断价值高但需要缓存和容量。两者都应一致传播父上下文，并设置租户与总量预算；被 Head 提前丢弃的数据无法由 Tail 恢复。
详细版
Head 路径可在入口按 traceId 做确定性概率决策并传播 sampled 标志。Tail 路径则必须让 SDK/Agent 记录并导出候选 span，由 Collector 等待 Trace 完成后保留错误、超 SLO、稀有服务和关键业务，其余丢弃；超长或缺失 Trace 到窗口后必须决策，不能无限等待。
事故时动态提高相关服务采样，但保留硬上限和自动回落。监控 spans received/dropped、decision latency、incomplete traces、各规则命中和估算覆盖；审计类数据不用普通 Trace 采样代替。
完整版教学
一、为什么必须采样
10 万 RPS、每请求 20 个 span，每秒就是 200 万 span，全量传输和索引代价极高。采样是在预算内保留能解释系统行为的代表 Trace。
易错点：采样不是均匀删数据，而是保护错误、长尾与稀有路径的诊断覆盖。
二、Head Sampling
sample = hash(trace_id) / 2^64 < probability入口即可丢弃未采样 span，资源最省；使用 traceId 确定性决策能让服务共享结果。但入口不知道后面是否会超时或失败，低比例会漏稀有事故。
三、Tail Sampling
Collector 暂存同一 traceId 的 span，等待完成或超时，再按最终 status、duration 和属性选择。它能做到错误 100%、超过 2s 全量、健康 1%，但消耗内存并引入决策延迟。
| 维度 | Head | Tail |
|---|---|---|
| 决策时机 | 入口 | 链路结束后 |
| 成本 | 低 | 较高 |
| 看见结果 | 否 | 是 |
| 完整性 | 易传播一致 | 依赖汇聚完整 |
四、父级一致与链路碎片
子服务应尊重父 sampled 决策，否则上游保留、下游丢弃会产生残缺 Trace。Tail Sampling 场景可先记录候选 span，由集中决策；跨边界仍传播 trace context。
对不受信外部 header 要校验格式和重建采样策略，避免攻击者强制全量采样。
五、规则优先级与预算
先保安全和关键业务错误，再保长尾、稀有 route，最后对健康流量概率采样。规则重叠时定义优先级，并给每租户最大 spans/s，防止一个故障流量占满 Collector。
例如总预算 10 万 traces/min，错误突然超过预算时仍需限流、分层保留和计数，不能因“错误全量”拖垮观测系统。
六、验证偏差
采样会让 Trace 数量不能直接代表请求总量；比率应来自 Metrics，或按已知概率加权。Tail 条件采样更非均匀，不可简单乘 100 推算。
用历史事故回放，检查关键根因 Trace 是否被保留；线上监控未完成率、丢弃原因和 exemplar 链接命中。
Collector 内存应按同时等待的 Trace 数、平均 span 大小和等待窗口估算，并在超限时优先保留高价值规则。
采样策略版本写入遥测元数据，才能解释同一时间段不同区域为何保留率不同。
跨区域集中 Tail Sampling 还要计算出口带宽与数据驻留要求，不能只看存储端节省。
七、常见误区与追问
- 误区：固定 1% 能覆盖所有服务。 低流量与稀有错误可能完全缺失。
- 误区：Tail Sampling 没有代价。 它需要缓存、汇聚和超时决策。
- 误区：各服务独立采样更灵活。 会产生链路碎片。
- 误区：错误永远全量即可。 大事故时仍可能超过平台容量。
- 追问：超长 Trace 怎么办？ 设置等待窗口，超时按不完整规则决策。
- 追问：如何动态提采样？ 限定服务/规则、总预算和自动到期。
- 追问：采样后怎样算错误率？ 优先使用 Metrics，条件样本不能直接计数。
八、加强记忆
采样选择记住“Head 省成本但不知结果，Tail 知结果但要汇聚”。用父级一致传播保完整，以错误、长尾和稀有路径优先，以租户和总预算保平台；最后用丢弃指标与事故回放证明采样策略仍能支持诊断。