ITBear旗下自媒体矩阵:

从用户体验出发,听云首创全栈溯源全面升级

   时间:2017-06-13 16:21:15 来源:互联网编辑:星辉 发表评论无障碍通道

在2000年及更早的时候,应用大都是简单的3层架构,即界面层、业务逻辑层和数据访问层。而随着云技术和移动互联网的发展,时代对IT技术提出了更高的要求,它需要适应更迅捷的变化。同时,产品的迭代速度和效率变得更快,应用的复杂性也发生了爆炸式的增长,新时代的应用也变得更加难于管理。

我们能看到,IT部门在面对新生的应用管理方面包括了这样几个方面:

SOA:面向服务的新架构

云资源的利用:类似 AWS EC2及私有云等,公司的IT资源已经演变成为一种云计算能力

大数据:海量的复杂数据,引发了大数据分析的浪潮,例如Hadoop, Storm和Spark等

移动化:在所有的用户流量中,几乎一半以上都来自于移动端

敏捷开发:业务的变化越来越快,随之就要求开发团队需要采用更灵活的架构来应对

在这其中,唯一不变的则是对关键业务流程稳健运行的要求。那么问题来了,

原有的传统的监控工具在面对所有新技术、新架构的应用时挑战巨大,它可能还没准备好应对这种变化,怎么办?

数字化转型规模在愈发扩大,各行业对性能监控提出了更高的要求,传统的监控方案只能定位解决不到30%的问题,怎么办?

传统的监控方案,面对新时代的应用体验秒级要求时往往无计可施,尤其是“最终用户到底在关键业务流程上经历了什么”,怎么办?

快速定位一个最终用户关键业务的性能问题是所有DevOps急于需要解决的,怎么办?

怎样才能保障关键业务流程方方面面的继续稳健运行?

Gartner2016 年,对APM 重新规划了标准:

1、 (DEM) 数字化体验监控

支持对操作体验和数字化探针、人和机器的行为优化;与企业的应用和服务交互;包括基于网络和移动端最终用户的真实用户监控(RUM)和综合事务监控(STM)。

2、 (ADTD) 应用发现、追踪和诊断

了解服务端应用之间的关系,将事务映射到节点上,对方法和其他资源进行深度的检查;这是一系列的过程,关注点均在问题的修复,且是相互关联的;包括应用程序拓扑发现和可视化,用户定义的事务处理,应用组件的深度钻取。

3、(AA) 应用分析

机器学习、统计推断和其他方法;自动检测Java和.NET服务端应用支持的HTTP/S事务的性能异常的来源(或根本原因)。

即只有满足以上3个条件才能称作真正的APM 。而在这组概念中,Gartner 认为APM 的核心功能则是能够基于应用去做问题的发现与诊断。

2016 年,为了能够帮助DevOps团队快速实现不同业务逻辑下的性能排障,国内领先的应用性能管理服务提供商听云推出了全栈溯源解决方案,它在国内首次实现了全端、跨应用监控。2017 年,面对现阶段复杂的全栈环境,定位问题变得更加复杂,为了能够对应用性能问题更加深入的追踪与诊断,听云全栈溯源进行了全面升级。

什么是全栈溯源?

从用户体验出发,基于事务请求进行全栈问题的定位追踪叫全栈溯源。

全栈溯源实现了什么功能?

APP端事务请求全栈溯源

浏览器页面事务请求全栈溯源

拨测事务请求全栈溯源

单用户全栈溯源

全栈溯源对DevOps的价值?

1、清晰责任界定:可以为各部门提供统一的信息平台,共同讨论目前应用发生的问题,以及解决方案。

监控:应用的用户体验细节指标,包括用户前端响应时间、网络响应指标细节,以及后端各API接口,每个服务的健康状况,识别每条性能曲线上是否存在突发点。

问题定位:隔离用户的问题,界定问题发生的位置,判定是前端还是后端或者是网络的问题,甚至是数据库问题,并且将以业务部门看懂的方式在平台上以可视化的图表展示出来。

解决:直接在平台报表里找到根本原因,无论是某个程序的某段代码,或者是相关的SQL语句,还是DNS解析异常,甚至是前端图片的异常加载,这些无需专业人员来操作,就能够以简单明白的报表的方式,展示给各个部门,从而容易直接处理。

2、告警: 严重问题自动响应

在过去,当遇到客户投诉后,分析判断问题是如何发生的、运维研发介入直到最终解决,这一过程往往要经历至少一周以上的时间,甚至可能是数星期。听云全栈溯源是基于客户关键业务的自动质量控制平台,将把以周为单位的解决问题时间缩短为几分钟。同时,当发生严重问题时,系统会进行自动响应,及时告警。

全栈溯源典型应用场景:

全栈溯源下的web端慢页面追踪

通过听云Browser发现某应用某关键业务的页面平均响应时间过高,通过观察页面性能分解图发现,该页面主要耗时发生在服务端请求处理过程中。

通过慢页面下的元素追踪功能发现,后端请求发生了响应慢的情况,接下来可以钻取查看具体在服务端的处理情况。

通过追踪,跳转到听云Server查看对应请求处理的trace详情。

通过详情的摘要信息,可以看到最耗时的是蓝色部分的jdbc操作,它执行的这一次操作相对于这次后端处理耗时来说最长的,通过这点发现了主要耗时的位置。

钻入后需要查看该SQL耗时是由哪个SQL语句造成的,点击追踪详情。从追踪详情请求入口开始,查看各项耗时,发现某条SQL语句占用了95%以上的耗时。这样就形成了一条完整查看问题出处的链路。

通过粗略的SQL语句可以看到,这条慢SQL做了一些count统计以及跨表查询、distinct处理,它有很多可以优化的地方。这就是一个问题从开始到最后分析的整个过程。

同时,全栈溯源还可以实现——

全栈溯源下的移动端慢请求追踪

全栈溯源下的移动端慢交互追踪

全栈溯源下的服务端慢应用过程追踪

举报 0 收藏 0 打赏 0评论 0
 
 
更多>同类资讯
全站最新
热门内容
网站首页  |  关于我们  |  联系方式  |  版权声明  |  网站留言  |  RSS订阅  |  违规举报  |  开放转载  |  滚动资讯  |  English Version
关闭
ITBear微信账号

微信扫一扫
加微信拉群
电动汽车群
科技数码群