浅析淘宝分布式调用跟踪系统

标签: 淘宝 跟踪 系统 | 发表时间:2016-04-30 16:37 | 作者:m635674608
出处:http://www.iteye.com

分布式系统为什么需要分布式跟踪?

电商平台由数以百计的分布式服务构成,每一个请求路由过来后,会经过多个业务系统并留下足迹,并产生对各种Cache或DB的访问,但是这些分散的数据对于问题排查,或是流程优化都帮助有限。

对于这么一个跨进程/跨线程的场景,汇总收集并分析海量日志就显得尤为重要。要能做到追踪每个请求的完整调用链路,收集调用链路上每个服务的性能数据,计算性能数据和比对性能指标(SLA),甚至在更远的未来能够再反馈到服务治理中,那么这就是分布式跟踪的目标了。

在业界,twitter的zipkin和淘宝的鹰眼就是类似的系统,它们都起源于Google Dapper 论文,就像历史上Hadoop发源于Google Map/Reduce 论文,HBase源自Google BigTable 论文一样。

这样的系统通常有几个设计目标:

(1)低侵入性——作为非业务组件,应当尽可能少侵入或者无侵入其他业务系统,对于使用方透明,减少开发人员的负担。

(2)灵活的应用策略——可以(最好随时)决定所收集数据的范围和粒度。

(3)时效性——从数据的收集和产生,到数据计算和处理,再到最终展现,都要求尽可能快。

(4)决策支持——这些数据是否能在决策支持层面发挥作用,特别是从DevOps的角度。

(5)可视化才是王道。

先来一个直观感受

数据流转过程:

图1-1淘宝鹰眼的数据收集和存储

鹰眼的调用链绘制界面:

图1-2 淘宝鹰眼的调用链

鼠标移动到调用链的每一层点击,可以看到执行时长、宿主机IP、数据库操作、传入参数甚至错误堆栈等等具体信息。

淘宝如何实现的

同一次请求的所有相关调用的情况,在淘宝EagleEye里称作调用链。同一个时刻某一台服务器并行发起的网络调用有很多,怎么识别这个调用是属于哪个调用链的呢?可以在各个发起网络调用的中间件上下手。

在前端请求到达服务器时,应用容器在执行实际业务处理之前,会先执行EagleEye的埋点逻辑(类似Filter的机制),埋点逻辑为这个前端请求分配一个全局唯一的调用链ID。这个ID在EagleEye里面被称为TraceId,埋点逻辑把TraceId放在一个调用上下文对象里面,而调用上下文对象会存储在ThreadLocal里面。调用上下文里还有一个ID非常重要,在EagleEye里面被称作RpcId。RpcId用于区分同一个调用链下的多个网络调用的发生顺序和嵌套层次关系。对于前端收到请求,生成的RpcId固定都是0。

当这个前端执行业务处理需要发起RPC调用时,淘宝的RPC调用客户端HSF会首先从当前线程ThreadLocal上面获取之前EagleEye设置的调用上下文。然后,把RpcId递增一个序号。在EagleEye里使用多级序号来表示 RpcId,比如前端刚接到请求之后的RpcId 是0,那么它第一次调用 RPC 服务A时,会把RpcId改成0.1。之后,调用上下文会作为附件随这次请求一起发送到远程的HSF服务器。

HSF服务端收到这个请求之后,会从请求附件里取出调用上下文,并放到当前线程ThreadLocal上面。如果服务A在处理时,需要调用另一个服务,这个时候它会重复之前提到的操作,唯一的差别就是RpcId会先改成 0.1.1再传过去。服务A的逻辑全部处理完毕之后,HSF 在返回响应对象之前,会把这次调用情况以及TraceId、RpcId都打印到它的访问日志之中,同时,会从ThreadLocal清理掉调用上下文。

如图2-1展示了一个浏览器请求可能触发的系统间调用。

图2-1一个浏览器请求可能触发的系统间调用

图2-1描述了EagleEye在一个非常简单的分布式调用场景里做的事情,就是为每次调用分配TraceId、RpcId,放在ThreadLocal的调用上下文上面,调用结束的时候,把TraceId、RpcId打印到访问日志。

类似的其他网络调用中间件的调用过程也都比较类似,这里不再赘述了。访问日志里面,一般会记录调用时间、远端IP地址、结果状态码、调用 耗时之类,也会记录与这次调用类型相关的一些信息,如URL、服务名、消息topic等。

很多调用场景会比上面说的完全同步的调用更为复杂,比如会遇到异步、单向、广播、并发、批处理等等,这时候需要妥善处理好ThreadLocal上的调用上下文,避免调用上下文混乱和无法正确释放。另外,采用多级序号的RpcId设计方案会比单级序号递增更容易准确还原当时的调用情况。

最后,EagleEye分析系统把调用链相关的所有访问日志都收集上来,按TraceId汇总在一起之后,就可以准确还原调用当时的情况了。

图2-2一个典型的调用链

如图2-2所示,就是采集自淘宝线上环境的某一条实际调用链。调用链通过树形展现了调用情况。调用链可以清晰地看到当前请求的调用情况,帮助问题定位。如上图,mtop应用发生错误时,在调用链上可以直接看出这是因为第四层的一个(tair@1)请求导致网络超时,使最上层页面出现超时问题。这种调用链,可以在EagleEye系统监测到包含异常的访问日志后,把当前的错误与整个调用链关联起来。问题排查人员在发现入口错误量上涨或耗时上升时,通过EagleEye查找出这种包含错误的调用链采样,提高故障定位速度。

调用链数据在容量规划和稳定性方面的分析

如果对同一个前端入口的多条调用链做汇总统计,也就是说,把这个入口URL下面的所有调用按照调用链的树形结构全部叠加在一起,就可以得到一个新的树结构(如图2-3所示)。这就是入口下面的所有依赖的调用路径情况。

图2-3 对某个入口的调用链做统计之后得到的依赖分析

这种分析能力对于复杂的分布式环境的调用关系梳理尤为重要。传统的调用统计日志是按固定时间窗口预先做了统计的日志,上面缺少了链路细节导致没办法对超过两层以上的调用情况进行分析。

例如,后端数据库就无法评估数据库访问是来源于最上层的哪些入口;每个前端系统也无法清楚确定当前入口由于双十一活动流量翻倍,会对后端哪些系统造成多大的压力,需要分别准备多少机器。有了EagleEye的数据,这些问题就迎刃而解了。

 

http://express.ruanko.com/ruanko-express_79/tech-overnight3.html



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [淘宝 跟踪 系统] 推荐:

浅析淘宝分布式调用跟踪系统

- - 企业架构 - ITeye博客
分布式系统为什么需要分布式跟踪. 电商平台由数以百计的分布式服务构成,每一个请求路由过来后,会经过多个业务系统并留下足迹,并产生对各种Cache或DB的访问,但是这些分散的数据对于问题排查,或是流程优化都帮助有限. 对于这么一个跨进程/跨线程的场景,汇总收集并分析海量日志就显得尤为重要. 要能做到追踪每个请求的完整调用链路,收集调用链路上每个服务的性能数据,计算性能数据和比对性能指标(SLA),甚至在更远的未来能够再反馈到服务治理中,那么这就是分布式跟踪的目标了.

分布式系统间请求跟踪

- - 码蜂笔记
现在的很多应用都是由很多系统系统在支持,这些系统还会部署很多个实例,用户的一个请求可能在多个系统的部署实例之间流转. 为了跟踪一个请求的完整处理过程,我们可以给请求分配一个唯一的 ID traceID,当请求调用到另一个系统时,我们传递这个 traceID. 在输出日志时,把这个 traceID 也输出到日志里,这样,根据日志文件,提取出现这个 traceID 的日志就可以分析这个请求的完整调用过程,甚至进行性能分析.

淘宝SPM流量跟踪体系的研究

- - 标点符
SPM是淘宝社区电商业务(xTao)为外部合作伙伴(外站)提供的一套跟踪引导成交效果数据的解决方案. 下面是一个跟踪点击到宝贝详情页的引导成交效果数据的SPM示例:http://detail.tmall.com/item.htm?id=3716461318&&spm=2014.123456789.1.2  其中spm=2014.123456789.1.2 便是下文所说的SPM编码.

淘宝推荐系统的学习

- - 标点符
维基百科:推荐系统属于资讯过滤的一种应用. 推荐系统能够将可能受喜好的资讯或实物(例如:电影、电视节目、音乐、书籍、新闻、图片、网页)推荐给使用者. 推荐系统大体可分为两类,即个性化推荐和非个性化推荐. 好的推荐系统更像一个有经验的网站导购员. 不同点:搜索是通过用户主动输入的关键字进行查询. 推荐则是用户在浏览网站的过程中,不一定需要用户输入,根据当前网页的上下文进行个性化的信息输出.

Facebook Cookies跟踪登出系统的用户

- 微笑!?~ - Solidot
淘宝网女装秋装外套 写道 "Facebook被人诟病的最大问题是隐私问题,现在它再次被曝光在用户登出系统后仍然跟踪用户行为. 新的隐私问题是:由于修改了cookie,Facebook现在知道用户在做什么,即使用户已经登出Facebook网站,他们也能通过Cookie继续跟踪用户. 澳大利亚技术抓紧Nik Cubrilovic运行一系列测试,分析浏览器向Facebook网站发出请求的HTTP头文件,他发现Facebook在用户登出的时候没有删除cookie,而是对其跟踪的cookie进行修改.

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

- - 美团点评技术团队
本文整理自美团点评技术沙龙第08期:大规模集群的服务治理设计与实践. 美团点评技术沙龙由美团点评技术团队主办,每月一期. 每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 目前沙龙会分别在北京、上海和厦门等地举行,要参加下一次最新沙龙活动. 赶快关注微信公众号“美团点评技术团队”.

研究人员发现无法躲避的在线跟踪系统

- Gnauk - Solidot
加州伯克利大学的研究人员曝光了一种用户无法避开的在线跟踪系统,即使他们屏蔽了cookies,或者是使用浏览器的隐身模式. KISSmetrics是被用于跟踪用户访问数量,所访问网页,从何处点击进入网站的路径等的在线服务,该公司声称它的功能比Google Analytics更全面. 但研究人员发现,用户无法选择退出KISSmetrics的跟踪系统.

淘宝开源其系统监控工具Tsar

- - InfoQ cn
淘宝在开发社区的贡献可谓功不可没,近日又将其系统监控工具 Tsar代码上传至 GitHub. 据 @淘叔度介绍,Tsar在淘宝内部已经被大量使用,它不仅可以监控CPU、IO、内存、TCP等系统状态,也可监控Apache、Nginx/Tengine、Squid等服务器状态. Tsar(Taobao System Activity Reporter)可将收集到的数据存储在磁盘上,另外可以支持将数据存储到MySQL中,也可将数据发送到Nagios报警服务器.

"Java在淘宝AD系统中的应用"分享汇总

- - ITeye博客
条幅AD 搜索AD 定向AD. 高性能Web服务器 关系数据库,内存KV数据库, NoSQL (BigTable) 搜索引擎 排序算法(Ranking) 实时计算 海量日志收集和处理(MapReduce, 报表和结算) RPC,消息中间件 客户端技术:浏览器,Javascript. 多个子系统都采用Java实现:.

王海亚:淘宝交易系统演进之路

- - CSDN博客研发管理推荐文章
淘宝的交易系统承载了购物车、下单、订单管理等多项淘宝的重要业务,随着淘宝业务量的不断上升,交易系统也随之几经改造. InfoQ此次专访了阿里巴巴架构师王海亚,另外作为ArchSummit深圳2014大会《电商,各走各的路》专题的讲师,王海亚将会分享淘宝交易平台的架构演变及并行化实践. InfoQ:淘宝的交易系统,主要承载了哪些业务.