第 11 章：采样改变的是观察，不是业务事实

11.1 从两个确定端点开始

本书使用 parent-based trace ID ratio sampler，默认比例 1.0。验收完成常规场景后，停止自己启动的 Java 子进程，再以 SAMPLER_RATIO=0 启动同一程序，保留 Redis、RocketMQ 与遥测后端运行。新的根请求不记录 trace，消费者继承未采样标志，但业务仍然应当完成。

采样为零阶段保存响应、消费者事件、Tempo HTTP 状态和指标查询。它要求 worker.processed 确实出现，并标记 sampled=false；Tempo 查询返回 404，而请求指标仍可见。这个组合比单独展示一张空白追踪界面更能说明采样的作用。

没有采用 0.1 比例来证明“恰好保留十分之一”，因为短时间、少量请求中比例会波动。确定的 1 与 0 先验证策略连接，统计采样效果则需要更大样本与误差分析。

11.2 继承策略意味着怎样的控制边界

parent-based 策略尊重已有上下文的采样决定，避免同一 trace 中各段随意割裂。但这也意味着入口接受外部上下文时，需要考虑谁能够影响采样。对不可信调用方，生产网关可能要新建内部 trace 并通过 link 关联，或实施明确的采样配额。不能一边完全继承外部标志，一边假设内部成本始终由自己控制。

头部采样在工作开始前决定，无法根据后来出现的错误自动保留一个此前没有记录的完整 trace。尾部采样则需要在 Collector 等位置观察更多 span 后再选择，代价是更多内存、等待时间，以及同一 trace 汇聚到合适决策位置的路由要求。

本实验没有启用尾部采样，也没有验证多 Collector 的 trace 分片。因此本章将尾采样作为设计推导，不把本地配置中的 batch 误称为已经完成尾采样。

11.3 三种信号不应强行保持同一保留率

HTTP 计数器表达全部被仪表化请求的累计事件，通常不应该跟着 trace 采样一起按比例丢弃。日志也有独立保留与限速策略。于是你可能看见一个错误日志，日志有 trace ID，但追踪后台没有对应内容；排查工具应该给出合理解释，而不是把它标成不可能状态。

Exemplar 也依赖可关联的观察上下文，不能保证每个桶变化都有一个可查询 trace。设计跳转时，需要同时处理缺失、过期与访问权限。一个能优雅说明数据边界的界面，比永远显示“加载失败”更有用。

练习。 维护者希望“只保存出错请求的完整 trace”，却只在入口把 ratio 设为 1%。解释为什么这个设置无法保证目标，再列出尾部采样需要新增的两项容量或路由约束。

采样与上下文的官方概念可从 OpenTelemetry Java 文档继续核对；实验实际 sampler 配置以 Telemetry.java 为准。