`

分布式服务的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组件又对各个基础组件的要求非常高。健壮、完备的基础组件对于这样系统的搭建是非常有益的。

分享到:
评论

相关推荐

    基于zipkin协议的分布式调用跟踪方案.pdf

    Zipkin是一个由Twitter开源的分布式调用跟踪系统,它基于Google Dapper的论文设计而来,旨在为分布式服务提供一个实时跟踪平台。Zipkin通过定义统一的协议来规范调用传递信息,使得不同服务间的通信能够被有效地监控...

    将各服务跟踪的数据上报给Zipkin Server,由Zipkin通过UI图形化页面对数据进行展示

    Zipkin的设计灵感来源于Google的Dapper,它的主要功能包括追踪服务调用链路、收集时间线数据以及提供可视化界面来展示这些信息。Zipkin通过收集服务之间的调用关系,形成所谓的"跨度"(Span),并将这些跨度组织成...

    zipkin-server-2.10.1-exec.zip

    Zipkin 的设计灵感来源于 Google 的 Dapper 和 Twitter 的 Zipkin。在微服务架构中,Zipkin 提供了关键洞察力,帮助开发者理解请求如何在分布式系统中传播。 这个压缩包 "zipkin-server-2.10.1-exec.zip" 包含了 ...

    美团的Mtrace分布式会话跟踪系统架构设计与实践

    1. **Dapper (Google)**:Dapper是谷歌于2010年发布的分布式跟踪系统,它为Mtrace的设计提供了很多灵感。但Dapper更偏向于研究领域,而Mtrace则是针对实际生产环境进行了大量优化。 2. **Zipkin (Twitter)**:Zipkin...

    分布式实时监控系统

    分布式实时监控系统的实现常常会参照某些理论模型,例如Google的Dapper模型,它定义了一个分布式系统的跟踪模型。基于此模型,监控系统可以使用一些开源组件如Twitter的Zipkin进行数据采集、存储和分析。 在技术...

    分布式追踪不是银弹.pdf

    首先,分布式追踪的历史可以追溯到2010年Google发布的Dapper论文,后来Twitter实现了Zipkin,Naver开源了Pinpoint,SkyWalking也成为了Apache顶级项目。分布式追踪的出现是为了解决分布式系统中的问题诊断困难和传统...

    使用分布式的追踪和APM系统架构.pdf

    Twitter在2012年实现了基于Dapper思想的Zipkin,这是一个开源的分布式追踪系统,旨在帮助开发者查找延迟问题。Zipkin提供了收集和可视化数据的能力,便于快速定位服务间的调用关系和性能瓶颈。 Naver在2012年开源了...

    分布式链路追踪

    - **Google的Dapper** - 目标:低消耗、应用透明、可扩展。 - 实现方式:通过在服务间传递跟踪上下文来实现跨服务跟踪。 - **Twitter的Zipkin** - 特点:基于HTTP的跟踪系统,易于集成。 - 支持多种语言和框架。...

    Hydra架构介绍1

    在 Hydra 系统中,我们使用的领域模型参考了 Google 的 Dapper 和 Twitter 的 Zipkin。在 Hydra 现阶段主要是对 Dubbo 服务调用框架,所以在这必须了解 Dubbo 的几个模型: * Application:一类业务类型的服务,...

    从头分析一则traceId穿透问题(附解决方案).docx

    常用的链路追踪组件包括Google的Dapper、Twitter的Zipkin以及Apache SkyWalking等。此外,阿里巴巴还开发了一款名为EagleEye的商用链路追踪工具。 这些工具通常通过客户端在不同服务间收集追踪数据(如trace ID和...

    Spring Cloud Sleuth.pdf

    Zipkin和HTrace是流行的分布式追踪工具,Zipkin是Twitter开源的分布式追踪系统,支持数据的存储、查询和展示;HTrace则是Hadoop开发的分布式追踪框架。 Spring Cloud Sleuth在Spring Cloud应用中实现追踪的方式主要...

    sleuth.docx

    Zipkin 是 Twitter 开源的一个分布式跟踪系统,灵感来源于 Google 的 Dapper 论文。它收集系统中的时序数据,用于分析微服务架构的延迟问题。Zipkin 提供了一个直观的用户界面,方便开发者查找和理解调用链路。 要...

    spring-cloud-zipkin-server

    Zipkin由Twitter开源,灵感来源于Google的Dapper,它是一个分布式的跟踪系统,能够帮助开发者收集服务之间的调用时间线数据,从而定位导致延迟和故障的原因。Spring Cloud Zipkin Server将其与Spring生态系统紧密...

    全链路应用体系建设-姚捷

    在技术栈方面,姚捷描述了唯品会如何利用Spark、Python、Time Series Database、Big Data Processing、OpenTSDB、Kafka、Grunt、AspectJ、Google Dapper、分布式发布订阅消息系统、ElasticSearch、Bootstrap、HBase...

Global site tag (gtag.js) - Google Analytics