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

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

2024-03-13 274

作者：图杨

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

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

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

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

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

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

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

该功能已正式发布，产品文档 [ 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 在各个维度上进行比较，所以理论上，只要是调用链上拥有的维度能表征的信息，我们都能定位出来，包括但不限于：

主机异常
接口异常
慢 SQL
消息队列异常等等

最佳实践

如何通过错 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

微信关注我们

原文链接：https://my.oschina.net/u/3874284/blog/11047133

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

《行业指标体系白皮书》重磅发布，剖析指标建设困境，构建前瞻性的指标体系（附下载）

正处于企业指标建设过程中的你，是否经常遇到这样的问题： • 各个部门独立建设信息系统，由此产生的指标定义和计算方式各异，导致管理层无法快速准确地掌握整体业务运行状况 • 缺乏对指标的统一管理和规范，产生重复的指标计算工作，导致数据计算资源被过度消耗，增加运维成本和数据处理压力 • 不知道指标体系建设有哪些流程？也不清楚在不同的流程阶段具体需要做哪些事情？更不了解同行业的其他企业的指标建设情况和参考？为了帮助各大企业解决这些指标问题和困境，在杭州师范大学大数据科学研究院及温州数据治理产教融合共同体的专业指导下，袋鼠云凭借其在行业指标体系建设领域的深厚底蕴与丰富的实战经验，汇聚了多位袋鼠云的一线大数据专家，精心编撰了《行业指标体系白皮书》。本白皮书系统阐述了指标体系建设的基础理念、目标价值、建设实施路径、管理原则及规范落地的全过程。不仅构筑了扎实的理论框架，还详尽剖析了三大典型行业在指标体系建设上的实践案例，深度解读了金融、大宗贸易、零售、港口及制造五大关键领域的行业指标库，为企业建设指标体系提供理论+实践的全新参考。 01 前瞻性的企业指标体系管理方法论本白皮书倾力打造了一套全面详...

2024-03-13

309

作者：鼎岳、稚柳、勇猛、家泽一款游戏作品之所以能在市场上引爆热潮，铸就爆款传奇，除了独树一帜的创新设计理念、引人入胜的故事情节和丰富多样的玩法机制之外，最核心的要素就是为玩家提供极致流畅且无与伦比的游戏体验。这种体验涵盖了从游戏载入速度、画面帧率稳定性、操作响应灵敏度到网络环境的优化等多个维度，每一环节都对游戏最终能否赢得市场青睐，并成为爆款起着至关重要的作用。近期，某游戏客户精心打造的一款冒险闯关类游戏，自发布以来便迅速在玩家群体中引发热烈反响，展现出强劲的发展势头，并已多次荣登行业内各大权威畅销榜单的前列。该款游戏之所以能快速崭露头角，不仅得益于其在玩法机制设计上的创新升级和深度优化，更在于它为玩家群体提供了流畅顺滑的游戏体验。游戏中的一处亮点场景，即每周特定时段会举办一场限时约 1 小时的“跨服战”，旨在增进不同服务器玩家之间的社交互动与竞技交流。这一场景具有时间短、频率低的特点，却能在短时间内吸引大量玩家参与，从而产生海量的跨服通信消息。消息中间件在此过程中扮演着至关重要的角色，它位于跨服通信的核心链路上，其可用性与性能表现直接决定了玩家的游戏体验质量。 RocketM...

2024-03-13

283

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。