本文定位：面向已经接入 Trace 或准备建设可观测性平台的团队，重点讨论链路追踪采样策略、尾采样边界和成本控制，不给固定采样比例承诺。
链路追踪采样的难点，不是把比例从 100% 改成 10%，而是决定哪些 Trace 必须保留、哪些可以丢弃、采样放在哪一层做，以及成本升高时该牺牲什么。采样策略如果只看比例，往往会丢掉最需要排查的异常链路。
OpenTelemetry 将 sampling 描述为减少收集和发送 traces 数量的机制，并区分 head sampling 与 tail sampling，见 OpenTelemetry Sampling。因此，采样设计应先区分“决策发生在请求开始前，还是请求结束后”。
如果需要先了解 Collector 管道，可参考站内 OpenTelemetry Collector管道部署-采样路由与故障降级；本文聚焦采样策略本身。
图1：链路追踪采样策略数据流与排障根因映射图，展示头采样、尾采
头采样和尾采样解决的问题不同
头采样在 Trace 开始时决定是否采集，成本低、实现简单，但不知道这个请求最终是否慢、是否报错。尾采样会等完整 Trace 到达后再判断保留，能更好保留错误和慢请求，但需要在 Collector 或后端前缓冲并做策略计算。
| 采样方式 | 决策时间 | 适合场景 | 主要代价 |
|---|---|---|---|
| 头采样 | 请求开始时 | 流量大、成本敏感、策略简单 | 可能提前丢掉关键异常 Trace |
| 尾采样 | 请求结束后 | 需要保留错误、慢请求、关键业务路径 | Collector 缓冲、内存和策略复杂度更高 |
| 分层采样 | SDK 与 Collector 都参与 | 多团队、多租户、核心链路分级 | 需要避免策略叠加导致过度丢弃 |
不要把尾采样理解成万能补救。如果上游 SDK 已经把 Trace 丢掉，Collector 侧尾采样无法再恢复它。
先定义保留优先级，再谈比例
固定采样比例很容易误导。一个低流量核心服务可能需要更高保留率；一个高流量低风险接口可能只保留异常 Trace。采样策略应围绕排障价值定义。
优先保留的 Trace 通常包括：
- 错误 Trace：HTTP 5xx、RPC error、异常状态码和业务错误。
- 慢 Trace：超过 SLO 或历史基线的请求。
- 关键路径：登录、支付、下单、任务提交、模型推理等核心业务。
- 变更窗口：发布、扩容、迁移、故障恢复期间的请求。
- 告警关联：与重要告警同时间段、同服务、同租户的 Trace。
如果预算有限，优先保留能解释故障的 Trace，而不是平均保留每个接口的一小部分样本。
采样策略要避免多层叠加
应用 SDK、Sidecar、Collector Gateway 和 Trace 后端都可能配置采样。如果多层各自丢弃数据，最终保留率会比预期低很多。平台应规定采样主控位置，例如 SDK 只做轻量头采样，Collector 负责尾采样和路由。
尾采样成本边界在哪里
尾采样的优势来自“看完整 Trace 后再决定”。它也因此需要在一段时间内缓存 span，等待 Trace 完整。OpenTelemetry Collector 的 tail sampling processor 需要根据等待时间、策略和缓存容量做配置，具体能力以 tail sampling processor 官方说明 为准。
尾采样成本主要来自：
- Collector 内存：需要暂存未决策的 Trace。
- CPU：需要执行策略匹配、属性判断和组合规则。
- 延迟：Trace 写入后端前需要等待完整性窗口。
- 丢弃风险：高峰期缓存不足时可能先丢数据。
- 运维复杂度：策略不透明会增加排障难度。
等待窗口不是越长越好
等待窗口太短，可能还没收到完整 Trace 就做出决策；等待窗口太长，则会提高内存占用和导出延迟。合理窗口要结合请求最长耗时、异步链路特征和 Collector 容量测试决定。
图2：链路追踪尾采样容量边界图，展示等待窗口、策略计算、内存队
成本控制要覆盖采集、传输、存储和查询
Trace 成本不只发生在存储后端。SDK 上报、Collector 处理、网络传输、后端写入和查询索引都会产生开销。
| 成本环节 | 常见问题 | 控制手段 |
|---|---|---|
| 采集 | 所有请求全量上报 | SDK 轻量头采样、关键服务白名单 |
| 处理 | Collector 队列和内存上涨 | batch、memory limiter、尾采样容量规划 |
| 传输 | 跨集群、跨地域导出过多 | 就近汇聚、分环境路由 |
| 存储 | Span 体积大、保留期过长 | 字段裁剪、分层保留 |
| 查询 | 大范围 Trace 查询拖慢后端 | 索引字段治理、按服务和时间窗口查询 |
OpenTelemetry Collector 提供 memory_limiter、batch 等 processor，用于在管道中管理资源和批处理，配置需参考 OpenTelemetry Collector Configuration 并结合实际容量压测。
关键结论是：采样只是成本治理的一环。只调采样比例，不治理字段、保留周期和查询方式，Trace 成本仍可能失控。
一个实用的链路追踪采样设计顺序
采样策略可以按“问题优先级”倒推，而不是从工具参数开始。
建议顺序：
- 列出必须排查的关键业务路径和核心服务。
- 定义错误、慢请求、变更窗口和告警关联的保留规则。
- 决定采样主控位置：SDK、Agent、Gateway 或后端。
- 对高流量低风险接口设置更严格采样。
- 为 Collector 设置容量、队列、内存和降级告警。
- 定期抽查故障复盘中是否缺关键 Trace。
采样策略要能被复盘验证
如果一次故障发生后，团队发现关键 Trace 没有保留下来，不应只临时提高采样比例。更应该复盘：是错误标记缺失、关键路径未加入白名单、尾采样等待窗口太短，还是 Collector 容量不足导致丢弃。
图3：链路追踪采样策略设计与复盘验证图，从关键路径、保留规则、
小结
链路追踪采样要解决的是诊断价值和成本边界的平衡。头采样适合早期降低数据量，尾采样适合保留错误、慢请求和关键路径，但会引入 Collector 缓冲、内存和策略复杂度。
更稳妥的做法是先定义保留优先级，再确定采样位置和容量边界，最后用故障复盘验证采样策略是否真的留下了有用 Trace。
原创声明：本文为 CNBPA 云原生社区原创技术内容，非商业转载须注明出处：https://www.cloudnative-tech.com/p/9362/。文中原创图示、架构图和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
参考资料
- OpenTelemetry Sampling
- OpenTelemetry Collector tail sampling processor
- OpenTelemetry Collector Configuration
常见问题
1. 链路追踪采样比例应该设置多少？
没有通用比例。应按服务流量、故障排查需求、存储预算和关键路径重要性决定。固定比例只能作为初始值，不能替代错误 Trace、慢 Trace 和关键路径保留规则。
2. 尾采样一定比头采样好吗？
不一定。尾采样能保留更有诊断价值的 Trace，但需要更多 Collector 资源和策略维护。低流量或简单系统可以先用头采样；复杂系统再引入尾采样治理关键链路。
3. SDK 和 Collector 能同时采样吗？
可以，但要明确主控位置。若 SDK 已经大量丢弃 Trace，Collector 尾采样无法恢复。通常建议 SDK 做轻量控制，Collector 负责更复杂的尾采样和路由策略。
4. 如何判断采样策略是否过度？
看故障复盘时是否经常缺少关键 Trace、错误请求是否没有样本、慢请求是否无法还原调用路径。如果这些问题频繁出现，说明采样策略需要按保留优先级调整，而不是只看总体数据量。
