链路追踪-Google-Dapper论文翻译总结

关于物理链路追踪，出名的有阿里的鹰眼，Twitter的zip-kin等，这些追踪的工具都是建立在Google的一篇Dapper论文的基础上，这篇论文可以说是指明了链路追踪设计的指导方针和设计原则（https://ai.google/research/pubs/pub36356）。所以楼主写了此篇博文对这篇博文进行总结。

一、两个基本需求

• 无处不在的部署:
  无处不在很重要，如果系统的一小部分没有被监视，就会受到影响
• 连续监测:
  因为通常情况下，不寻常或其他值得注意的系统行为很难或不可能重现

最终形成三个具体的设计目标

二、三个设计目标

• 低开销：跟踪系统对运行服务的性能影响应该可以忽略不计。在一些高度优化的服务中，即使很小的监视开销也很容易被发现，并且可能迫使部署团队弃用跟踪系统，Dapper的消耗时间在200纳秒左右。
• 应用程序级透明度：应用程序的开发人员不需要知道追踪系统，依赖于开发人员的基础设施经常是会变的极其脆弱
• 可伸缩性，需要能支持公司未来几年内的服务数量
  
  如上图所示，在架构的最上端是应用集群，每台机器中都有一个带鹰眼埋点，该中间件负责向日志文件中写入数据，每台机器上的数据收集agent从日志文件读取数据，实现实时收集日志；在鹰眼系统中通过实时处理集群对实时日志进行计算分析，得到两种类型的数据，分别是统计类型的报表（存放在HBase中）和调用链调用明细详情（存放在HiStore中）；另外，涉及到离线数据分析的数据使用ODPS离线分析集群进行计算，主要是一些模型建设方面的分析。关于鹰眼的介绍，楼主也是参考了如下被转载的文章：分布式调用跟踪与监控实战

三、详细实施办法

• 1、记录rpc调用的开始时间和结束时间：只有记录了时间才知道每个rpc调用所消耗的时间
• 2、记录消费方调用服务的id：如果想知道完整的调用顺序的调用链，必须知道调用的前后关系。
• 3、每调用一层rpc，添加一个深度级别：有时候服务多次调用，光用id是不行的，这时候深度级别是可以鉴别调用链关系的字段
• 4、有一个全局唯一的TraceId：用来定位追踪
• 5、不仅要追踪访问了的服务，还要在返回端打印追踪情况情况，记录是否返回。
• 6、不同主机时间不完全相等：在一个rpc调用中，不能根据时间判断调用顺序，不同主机的时间不是一样的，在rpc调用中，2，3ms的影响就很明显。
• 7、对于部分直接进行TCP或者SOAP连接的服务，支持手动代码添加
• 8、写磁盘是非常昂贵的消耗，通过异步合并多个日志文件写操作并异步执行。经测量Dapper的cpu使用率不到0.3%，数据收集的网络流量占用不到0.01%。将cpu的轮转优先级调到最低。
• 9、为了避免追踪代码影响应用的逻辑，怎么进行测试，是一个非常值得重视的问题。

四、鹰眼

在鹰眼平台中，通过顺序编号的方式表示服务间的顺序关系，采用如1.1、1.2.1多级嵌套编号的方式体现服务的调用顺序与调用关系，下图中的数字就是rpcId的示意，鹰眼平台正是通过RPCID还愿一次请求过程中各服务的调用关系。

鹰眼的埋点日志中包含如下信息：

• TraceId,RPCID、开始时间、调用类型、对端IP
• 处理耗时
• 处理结果（ResultCode）
• 数据传输量：请求大小/响应大小
  对于打印日志带来的影响非常敏感的服务，如大促秒杀，就只收集记录其中很小一部分日志的方式。

这段引用自阿里巴巴中台实战架构

五、其他

在Google的Dapper中，链路追踪还提供了统计，校验等功能，但这些应该不是链路追踪所必须的，上面的基础功能先进行实现是最为重要的。