本文目录导读：
Zipkin 追踪的采样率，直接回答如下：
核心答案： Zipkin 默认的采样率通常是 001（即 0.1%），意味着每 1000 个请求中只有 1 个会被采样并发送到 Zipkin。
但这个值可以通过配置灵活调整,具体取决于你使用的客户端库（如 Brave、Sleuth、OpenTelemetry 等）。
常用框架的采样率配置方式
1 Spring Cloud Sleuth（已迁移至 Micrometer Tracing）
spring.sleuth.sampler.probability=1.0 # 采样率，1.0 = 100%
0：从不采样5：50% 采样（生产环境常用）0：100% 采样（仅适合低流量测试）
2 OpenTelemetry（官方推荐的新标准）
OTEL_TRACES_SAMPLER=parentbased_always_on # 总是采集 OTEL_TRACES_SAMPLER=parentbased_traceidratio OTEL_TRACES_SAMPLER_ARG=0.1 # 10% 采样
或者通过代码设置：
SdkTracerProvider.builder()
.setSampler(Sampler.traceIdRatioBased(0.1))
.build();
3 Brave（Zipkin 原生 Java 客户端）
Tracing tracing = Tracing.newBuilder()
.sampler(Sampler.create(0.1f)) // 10% 采样
.build();
采样策略分类
| 策略类型 | 说明 | 适合场景 |
|---|---|---|
| 固定概率采样 | 按百分比随机采样（最常见） | 通用场景 |
| 速率限制采样 | 限制每秒采集的 Span 数量 | 高并发必须限流 |
| 自定义采样 | 根据请求路径、Header、参数等动态决定 | 业务精细化 |
| 强制采样 | 对特定请求标记为“必须采集” | 问题排查，调试 |
生产中如何设置合适的采样率？
黄金建议
- 开发/测试环境：100%（
0），能看到完整流程 - 低流量生产（<100 req/s）：10% ~ 100%
- 高流量生产（>1000 req/s）：1% ~ 1%（太多数据会撑爆存储或浪费网络 IO）
- 极端高并发（电商大促、秒杀）：可以设
01%甚至更低，配合自适应采样（如 Head-Based 采样）
采样率越低,Zipkin Collector 和 Elasticsearch 负载越低，但问题定位时可能需要更多的重试才能捕获到异常 Span。
配合“强制采样”做问题定位
在业务逻辑中,如果检测到错误或慢调用，可以强制该条链路采样（忽略采样率），
Span span = tracer.nextSpan().name("critical").start();
span.tag("error", "true");
span.finish(); // 即使采样率 1%，此 span 依然上报
采样率带来的影响
| 采样率 | 存储成本 | 网络开销 | 定位问题能力 |
|---|---|---|---|
| 100% | 极高 | 高 | 完美 |
| 10% | 中等 | 中等 | 较好 |
| 1% | 极低 | 低 | 需要多次尝试 |
常见注意事项
- 采样率是概率性的：低采样率下，链路上游被采样、下游可能不被采样（Zipkin 会根据
traceId一致性自动处理，但仍可能丢失部分 Span）。 - 不要只依赖采样率做容量预估：建议限流 + 采样双重控制。
- 若是全链路采样（如 Istio + Zipkin）：链路越长，Span 数量越多，采样率需更低。
- 使用“自适应采样”（Adaptive Sampling）：如 Sentinel 或阿里开源的 Tracer 支持根据流量动态调整采样率，高流量自动降低、低流量自动升高。
总结一句话
生产环境推荐采样率：0.1% ~ 1%，100% 仅适合测试环境，高并发务必配合限流，若需要精准定位，可采用强制采样标记关键错误请求。
如果你能补充具体的框架（Java, Go, Node）或版本，我可以给出更精确的配置示例。
