全链路追踪系统
以微服务开发为架构的互联网应用,大多为分布式应用,它们具有规模大、复杂度高的特点。集群应用部署在不同的机器上且分布在不同的机房。
多个服务很可能是由不同团队开发和维护的,而且使用不同的编程语言来实现,横跨多个不同的数据中心。当系统出现问题时,需要有一个全链路追踪系统。这个系统可以用来分析链路中的性能问题,同时还可以监控系统的报警信息,追踪横跨不同应用和不同服务器之间的调用关系链。本章主要介绍全链路追踪系统的原理及一些知名的全链路追踪系统开源框架。
全链路追踪系统简介
在微服务开发中,一次服务的调用也许会涉及多个依赖服务和团队。当线上出现问题时,通常需要多个团队配合定位,排查问题需要的时间较长,涉及的人员较广,这样排查问题的效率很低。全链路追踪系统就是为了解决这些问题而开发,有了该系统,可以在发生故障时能够快速定位问题并解决问题。
最为开发人员所熟知的全链路追踪系统是谷歌公司的Dapper。谷歌公司开发Dapper系统是为了收集复杂的分布式系统的行为信息,大部分开源的分布式链路追踪系统都是基于Dapper的基本原理开发的。
本节主要讲解全链路追踪系统的设计目标及基本概念。
基本特性
全链路追踪系统作为一个追踪监控系统,需要快速发现线上系统的故障,并能迅速定位故障位置,同时可以分析分布式系统中存在的性能瓶颈,从而辅助优化系统。这就要求全链路系统可以实时并全量地提供系统中的行为数据,做到高可用,并全面展现链路信息。
全链路追踪系统的设计目标主要包含以下几点:
性能消耗低。调用链追踪应该对服务影响足够小,不应消耗太多的系统资源。
代码侵入低。作为中间件,应当尽可能少地侵入或者不侵入其他业务系统,保持对使用方的透明性,减少开发人员的负担和接入门槛。
高度可扩展。整个调用链追踪通路都应该可扩展,以应对不断接入的服务。
实时数据采集。全链路追踪系统从数据采集、分析、查询,到展示整个链路的操作都要尽量快速,这样才能完成对线上问题的快速定位。
提供决策支持。全链路追踪系统可以定位业务系统问题,通过分析系统服务,为服务的优化提供决策支持。
通过上面列出的设计目标可知,全链路追踪系统的主要功能如下:
对调用请求进行整个链路追踪,分析每个环节的耗时,并协助开发和运维人员找到性能瓶颈。
展示调用服务之间的拓扑关系。
对线上服务进行监控与报警。
采用简单的接入方式,和业务代码低耦合。
实时采集数据,可以设置采集率。
可以展示调用链的UI页面。
基本概念
不同的开源链路追踪系统的设计虽然不同,但基本上都包括Trace、Span、Tag及采样率等几部分。本节将重点讲解全链路追踪系统中的一些常用概念。
1. Span
Span是调用链中的一个基本单元。通常,一次服务调用会创建一个Span,每个Span都有一个ID来标识,并且它在调用链中是唯一的。
同时,Span中还有其他信息,如描述信息、Tag信息及父Span id等。
如图7.1所示为一个Span链路信息图。如果Span没有父Span,则它是根Span。通过Span id与Parent id可以查询整个链路中的Span。同时,每个Span都封装了很多信息,如操作描述信息、时间戳信息及键值对(Tag)信息。
2. Trace
通常,一个调用链会生成一条Trace,由唯一的Trace id来标识。
一条Trace可以由一个或多个Span组成,类似于树状结构,是一条调用链路,相当于一次完整的请求链路。
如图7.2所示,一条链路只有一个Trace id,每个Span就是链路中的节点,节点之间的连线使Span与父节点Span发生联系,每个Span中保存了一些请求信息。
3. Tag
Tag用来描述Span中的一些特殊信息。在调用链的过程中,开发者如果需要保存一些特殊的业务信息,可以通过Tag设置键值对的方式进行保存。
4. 采样率
线上环境对性能要求很高,如果对全部的请求都开启链路信息采集,会有一定的压力,因此可以通过设置采样率,在不牺牲大量性能的情况下进行信息采集,或者在某些关键时刻进行采集,便于定位线上问题。采样率可以设置全采样或某个速度进行采集。