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

作者：图杨

工程师小 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 的体验链接，欢迎大家来体验。

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 进行进一步分析。

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

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

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

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

最佳实践

如何通过错 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" 相关的程序出现了错误，建议查一下相关代码近期的变更。

如何通过慢 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 体验链接

https://www.aliyun.com/product/arms?spm=5176.26798190.J_8765075780.1.7b673fd69umBcT

Step 1：切换成新版控制台

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

总结

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

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

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

欢迎加入我们的 AIOps 客户交流钉钉群（群号：25125004458）：

相关链接：

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

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

https://help.aliyun.com/zh/arms/application-monitoring/user-guide/call-chain-analysis

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

https://help.aliyun.com/zh/arms/application-monitoring/use-cases/troubleshooting-application-anomalies-through-error-slow-trace-analysis