查看原文

这篇论文介绍了 Google Tracing System 的架构和使用情况。Google 在 black-box 和 annotation 方案中选择了后者。它准确率更高，但也因海量数据引入维护复杂的问题。论文花了2/3的篇幅介绍系统的运行情况。Dapper 的维护团队说几乎所有的 Google 的生产环境的程序可能都植入了 Dapper。

• 这个系统使用一系列ID标记调用链，每个服务调用记录根节点ID，父节点ID，自身ID，主机，时间戳。用户请求是调用链的根节点。一次服务调用会有至少两次日志记录，开始+结束。
• 允许服务添加业务数据（注解）到日志（有个数限制）。
• 记开头的原因与服务器时间不同步有关。
• 追踪触发点：进程内的上下文有追踪容器，异步调用和同步调用使用两个公共的库，该两个库都保证异步调用上会带上追踪信息。
• 性能损耗：可以选择性地关停，或做采样。损耗非常低，不纳入采样 9 ns, 否则 40ns 左右。（因为写数据基本都是异步的）。尽管如此，某些场景还是有可能有影响。google 的访问量大到采样率设为 1/1024 都足够。还能根据流量大小自动浮动。
• 数据流：存储到本地，收集组件拉到Bigtable。数据到中央仓库会有2min到数小时时延不等。
• 数据量：还行，目测大概0.1k吧。每天记大约 1TB 数据。
• 数据安全：只记方法名，不记载荷数据；注解的内容会审核。
• 代码：2k lines，主要包括节点创建，采样，写日志。
• 访问方式：查特定的ID；MapReduce批量查时间窗口内ID的调用链；给节点建索引（主机，服务）地查。
• 他们有很多内部 WebUI工具。