做衣服网站,phpmysql网站模板,泰安人才市场官网,凤翔网站建设作者#xff1a;图杨
工程师小 A 刚刚接手他们公司最核心的电商系统的运维工作#xff0c;小 A 发现#xff0c;在生产环境中#xff0c;系统明明运行得非常稳定#xff0c;但是总会出现一些“诡异”的情况。比如#xff1a;
偶尔会一些错误调用#xff0c;但是#…作者图杨
工程师小 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发现 1321 到 1328应用 “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” 中在 1340 到 1349 存在许多 5s 以上的慢调用 Step 2先关注 1540 到 15495s 的 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?spm5176.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
