你应该知道的APM(二):性能瓶颈跨应用追踪实例

版权声明:此文章如需转载请联系听云College团队成员阮小乙,邮箱:ruanqy#tingyun.com

大家好,我们又见面了,上一期《你应该知道的APM》我们讲到APM的概念以及不同情况下用户使用APM的具体场景(错过第一期的朋友可以点击标题下方“听云”查看历史内容),相信大家一定对APM有了一定的了解,为了进一步的强化APM的概念,今天我们为大家带来一个APM实用中比较典型的案例:性能瓶颈跨应用追踪实例。

进行案例分解之前我们先来解释一下相关概念。实现APM所用的技术有很多种,为了方便说明,请大家先看这张图:

55.png

这是一个典型的互联网应用的拓扑示意图,图中每个炸弹的位置都可能是应用性能瓶颈和故障的出现点。因此,为了全面监控应用的性能,我们需要在多个位置采集性能数据,一般来说可以分为从客户端采集和从服务端采集两大类技术,这就是所谓的端(客户端)到端(服务端)的应用性能监控。

端到端的应用性能管理,从技术层面上来解释,指的是从应用的客户端到服务端都同时进行应用性能的监控和管理。应用性能管理和监控需要多方面的数据支持,包括来自各个探测的各层面性能数据:网络、运营商、机房、服务器、代码、数据库等,包括自身服务、第三方服务、行业甚至竞品服务的性能数据。通常我们会在用户体验层 (App, 网站等)发现一个问题,但问题的原因非常的复杂未必可以直接定位,只有多方面的性能数据都汇总到了一起,我们才能对自己的应用性能有完整清晰的认识,从而建立完善的应用监控基准和监控体系。

下面为大家演示一个端到端代码级跨应用追踪的案例。假设我们App上线后,用户投诉发现一个界面总是load不出来,这时候我们可能第一时间想到问题是出在App层面上,但其实未必。

55.1.png

如果这个App安装了听云App,我们可以在后台找到相对应于上面问题的交互分析界面,可以很清晰的定位问题所在。当然,如果你设置了警报,或者定期进来看看,不用用户发现,也可以发现这个问题。

55.2.png

我们找到对应的问题,就可以进入这个慢交互界面的具体分析,这时候我们可以看到这个慢交互发生时间段内的操作系统,版本,地域,网络接入情况等环境信息,还有对应内存、CPU的变化等。

55.3.png

点击查看其中一个占用执行最慢的线程,可以看到原来是这个服务端部署的应用占用了主要执行时间,如果这个应用在服务端部署了听云Server,我们可以开启听云首创的“跨应用追踪”功能,直接进入到服务端听云Server的应用性能分析,就可以直接跨应用追踪到服务端的具体问题。

55.4.png

然后我们就能在听云Server应用性能管理页面上可以看到这个慢应用分别是哪些组建占用了执行时间,如下图。

55.5.png

选择一个最慢的代码段,可以看他的时间消耗,以及他在哪个Java类里面的代码行数是多少。

55.6.png

然后我们还可以看到一些运行较慢的MySQL,并且可以查询看到相应的完整的调用堆栈。

55.7.png

同时还可以看到SQL语句的记录。

55.8.png

还有该SQL语句被调用了多少次,以及总耗时,这样我们就能定位到代码级的问题所在,方便研发进行修改。

55.9.png

以上就是关于慢交互的一个完整的跨应用追踪,从移动客户端的响应数据反映到服务端的真实代码级定位,这是一个典型的端到端的发现、定位并解决问题的应用性能管理解决方案。

当然,很多时候我们的问题只需要App端或者Server端监控就能解决,通常我们在使用APM的时候,有两件事是一定要做的:一个是要设警报阈值,一个是要对关键业务流程做配置关注,这样就可以做到及时且有重点的发现问题,同时也可参考APM中关于应用方方面面的数据表现来对应用做性能整体调优。到此为止,我们这一期的《你应该知道的APM》就告于段落了,大家有什么收获吗?如果有什么问题或者感想想要与大家分享的话,欢迎大家登陆我们听云的论坛留言,期待您的到来,我们下一期再见。

《你应该知道的APM》系列是由听云推出的一个APM专栏,旨在传播APM技术知识,不同行业用户的APM服务使用体验,让更多用户认识到APM对其行业的帮助,助力全行业应用性能体验提升。

想阅读更多技术文章,请访问听云技术博客,访问听云官方网站感受更多应用性能优化魔力。

关于作者

莫铭

我是懒鬼。没有欲望。有放荡的过去。不相信人。心胸狭窄。不负责任。是应该小心的类型。

我要评论

评论请先登录,或注册