什么是ARMSArthas诊断

本篇内容介绍了“什么是ARMS Arthas诊断”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

创新互联建站主要企业基础官网建设，电商平台建设，移动手机平台，小程序开发等一系列专为中小企业按需定制开发产品体系；应对中小企业在互联网运营的各种问题，为中小企业在互联网的运营中保驾护航。

首先来看看我们排查线上问题的一个基本步骤，这个步骤一般是排查大多数线上问题的步骤。

步骤1：找到能复现问题的输入；

步骤2：判断该输入能否在日常环境构造, 如果能，调到步骤 5。如果不能，继续步骤 3；

步骤3：查看线上环境日志，看能否找到异常输入相关的异常日志，辅助排查问题；

步骤4：初步推断问题原因，尝试修复并加上更多日志输出。然后打包、发布。重复步骤 3 直到定位根因；

步骤5：日常构造相同输入，单点调试，定位问题；

实际的场景中，因为线上线下环境隔离的问题，线上的输入很多时候难以在日常环境中构造，大多数时候我们都在步骤 2、3、4 中循环，于是时间就在循环中慢慢的流逝了。

上面做这么多步骤其实对于查问题而言就是希望可以知道当某段代码执行不符合预期的时候，这段代码的输入是什么，输出是什么，抛出了什么异常，以及代码中每一行的具体执行情况。那么是否有一款产品可以让用户方便快捷的实现这个目标呢？答案是有的。

聊一聊 ARMS

阿里云的应用实时监控服务 ARMS  是一款应用性能管理（APM）产品，包含应用监控、Prometheus 监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、APP 等领域的性能管理，能帮助用户实现全栈式性能监控和端到端全链路追踪诊断。

ARMS 最新推出了 Arthas 诊断功能，其第一个版本主要包含四个能力，分别是 JVM 概览、线程耗时分析、方法执行分析以及性能分析。

• JVM 概览：查看实时的 JVM 内存、GC 信息以及操作系统信息、环境变量、系统变量等信息。

• 线程耗时分析：查看实时的线程耗时情况，并可查看每个线程实时的方法堆栈。

• 方法执行分析：实时的抓取满足指定条件的方法执行明细、出入参数以及异常。

• 性能分析：快捷的通过火焰图的的形式，展示系统性能瓶颈。

ARMS 的 Arthas 功能使用起来也比较简单，详情可参照文档（ https://help.aliyun.com/document_detail/204809.html ）。下面来简单聊一聊如何利用 ARMS 的 Arthas 诊断能力来进行线上问题的定位。

聊一聊 ARMS Arthas 诊断

上一节简单介绍了 ARMS 的 Arthas 诊断具备的能力，那么用这些能力能解决哪些线上问题呢？在这里，我们对线上问题进行了一个归纳总结，将其分为下面四类问题：

• 方法执行不符合预期：包括方法执行耗时、方法返回值、方法抛出了异常等情况，表现在应用上可能是一些接口或者服务的 RT 增高，错误率增高，返回值异常等。

• 进程 CPU 耗时突增：一般有代码死循环问题、FullGC 导致 GC 线程耗时高、并发使用 HashMap 等。

• 性能优化问题：主要用于分析性能瓶颈，辅助性能优化，包括 CPU 耗时、内存分配、锁竞争、itimer 等情况的性能分析。

• 其他问题：比如初始化环境变量读取错误、内核版本不符合要求、类冲突等问题。

下面就以一个实际的 demo 来演示如何利用 ARMS 的 Arthas 执行不符合预期这种问题的诊断，后续的文章会继续介绍如何利用 Arthas 进行其他类型问题的诊断。

利用 ARMS Arthas 诊断方法执行不符合预期类问题

问题背景：product 应用的 com.alibabacloud.hipstershop.productserviceapi.service.ProductService@confirmInventory   

接口某次发布后平均 RT 到达 400，发布以前的平均 RT 在 1ms 以下，如下图所示。现在想定位耗时具体耗在哪儿 。 

首先，进入 ARMS Arthas 诊断的页面。当我们进行 Bug 定位的时候，首先需要知道出问题的类名和方法名，按照图示截图中的红色注释输入相应的类名和方法名。如果你是 EDAS用户，可直接选择一个服务或者接口，后台会自动推断相应的实现类和方法。对应到本案例，对应的类是 com.alibabacloud.xxx.xxx.xxx.ProductService，方法是 confirmInventory。填写完毕后点击确定。

如下图所示，点击确定后可以得到 confirmInventory 方法执行的纪录，包含执行的入参，返回值异常以及方法执行明细。

但是这次执行的耗时 2.89 ms，不是我们预期中的一次耗时高调用。此时，可点击右上角修改诊断参数，设定抓取耗时大于 300ms 的方法调用(除此以外还可以设置更多的过滤条件，包括方法参数满足的条件等等，具体可查看文档)。

点击确定后，点击右上角刷新图标再次诊断，这次抓取到一次耗时 1501ms 的方法调用，发现原来是在该方法的执行过程中，执行了 Thread.sleep() 方法。

到这里，你可能还会好奇，为什么会执行 sleep 方法呢？这块代码的逻辑是怎样的呢？点击右上角查看方法源码，一目了然的将方法源码与方法执行明细相结合。如下图所示，confirmInventory 方法中执行的每一次方法调用最后会以“//-”为前缀展示该方法执行的耗时情况。

此外，你还可以点击图5 ，列表最右侧的操作列的下钻，快捷的进一步分析 confirmInventory 调用的子方法的执行情况。这在根因比较深的场景下十分方便好用。

至此，完成了我们这个问题的一个定位演示。

相信 ARMS 的 Arthas 诊断功能一定给你留下了深刻的印象，也一定会成为您线上问题诊断的利器，帮助您更快更方便的诊断线上故障。

“什么是ARMS Arthas诊断”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站，小编将为大家输出更多高质量的实用文章！