[说明:本文是阅读Google论文“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”之后的一个简要总结,完整译文可参考此处。 另论文“Uncertainty in Aggregate Estimates from Sampled Distributed Traces”中有关于采样的更详细分析。此外,Twitter开源的Zipkin就是参考Google Dapper而开发。]
Dapper最初是为了追踪在线服务系统的请求处理过程。比如在搜索系统中,用户的一个请求在系统中会经过多个子系统的处理,而且这些处理是发生在不同机器甚至是不同集群上的,当请求处理发生异常时,需要快速发现问题,并准确定位到是哪个环节出了问题,这是非常重要的,Dapper就是为了解决这样的问题。
对系统行为进行跟踪必须是持续进行的,因为异常的发生是无法预料的,而且可能是难以重现的。同时跟踪需要是无所不在,遍布各处的,否则可能会遗漏某些重要的点。基于此Dapper有如下三个最重要的设计目标:低的额外开销,对应用的透明性,可扩展。同时产生的跟踪数据需要可以被快速分析,这样可以帮助用户实时获取在线服务状态。
实现方法
低的额外开销:不是对所有的请求进行跟踪而是要采样,收集跟踪数据时进行二次采样
对应用的透明性:修改多线程,控制流,RPC等基础库代码,插入负责跟踪的代码。在Google,应用使用的是相同的多线程,控制流,RPC等基础库代码,所以仅通过修改它们就可以实现跟踪功能。当线程进行一个被跟踪的处理时,Dapper会将一个trace context关联到线程本地化存储中。trace context中包含了span相关属性,比如trace和span id。对于需要进行异步处理的情况,Google开发者通常都会采用一个通用的控制流库来实现回调,并将它们调度到一个线程池或是执行器中调用。Dapper保证所有回调都会保存它们创建者的trace context,同时在该回调被调用时该trace context也会被关联到对应线程。这样,Dapper就可以实现这种异步处理过程的跟踪。对于被跟踪的RPC调用,span和trace id也会跟着被从客户端传到服务端。从功能上看这部分代码主要包括span的创建,采样,本地磁盘日志写入,但是因为它会被很多应用所依赖,维护和bug fix难度高,需要非常高的稳定性和健壮性。同时还要轻量,实际上这部分代码的C++实现也总共不到1000行。
Dapper支持用户直接获取Tracer对象,并输出自己的自定义信息,用户可以输出自己任意想输出的内容,为防止用户过度输出,提供用户可配置参数来控制其上限。
跟踪时需要对请求进行标记,会产生一个唯一ID(在Dapper中是一个64位整数)用来标识该请求。对于Dapper来说,一个trace(跟踪过程)实际上是一颗树,树中的节点被称为一个span,根节点被称为root span。如下图所述:
![](https://i-blog.csdnimg.cn/blog_migrate/05439b171339c7973afb7c3053698a8d.png)
需要注意的是一个span可能包含来自多个主机的信息;实际上每个RPC span包含了来自客户端和服务端的信息。但是客户端和服务端的时钟是有偏差的,文中并未指明如何解决这个问题,只是说可以利用如下事实"RPC的发起客户端是在服务端接收到前进行地,针对该RPC的响应则是由服务端在客户端收到前发出的",确定时间戳的一个上下界。
![](https://i-blog.csdnimg.cn/blog_migrate/1e4a1292879e8f03bf434c601ab5c126.png)
Dapper的整个数据收集过程如下图所示:首先将span数据写入本地日志文件,然后将数据收集并写入Bigtable,每个trace记录将会被作为表中的一行,Bigtable的稀疏表结构非常适合存储trace记录,因为每条记录可能有任意个的span。整个收集过程是out-of-band的,与请求处理是完全不相干的两个独立过程,这样就不会影响到请求的处理。如果改成in-band的,即将trace数据与RPC响应报文一块发送回来,会影响到应用的网络状况,同时RPC调用也有可能不是完美嵌套的,某些RPC调用可能会在它本身依赖的那些返回前就提前返回了。
![](https://i-blog.csdnimg.cn/blog_migrate/7711684ebb3e33ed338adac7319a0e76.png)
Dapper提供API允许用户直接访问这些跟踪数据。Google内部开发人员可以基于这些API开发通用的或者面向具体应用的分析工具。这一点,对于提高Dapper的作用和影响力起到了出人意料的效果。
跟踪开销
如果跟踪带来的额外开销太高,用户通常会选择关掉它,因此低开销非常重要。采样可以降低开销,但是简单的采样可能导致采样结果无代表性,Dapper通过采用自适应的采样机制来满足性能和代表性两方面的需求。
trace的生成开销对Dapper来说是最关键的,因为数据的收集和分析可以临时关掉,只要数据一直生成就可以后面再进行收集分析。在trace生成中,最大头的地方在于span和annotation的创建和销毁上。根span的创建和销毁平均需要204ns,普通span只需要176ns,区别在于根span需要产生一个全局唯一的trace id。如果span没有被采样到,那么对它添加annotation的开销基本可忽略,大概需要9ns。但是如果是被采样到的话,那么平均开销是40ns。这些测试是在一个2.2GHZ的x86服务器上进行的。本地磁盘写入是Dapper运行库中最昂贵的操作,但是它们可以异步化,批量化,因此它们基本上只会影响到那些高吞吐率的应用。
将跟踪数据通过Dapper后台进程读出也会产生一些开销。但是根据我们的观察,Dapper daemon的CPU开销始终在0.3%之下,内存占用也很少,此外也会带来轻量的网络开销,但是每个span平均只有426字节大小,网络开销只占了整个产品系统流量的0.01%不到。
对于那些每个请求都可能产生大量跟踪数据的应用来说,我们还会通过采样来降低开销。我们通过保证跟踪开销可以始终保持在很低的水平上,使得用户可以放心大胆的使用它。最初我们的采样策略很简单,是在每1024个请求中选择一个进行跟踪,这种模式对于那种请求量很高的服务来说,可以保证跟踪到有价值的信息,但是对于那些负载不高的服务来说,可能会导致采样频率过低,从而遗漏重要信息。因此我们决定以时间为采样单位,保证单位时间内可以进行固定次数的采样,这样采样频率和开销都更好控制了。
应用
用户可以通过DAPI(Dapper“Depot API”)直接访问跟踪数据。DAPI提供如下几种访问方式:指定trace id进行访问;大规模批量访问,用户可以通过MapReduce job并行访问,用户只需要实现一个以Dapper trace为参数的虚函数,在该函数内完成自己的处理即可,框架负责为用户指定时间段内的所有trace调用该函数;通过索引进行访问,Dapper会为跟踪数据建立索引,用户可通过索引进行查询,因为trace id是随机生成的,因此用户通常需要通过服务名或机器名进行检索(实际上Dapper是按照(服务名,机器名,时间戳)进行索引的)。
大部分用户都是通过一个交互式web接口来使用Dapper的,典型流程如下图所示:
![](https://i-blog.csdnimg.cn/blog_migrate/b80f693f3da5f68cbe774b5444203852.png)
1.用户输入他感兴趣的服务和时间窗口,选择相应跟踪模式(这里是span名称),以及他最关心的某个度量参数(这里是服务延迟)
2.页面上会展示一个指定服务的所有分布式执行过程的性能摘要,用户可能会对这些执行过程根据需要进行排序,然后选择一个详细看
3.一旦用户选定了某个执行过程后,将会有一个关于该执行过程的图形化描述展现出来,用户可以点击选择自己关心的那个过程
4.系统根据用户在1中选择的度量参数,以及3中选择的具体过程,显示一个直方图。在这里显示的是有关getdocs的延迟分布的直方图,用户可以点击右侧的example,选择具体的一个执行过程进行查看
5.显示关于该执行过程的具体信息,上方是一个时间轴,下方用户可以进行展开或折叠,查看该执行过程各个组成部分的开销,其中绿色代表处理时间,蓝色代表花在网络上的时间。
经验教训
在开发过程中使用Dapper,可以帮助用户提高性能(分析请求延迟,发现关键路径上不必要的串行化),进行正确性检查(用户请求是否正确发送给了服务提供者),理解系统(请求处理可能依赖很多其他系统,Dapper帮助用户了解总体延迟,重新设计最小化依赖),测试(新代码release前要通过一个Dapper跟踪测试,验证系统行为和性能)。比如,通过使用Dapper,Ads Review团队将延迟降低了两个数量级。
同时我们还将跟踪系统与异常监控系统进行集成,如果异常发生在一个采样到的Dapper tracer上下文中,那么相应的trace和span id还会被作为异常报告的元数据,前端的异常监控服务还会提供相应链接指向跟踪系统。这样可以帮助用户了解异常发生时的情况。
解决长尾延迟,帮助用户分析复杂系统环境下的延迟问题。网络性能的瞬时下降不会影响系统的吞吐率,但是对延迟有很大影响。很多开销昂贵的查询模式是由于未预料到的服务间的交互造成的,Dapper的出现使得这种问题的发现变得非常容易。
帮助用户进行服务间依赖的推理。Google维护了非常多的集群,每个集群上承载了各种各样的任务,而任务间可能存在依赖关系。但是各个任务需要精确知道它所依赖的服务信息,以帮助发现瓶颈或进行服务的移动。服务间的依赖是复杂的而且是动态的,单纯依赖配置文件很难判断。但是通过使用Dapper的trace信息和DAPI MapReduce接口可以自动化的确定服务间依赖关系。
帮助网络管理员对跨集群的网络活动进行应用层的分析。帮助发现某些昂贵的网络请求开销的产生原因。
很多存储系统都是共享的。比如GFS,会有很多用户,有的可能是直接访问GFS,有的可能是比如通过Bigtable产生对GFS的访问,如果没有Dapper,对这种共享式系统将会很难调试,通过Dapper提供的数据,共享服务的owner可以方便的对用户根据各项指标(比如网络负载,请求耗时)进行排序。
救火。但是不是所有的救火,都可以使用Dapper来完成。比如,那些正在救火的Dapper用户需要访问最新的数据,但是他可能根本没有时间写一个新的DAPI代码或者等待周期性报告的产生。对于那些正在经历高延迟的服务,Dapper的用户接口并不适于用来快速定位延迟瓶颈。但是可以直接与Dapper daemon进行交互,通过它可以很容易地收集最新数据。在发生灾难性的故障时,通常没有必要去看统计结果,单个例子就可以说明问题。但是对于那些共享存储服务来说,信息聚合会很重要。对于共享服务来说,Dapper的聚合信息可以用来做事后分析。但是如果这些信息的聚合无法在问题爆发后的10分钟之内完成,那么它的作用将会大大削弱,因此对于共享服务来说,Dapper在救火时的效果没有想象中的那么好。
通过开放跟踪数据给用户,激发了用户创造力,产生了很多意料之外的应用。那些没有跟踪功能的应用只需要用新的库重新编译下它们的程序,就获得了跟踪功能,迁移非常方便。
但是还存在如下一些需要改进的地方:
合并产生的影响。我们通常假设各种子系统会一次处理一个请求。但是某些情况下,请求会被缓存,然后一次性地在一组请求上执行某个操作(比如磁盘写入)。在这种情况下,被追踪的请求拿到的实际上并不是它本身的处理过程。
对批量处理进行跟踪。虽然Dapper是为在线服务系统而设计,最初是为了理解用户发送请求给Google后产生的一系列系统行为。但是离线的数据处理实际上也有这样的需求。在这种情况下,我们可以将trace id与某些有意义的工作单元进行关联,比如输入数据里的一个key(或者是一个key range)。
寻找根本原因。Dapper可以迅速找到系统短板,但是在寻找根本原因时并不那么高效。比如某个请求变慢可能并不是因为它自己的原因,而是因为在它之前已经有很多请求在排队。用户可以在应用层将某些参数,比如队列大小交给跟踪系统。
记录内核级信息。我们有很多工具可以进行内核执行过程的跟踪和profiling,但是直接将内核级信息捆绑到一个应用层的trace context中很难优雅的实现。我们打算采用一种折中的解决方案,通过在应用层获取内核活动参数的快照,然后将它们与一个活动span关联起来。