43 | 一个完整的分布式追踪系统是什么样子的?
周志明
你好,我是周志明。这节课我们来讨论链路追踪的话题。
虽然在 2010 年之前,就已经有了 X-Trace、Magpie 等跨服务的追踪系统了,但现代分布式链路追踪公认的起源,是 Google 在 2010 年发表的论文《Dapper : a Large-Scale Distributed Systems Tracing Infrastructure》,这篇论文介绍了 Google 从 2004 年开始使用的分布式追踪系统 Dapper 的实现原理。
此后,所有业界有名的追踪系统,无论是国外 Twitter 的Zipkin、Naver 的Pinpoint(Naver 是 Line 的母公司,Pinpoint 的出现其实早于 Dapper 论文的发表,在 Dapper 论文中还提到了 Pinpoint),还是国内阿里的鹰眼、大众点评的CAT、个人开源的SkyWalking(后来进入 Apache 基金会孵化毕业),都受到了 Dapper 论文的直接影响。
那么,从广义上讲,一个完整的分布式追踪系统,应该由数据收集、数据存储和数据展示三个相对独立的子系统构成;而从狭义上讲,则就只是特指链路追踪数据的收集部分。比如Spring Cloud Sleuth就属于狭义的追踪系统,通常会搭配 Zipkin 作为数据展示,搭配 Elasticsearch 作为数据存储来组合使用。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
分布式追踪系统是现代分布式系统中不可或缺的组成部分。本文从Google的Dapper论文出发,介绍了分布式追踪系统的起源和影响,以及追踪与跨度的概念。文章指出一个完整的分布式追踪系统应该由数据收集、数据存储和数据展示三个相对独立的子系统构成。在功能性和非功能性上都有不小的挑战,包括低性能损耗、对应用透明、随应用扩缩和持续的监控。此外,文章还介绍了分布式追踪的三种主流的数据收集方式,分别是基于日志的追踪、基于服务的追踪和基于边车代理的追踪。基于日志的追踪对网络消息没有侵入性,但可能不如其他两种追踪实现来的精准。分布式追踪的主要需求是如何围绕着一个服务调用过程中的Trace和Span,来低损耗、高透明度地收集信息。这些信息对于排查故障和分析性能提供了重要的数据支持。 此外,文章还介绍了追踪规范化的重要性,以及OpenTracing和OpenCensus等规范的出现和发展。这些规范的制定和推广,有望解决目前追踪系统互不兼容的问题,为追踪系统的标准化和统一提供了方向。 总的来说,本文通过介绍分布式追踪系统的基本概念、实现方式和规范化发展,为读者提供了对分布式追踪系统的全面了解和认识,有助于读者在实际工作中选择合适的追踪方式和工具,以提高系统的可观测性和性能分析能力。
该试读文章来自《周志明的软件架构课》,如需阅读全部文章,
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(9)
- 最新
- 精选
- qinsi文中写道:“日志追踪对网络消息完全没有侵入性”,这个不确定个人理解是否正确 根据个人理解,像是TraceID和SpanID等信息,都是需要通过网络从调用方传递到被调用方,这样才能最终串起整棵Trace Tree。文中所提到的几种数据收集方式,只要Trace信息随着请求一起发送,就对网络消息有侵入性(当然这里可以argue说把Trace信息放在http header里或是grpc metadata里可以做到对消息体无侵入,但这类情况下的无侵入性是由网络协议提供的,而非不同的追踪数据收集方式导致的)。
作者回复: TraceID和SpanID是现代追踪系统的基础,是追踪的既有属性了,而不是日志的。举个例子类比,在一次HTTP访问后,日志中记录了HTTP消息中的某项信息,譬如agent吧,这时候很难去说因为log中打印了agent,所以log对HTTP消息是有侵入的,无论是否打印agent到日志,agent都客观地存在与HTTP消息里。
2021-03-035 - zhanyd关于Dapper中的“追踪”与“跨度”在网上看到调用追踪的过程: 1.请求到来生成一个全局TraceID,通过TraceID可以串联起整个调用链,一个TraceID代表一次请求。 2.除了TraceID外,还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id,通过他们可以组织一次完整调用链的父子关系。 3.一个没有parent id的span成为root span,可以看成调用链入口。 4.所有这些ID可用全局唯一的64位整数表示; 5.整个调用过程中每个请求都要透传TraceID和SpanID。 6.每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下,并且将自己生成的SpanID也记录下。 7.要查看某次完整的调用则 只要根据TraceID查出所有调用记录,然后通过parent id和span id组织起整个调用父子关系。 https://juejin.cn/post/68449035607322132612021-03-0314
- 陈珙谢谢老师的分享,当时我们团队在微服务搭建的中后期引入的,也是因为随着微服务的规模变大后,跟踪定位问题越来越困难,经过多种产品的对比,最后选择了支持多语言,侵入性相对比较低的skywalking,根据团队的需要我针对sdk进行了扩展添加了request 和response的信息记录,在排查定位问题时结合efk能很快速的解决,同时他的耗时记录让我提前的解决了不少的性能问题。 当时引入skywalking的时候有个小插曲,开始我的微服务选择的是Fabio这个均衡器,因为Fabio在做请求转发的时候把skywalking的部分跟踪信息丢了,导致记录跟踪并不能串起来,使用查看效果并不好,后来也是多方面的考虑与取舍,坚持保留skywalking,把Fabio换成了Comsul-Teamplate+Nginx才解决了这个问题。2021-03-0316
- walkingonair打卡,公司在用elk和pinpoint,说来惭愧,之前一直理解的是分布式日志和分布式服务预警解决方案,没想到背后还有这么多知识,还是怪自己没有深入去了解,今天又学到了。2021-03-031
- 鱼丸粗面公司之前用的自研的trace框架,在像opentelemeter迁移2024-01-04归属地:广东
- 锐老师提到“Pinpoint 这种详细程度的追踪,对应用系统的性能压力是相当大的”,有没有相关资料,比如什么情况下不能使用2022-04-21
- stonejianbu此前因为有分布式框架的直接插件式支持,有在项目中使用jaeger基于服务的追踪。但后又切换到不同项目使用不同语言和框架,框架没有直接支持,自己也没有去着手实现,所以也没有使用追踪功能。 自己有调试使用kubernetes+istio,对于安全(传输、认证授权)、可视化(日志、追踪和度量)和灰度发布等功能应用,深感将这些功能下沉到基础设施带来的效益巨大。跟周大一样,对于网格化抱有很大信心,未来可期。2022-03-30
- 无心水使用的jaeger,对应用有一定的侵入性,需要写代码,排除其他依赖。感觉不好用,应该使用skywalking,不知道基础架构部是怎么做的选型2022-01-20
- good boby系统架构采用的Spring Cloud 在链路追踪上采用的zipkin+sleuth2021-05-11
收起评论