稳定性专题 | 通过链路追踪快速发现和定位业务问题的实践

本文涉及的产品
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
性能测试 PTS,5000VUM额度
云原生网关 MSE Higress,422元/月
简介:

导读

『StabilityGuide』是阿里多位阿里技术工程师共同发起的稳定性领域的知识库开源项目,涵盖性能压测、故障演练、JVM、应用容器、服务框架、流量调度、监控、诊断等多个技术领域,以更结构化的方式来打造稳定性领域的知识库,欢迎您的加入。

✅ @GitHub :
https://github.com/StabilityMan/StabilityGuide
✅ @钉钉群:

lADPDgQ9rfBu__bNAyDNAmw_620_800_jpg_620x10000q90g

  • 正文开始 -

🧯

引言

在可观察性领域,Metrics,Tracing 和 Logging 的介绍由来已久。三种之间的边界越来越模糊。OpenTracing 中已经支持 LogEvent,OpenTelemetry 已经把 OpenMetric 和 OpenTracing 整合到一块。今天我们要介绍的链路追踪的业务分析功能,通过对链路数据进行聚合统计,可以查看各种业务报表。

lADPDgQ9rfBu__fNAZDNAmU_613_400_jpg_620x10000q90g

为什么需要业务分析关联链路数据?

精细化分析,全链路数据,快速发现和定位问题。

在传统的 APM 分析中,主要是关注各种接口的响应时间,对业务不够贴切,这样会带来一些问题:

发现问题

同一个接口被很多业务方调用,某一个重要业务调用出了问题,由于这个业务占比不高,无法通过平均数或者 p90 分析出来。例如创建订单中重要客户,这些客户订单占比不高,但是重要性比较高,需要重点分析和监控。

排查定位问题

某些用户反馈下单或者付款出现问题,但是这种情况只存在少量用户,重现比较困难。如果把用户的异常和链路关联起来,分析异常用户的链路数据,比如出入参数,用户属性等,可以发现一些线索。例如查看用户 ID 对应的失败订单,分析订单上链路,发现失败订单的来源都是某个旧版的客户端调用。

业务分析概述

在介绍业务分析功能之前,先简单提两个问题,大家发散思考下怎么解决这两个问题。
1、某个应用的对外接口流量突增,是不是由于某个用户或者地域流量暴涨?
2、应用出现比较多空指针异常,这些异常对业务有多大的影响?

通用的监控系统主要是对操作系统,分布式调用,数据库组件进行监控。如果对业务监控,那就需要开发同学对调用链埋点添加业务属性(用 tag 来记录各种业务属性)。通过对 tag 标签进行过滤和统计聚合,达到业务分析和监控的效果。

lADPDgQ9rfBu__rNAhjNBQA_1280_536_jpg_620x10000q90g

业务分析的实现方式

业务分析是在链路上标注一些业务数据,以下我们用 Jaeger 和 Skywalking 为例子讲解业务埋点。

Jaeger 中添加 Tag 信息

以 Java 语言为例,

// 获取业务中的用户Id
String userId = ****;
Tracer tracer = GlobalTracer.get();
if (tracer != null && tracer.activeSpan() != null) {
  // 将 UserId以 Tag 的形式存放到链路中
  tracer.activeSpan().setTag("userId", userId);
}

Skywalking 中添加 Tag 信息,
不插入代码的方式:
https://github.com/apache/skywalking/blob/master/docs/en/setup/service-agent/java-agent/Customize-enhance-trace.md

<class class_name="test.apache.skywalking.testcase.customize.service.TestService2">
     <method method="staticMethod(java.lang.String,int.class)" operation_name="/is_2_static_method" static="true">
          <tag key="tag_2_1">arg[0]</tag>
          <log key="log_1_1">arg[1]</log>
     </method>
</class>

用 OpenTracing 插入代码方式

// global tracer object
private static Tracer tracer = new SkywalkingTracer();
...
 if (tracer != null && tracer.activeSpan() != null) {
      tracer.activeSpan().setTag("userId", yourUserId);
  }

Java 代码方式:

ActiveSpan.tag("userId", yourUserId);

Java 注解方式

@Tag(key = "userId", value = "arg[0]")
@Tag(key = "requestId", value = "arg[1]")
public someMethod(final String userId, final String requestId) {
    // ...
}

对链路数据进行业务分析

Tag 信息就好比给图书打上编号分类信息,让我们可以在图书馆海量的图书中找到我们需要图书。通过 Tag 来进行分类、查找、统计,可以快速找到我们需要的数据。

业务标签的过滤

可以通过筛选 Tag 进行过滤,寻找所需要的链路。如下图,查看手机端下单的请求的变化趋势,详情等。

lADPDgQ9rfBu__3NAmPNBQA_1280_611_jpg_620x10000q90g

业务标签的聚合

指定 Tag 进行聚合,分析 Tag 聚合的统计。如下图查看每个入口(PC 和 Mobile)的请求数,响应时间,异常查询。可以识别是不同业务的对比情况。

lADPDgQ9rfBu___NAivNBQA_1280_555_jpg_620x10000q90g

业务分析的一些使用场景案例

Tag 功能主要是业务开发同学用来进行业务监控的, 通过在链路上写入 Tag,可以把业务和链路打通,从而很好的发现,定位,跟踪问题。

我们接下来做一些业务场景举例。

业务异常分析

生成订单时,会调用优惠,库存,物流,商品等系统接口。这些接口都有可能会返回异常,有些异常有些比较重要,有些只是用于展示。我们怎么快速识别当前应用的异常严重程度呢?可以通过加 Tag 的方式来实现。我们对异常进行分 1~5 级,1 级表示非常严重。

那我们每次调用远程接口完成后,对返回的异常添加 Tag,例如调用优惠时返回系统异常加 Tag: tracer.activeSpan().setTag("bizErr", “1-PromotionSysExcep”); ,调用库存返回库存不足,可以添加tracer.activeSpan().setTag("bizErr", “5-InventoryNotEmpty”);

那么通过 Tag bizErr 进行聚合,对数量进行排序下,如果 1-** 开头的比较多,那表示当前系统比较严重,需要紧急处理。查看这些异常链路的请求参数或者返回值,我们可以快速定位问题。

lADPDgQ9rfBvAADNAoTNBQA_1280_644_jpg_620x10000q90g

用户分析

将 UserId 用 Tag 方式写入到 Span 中,可以统计到没有用户的数据,例如访问量,响应时间。我们之前遇到一个问题,Web 的流量突然变大,响应比较慢。从监控来看流量比较大,但为什么流量会比较大呢,通过 UserId 分组统计后,发现某个用户的流量暴涨,导致整个后台响应比较慢,对这个用户进行限流后,web流量和相应时间恢复正常。

lADPDgQ9rfBvAAHNAmzNBNo_1242_620_jpg_620x10000q90g

业务大盘

中台系统中各个业务的创建订单大盘。

在中台应用中,各个业务使用同一个交易系统,通过订单中的一个业务类型字段来区分不同的业务。通过在链路上的标签,可以查看到不同业务线的下单成功和失败曲线。比如大盘上可以展示天猫,聚划算,盒马生鲜等业务的订单情况。一旦有异常就可以分析链路的明细信息来查找原因。

和传统的统计不同点

传统的 ELK 方式,用户通过插入代码,将业务的属性都打到日志里面。通过数据聚合,可以生成各种 Metrics,添加告警等。这样做监控是合适的,但是需要更深层次的挖掘问题的话,还需要和链路打通。将监控的内容上下游的信息都串起来,可以更方便的定位问题。

比如:更新库存失败,发现异常都是上游某个业务的某台机器上,而这条机器是灰度机器,使用了非稳定版本的。

总结

业务排查的问题方式有很多种,调用链和业务信息打通已经是一种行之有效的方法。通过在调用链写入业务信息,将会给调用链配上显微镜,快速发现隐藏在链路数据中的各种问题。而业务数据关联调用链,也给业务排查插上翅膀,从链路的上下文信息中快速找到线索。

本文作者:徐建伟,花名竹影,阿里云技术专家,多年系统架构,性能调优经验, 目前主要从事链路跟踪,应用监控相关工作。

相关实践学习
基于OpenTelemetry构建全链路追踪与监控
本实验将带领您快速上手可观测链路OpenTelemetry版,包括部署并接入多语言应用、体验TraceId自动注入至日志以实现调用链与日志的关联查询、以及切换调用链透传协议以满足全链路打通的需求。
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
相关文章
|
存储 缓存 前端开发
基于Otel的前端全链路追踪思考和实践
本文内容是笔者基于 GOTC 2023 全球开源技术峰会整理。前端为什么要接入链路追踪大家都应该经历过这样的事情:某一个页面或者某一个请求比较慢,前后端分别调查后数据对不上,或者很难说明差异的来源是由什么造成的,这就是单点监控带来的问题。然后是问题定位,前端作为系统的出入口,导致很多团队问题一般界线模棱两可的问题都会交给前端去定位,相信很容前端应该都经历过这样的痛苦,而作为前端也只能人肉的去分析这
5570 0
基于Otel的前端全链路追踪思考和实践
|
JavaScript 小程序 Java
Spring Boot 实现日志链路追踪,无需引入组件,让日志定位更方便!
Spring Boot 实现日志链路追踪,无需引入组件,让日志定位更方便!
|
JavaScript 小程序 Java
手动实现 SpringBoot 日志链路追踪,无需引入组件,日志定位更方便!
手动实现 SpringBoot 日志链路追踪,无需引入组件,日志定位更方便!
|
Java Spring
Spring Boot 实现日志链路追踪,无需引入组件,让日志定位更方便!
Spring Boot 实现日志链路追踪,无需引入组件,让日志定位更方便!
502 0
|
存储 分布式计算 运维
分布式链路追踪Jaeger + 微服务Pig在Rainbond上的实践分享
随着微服务架构的流行,客户端发起的一次请求可能需要涉及到多个或 N 个服务,致使我们对服务之间的监控和排查变得更加复杂。
|
监控 网络协议 Java
分布式链路追踪- SkyWalking使用手册
分布式链路追踪- SkyWalking使用手册
1212 0
分布式链路追踪- SkyWalking使用手册
|
3月前
|
存储 监控 开发者
分布式链路监控系统问题之系统拆分后链路追踪技术的问题如何解决
分布式链路监控系统问题之系统拆分后链路追踪技术的问题如何解决
|
6月前
|
消息中间件 SpringCloudAlibaba Java
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
【Springcloud Alibaba微服务分布式架构 | Spring Cloud】之学习笔记(八)Config服务配置+bus消息总线+stream消息驱动+Sleuth链路追踪
990 0
|
12月前
|
存储 监控 数据可视化
Golang链路追踪:实现高效可靠的分布式系统监控
Golang链路追踪:实现高效可靠的分布式系统监控
|
消息中间件 监控 安全
RocketMQ x OpenTelemetry 分布式全链路追踪最佳实践(3)
RocketMQ x OpenTelemetry 分布式全链路追踪最佳实践
140 0
RocketMQ x OpenTelemetry 分布式全链路追踪最佳实践(3)