分布式链路监控追踪分析与实践
转载声明：商业转载请联系作者获得授权,⾮商业转载请注明出处.原⽂来⾃ ©
背景
随着互联⽹架构的扩张，分布式系统变得⽇趋复杂，越来越多的组件开始⾛向分布式化，如微服务、消息收发、分布式数据库、分布式缓存、分布式对象存储、跨域调⽤，这些组件共同构成了繁杂的分布式⽹络，那现在的问题是⼀个请求经过了这些服务后其中出现了⼀个调⽤失败的问题，只知道有异常，但具体的异常在哪个服务引起的就需要进⼊每⼀个服务⾥⾯看⽇志，这样的处理效率是⾮常低的。
现实中的分布式服务之间的调⽤链⽐上图还要复杂，像⼀张⼤⽹，盘根错节。所以，我们急需⼀种能追踪其调⽤链的⽅案，以快速完成问题的定位。
那什么是分布式调⽤链呢？
分布式调⽤链其实就是将⼀次分布式请求还原成调⽤链路。显式的在后端查看⼀次分布式请求的调⽤情况，⽐如各个节点上的耗时、请求具体打到了哪台机器上、每个服务节点的请求状态等等。
链路追踪系统应该具备的功能
分布式和微服务的关系根据前⾯的分析，我们已经知道追踪分布式调⽤链是解决上述场景的⼀个可⾏⽅案，那分布式链路追踪应该具备哪些功能才能达到我们的要求呢？
故障快速定位
通过调⽤链跟踪，⼀次请求的逻辑轨迹可以⽤完整清晰的展⽰出来。开发中可以在业务⽇志中添加调⽤链ID，可以通过调⽤链结合业务⽇志快速定位错误信息。
各个调⽤环节的性能分析
在调⽤链的各个环节分别添加调⽤时延，可以分析系统的性能瓶颈，进⾏针对性的优化。通过分析各个环节的平均时延，QPS等信息，可以到系统的薄弱环节，对⼀些模块做调整，如数据冗余等。
数据分析
调⽤链绑定业务后查看具体每条业务数据对应的链路问题，可以得到⽤户的⾏为路径，经过了哪些服务器上的哪个服务，汇总分析应⽤在很多业务场景。
⽣成服务调⽤拓扑图
通过可视化分布式系统的模块和他们之间的相互联系来理解系统拓扑。点击某个节点会展⽰这个模块的详情，⽐如它当前的状态和请求数量。
分布式调⽤跟踪系统的设计
我们前⾯已经说了链路追踪系统需要具备的功能，那从哪些⽅⾯考虑去设计它呢？
（1）分布式调⽤跟踪系统的设计⽬标
低侵⼊性，应⽤透明：作为⾮业务组件，应当尽可能少侵⼊或者⽆侵⼊其他业务系统，对于使⽤⽅透明，减少开发⼈员的负担
低损耗：服务调⽤埋点本⾝会带来性能损耗，这就需要调⽤跟踪的低损耗，实际中还会通过配置采样率的⽅式，选择⼀部分请求去分析请求路径
⼤范围部署，扩展性：作为分布式系统的组件之⼀，⼀个优秀的调⽤跟踪系统必须⽀持分布式部署，具备良好的可扩展性
（2）埋点和⽣成⽇志
埋点即系统在当前节点的上下⽂信息，可以分为客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点⽇志通常要包含以下内容：
TraceId、RPCId、调⽤的开始时间，调⽤类型，协议类型，调⽤⽅ip和端⼝，请求的服务名等信息；
调⽤耗时，调⽤结果，异常信息，消息报⽂等；
预留可扩展字段，为下⼀步扩展做准备；
（3）抓取和存储⽇志
⽇志的采集和存储有许多开源的⼯具可以选择，⼀般来说，会使⽤离线+实时的⽅式去存储⽇志，主要是分布式⽇志采集的⽅式。典型的解决⽅案如Flume结合Kafka等MQ。
（4）分析和统计调⽤链数据
⼀条调⽤链的⽇志散落在调⽤经过的各个服务器上，⾸先需要按 TraceId 汇总⽇志，然后按照RpcId 对调⽤链进⾏顺序整理。⽤链数据不要求百分之百准确，可以允许中间的部分⽇志丢失。
（5）计算和展⽰
汇总得到各个应⽤节点的调⽤链⽇志后，可以针对性的对各个业务线进⾏分析。需要对具体⽇志进⾏整理，进⼀步储存在HBase或者关系型数据库中，可以进⾏可视化的查询。
链路追踪Trace模型分析
⽬前，⼏乎所有的分布式链路追踪都是来⾃于⾕歌的⼀篇论⽂⽽设计开发⽽成的，论⽂名称：
Trace调⽤模型，主要有以下概念：
Trace：⼀次完整的分布式调⽤跟踪链路。
Span： 追踪服务调基本结构，表⽰跨服务的⼀次调⽤； 多span形成树形结构，组合成⼀次Trace追踪记录。
Annotation：在span中的标注点，记录整个span时间段内发⽣的事件。
BinaryAnnotation：可以认为是特殊的Annotation，⽤户⾃定义事件。
Annotation类型：保留类型
Cs CLIENT_SEND，客户端发起请求
Cr CLIENT_RECIEVE，客户端收到响应
Sr SERVER_RECIEVE，服务端收到请求
Ss SERVER_SEND，服务端发送结果
⽤户⾃定义类型：
Event 记录普通事件
Exception 记录异常事件
Client && Server：对于跨服务的⼀次调⽤，请求发起⽅为client，服务提供⽅为server
各术语在⼀次分布式调⽤中，关系如下图所⽰：
调⽤跟踪系统对⽐
当下互联⽹环境，⼤的互联⽹公司都有⾃⼰的分布式跟踪系统，⽐如Google的Dapper，Twitter的zipkin，淘宝的鹰眼，新浪的Watchman，京东的Hydra等，下⾯来简单分析。
Google的Drapper（闭源）
Dapper是Google⽣产环境下的分布式跟踪系统，Dapper有三个设计⽬标：
低消耗：跟踪系统对在线服务的影响应该做到⾜够⼩。
应⽤级的透明：对于应⽤的程序员来说，是不需要知道有跟踪系统这回事的。如果⼀个跟踪系统想⽣效，就必须需要依赖应⽤的开发者主动配合，那么这个跟踪系统显然是侵⼊性太强的。
延展性：Google⾄少在未来⼏年的服务和集的规模，监控系统都应该能完全把控住。
处理分为3个阶段：
①各个服务将span数据写到本机⽇志上；
②dapper守护进程进⾏拉取，将数据读到dapper收集器⾥；
③dapper收集器将结果写到bigtable中，⼀次跟踪被记录为⼀⾏。
⼤众点评——CAT
架构简单。可以实现⼀个Trace系统的所有功能。架构如下图所⽰：
跟踪模型
Transaction是最重要的事件消息类型，适合记录跨越系统边界的程序访问⾏为,⽐如远程调⽤，数据库调⽤，也适合执⾏时间较长的业务逻辑监控，记录次数与时间开销。Transaction可嵌套。
跨服务的跟踪功能与点评内部的RPC框架集成，这部分未开源。
客户端接⼊⽅式
对于⽅法调⽤、sql、url请求等粒度较⼩的兴趣点，需要业务⼈员⼿写代码实现。
⽇志收集⽅式
直接向⽇志收集器发异步请求（有本地内存缓存），⼀台客户端会连向⼏个服务端，当⼀个服务端出问题，数据不会丢失。
当所有服务端都挂掉，消息会存⼊queue，当queue满了，就丢弃了，没有做数据存储本地等⼯作。
全量采样，系统繁忙的时候对性能影响较⼤（可能达到10%的影响）
最后⼀个稳定版本是2014年1⽉，之后已经失去维护。
阿⾥-鹰眼（闭源）
埋点和⽣成⽇志
基于中间件、TraceId/RpcId、异步写、采样
抓取和存储⽇志
实时抓⽇志，实时+离线结合的存储
汇总和重组调⽤链
按TraceId汇总、按RpcId重组
分析和统计调⽤链
⼊⼝标准化、带上下⽂的调⽤统计
京东-hydra
与dubbo框架集成。对于服务级别的跟踪统计，现有业务可以⽆缝接⼊。对于细粒度的兴趣点，需要业务⼈员⼿动添加。架构如下：Hydra中跟踪数据模型
Trace: ⼀次服务调⽤追踪链路。
Span: 追踪服务调基本结构，多span形成树形结构组合成⼀次Trace追踪记录。
Annotation: 在span中的标注点，记录整个span时间段内发⽣的事件。
BinaryAnnotation: 属于Annotation⼀种类型和普通Annotation区别，这键值对形式标注在span中发⽣的事件，和⼀些其他相关的信息。
⽇志收集⽅式
与CAT类似。⽀持⾃适应采样，规则粗暴简单，对于每秒钟的请求次数进⾏统计，如果超过100，就按照10%的⽐率进⾏采样。
开源项⽬已于2013年6⽉停⽌维护
Twitter—Zipkin
功能、数据跟踪模型与hydra类似。Zipkin本⾝不开源，开源社区的是另外⼀套scala实现，依托于finagle这个RPC框架。架构如下：
Zipkin与其他Trace系统的不同之处
Zipkin中针对 HttpClient、jax-rs2、jersey/jersey2等HTTP客户端封装了。可以在较⼩的代码侵⼊条件下实现URl请求的拦截、时间统计和⽇志记录等操作。
⽇志收集
Cat是直接将⽇志发往消费集；
hydra是发给⽇志收集器，⽇志收集器推到消息队列；
Zipkin的client将统计⽇志发往消息队列，⽇志收集器读取后落地存储；
Dapper和Eagle eye是记录本地⽂件，后台进程定期扫描。
Trace系统现状分析
以上⼏款链路跟踪系统都各⾃满⾜了请求链路追踪的功能，但落实到我们⾃⼰的⽣产环境中时，这些Trace系统存在诸多问题：
Google和alibaba的Trace系统不开源，但现阶段来说阿⾥是做得最好的，如果⽤的是阿⾥的服务器，
可考虑直接⽤阿⾥的追踪系统以节省开发代价；
京东和点评的虽然开源，但是已经多年没有维护，项⽬依赖的jdk版本以及第三⽅框架过于陈旧等等，不适合⽤在⽣产环境中；
Twitter的OpenZipkin使⽤scala开发，⽽且其实现基于twitter内部的RPC框架finagle，第三⽅依赖⽐较多，接⼊和运维的成本⽐较⾼。
如果不是⽤阿⾥的服务，我们可以借鉴这些开源实现的思想, ⾃⾏开发Trace系统。那是⾃⼰从0开始开发还是基于开源⽅案⼆次开发？ 这⾥⾯也要考虑到跨平台，如NET和java环境，尽量减少原系统的侵⼊性或只需要更改少量的代码即可接⼊，在这⾥可以基于zipkin和pinpoint进⾏⼆次开发，功能可参考阿⾥的系统。
参考⽂章：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。