听云全栈溯源功能上线,助力应用打通任督二脉

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

  • 面对APP出现缓慢耗时过长,你是否苦于无法即时定位问题的出处?

  • 面对网站的访问缓慢,你是否纠结于是网络原因还是后台程序原因造成的?

  • 面对页面性能耗损严重,你是否无法定位是页面结构问题还是资源请求过慢?

  • 面对复杂的跨系统的性能问题,是否无法精准找出问题的根源?

没关系,现在有听云APM全栈溯源来帮你,它是国内首家实现全端、跨应用监控的功能,能够帮助DevOps快速实现不同业务逻辑下的性能排障。

什么是全栈溯源?

在复杂的应用环境下,精确定位并判断网络、移动端、浏览器端、服务端性能问题根源的技术手段。其中,它包括:

1、从移动端到服务端的性能溯源

2、从网络到服务端的性能溯源

3、从浏览器端到服务端的性能溯源

4、服务端跨语言跨应用的性能溯源

全栈溯源对DevOps的价值

1、降低跨部门排障沟通成本

2、从3天到5分钟快速追溯性能问题根源

3、性能问题界定,协助运维明确责任,协助研发修改问题

4、完整业务调用链跟踪(业务、运维、研发)

全栈溯源必要条件

在部署听云Server 的同时需部署听云App/Network/Browser其中一款产品,打通双端。

如何使用全栈溯源?

从移动端到服务端的性能溯源

[1]场景:

在一次HTTP请求的过程当中,请求所消耗的时间可能是在不同的步骤发生的,即耗时过长可能发生在建连时间或服务器消耗上。那么我们如何分解时间,以便知道一次网络请求的时间都消耗在什么地方了?在这方面,全栈溯源可以直接将一次网络请求耗时细化到服务端所消耗的时间。

[2]解决流程:

1.2211.png

  • 选中某一个具体的URL,当发起请求的APP同时部署听云App和听云Server探针后,便可以进行全栈溯源的操作

  • 将该URL通过跳转按钮跳转到Web应用过程,可以在POST请求跳转到服务端的部分上看到服务端消耗时间

  • 可以看到具体的耗时部分,找到问题根源

从网络到服务端的性能溯源

[1]场景:

有时候网站发生的性能问题并不是由于网站、网络、运营商等前端造成的,而是由于后端服务器产生的影响。

[2]解决流程:

2.32.png

全栈溯源可以关联听云Network与听云Server 2个产品的监测数据,实现完整的端到端的监测解决方案。当监测数据发生异常时,听云Network可以定位到防火墙以外的问题,关联听云Server后可以更好的定位到服务端的问题,帮助用户更加快速的定位问题的原因。

  • 听云Network对支持跨应用追踪的任务会自动进行关联,任务列表中进行提示

  • 关联成功后会增加服务器端指标排队时间(Server)和服务器响应时间(Server)

  • 关联成功的元素会在元素瀑布图中进行标记,可以直接跳转到Server下对应的web应用过程

  • 直接跳转到主元素的web应用过程

  • 对于应用响应时间超于阈值的会触发Server的慢应用过程追踪

  • 慢应用过程可以直接追踪到Server中的数据进行分析

3.4444.png

从浏览器端到服务端的性能溯源

[1]场景:

H5发展日渐迅猛,运行环境也更加复杂,有时会发现HTML5页面的渲染缓慢,AJAX时间过长都不一定是HTML5本身的问题,有可能是后端引发的性能问题。

[2]解决流程:

0.9988.png

一般应用的性能损耗会发生在网页前端、网络以及后端服务器。听云Browser能够监测网页访问的性能情况,配合听云Server可以了解到服务器端响应的性能损耗。

  • 在听云Browser应用列表中采用自动嵌码Server探针的,可以直接查看听云Server应用的情报汇总

  • 页面分析和AJAX请求中添加到Server的Web应用过程的查看

  • 直接跳转到停运Server控制台下对应的web应用过程进行分析

  • 在听云Browser的慢页面追踪中,如果元素超过阈值可以继续进行Server的慢应用过程追踪

  • 可以继续定位到听云Server慢应用过程追踪详情

99.88.png

服务端跨系统、业务的性能溯源

[1]场景:

无论是从互联网行业还是传统的IT行业来看,当前的系统架构都变得越来越复杂。从最简单的互联网架构:前端做分流,后端做业务,到传统行业拥有自己的前端、逻辑层、数据层,以及系统间的调用、通信越来越多,都导致了一个问题:发现问题的地方和真正导致这个问题的出处存在了一定的距离,并且在未来距离会越来越大。

比如发现了A系统响应时间非常久,经调查A系统本身没有问题,那么很可能便是A系统在调用别的系统时引发响应时间过长。而全栈溯源便可以很好地解决这个问题,无论是调用链多么复杂,都能根据业务进行有效追踪,从发现问题的入口一直跟踪到产生问题的出处。同时,听云Server能够完美接入听云App、听云Network、听云Browser产品,通过连通听云Server,定位到其他的应用上、数据库或者中间件上的问题。

[2]解决流程:

9.877.png

搭建模拟的系统,共三层:(1)前端:用户注册层;(2)业务层;(3)用户校验系统

  • 当从前端发现用户注册的时间非常久,通过查看 Web应用过程,发现Web应用过程慢应用追踪记录

  • 经查看前端服务器发现,调用耗时久的原因在于所有的时间都消耗在另一台服务器上,即后端服务器(用户管理中心服务器)

  • 经追踪发现,该服务器大面积运行的耗时都在另一台服务器上,即用户管理服务器性能无碍,问题发生在验证服务器上,点击进行追踪下去,发现在追踪详情上可以看到存在一条慢SQL,该SQL语句执行时间非常久

  • 针对该SQL进行优化,解决问题

全栈溯源可以将所有你能想象得到碎片化的问题完美整合,以一种串行的方式去定位问题,并且无论从研发人员还是运维人员角度去利用听云全栈溯源去解决问题,都可以非常直接、准确定位问题出处,高效将问题解决。

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

关于作者

小孟德

职业写手的前途真的断了,千万不要轻易入行。

我要评论

评论请先登录,或注册