一、全链路背景

二、全链路概念原理

三、项目场景实践

四、全链路项目价值

全链路背景

为什么会有链路追踪（Trace）系统这个概念？

图一

在2010年，google发表了一篇名为“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”的论文，在文中介绍了google生产环境中大规模分布式系统下的跟踪系统Dapper的设计和使用经验。而Twitter的Zipkin，Uber的Jaeger，阿里的鹰眼，美团的Mtrace等系统都是基于这篇文章而实现的。

随着微服务、容器等新型架构技术的流行，分布式系统环境的调用链追踪问题也变得愈加复杂。简单来说就是已有的监控手段不能满足现在大型集群系统或跨系统的应用监控需求，链路追踪系统也就应运而生。2010年，谷歌开源了其内部使用的分布式追踪系统Dapper，此后很多企业和组织发布了各自的分布式追踪系统，其中比较知名的开源项目包括Zipkin、Pinpoint等。

随着金融科技日益盛行，金融机构IT系统及承载物理环境日趋复杂，为了保障业务系统的正常运行，支撑日益增长的庞大业务群，交易全链路监控系统主要应用于各种交易数据的采集和分析监控。

金融机构业务往往会产生大量的数据，除了核心系统交易数据，还有手机银行、网贷平台等不同模块的链路日志。交易全链链路监控系统需要准确处理这些数据，才能保证融资申请、贷款审批、放款等业务流程的顺利进行。这些数据中，如果有一项出错，就可能会影响整个系统的正常运转。“全链路交易监控系统”可以对这些海量数据进行实时链式跟踪、预警，防范故障蔓延，有效保障系统的稳定运行。

链路分析难点

• 故障定位难
  一次请求往往需要涉及到多个服务，这些服务很能是由不同团队负责。一旦出现问题，只知道有异常，但具体的异常在哪个服务引起的就需要进入每一个服务里面看日志，这样的处理效率是非常低的，最坏的情况可能拉上多个团队一起定位问题。
• 性能分析难
  一个服务依赖于后台多个服务， 如果中间某个接口的耗时异常，开发得从自己开始，逐步分析各依赖接口的耗时情况。
• 链路梳理难
  一笔交易经过n个系统，经过上百上千个接口服务，一笔笔交易各不同。

全链路概念原理

在这里，我们对链路追踪、调用链、全链路、分布式链路追踪的概念不做区分，可以理解为整个链路，一个链路会经过如下图的调用过程：

图二

上一段的图一表示一个最典型的请求调用过程，所谓链路就是把图中 (1-6) 这6个环节串连起来。在进行链路分析时，需要为每次请求定义一个唯一标识traceid，这样才能根据traceid查出本次请求调用的所有服务。

图中标示的 (1-6) 分别代表两服务之间的一个请求-应答对，我们把它定义为一个span，每个span包含以下字段：

• TraceId：一次业务请求会分配一个唯一的 TraceID，用它来标记一次完整服务调用。rpc 的时候，框架会通过带内数据的方式吧 TraceID 传递到下游 svr，本请求涉及的所有 rpc 上报的 span 拥有同一个唯一的 TraceID， 系统可以通过 TraceID 把所有 rpc 的 span 关联起来，形成一个 span 集合。
• SpanId ：span 的 ID，每个合并 span 在一个 traceId 下有唯一的 SpanID。为了方便后续处理，一个 rpc 的“主调 span”和“被调 span”拥有相同的 spanID
• ParentId：父span的id，调用有层级关系；
• Timestamp：span创建时的时间戳
• Duration：开始span到结束span的持续时间，单位微秒；
• ServiceName：服务名
• Name：接口名字
• Annotations：记录事件，value有一些预定义的值，例如客户端发送(cs)，客户端接收(cr)，服务端接收(sr)，服务端发送(ss)等
• Tags：记录附加数据成功与否（status）、错误类型（errortype）、其他字段（attribute、remark) ... ...

图三：状态码

• status:0 调用成功
• status:1 自身错误
• status:2 非自身错误
• status:3 超时错误

图四：耗时

• Starttime:span创建时的时间戳
• Endtime:span调用结束的时间戳
• Take_time:一笔请求消费的时间

有了timestamp字段，就可以计算出从服务调用到服务返回的总耗时，但是这个时间包含了服务的执行时间和网络延迟，有时候我们需要区分出这两类时间以方便做针对性优化。那如何计算网络延迟呢？我们可以把调用和返回的过程分为以下四个事件：

• Client Sent：cs事件，指客户端发起调用请求到服务端；
• Server Received：sr事件，指服务端接收到了客户端的调用请求；
• Server Sent：ss事件，指服务端完成了处理，将信息返回给客户端；
• Client Received：cr事件，指客户端接收到了服务端的返回信息。

图五

我们将span的四个基本事件补充到调用链图上，得到图六。

图六

在图六中，对服务器Service0来说，会产生两个事件，一个是发起事件cs，另一个是接收事件cr。对Service1来说，首先要接收Service0请求，即事件sr，当处理完成时，作为服务端对服务器Service0进行响应，即事件ss。其它服务之间的交互事件以此类推。

规范地记录以上日志，通过日志易SPL（Search Processing Language）进行分析统计，进而实现可视化呈现，将帮助金融企业更好地监控业务调用状态及健康度，快速实现故障定位，分析及优化业务性能瓶颈。

项目场景实践

图七

链路分析日志需要和业务日志做联动，业务日志包括系统分析日志以及追溯涉及的日志，调用链日志包括全链路监控的拓扑以及单笔调用链和呈现方式。

• IT系统静态拓扑：网络架构或系统架构监控指标的实时动态展现。静态拓扑是从系统或网络结构层面上进行呈现，能体现业务系统的架构、从上游到下游的流转、分流的情况，每个节点上包括曲线、指标统计等信息。在运维以及安全态势方面，指标统计可以发现异常问题。
• 业务全局概览：通过系统维度/业务维度/异常维度三大维度展示业务系统整体运行状况。系统维度呈现的是成功率的同环比，可以钻取到每个系统专题分析页面产品维度呈现的是黄金指标，比如交易量、平均耗时、成功率、错误等指标；异常维度呈现的是发现问题的概览统计，它按系统维度对错误进行趋势图展示，可以钻取到链路分析页面。
• 全链路监控：对接口级服务调用关系进行自动拓扑，形成对整个交易路径动态全局监控，异常故障点自动标识。宏观监控：监控交易的接口级运行状况；指标统计：将接口的调用量、成功率、平均耗时、自身错误、非自身错误、超时错误等指标做统计，进行浮窗展示；异常标注：当出现不同错误时，可以用不同颜色来标记；历史追溯：追溯时间轴历史及标注，比如历史拓扑播放、时间轴异常点标记、已知异常标注等。
• 一键链路跟踪：故障点信息联动传递实现针对单次交易请求进行链路跟踪分析，快速定位到异常主机和接口。比如可以对系统调用总量、系统调用失败总量、当前耗时最高接口及耗时、接口错误类型统计、接口平均耗时等指标进行分析。
• 根因追溯：异常信息进一步关联业务日志、报错日志进行根因追溯查询。全链路原始日志查询。例如，可通过remask字段进行相应关联日志的查询。

IT系统静态拓扑

图八

某业务额度申请-全局概览

图九是基于日志改造的「某业务额度申请」链路动态自动拓扑图，我们可以看到一笔交易经历的各个接口，通过选择不同的交易业务类型，动态拓扑图会自动的展示一分钟内这类交易所有的流程。

图九

• 自动生成拓扑图，其中节点的增加与减少随着时间自动变化（用户可以手动调整节点位置，固定布局，以求美观）
• 接口级（系统、服务、接口、函数）从宏观的角度监控接口级的交易运行状况
• 指标：调用量、平均耗时、成功率、自身错误、非自身错误、超时错误
• 时间轴：接口指标状态回放，历史拓扑播放、时间轴异常点标记、已知异常标注
• 异常颜色标记，超过阈值时，会标记颜色自定义
• 最大耗时：向下钻取

图十：某业务额度申请-全局概览

通过系统维度、产品维度、异常维度三大维度展示整体运行状况。

• 系统维度呈现的是成功率的同环比，可以钻取到每个系统专题分析页面；
• 产品维度呈现的是黄金指标，比如交易量、平均耗时、成功率、错误等指标；
• 异常维度呈现的是发现问题的概览统计，它按系统维度对错误进行趋势图展示，可以钻取到链路分析页面。

调用链故障定位

利用跟踪数据，可以还原调用链，再结合日志数据，可以快速实现故障定位，并重现调用过程顺序。

图十一图十二

链路梳理有了跟踪数据，画出业务拓扑图就是水到渠成，能根据链路跟踪日志内容自动生成服务级、接口级、函数级拓扑视图。

动态自动拓扑

• 业务服务调用拓扑
• 1m粒度动态展现
• 业务类型区分及接口细分
• 依据上述traceid、span属性实时计算

服务调用接口级别自动拓扑

• 接口级（系统、服务、接口、函数）
  从宏观的角度监控接口级的交易运行状况
• 浮窗展示
  「调用量」「成功率」「平均耗时」「自身错误」「非自身错误」「超时错误」
• 异常标注
  三种错误中当出现「自身错误」「超时错误」时，整个节点标红
  节点「平均耗时」超过阈值时（生产上线后会根据历史耗时进行分析，给出建议阈值，也需要各项目组提供一个基准阈值），整个节点标黄
• 时间轴历史追溯及标注
  历史拓扑播放、时间轴异常点标记、已知异常标注

全链路分析价值

01-可观察性

Logging、Tracing、Metrics融合，提升服务可观察性

02-开发测试及链路优化

异常监控数据二次统计分析，优化异常节点

开发过程中查看关联模块的日志和作为测试提单线索

03-拓扑模式异常检测

拓扑结构形成基线，异常发现与告警

影响范围快速确认，启动应急预案

04-个例分析及宏观监控

点面结合，快速故障定位

统计为多维数据用于监控告警和原因分析