共计 3176 个字符，预计需要花费 8 分钟才能阅读完成。
简介：因为线上线下环境隔离的问题，线上的输出很多时候难以在日常环境中结构，定位 bug 效率低下。是否有简略快捷的方法呢？
一个小故事
周末 12 点的闹钟在回龙观均价 3000 的出租屋短促的响起，程序员小 A 慵懒的拿过手机，滑开手机告诉栏，没有未接电话，点开手机的拦挡信箱，没有报警短信，昨晚的公布肯定很顺利。小 A 幸福的伸了个懒腰。戴上 3000 块的 BeatsSolo Pro，音乐逐步响起来，小 A 缓缓的闭上了眼睛，正午的阳光从窗户漫进来，撒在小 A 稠密的头发上。此时的小 A 正在脑海中勾画着本人美妙的将来。房东说：十年前住在这间屋的小 B，当初曾经是某度的 T10 大佬，五年前住在这儿的小 T，当初曾经在某条率领 200 人的团队，想到这儿，小 A 的嘴角微微上扬，那我也肯定不会太差吧～
嘀嘀.. 耳机里传来两声音讯提示音，小 A 心里咯噔一声，刺骨的寒意洋溢开来，北京三月的阳光忽然就不暖了。小 A 使劲的微微睁开双眼，告诉栏测试同学小 C 的头像一闪而过。
xx 线上 BUG 紧急修复群
小 C:“@小 A 昨晚上线的代码如同有点有问题，来公司看下？我在公司等你。”
点开群设置，老板的头像赫然在列。
怀着愧疚、彷徨、懊悔、无奈、愤恨的情绪，小 A 翻身穿上他在路边买的价值 20 元的人字拖，坐上了返回西二旗的地铁十号线。
不久，西二旗某办公室传来了亘古不变的对话，“这段代码测试过，在我电脑上没问题啊”、” 你重启下试试 ”、“是不是代码没上线”、“是不是谁把我代码冲掉了”、“你们测试数据是不是有问题呀”……于是一个下午过来了、一个早晨过来了、一个周末过来了、一个程序员的青春过来了、一个程序员本就不长的职业生涯过来了。
一个小总结
下面这个虚构的小故事只是想阐明一个简略的景象，程序员的很多工夫被线上 bug fix 占据。因为线上线下环境不统一、输入输出不一等等起因，很多 bug 定位起来效率低下，耗时巨长，导致很多时候程序员遇到线上 bug 总是头疼不已，情不自禁的想要甩锅给外在因素，在确定是本人的问题的时候再排查问题。那么线上问题排查到底难在哪儿？首先来看看咱们排查线上问题的一个根本步骤，这个步骤个别是排查大多数线上问题的步骤。
步骤 1：找到能复现问题的输出；
步骤 2：判断该输出是否在日常环境结构, 如果能，调到步骤 5。如果不能，持续步骤 3；
步骤 3：查看线上环境日志，看是否找到异样输出相干的异样日志，辅助排查问题；
步骤 4：初步推断问题起因，尝试修复并加上更多日志输入。而后打包、公布。反复步骤 3 直到定位根因；
步骤 5：日常结构雷同输出，单点调试，定位问题；
理论的场景中，因为线上线下环境隔离的问题，线上的输出很多时候难以在日常环境中结构，大多数时候咱们都在步骤 2、3、4 中循环，于是工夫就在循环中缓缓的流逝了。
下面做这么多步骤其实对于查问题而言就是心愿能够晓得当某段代码执行不合乎预期的时候，这段代码的输出是什么，输入是什么，抛出了什么异样，以及代码中每一行的具体执行状况。那么是否有一款产品能够让用户方便快捷的实现这个指标呢？答案是有的。
聊一聊 ARMS
阿里云的利用实时监控服务 ARMS 是一款利用性能治理（APM）产品，蕴含利用监控、Prometheus 监控和前端监控三大子产品，涵盖分布式应用、容器环境、浏览器、小程序、APP 等畛域的性能治理，能帮忙用户实现全栈式性能监控和端到端全链路追踪诊断。
ARMS 最新推出了 Arthas 诊断性能，其第一个版本次要蕴含四个能力，别离是 JVM 概览、线程耗时剖析、办法执行剖析以及性能剖析：
• JVM 概览：查看实时的 JVM 内存、GC 信息以及操作系统信息、环境变量、零碎变量等信息。
• 线程耗时剖析：查看实时的线程耗时状况，并可查看每个线程实时的办法堆栈。
• 办法执行剖析：实时的抓取满足指定条件的办法执行明细、出入参数以及异样。
• 性能剖析：快捷的通过火焰图的的模式，展现零碎性能瓶颈。
ARMS 的 Arthas 性能应用起来也比较简单，详情可参照文档。上面来简略聊一聊如何利用 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 以下，如下图所示。当初想定位耗时具体耗在哪儿。
图 1
首先，进入 ARMS Arthas 诊断的页面。当咱们进行 BUG 定位的时候，首先须要晓得出问题的类名和办法名，依照图示截图中的红色正文输出相应的类名和办法名。如果你是 EDAS 用户，可间接抉择一个服务或者接口，后盾会主动推断相应的实现类和办法。对应到本案例，对应的类是 com.alibabacloud.xxx.xxx.xxx.ProductService，办法是 confirmInventory。填写结束后点击确定。
图 2
如下图所示，点击确定后能够失去 confirmInventory 办法执行的纪录，蕴含执行的入参，返回值异样以及办法执行明细。
图 3
然而这次执行的耗时 2.89ms，不是咱们预期中的一次耗时高调用。此时，可点击右上角批改诊断参数，设定抓取耗时大于 300ms 的办法调用(除此以外还能够设置更多的过滤条件，包含办法参数满足的条件等等，具体可查看文档。
图 4
点击确定后，点击右上角刷新图标再次诊断，这次抓取到一次耗时 1501ms 的办法调用，发现原来是在该办法的执行过程中，执行了 Thread.sleep() 办法。
图 5
到这里，你可能还会好奇，为什么会执行 sleep 办法呢？这块代码的逻辑是怎么的呢？点击右上角查看办法源码，高深莫测的将办法源码与办法执行明细相结合。如下图所示，confirmInventory 办法中执行的每一次办法调用最初会以“//-”为前缀展现该办法执行的耗时状况。
图 6
此外，你还能够点击图 5，列表最右侧的操作列的下钻，快捷的进一步剖析 confirmInventory 调用的子办法的执行状况。这在根因比拟深的场景下非常不便好用。
至此，实现了咱们这个问题的一个定位演示。
置信 ARMS 的 Arthas 诊断性能肯定给你留下了粗浅的印象，也肯定会成为您线上问题诊断的利器，帮忙您更快更不便的诊断线上故障。
写在最初
点此疾速收费体验 ARMS 性能。此外，企业级分布式应用服务 EDAS K8s 作为一款一体化的产品，既具备了利用的托管能力，也集成了 ARMS 的监控诊断能力，同样能够体验 ARMS 的 Arthas 诊断性能，可依据您目前的理论状况抉择一款产品来体 ARMS 的 Arthas 诊断能力。
备注：上述性能目前仅对部署在 K8s 为集群中的 Java 利用无效，后续会反对部署的 ECS 上的 Java 利用。
原文链接
本文为阿里云原创内容，未经容许不得转载。
