为什么要做这个功能？
作为一款 应用性能监控产品，我们通常会给用户展示两类数据：
- 第一种是统计数据：用户通过使用统计数据设置报警（比如应用响应时间大于2s），缩小问题范围（比如报警时间范围内，是哪一个接口响应时间最长）。
- 第二种是明细数据：用户通过统计值确认了特征以后，可以具体查看一个缓慢请求的执行过程，确认具体缓慢的方法或者慢SQL.
在用户实际使用过程中，我们发现实际上用户并不会按照我们预想的情况使用，常常是如下两种情况：
- 由于ARMS提供了相当丰富的指标和维度，且用户对于产品不熟悉，当出现应用响应时长等性能问题时，用户不知道如何继续分析问题。
- 基于性能开销的考虑，我们的明细数据不是全量上报的（默认10%采样，可调），有可能用户最缓慢的请求我们没有上报。
为了解决这两个问题，我们经过两个月的迭代，隆重推出了 智能和实时诊断功能。
智能诊断：
通过以应用的响应时间突增作为抓手，我们会帮助用户，依次做六项体检：
- 导致的本次响应时间突增的服务器
- 应用 SQL 耗时分析。
- 检测应用的 FullGC 的次数、耗时是否有突增。
- 是否存在内存泄露。
- 检测异常日志。
- 检测下游应用的响应时间是否出现同样的趋势。
经过“三堂会审”，主动的把与这次性能问题相关的 所有检查结果 呈现给您，让您一分钟内发现系统中发生了什么事情。
举个例子：
某应用发现RT突增到4s多
通过主动诊断，准确的抓到了本次异常，主动诊断发现java.util.concurrent.TimeoutException异常的统计指标和RT异常类似。
点击异常，直接跳转到异常诊断界面，发现异常在同一时刻突增，并且把异常栈和上下文给打印出来了。
实时诊断：
当您需要密切监控一小段时间内的应用性能时，例如发布应用时，或者应用出现问题时，您可以使用 ARMS 应用监控的实时诊断功能。开启实时诊断后，ARMS 应用监控会持续监控应用 5 分钟，并在此期间通过来一条上报一条的方式（延时在秒级），实时全量的上报调用链数据。接下来，您就能以出现性能问题的调用链路为抓手，通过方法栈瀑布图和线程剖析等功能定位问题原因。
接下来来我们还会继续补足智能分析的场景和数据源，希望当 响应时间/错误率 出现问题时，能让用户通过ARMS尽可能的缩短定位和解决问题的时间，让天下没有难解的性能问题。
产品链接： 应用实时监控服务ARMS
本文作者：中间件小哥
本文为云栖社区原创内容，未经允许不得转载。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69915408/viewspace-2654295/ ，如需转载，请注明出处，否则将追究法律责任。
