Dapper - Google Tracing System

查看原文

这篇论文介绍了 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工具。