AIOps 智能运维:比专家经验更优雅的错/慢调用分析工具

简介: 本文主要介绍ARMS 错/慢 Trace 分析功能基本原理; 该功能能够覆盖哪些异常 Trace 根因; 最后会介绍一些最佳实践案例。


1. 背景


工程师小 A 刚刚接手他们公司最核心的电商系统的运维工作,小 A 发现,在生产环境中,系统明明运行得非常稳定,但是总会出现一些“诡异”的情况。比如:


  1. 偶尔会一些错误调用,但是,还没来得及修,系统又莫名奇妙地恢复正常。
  2. 应用的平均响应时间很短,但是总会有一些响应时间非常长的离群调用,每次花很多时间来分析这些离群点,但是每次分析出来的结果都不一样,有时候是数据库问题,有时候是消息队列的问题,原因千奇百怪,很难逐一排查。


如果是经验丰富的工程师,对系统非常非常熟悉,也许能够依靠经验来解决这些“诡异”的问题。但是,对于一个大型公司来说,他们的系统已经迭代了十几年,几百个人贡献过代码,很难再出现对系统非常熟悉的工程师了。所以,每次系统出现问题,小 A 都需要用多种工具,花费大量时间来排查,还要面对客户时不时的投诉;每一次 618 和双十一前夕,大家都战战兢兢,求神拜佛,祈祷千万不要在关键时刻发生异常。


那么,除了专家经验和对好几十种可能性逐一排查之外,有没有更优雅的,快速定位错/慢 Trace 产生原因的工具?


答案是有的,阿里云应用实时监控服务 ARMS 最近推出了错/慢 Trace 分析功能(Trace 是调用链,指从用户发起服务请求到结束,按顺序记录整个请求链路的相关数据,关于 Trace 的介绍可以看[1])。我们会对错/慢 Trace 和正常 Trace 在每一个维度进行对比分析,从而帮助用户挖掘错/慢 Trace 的的共有特征。


该功能不需要任何专家经验,即使小 A 对系统不那么熟悉,他也可以利用这个功能,在大促前夕梳理一下经常出错,或者响应时间远高于平均值的接口和机器,有针对性的对系统进行优化。在这篇文章中,我们将介绍:


  1. ARMS 错/慢 Trace 分析功能基本原理;
  2. 该功能能够覆盖哪些异常 Trace 根因;
  3. 最后会介绍一些最佳实践案例。


该功能已正式发布,产品文档[2]和最佳实践案例[3]均已上线,文章的最后有免登录 demo 的体验链接,欢迎大家来体验。


2. ARMS 错/慢 Trace 分析功能基本原理


在生产环境下,影响调用时延以及引发错误的因素有很多,流量不均、单机故障、程序异常、依赖组件瓶颈等。友商和学术界常用的方式是利用 ML、LLM 对大量 Trace 进行训练,再来对新来的异常 Trace 进行分类,以此来定位根因。但是在实际生产环境中,不同系统的 Trace 特征完全不同,而且随着系统的更新,Trace 的特征以及引发错/慢 Trace 的根因也会不断改变。因此,对于商业可观测产品而言,这种基于历史数据对新数据进行判断的方法,基于我们浅薄的认知,现有的算法可能还不够成熟。


为了避免应用间的差异对错/慢 Trace 根因定位准确率的影响,我们的方案是:


“将错/慢 Trace 和同一系统中,正常 Trace 从各个维度进行对比,识别出错/慢 Trace 的特征,引导用户不断探索,最终定位异常根因。”


举个例子,当用户收到了大量接口报错的告警,但是不知道引发异常的根因是什么。在这种情况下,ARMS 错/慢调用分析功能,会对一个系统中 1000 条错 Trace 样本和 1000 条正常 Trace 样本从各个维度进行比较,发现几乎所有的错 Trace 都集中在应用 "mall-gateway"、主机 “10.0.0.47” 和接口 "components/api/v1/mall/product" 上,并且经过它们的,基本没有正常 Trace,那么和应用名 ="mall-gateway"、主机 Ip=“10.0.0.47” 和接口名 ="components/api/v1/mall/product" 的 Trace 值得进一步排查,因为很有可能就是部署在这台主机上的这个接口出现了问题。



并且,ARMS 支持用户自定义要分析和对比的 Trace,只需要在调用链分析的筛选框修改条件即可,比如可以把 serviceName="mall-gateway" 放到筛选框中,对该应用的错 Trace 进行进一步分析。



您可以不断地重复这个过程,直到您定位到系统的异常。


3. ARMS 错/慢 Trace 分析功能能够覆盖哪些异常 Trace 根因?


我们定位根因的逻辑是,对批量错/慢 Trace 和批量正常 Trace 在各个维度上进行比较,所以理论上,只要是调用链上拥有的维度能表征的信息,我们都能定位出来,包括但不限于:


  1. 主机异常
  2. 接口异常
  3. 慢 SQL
  4. 消息队列异常等等


4. 最佳实践


4.1 如何通过错 Trace 分析功能,排查错调用根因?


Step 1:发现 13:21 到 13:28,应用 "mall-gateway" 出现了一些 Http 错误的调用



Step 2:修改时间窗口到批量 Http 错误发生的时间段,开始排查问题



Step 3:进入错 Trace 分析页面


发现:错调用集中在 3 个维度:接口名 =

"/components/api/v1/mall/product",IP=“10.0.0.47” 以及 IP=“10.0.0.37”,下面依次进行排查。



Step 3.1:排查 spanName="/components/api/v1/mall/product"


发现:接口 "/components/api/v1/mall/product" 的错调用几种在 3 个 Ip 中,并且,路过这些 IP 的,全部都是错误调用。


这说明这三个 Ip 对应的主机很可能出现了异常,下面进行进一步排查。



Step 3.1.1:

serviceName="mall-gateway" AND spanName="/components/api/v1/mall/product" AND ip="10.0.0.47"


发现该筛选条件下,每一次调用都是错误调用,这说明主机 "10.0.0.47" 中,应用 "mall-gateway" 的接口 "/components/api/v1/mall/product"。在该时段确实出现了异常。



可以回到调用链列表页面进一步确认。



可以点击任意一条 Trace 查看详情。


Step 3.1.2:

排查 serviceName="mall-gateway" AND spanName="/components/api/v1/mall/product" AND ip="10.0.0.50"


类似地,发现该筛选条件下,每一次调用都是错误调用。



Step 3.1.3:

排查 serviceName="mall-gateway" AND spanName="/components/api/v1/mall/product" AND ip="10.0.0.37"

......


Step 3.2:排查 Ip ="10.0.0.50" 和 Ip = "10.0.0.37"


其实聪明的读者应该已经发现了问题,刚刚我们在排查接口 "/components/api/v1/mall/product" 时就已经发现了这两台主机有问题。但是我们还是可以继续排查。


发现:对 Ip ="10.0.0.47" 或  Ip = "10.0.0.37" 的错调用开始下钻分析,也指向了接口 "/components/api/v1/mall/product",并且这些错误都是 500 错误。


这和上一步的排查指向了同样的根因,这说明部署在主机 "10.0.0.47" 以及 "10.0.0.37" 上,接口 "/components/api/v1/mall/product" 相关的程序出现了错误,建议查一下相关代码近期的变更。



4.2 如何通过慢 Trace 分析功能,梳理慢接口?

Step 1:发现应用 serviceName="mall-user-server" 中,在 13:40 到 13:49 存在许多 5s 以上的慢调用



Step 2:先关注 15:40 到 15:49,5s+ 的 Trace,将【耗时对比临界值】改成 5s


发现耗时大于 5s 的 Trace 集中在接口 "/components/api/v1/local/success"、"/components/api/v1/http/success" 和 Ip="10.0.0.44" 的主机中。



Step 3:依次排查 2 个接口和一个 Ip 地址


Step 3.1:排查 serviceName="mall-user-server" AND spanName="/components/api/v1/local/success"


发现:该筛选条件下,每一次调用耗时都大于 5s,它是一个慢接口,已经定位到根因。



回 Trace 详情页面进一步确认,发现该筛查条件下,平均耗时就大于 5s。



Step 3.2:排查 serviceName="mall-user-server" AND spanName="/components/api/v1/http/success"


发现:该筛选条件下,每一次调用耗时都大于 5s,它是一个慢接口。



Step 3.3:排查 serviceName="mall-user-server" AND ip="10.0.0.44"


发现:该筛选条件下,慢 Trace 的也指向了接口 "/components/api/v1/http/success",和 Step 3.2 重合了,可以推断接口 "/components/api/v1/http/success" 部署在主机 "10.0.0.44" 上,它出现了一些异常。


当然用户还可以进一步往下探索。



Demo 体验链接


Step 1:切换成新版控制台



Step 2:点击调用链分析按钮



5. 总结


在这篇文章中,我们试图帮助小 A 排查系统中,“诡异”的错/慢调用产生原因。我们给出了一种,比专家经验更优雅的,排查问题的工具—— ARMS 错/慢 Trace 分析,并给出了最佳实践教程。


通过使用 ARMS 错/慢 Trace 分析功能,系统发生故障的时候,小 A 可以不再依靠“直觉”来排查问题;在大促前夕,也可以梳理出慢调用接口、容易引发错误的主机等,这样工程师们能够更优针对性地对系统进行优化。


这样,工程们在排查问题上花的时间少一点,专注在业务代码上的时间多一点,把核心业务做大做强。


欢迎加入我们的 AIOps 客户交流钉钉群(群号:25125004458):



相关链接:

[1] 基础篇丨链路追踪(Tracing)其实很简单

[2] 查看应用的调用链信息_应用实时监控服务(ARMS)-阿里云帮助中心

[3] 通过错/慢调用链排查应用产生异常的原因_应用实时监控服务(ARMS)-阿里云帮助中心


作者:图杨

作者介绍
目录