分布式服务的Trace——Google Dapper & Twitter Zipkin

对于分布式在线服务,一个请求需要经过系统中多个模块,上百台机器的协作完成单次请求,典型场景就是Search Engine的一次用户检索,单靠人力无法掌握整个请求中各个阶段的性能开销,更无法快速的定位系统中性能瓶颈。Google Dapper文章描述了广泛用于Google内部服务的Trace Infrastruce—Dapper(原文地址见 这里, 译文地址见 这里 ),文章本身的很易懂,没有复杂、精巧的实现机制(好像也是g公司publish出来的文章的特点),有一些分布式在线服务经验的程序员都可以很好的理解(英文版),这里就只抽一些点出来记录。而Zipkin是Twitter开源出来的一个Trace系统组件,实现中就参考了Google Dapper,项目主页见http://twitter.github.io/zipkin/ 。

Google Dapper

目标: 无所不在的持续跟踪(ubiquitous deployment,and continuous monitoring),只有无所不在和持续,才能保证所有的问题都能被跟踪到,因为服务也是7*24的。为了做到这两点,Dapper对于这个Tracing组件,拆分出如下几个目标。

  • 低消耗(Low overhead): 分布式在线系统对于性能、资源要求都很严格,Trace组件必须对服务影响足够小,否则一定不会被启用。
  • 应用层透明(Application-Level Transparency): 应用层开发者不需要对Trace组件关心,Trace嵌入到基础通用库中,提供高稳定性,而如果Trace需要应用开发者配合,那可能会引入额外的bug导致Trace系统更加脆弱。
  • 扩展性(Scalability): Google的服务在线集群数量可想而知,一次检索就可能跨越上百台甚至成千台机器,因此这个Trace Infrastructure的扩展性也很重要。
  • 快速的数据分析(Analysis Quickly): 数据快速导出和分析,能够快速的定位系统的异常,及时应对,提升系统的稳定性。

典型检索场景: 单次user检索贯串前后端多个模块,模块之间使用rpc进行通信,如下图,request需要系统中由不同团队、不同语言构成的多个模块通信协作完成,典型的一个自上而下的调用序列。Dapper的采集方式基于这种调用序列构成的树,拆分为不同的span(一次rpc远程调用),通过全局唯一的Trace Id串起来,span指向自己的parent span。

image

Trace组件的实践经验:

  • 低采样率: 在保证数据误差的情况下,Dapper尽可能采用低的采样率来保证Trace的low overhead,一方面会给应用层自己的Annotation标记留出更多的性能空间,也可以在硬盘上保存更长时间的数据。
  • 带外数据收集(out-of-band): Trace组件将span信息落地到本机,使用守护进程进行带外收集,可以避免Trace数据占用检索带宽。同时,并不是所有的调用过程都是完美的嵌套(prefect nested),有些组件会在下游返回结果前先向上游汇报一些结果,不适合将Trace结果与检索数据绑定。
  • 数据隐私: Trace系统仅面向的是系统的性能开销诊断,考虑到隐私,Dapper只记录RPC的名称和性能开销,对于一些策略和业务数据,可以考虑使用类似Online Debug的系统实现,引入权限控制。
  • 精简的基础lib: Dapper基础代码库很精简,便于植入各个通用库,保证稳定性和性能开销,在大部分控制流的基础库上进行了默认植入,来记录各个span的开销,其中C++的代码实现不到1000行。
  • 控制Dapper数据采集守护进程的资源消耗: 机器上的一些例行任务,例如数据统计脚本运行、外部数据的自动更新等,也会对部署在机器上的进程产生性能影响。因此,Dapper守护进程的性能数据采集,对使用的网络、CPU都非常谨慎,Dapper守护进程为内核scheduler最低的优先级。
  • 开放API和易用的UI: 方便的DAPI来访问导入到Bigtable中的采集数据,其他使用方可以使用API来构建web应用、可执行的command等(根据经验,RESTFul是一个不错的选择),并且默认提供一个良好的UI,便于查询。

Twitter Zipkin

Zipkin的项目主页上说到——Zipkin is a distributed tracing system that helps us gather timing data for all the disparate services at Twitter. It manages both the collection and lookup of this data through a Collector and a Query service. We closely modelled Zipkin after the Google Dapper paper 。看Zipkin的Architecture文档,描述上也都实现了一些Dapper文章中核心的描述。

Zipkin Infrastructure

image

image

  • Trace数据的收集系统,使用了Facebook开源的Scribe作为日志传输通路,将不同service上的Trace数据传输到Zipkin/Hadoop。
  • Zipkin的Storage系统最先使用的是Cassandra,后来加入了Redis, HBase, MySQL, PostgreSQL, SQLite, and H2等存储系统的支持,猜测这个也是Twitter当时放弃Cassandra转回MySQL有关。
  • Twitter中广泛使用了一个叫做Finagle的Java Async RPC服务,将trace library嵌入到这个Finagle中就成为支持系统跟踪的一个自然而然的选项。这个Library也是基于Dapper文章中的几个概念(Annotation—包含host、时间戳的key/value;Span—一次特定的rpc调用,包含多个Annotation;Trace—由一组span组成,共享一个root span)。
  • Client和Server在通信时,会在tracing header信息中加上TraceId(标识整个trace)、SpanId(独立的RPC request)、可选的Parent SpanId(一个服务会调用多个下游RPC服务)以及Sample boolean变量(标识本次是否采集)。
  • 通过Thrift Api来提供数据的访问查询功能,并搭建自己的UI(基于Rails,使用了d3js)。

按照主页上描述,Server接收到Client请求后,解析Trace头的处理逻辑流程图,自己画的简易流程图(字很丑- -)。

image

不论是Dapper的文章,还是Zipkin的主页,对于分布式系统中Trace Infrastructure的描述都比较简单,只提到了一些必须的基础组件,以及每个组件需要关注的问题。但结合实际工作中经验,这样完备的Trace系统对分布式在线服务的异常诊断、性能优化有非常大的帮助,而这样的Trace组件又对各个基础组件的要求非常高。健壮、完备的基础组件对于这样系统的搭建是非常有益的。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Modern Internet services are often implemented as complex, large-scale distributed systems. These applications are constructed from collections of software modules that may be developed by different teams, perhaps in different programming languages, and could span many thousands of machines across multiple physical facilities. Tools that aid in understanding system behavior and reasoning about performance issues are invaluable in such an environment. Here we introduce the design of Dapper, Google’s production distributed systems tracing infrastructure, and describe how our design goals of low overhead, application-level transparency, and ubiquitous deployment on a very large scale system were met. Dapper sharesconceptualsimilaritieswithothertracingsystems, particularlyMagpie[3]andX-Trace[12],butcertaindesign choices were made that have been key to its success in our environment, such as the use of sampling and restricting the instrumentation to a rather small number of common libraries. The main goal of this paper is to report on our experience building, deploying and using the system for over two years, since Dapper’s foremost measure of success has been its usefulness to developer and operations teams. Dapper began as a self-contained tracing tool but evolved into a monitoring platform which has enabled thecreationofmanydifferenttools, someofwhichwere notanticipatedbyitsdesigners. Wedescribeafewofthe analysis tools that have been built using Dapper, share statisticsaboutitsusagewithinGoogle,presentsomeexample use cases, and discuss lessons learned so far.

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值