作者：图杨
工程师小 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 体验链接
Step 1：切换成新版控制台
Step 2：点击调用链剖析按钮
总结
在这篇文章中，咱们企图协助小 A 排查体系中，“怪异”的错/慢调用发生原因。咱们给出了一种，比专家经历更高雅的，排查问题的东西—— ARMS 错/慢 Trace 剖析，并给出了最佳实践教程。
经过使用 ARMS 错/慢 Trace 剖析功用，体系发生毛病的时分，小 A 能够不再依托“直觉”来排查问题；在大促前夕，也能够整理出慢调用接口、容易引发过错的主机等，这样工程师们能够更优针对性地对体系进行优化。
这样，工程们在排查问题上花的时刻少一点，专心在事务代码上的时刻多一点，把中心事务做大做强。
欢迎加入咱们的 AIOps 客户交流钉钉群（群号：25125004458）：
相关链接：
[2] 查看使用的调用链信息_使用实时监控服务(ARMS)-阿里云协助中心
[3] 经过错/慢调用链排查使用发生反常的原因_使用实时监控服务(ARMS)-阿里云协助中心
