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