案例库 · 工程与运营 · 技术决策 · 2008–2010
谷歌的Dapper：用采样追踪一次请求跨数千台机器的过程
Dapper为每个Google请求分配一个跟踪ID，在服务间传递，然后对跟踪记录进行低成本采样，将延迟排查的猜测变成监控平台。
解法
一次谷歌搜索或请求可能扩展到数千台机器、数十个服务和多个数据中心，因此从单机日志几乎无法解释缓慢响应。虽然有研究工具（如Magpie、X-Trace），但没有一个能满足谷歌对低开销和普遍部署的需求。
Dapper的设计让追踪几乎零成本：跟踪ID和跨度ID在RPC元数据中传递，几个通用库完成插桩（应用无需修改），采样策略只记录一小部分跟踪——默认约为1/1024。结果是在大规模下实现了透明的应用追踪。
经过两年的生产运行，Dapper从调试工具演变为监控平台：团队用它发现延迟异常、测量依赖关系、优化存储和搜索路径。其理念直接启发了开源后续者如Zipkin和Jaeger，它们把相同的方法推广到了整个行业。
生效的原因
- 采样在谷歌规模下保持开销可忽略不计
- RPC元数据中的跨度ID使追踪对应用透明
- 树形重组展示完整调用路径而非单台服务器
- 追踪数据成为新监控工具的平台
取得的成效跟踪ID伴随RPC传递；采样跟踪以保持低成本聪明
可借鉴之处
要调试一个太大难以观察的系统，可以观察统计样本并降低识别成本：在每个RPC中携带跟踪ID，就能把分布式延迟变成可查询的树。
后续进展
Dapper的设计成为分布式追踪的蓝图——Zipkin和Jaeger基于其理念构建，并成为CNCF标准。如今，追踪是现代云系统可观测性的核心支柱。
资料来源
- Dapper, a Large-Scale Distributed Systems Tracing Infrastructure
- Dapper, a Large-Scale Distributed Systems Tracing Infrastructure (paper PDF)
发现哪里写错了？告诉我们。