终结DevOps之殇—业务级运维时代谈APM

如今,DevOps面临的变化越来越多,CI/CD机制无法从根本上解决变更所带来的性能变差、基础设施不可靠等问题,运维该做的事情不能减少,同时还要了解开发的内容。带着这样的问题,听云研发副总裁廖雄杰先生在GITC2015运维专场带来《业务级运维时代的应用性能管理》的分享,现场向技术人员讲述APM如何帮助DevOps有效地进行资源管理,提升工作效率。 

监控的三个特点

1、可度量:系统可度量

2、指标化:系统中用户端、网络端、服务端的指标提取出来进行分析

3、实时性:运维系统实时性必不可少,这需要系统在用户发现问题之前便响应出来。

端到端用户体验优化

  • 浏览器

廖雄杰表示:“在浏览器嵌入探针后,用户便可以收集到每个页面的响应时间、 TCP建连时间,深入钻取可分解出网络延迟、DOM处理各自时间占比以及页面渲染时长。一般情况下,运维人员可能只关注网络延迟时间,相对来说这些数据更有益于前端优化人员从中发现优化的途径,例如页面渲染、DOM处理的优化。 同时针对AJEX请求也会从地域、运营商等多种维度予以呈现,通过对这些性能数据进行分析、解读,汇集多样本数据来总结出特征,从而准确定位问题。”

  • 网络

“在这部分,通过浏览器的JS监测,用户可以收集到DNS时间、首包时间等网络数据,但是相对于网络层,还需要提供更完善以及更详细的手段去监测。当网络出现问题时,JS代码无法运行,DNS出现问题,用浏览器的手段无法监测。从网络这层听云可以提供更细致的指标呈现,例如从运营商、地域维度进行分析。”

  • 移动端

“在移动端,听云能够监测到每一个HTTP请求的性能:经常界面出现了卡顿,原因是后端出现HTTP请求同步运行或异步运行。通过最细力度去监测可以看到中间每个网络请求,例如使用一个购物的应用,界面中出现一段白屏,白屏的时间跟后端需要传递的图片或其他请求息息相关。从这个示例图中可以看到这个应用每一个请求的响应时间,在响应时间的最高点同步有流量的上升,从中可以看出,在流量激增的情况下服务器没有及时扩容从而造成体验下降。”廖雄杰在讲到移动端性能优化时谈到。

6.png

下一张示例图是关于App的错误监测,图中看到某图片的错误率很高,这种情况下需要结合网络分析发现在某地区出现大量HTTP错误访问,在其他地区并无影响,从而定位到是某地区CDN节点出现问题。

6.1.png

关于崩溃,抓取到异常之后看到崩溃详情,崩溃时间点停留在某个操作,将整个操作轨迹进行回放,可以了解到在什么视图下对哪些资源进行了操作,开发人员就大概能判断出崩溃前用户做了什么,哪种操作可能复现崩溃现象。

作为开发人员,最关心的是哪行代码引起了崩溃,这时就需要通过崩溃堆栈来进行锁定,找到崩溃的一瞬间调用了哪些代码,是系统代码还是应用代码,位于哪个函数中的哪一行,帮助我们最精确的定位问题。

  • 服务端

廖老师讲到:“要监控的所有指标本质上都是由应用发起的,例如Redis响应时间、缓存读取时间、数据库调用时间。一方面我们可以从数据库端做监控,另一方面可以直接从应用层发起监控。例如数据库查询时间、NoSQL的时间、外部服务调用的时间,都可以通过从应用层发起的监控方式展示出来。”

6.3.png

在这个示例中可以看到响应时间的基本趋势、错误率、比较耗时的请求的访问情况。这些会通过耗时的长短进行排序,点开每一项可以进行分解,了解耗时的节点到底处于哪里,是数据库的查询还是其他的调用,可以直接的看到各项的时间占比。

6.3.png

下图看到的是慢应用查询的分解图表,当一个应用的响应时间超过设定的阈值后,会将这个应用的详细调用数据汇集起来用于详细排查。将每个阶段的性能指标一一呈现,这个示例的瓶颈在MySQL查询阶段,展开后可以看到每一个阶段的调用时间占比。同时从调用堆栈中也能看到是哪一行代码调用了这个查询导致了性能的整体下降。A应用频繁调用B应用时也会阻塞整体执行时间从而导致性能下降。总体来说,研发人员在后期排查时直接通过此界面轻松发现问题。

6.5.png

6.6.png

随着互联网行业的不断发展,用户需求也会随之变化,廖雄杰表示,未来几年,听云将继续专注在APM技术的研发上,主要的方向是移动、云和大数据,在移动方面会支持更多类型的移动设备和平台,支持H5和混合型的App。在云上,则会与各家云服务商密切合作,为云用户提供简单易用的云端APM产品,支持更多的云平台服务。在数据分析方面,听云将对采集到的海量数据进行更深的挖掘和分析,为大家提供更多行业性能数据,提供更丰富多彩的应用性能管理报告,作为一种有价值的数据服务提供给用户。

关于作者

许小午

不是一个没有故事的女同学

我要评论

评论请先登录,或注册