。

随着软件架构的复杂化#xff0c;传统的日志分析方法已不足以应对问题定位的需求。

文章首先解释了链路追踪的基本概念#xff0c;如Trace和Span#xff0c;并讨论了其基本原理。

接着#xff0c;文章介绍了SkyWa…摘要

本文深入探讨了分布式链路追踪系统的必要性与实施细节。

随着软件架构的复杂化传统的日志分析方法已不足以应对问题定位的需求。

文章首先解释了链路追踪的基本概念如Trace和Span并讨论了其基本原理。

接着文章介绍了SkyWalking这一开源链路追踪系统包括其架构设计、部署方式、数据采集与存储等关键特性。

最后通过大众点评的实践案例文章展示了链路追踪在实际业务中的应用效果强调了其在提升分布式系统可观测性方面的重要性。

分布式链路追踪背景

随着互联网业务快速扩展软件架构也日益变得复杂为了适应海量用户高并发请求系统中越来越多的组件开始走向分布式化如单体架构拆分为微服务、服务内缓存变为分布式缓存、服务组件通信变为分布式消息这些组件共同构成了繁杂的分布式网络。

假如现在有一个系统部署了成千上万个服务用户通过浏览器在主界面上下单一箱茅台酒结果系统给用户提示系统内部错误相信用户是很崩溃的。

运营人员将问题抛给开发人员定位开发人员只知道有异常但是这个异常具体是由哪个微服务引起的就需要逐个服务排查了。

1.2.

日志作为业务系统的必备能力职责就是记录程序运行期间发生的离散事件并且在事后阶段用于程序的行为分析比如曾经调用过什么方法、操作过哪些数据等等。

在分布式系统中ELK技术栈已经成为日志收集和分析的通用解决方案。

如下图1所示伴随着业务逻辑的执行业务日志会被打印统一收集并存储ESElasticsearch。

传统的ELK方案需要开发者在编写代码时尽可能全地打印日志再通过关键字段从ES中搜集筛选出与业务逻辑相关的日志数据进而拼凑出业务执行的现场信息。

然而该方案存在如下的痛点

日志搜集繁琐虽然ES提供了日志检索的能力但是日志数据往往是缺乏结构性的文本段很难快速完整地搜集到全部相关的日志。

日志筛选困难不同业务场景、业务逻辑之间存在重叠重叠逻辑打印的业务日志可能相互干扰难以从中筛选出正确的关联日志。

日志分析耗时搜集到的日志只是一条条离散的数据只能阅读代码再结合逻辑由人工对日志进行串联分析尽可能地还原出现场。

综上所述随着业务逻辑和系统复杂度的攀升传统的ELK方案在日志搜集、日志筛选和日志分析方面愈加的耗时耗力很难快速实现对业务的追踪。

1.3.

分布式链路追踪就是将一次分布式请求还原成调用链路将一次分布式请求的调用情况集中展示比如各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

链路跟踪主要功能

故障快速定位可以通过调用链结合业务日志快速定位错误信息。

链路性能可视化各个阶段链路耗时、服务依赖关系可以通过可视化界面展现出来。

链路分析通过分析链路耗时、服务依赖关系可以得到用户的行为路径汇总分析应用在很多业务场景。

1.4.

链路追踪系统可能最早是由Goggle公开发布的一篇论文《Dapper,

Large-Scale

Infrastructure》被大家广泛熟悉所以各位技术大牛们如果有黑武器不要藏起来赶紧去发表论文吧。

在这篇著名的论文中主要讲述了Dapper链路追踪系统的基本原理和关键技术点。

接下来挑几个重点的技术点详细给大家介绍一下。

1.4.1.

Trace的含义比较直观就是链路指一个请求经过所有服务的路径可以用下面树状的图形表示。

服务A

chrome。

服务间经过的局部链路构成了一条完整的链路其中每一条局部链路都用一个全局唯一的traceid来标识。

1.4.2.

在上图中可以看出来请求经过了服务A同时服务A又调用了服务B和服务C但是先调的服务B还是服务C呢从图中很难看出来只有通过查看源码才知道顺序。

同一层级parent

id从小到大表示请求的顺序从下图中可以很明显看出服务A是先调了服务B然后再调用了C。

id为2这就表示服务C和服务D形成了父子关系很明显是服务C调用了服务D。

总结通过事先在日志中埋点找出相同traceId的日志再加上parent

id和span

Dapper中还定义了annotation的概念用于用户自定义事件用来辅助定位问题。

通常包含四个注解信息

csClient

crClientReceived表示客户端获取到服务端返回信息

上图中描述了一次请求和响应的过程四个点也就是对应四个Annotation事件。

如下面的图表示从客户端调用服务端的一次完整过程。

如果要计算一次调用的耗时只需要将客户端接收的时间点减去客户端开始的时间点也就是图中时间线上的T4

1.4.4.

带外数据是各个节点产生的事件如csss这些数据可以由节点独立生成并且需要集中上报到存储端。

通过带外数据可以在存储端分析更多链路的细节。

带内数据如traceid,spanid,parentid用来标识tracespan以及span在一个trace中的位置这些数据需要从链路的起点一直传递到终点。

1.4.5.

由于每一个请求都会生成一个链路为了减少性能消耗避免存储资源的浪费dapper并不会上报所有的span数据而是使用采样的方式。

举个例子每秒有1000个请求访问系统如果设置采样率为1/1000那么只会上报一个请求到存储端。

通过采集端自适应地调整采样率控制span上报的数量可以在发现性能瓶颈的同时有效减少性能损耗。

1.4.6.

链路中的span数据经过收集和上报后会集中存储在一个地方Dapper使用了BigTable数据仓库常用的存储还有ElasticSearch,

HBase,

可视化全链路日志追踪考虑在前置阶段即业务执行的同时实现业务日志的高效组织和动态串联如下图4所示此时离散的日志数据将会根据业务逻辑进行组织绘制出执行现场从而可以实现高效的业务追踪。

2.1.1.

为了实现高效的业务追踪首先需要准确完整地描述出业务逻辑形成业务逻辑的全景图而业务追踪其实就是通过执行时的日志数据在全景图中还原出业务执行的现场。

新方案对业务逻辑进行了抽象定义出业务逻辑链路下面还是以“审核业务场景”为例来说明业务逻辑链路的抽象过程

逻辑节点业务系统的众多逻辑可以按照业务功能进行拆分形成一个个相互独立的业务逻辑单元即逻辑节点可以是本地方法如下图5的“判断逻辑”节点也可以是RPC等远程调用方法如下图5的“逻辑A”节点。

逻辑链路业务系统对外支撑着众多的业务场景每个业务场景对应一个完整的业务流程可以抽象为由逻辑节点组合而成的逻辑链路如下图5中的逻辑链路就准确完整地描述了“审核业务场景”。

一次业务追踪就是逻辑链路的某一次执行情况的还原逻辑链路完整准确地描述了业务逻辑全景同时作为载体可以实现业务日志的高效组织。

2.1.2.

业务逻辑执行时的日志数据原本是离散存储的而此时需要实现的是随着业务逻辑的执行动态串联各个逻辑节点的日志进而还原出完整的业务逻辑执行现场。

由于逻辑节点之间、逻辑节点内部往往通过MQ或者RPC等进行交互新方案可以采用分布式会话跟踪提供的分布式参数透传能力实现业务日志的动态串联

通过在执行线程和网络通信中持续地透传参数实现在业务逻辑执行的同时不中断地传递链路和节点的标识实现离散日志的染色。

基于标识染色的离散日志会被动态串联至正在执行的节点逐渐汇聚出完整的逻辑链路最终实现业务执行现场的高效组织和可视化展示。

与分布式会话跟踪方案不同的是当同时串联多次分布式调用时新方案需要结合业务逻辑选取一个公共id作为标识例如图5的审核场景涉及2次RPC调用为了保证2次执行被串联至同一条逻辑链路此时结合审核业务场景选择初审和复审相同的“任务id”作为标识完整地实现审核场景的逻辑链路串联和执行现场还原。

2.2.

明确日志的高效组织和动态串联这两个基本问题后本文选取图4业务系统中的“逻辑链路1”进行通用方案的详细说明方案可以拆解为以下步骤

2.2.1.

“链路定义”的含义为使用特定语言静态描述完整的逻辑链路链路通常由多个逻辑节点按照一定的业务规则组合而成业务规则即各个逻辑节点之间存在的执行关系包括串行、并行、条件分支。

**DSLDomain

Language**是为了解决某一类任务而专门设计的计算机语言可以通过JSON或XML定义出一系列节点逻辑节点的组合关系业务规则。

因此本方案选择使用DSL描述逻辑链路实现逻辑链路从抽象定义到具体实现。

[{nodeName:

“链路染色”的含义为在链路执行过程中通过透传串联标识明确具体是哪条链路在执行执行到了哪个节点。

链路染色包括两个步骤

步骤一确定串联标识当逻辑链路开启时确定唯一标识能够明确后续待执行的链路和节点。

链路唯一标识

三个标识共同决定“某个业务场景下的某次执行”业务标识赋予链路业务含义例如“用户id”、“活动id”等等。

场景标识赋予链路场景含义例如当前场景是“逻辑链路1”。

执行标识赋予链路执行含义例如只涉及单次调用时可以直接选择“traceId”涉及多次调用时则根据业务逻辑选取多次调用相同的“公共id”。

节点唯一标识

链路唯一标识

两个标识共同决定“某个业务场景下的某次执行中的某个逻辑节点”节点名称DSL中预设的节点唯一名称如“A”。

步骤二传递串联标识当逻辑链路执行时在分布式的完整链路中透传串联标识动态串联链路中已执行的节点实现链路的染色。

例如在“逻辑链路1”中

当“A”节点触发执行则开始在后续链路和节点中传递串联标识随着业务流程的执行逐步完成整个链路的染色。

当标识传递至“E”节点时则表示“D”条件分支的判断结果是“true”同时动态地将“E”节点串联至已执行的链路中。

2.2.3.

“链路上报”的含义为在链路执行过程中将日志以链路的组织形式进行上报实现业务现场的准确保存。

、上报的日志数据包括节点日志和业务日志。

其中节点日志的作用是绘制链路中的已执行节点记录了节点的开始、结束、输入、输出业务日志的作用是展示链路节点具体业务逻辑的执行情况记录了任何对业务逻辑起到解释作用的数据包括与上下游交互的入参出参、复杂逻辑的中间变量、逻辑执行抛出的异常。

2.2.4.

“链路存储”的含义为将链路执行中上报的日志落地存储并用于后续的“现场还原”。

上报日志可以拆分为链路日志、节点日志和业务日志三类

链路日志链路单次执行中从开始节点和结束节点的日志中提取的链路基本信息包含链路类型、链路元信息、链路开始/结束时间等。

节点日志链路单次执行中已执行节点的基本信息包含节点名称、节点状态、节点开始/结束时间等。

业务日志链路单次执行中已执行节点中的业务日志信息包含日志级别、日志时间、日志数据等。

下图就是链路存储的存储模型包含了链路日志节点日志业务日志、链路元数据配置数据并且树状结构其中业务标识作为根节点用于后续的链路查询。

链路追踪系统技术选型

Dapper论文发出来之后很多公司基于链路追踪的基本原理给出了各自的解决方案如Twitter的ZipkinUber的JaegerpinpointApache开源的skywalking还有国产如阿里的鹰眼美团的Mtrace滴滴Trace新浪的Watchman京东的Hydra不过国内的这些基本都没有开源。

为了便于各系统间能彼此兼容互通OpenTracing组织制定了一系列标准旨在让各系统提供统一的接口。

分布式开源链路追踪系统

Skywalking是一款开源的应用程序性能监控工具旨在帮助开发人员和

DevOps

团队监控分布式应用程序的性能。

它可以帮助用户了解应用程序的运行情况并通过可视化图形和数据报告提供实时的指标和分析。

Skywalking

Python。

它使用分布式追踪技术来监控应用程序内部和外部的所有调用从而获得关于应用程序性能的完整见解。

Skywalking

提供了一系列强大的功能包括性能监控、故障诊断和调试、数据分析等。

它还提供了警报功能当发生重要的性能问题时可以向开发人员和

DevOps

是一款功能强大且易于使用的应用程序性能监控工具。

它可以帮助开发人员和

DevOps

团队更好地了解应用程序的运行情况并在发生性能问题时及时采取行动。

4.2.

agent和业务系统绑定在一起负责收集各种监控数据。

skywalking

oapservice是负责处理监控数据的比如接受skywalking

agent的监控数据并存储在数据库中;接受skywalking

webapp的前端请求从数据库查询数据并返回数据给前端。

Skywalking

oapservice通常以集群的形式存在。

skywalking

webapp前端界面用于展示数据。

用于存储监控数据的数据库比如mysql、elasticsearch等。

4.3.1.

表示对请求提供相同行为的一系列或一组工作负载在使用Agent时可以定义服务的名字服务实例(Service

Instance)

一个服务实例实际就是操作系统上的一个真实进程端点(Endpoint)

方法签名

dependencygroupIdorg.apache.skywalking/groupIdartifactIdapm‐toolkit‐trace/artifactIdversion8.4.0/version

/dependency

如果一个业务方法想在ui界面的跟踪链路上显示出来只需要在业务方法上加上Trace注解即可

我们还可以为追踪链路增加其他额外的信息比如记录参数和返回信息。

实现方式在方法上增加Tag或者Tags。

Tag

注解中

userMapper.list();}TraceTags({Tag(key

param,

skywalking的性能分析在根据服务名称、端点名称以及相应的规则建立了任务列表后在调用了此任务列表的端点后。

skywalking会自动记录剖析当前端口生成剖析结果具体流程如图

4.3.3.

SkyWalking和Prome***usGrafanaAgnet的两个有区别

SkyWalking

是两种主流的监控与性能管理工具组合它们的核心关注点和功能略有不同以下是它们之间的主要区别

4.3.4.

APM应用性能监控特别是分布式系统中的链路追踪。

适用于监控微服务架构下的调用链服务性能以及依赖关系。

跟踪请求从入口到各个服务间的传播路径。

提供更强大的调用链分析和上下文信息。

系统监控与告警Prome***us

提供可视化能力适合创建仪表盘。

适用于监控底层资源与自定义服务指标更侧重于指标的收集和展示。

Prome***us

或探针支持无侵入式数据采集。

在分布式环境中插桩自动记录调用链路。

支持服务拓扑图、调用链分析直接呈现服务调用关系。

数据采集基于拉取模型

模型。

支持大规模的集群或服务通过配置抓取不同端点的数据。

强调高效采集定量指标如每秒请求数、延迟等而非事务级别的细节。

4.3.6.

TraceId、SpanId、调用栈等。

数据更复杂存储要求较高需要

Elasticsearch、H2

使用时间序列数据库存储监控指标。

数据结构简单key-value

TSDB

提供强大的定制化仪表盘支持多种数据源。

更适合基础设施运维团队用于系统资源监控和指标告警。

4.3.8.

SkyWalking。

如果你需要全面监控基础设施、服务和自定义指标Prome***usGrafana

可以根据具体需求和环境甚至同时使用两种工具进行监控。

你觉得哪个更贴近你的场景我可以进一步详细分析或帮助配置。

分布式链路追踪系统实践

大众点评和美团App拥有丰富多样的内容站内外业务方、合作方有着众多的消费场景。

对于内容流水线中的三方分别有如下需求

内容的生产方希望生产的内容能在更多的渠道分发收获更多的流量被消费者所喜爱。

内容的治理方希望作为“防火墙”过滤出合法合规的内容同时整合机器和人工能力丰富内容属性。

内容的消费方希望获得满足其个性化需求的内容能够吸引其种草或辅助其做出消费决策。

生产方的内容模型各异、所需处理手段各不相同消费方对于内容也有着个性化的要求。

如果由各个生产方和消费方单独对接内容模型异构、处理流程和输出门槛各异的问题将带来对接的高成本和低效率。

在此背景下点评内容平台应运而生作为内容流水线的“治理方”承上启下实现了内容的统一接入、统一处理和统一输出

统一接入统一内容数据模型对接不同的内容生产方将异构的内容转化为内容平台通用的数据模型。

统一处理统一处理能力建设积累并完善通用的机器处理和人工运营能力保证内容合法合规属性丰富。

统一输出统一输出门槛建设对接不同的内容消费方为下游提供规范且满足其个性化需求的内容数据。

如下图11所示是点评内容平台的核心业务流程每一条内容都会经过这个流程最终决定在各个渠道下是否分发。

内容是否及时、准确经过内容平台的处理是内容生产方和消费方的核心关注也是日常值班的主要客诉类型。

而内容平台的业务追踪建设主要面临以下的困难与复杂性

业务场景多业务流程涉及多个不同的业务场景且逻辑各异例如实时接入、人工运营、分发重算等图中列出的部分场景。

逻辑节点多业务场景涉及众多的逻辑节点且不同内容类型节点各异例如同样是实时接入场景笔记内容和直播内容在执行的逻辑节点上存在较大差异。

触发执行多业务场景会被多次触发执行且由于来源不同逻辑也会存在差异例如笔记内容被作者编辑、被系统审核等等后都会触发实时接入场景的重新执行。

点评内容平台日均处理百万条内容涉及百万次业务场景的执行、高达亿级的逻辑节点的执行而业务日志分散在不同的应用中并且不同内容不同场景不同节点以及多次执行的日志混杂在一起无论是日志的搜集还是现场的还原都相当繁琐耗时传统的业务追踪方案越来越不适用于内容平台。

点评内容平台是一个复杂的业务系统对外支撑着众多的业务场景通过对于业务场景的梳理和抽象可以定义出实时接入、人工运营、任务导入、分发重算等多个业务逻辑链路。

由于点评内容平台涉及众多的内部服务和下游依赖服务每天支撑着大量的内容处理业务伴随着业务的执行将生成大量的日志数据与此同时链路上报还需要对众多的服务进行改造。

因此在通用的全链路日志追踪方案的基础上点评内容平台进行了如下的具体实践。

5.1.1.

点评内容平台实现了图所示的日志上报架构支持众多服务统一的日志收集、处理和存储能够很好地支撑大数据量下的日志追踪建设。

日志收集各应用服务通过机器上部署的log_agent收集异步上报的日志数据并统一传输至Kafka通道中此外针对少量不支持log_agent的服务搭建了如图所示的中转应用。

日志解析收集的日志通过Kafka接入到Flink中统一进行解析和处理根据日志类型对日志进行分类和聚合解析为链路日志、节点日志和业务日志。

日志存储完成日志解析后日志会按照树状的存储模型进行落地存储结合存储的需求分析以及各个存储选项的特点点评内容平台最终选择HBase作为存储选型。

整体而言log_agent

HBase的日志上报和存储架构能够很好地支持复杂的业务系统天然支持分布式场景下众多应用的日志上报同时适用于高流量的数据写入。

5.1.2.

点评内容平台实现了“自定义日志工具包”即下图13的TraceLogger工具包屏蔽链路追踪中的上报细节实现众多服务改造的成本最小化。

TraceLogger工具包的功能包括

模仿slf4j-api工具包的实现在slf4j框架之上并模仿slf4j-api对外提供相同的API因此使用方无学习成本。

屏蔽内部细节内部封装一系列的链路日志上报逻辑屏蔽染色等细节降低使用方的开发成本。

上报判断

判断链路标识无标识时进行兜底的日志上报防止日志丢失。

判断上报方式有标识时支持日志和RPC中转两种上报方式。

日志组装实现参数占位、异常堆栈输出等功能并将相关数据组装为Trace对象便于进行统一的收集和处理。

异常上报通过ErrorAPI主动上报异常兼容原日志上报中ErrorAppender。

日志上报适配Log4j2日志框架实现最终的日志上报。

下面是TraceLogger工具包分别进行业务日志和节点日志上报的使用案例整体的改造成本较低。

替换前原日志上报

GsonUtils.toJson(structRequest),

e);

GsonUtils.toJson(structRequest),

e);

执行标识TraceUtils.passLinkMark(contentId_type_uuid);//

...//

本地调用(API上报节点日志)TraceUtils.reportNode(contentStore,

contentId,

StatusEnums.RUNNING)contentStore(contentId);TraceUtils.reportNode(contentStore,

structResp,

AOP上报节点日志TraceNode(nodeNamepicProcess)public

Response

业务日志数据上报TraceLogger.warn(picProcess

failed,

基于上述实践点评内容平台实现了可视化全链路日志追踪能够一键追踪任意一条内容所有业务场景的执行并通过可视化的链路进行执行现场的还原追踪效果如下图所示

【链路查询功能】根据内容id实时查询该内容所有的逻辑链路执行覆盖所有的业务场景。

【链路展示功能】通过链路图可视化展示业务逻辑的全景同时展示各个节点的执行情况。

【节点详情查询功能】支持展示任意已执行节点的详情包括节点输入、输出以及节点执行过程中的关键业务日志。

目前可视化全链路日志追踪系统已经成为点评内容平台的“问题排查工具”我们可以将问题排查耗时从小时级降低到5分钟内同时也是“测试辅助工具”利用可视化的日志串联和展示明显提升了RD自测、QA测试的效率。

最后总结一下可视化全链路日志追踪的优点

接入成本低DSL配置配合简单的日志上报改造即可快速接入。

追踪范围广任意一条内容的所有逻辑链路均可被追踪。

使用效率高管理后台支持链路和日志的可视化查询展示简单快捷。

博文参考

分布式链路追踪在字节跳动的实践_哔哩哔哩_bilibilihttps://juejin.cn/post/7234836453654052922美团:

Java

system分布式会话跟踪系统架构设计与实践凤凰架构-可观测性万字破解云原生可观测性zipkinhttps://zipkin.io/Jaegerwww.jaegertracing.io/Pinpointhttps://github.com/pinpoint-apm/pinpointSkyWalkinghttp://skywalking.apache.org/