链家全链路跟踪平台 LTrace 设计实践

栏目: 服务器 · 发布时间: 6年前

内容简介:当今的互联网服务,通常都是用大规模的分布式集群来实现的。服务可能来自不同的研发团队、使用不同的编程语言来实现、运行在上千台服务器上。随着链家的业务发展,公司的分布式系统变得越来越复杂,用户的一次请求通常由多个系统协同完成处理,而且这些处理是发生在不同机器甚至是不同集群上的,当请求处理发生异常时,需要快速发现问题,并准确定位到是哪个环节出了问题,这是非常重要的。作者|李宝银编辑|蔡白银

当今的互联网服务,通常都是用大规模的分布式集群来实现的。服务可能来自不同的研发团队、使用不同的编程语言来实现、运行在上千台服务器上。随着链家的业务发展,公司的分布式系统变得越来越复杂,用户的一次请求通常由多个系统协同完成处理,而且这些处理是发生在不同机器甚至是不同集群上的,当请求处理发生异常时,需要快速发现问题,并准确定位到是哪个环节出了问题,这是非常重要的。

作者|李宝银

编辑|蔡白银

网址|tech.lianjia.com

微信公众号|链家产品技术团队

当今的互联网服务,通常都是用大规模的分布式集群来实现的。服务可能来自不同的研发团队、使用不同的编程语言来实现, 运行在上千台服务器上。

随着链家的业务发展,公司的分布式系统变得越来越复杂,用户的一次请求通常由多个系统协同完成处理,而且这些处理是发生在不同机器甚至是不同集群上的,当请求处理发生异常时,需要快速发现问题,并准确定位到是哪个环节出了问题,这是非常重要的。

链家全链路跟踪平台 LTrace 设计实践

为了解决这样的问题,我们经过调研与测试,结合业界的实践经验 开发了LTrace链家全链路跟踪平台,有效应对上面的问题,大幅度提升工作效率。目前已经在公司多部门的各条业务线项目中得到成功应用。基于请求链路采集到的全量丰富数据,我们能够直观的了解到项目间的链路关系,就能够进行问题的快速定位与瓶颈节点的快速排查,代码性能问题一览无余。

链路跟踪,关键的核心是调用链,就是对一次请求进行跟踪。通过为每个请求生成一个全局唯一的ID,将分布在各个服务节点上的同一次请求串联起来,还原出更多有价值的数据。在 我们设计实现LTrace平台过程中,遇到几项大的挑战。

  1. 稳定性挑战。我们的业务 系统对于稳定性、性能、资源要求极其严格,不能有太复杂的逻辑和外部依赖,并对业务系统性能几乎无影响,LTrace平台的稳定性不应该对业务系统的稳定性造成任何影响;

  2. 高性能挑战。目前公司存在 众多复杂的分布式业务系统,数十 亿hits 生成的链路数据需要及时采集存储, 这就要求LTrace平台具备快速的数据处理能力

  3. 透明、易扩展、避免侵入业务。易于被使用方广泛接受、低耦合是很重要的,透明性用来隐藏实现策略,避免让使用者卷进细节,同时 具备良好的可扩展性

  4. 跨语言、多协议。在公司各部门中,存在 JAVAPHP 等众多异构系统以及各种服务中间件,因此LTrace平台要实现全链路跟踪,必须要支持跨语言、多协议。

功能简介

一, 调用链路

我们通过对一次请求进行还原,形成一个完整的调用链路图,如下图。界面中展示请求依次通过的各个服务节点的情况。比如请求经过每个服务节点的IP、发送与响应时间点、处理结果与处理时长,网络传输时长、异常描述等信息。

链家全链路跟踪平台 LTrace 设计实践

二,问题快速定位

再比如,我们现在可以在界面中快速的定位到问题出现的服务节点、机器IP与问题原因。以前我们遇到线上问题时,通常需要同时登录N台机器抓日志排查,有时还可能需要关联上下游项目一起排查。 

链家全链路跟踪平台 LTrace 设计实践

三,瓶颈节点

再次,我们还能够快速定位瓶颈节点。如界面中红框部分显示的是链路调用的瓶颈节点,由于该节点的耗时,导致了整个链路调用的耗时延长,因此针对该节点进行优化,进而达到优化整个链路的效率。

链家全链路跟踪平台 LTrace 设计实践

四,代码优化

除此,我们还能够检测到代码中一些需要优化的地方。比如图中红框部分都是同一个接口的调用,甚至连请求参数都是一样的。这种调用如果优化成批量请求或者相同参数只请求一次,能够快速提升节点的服务质量。

链家全链路跟踪平台 LTrace 设计实践

对系统行为进行链路跟踪必须是持续进行的,因为异常、超时等的发生是无法预料的,异常超时可能发生在链路的任何一个节点上或者一次调用的网络中,而且可能是难以重现的。同时跟踪需要是无所不在,遍布各处的,否则可能会遗漏某些重要的点。基于此LTrace设计了三个最重要的设计目标:极低的额外开销,对应用的透明性,可扩展。同时产生的跟踪数据需要可以被快速分析,这样可以帮助我们实时获取各节点状态。

平台设计

一,平台架构

链家全链路跟踪平台 LTrace 设计实践

上图中,LTrace平台架构主要分为三部分:数据埋点上报、数据实时存储、数据前端展示。

  1. 左侧部分使用埋点中间件完成数据的采集,并异步写入到本地trace文件,通过rsyslog发送数据到消息服务中。至于采样策略,后面会有详细介绍

  2. 中间部分数据汇集并存储,接受消息队列中数据并存储到Hbase与ES中。

  3. 右侧部分在界面中检索数据,分析数据进行展示。

二,基本概念

TraceId :全局唯一,用于标识一次请求,会在RPC调用的网络中传递。

SpanId :签名方式生成:0, 0.1, 0.1.1, 0.2。用于标识一次RPC在分布式请求中的位置,比如0.2就是0节点服务调用的第二个服务。

Annotation :基本标注列表,记录一次RPC生命周期中重要时刻的数据快照。

BinaryAnnotation:业务标注列表,如果项目需要带上业务数据(比如电话号码、UserId等),可以将需要的数据放入。

三,调用链-Trace树

我们将一次请求所形成的调用链路,标记成一棵Trace树,并用全局唯一的TraceId来标记这棵树,如下图:

链家全链路跟踪平台 LTrace 设计实践

四,调用链-Span节点

对于一次分布式请求,总会存在多次调用关系(如图中箭头线),我们将每次调用(箭头线)标记成一个Span节点,并用SpanId来标记这个Span节点。

链家全链路跟踪平台 LTrace 设计实践

五,数据埋点

LTrace平台对应用开发者近乎零侵入,通过为不同的异构系统提供对应的埋点中间件(如JAVA、PHP等)完成链路跟踪。在埋点中间件,生成统一的TraceId等核心数据,并收集比如调用类型、机器IP、服务名称、耗时、层级关系、异常信息、业务系统的自定义数据等。

在一次分布式请求中,都有四个埋点阶段,如下图。

链家全链路跟踪平台 LTrace 设计实践

  1. 客户端发送(Client Send):客户端发起请求时埋点,需要传递一些参数,比如TraceId、SpanId等;

  2. 服务端接收(Server Receive):服务端接受请求时埋点,回填一些参数,比如TraceId、SpanId等;

  3. 服务端响应(Server Send):服务端返回请求时埋点,将埋点数据传递到后端线程;

  4. 客户端接收(Client Receive):客户端接受返回结果时埋点,将埋点数据传递到后端线程;

六,示例

接下来我们通过一个示例进行详细描述,如下图,对于一次分布式请求,TraceId=12345。

在应用A收到客户端请求时刻为0ms,响应请求时刻为69ms,即是本次请求耗费时长69ms

链家全链路跟踪平台 LTrace 设计实践

七,数据存储

调用链路数据的实时查询主要是通过Hbase,使用traceID作为RowKey,SpanId + Type(c代表客户端、s代表服务端)能天然的把一整条调用链聚合在一起,提高查询效率。

链家全链路跟踪平台 LTrace 设计实践

一,低开销与采样

低开销是LTrace的一个关键的设计目标,如果一个 工具 价值未被证实但又对性能有影响的话,用户通常不会接受它。采样可以降低开销,但是简单的采样可能导致采样结果无代表性,LTrace通过提供多种采样机制来满足性能和代表性两方面的需求。

链家全链路跟踪平台 LTrace 设计实践

最初我们的默认采样策略很简单,是在每100个请求中选择一个进行跟踪,这种策略对于那种请求量很高的服务来说,可以保证跟踪到有价值的信息;但对于那些负载不高的服务来说,可能会导致采样频率过低,从而遗漏重要信息,因此我们提供了自定义采样策略;对于异常、超时等这类极端的情况,我们认为这类数据非常有价值,因此我们决定在极端情况下全采样;另外,对于测试人员,我们提供了可对一次请求显示指定采样。这样采样就既灵活又高度可控。

此外,通过优化消息、缓存、存储结构、批量异步写入等方式,平台性能得到大幅度提升。

通过以上采样策略与性能优化手段,我们只需要线上原来几十分之一的机器数量,就能够实现原来数十倍机器相同的效果。

二,日志TraceId绑定

  1. 我们通常为了便于在日志中跟踪一次请求,一般做法是在项目收到请求的入口放入一个RequestId。现在,应用方可以将TraceId绑定到日志中,通过这个TraceId我们不仅能够将应用内一次请求给串联起来,同时还能够用这个TraceId到上下游应用中去进行串联。

  2. 有时为了知道接口都有哪些上游在使用,通过在日志中记录调用方来源。LTrace就能够解决这个问题,通过在每次请求中输出当前请求已经过的应用名称列表,我们不仅能通过日志就能够识别这个请求的上游,还能知道这个请求所经过的所有上游应用以及请求入口。

链家全链路跟踪平台 LTrace 设计实践

三,支持自定义TraceId

为便于研发、测试人员进行线上线下问题的调试、排查,LTrace平台支持传递自定义TraceId,通过TraceId对问题进行跟踪。

链家全链路跟踪平台 LTrace 设计实践

四,支持多线程等场景

业务系统中,可能会存在一些对线程池的使用场景,而线程池的切换对于TraceId的传递是很困难的。在LTrace平台中,我们提供了显示API的支持方式,保证在多线程的场景下TraceId也能进行上下文传递。

五,业务方接入简单,稳定可靠

  1. 业务方接入LTrace平台,只需要花费几分钟阅读使用文档,添加几行配置,就能够投入使用。

  2. Trace系统的可用性能够达到99.99%以上,业务系统的稳定性不依赖LTrace平台的稳定性,即使LTrace平台出现异常,也不会对业务系统的稳定性造成任何影响。

经验总结

  1. 使用LTrace平台,我们可以理清系统之间关系,帮助找到关键系统路径上的请求延迟,解决并提高整体性能;

  2. 分析请求是否正确发送给了服务提供者,进行正确性检查;

  3. 同时我们还将LTrace与公司的监控系统进行集成,如果异常发生了,我们会生成包含TraceId在内的详细异常数据并上报给监控系统,监控服务立即发出实时的问题报警,这样可以帮助快速发现异常以及异常的情况。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

MFC编程技巧与范例详解

MFC编程技巧与范例详解

曾凡锋、苗雨 / 清华大学出版社 / 2008-10 / 45.00元

本书集作者多年教学与软件开发经验,通过不同类型的实例详解向读者解读了如何使用MFC进行软件开发,并按实例的复杂度进行分级介绍,以满足不同层次读者的切实需要。. 本书共55个完整实例,均选自作者多年工程应用开发中的案例;内容共分14章,分别为MFC的基本概念、文档和视图、对话框、按钮控件、编辑控件、组合框控件、列表框控件、列表视图控件、树状视图控件、图像、多媒体、GDI与GDI+、网络编程、I......一起来看看 《MFC编程技巧与范例详解》 这本书的介绍吧!

MD5 加密
MD5 加密

MD5 加密工具

Markdown 在线编辑器
Markdown 在线编辑器

Markdown 在线编辑器

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具