从前端程序员的视角看小程序的稳定性保障

图片 77

从前端程序员的视角看小程序的稳定性保障

原标题:如何使用阿里云ARMS轻松重现用户浏览器问题

页面加载较慢是用户经常会反馈的问题,也是前端非常关注的问题之一。但定位、排查解决这类问题就通常会花费非常多的时间,主要原因如下:

摘要: 今天我分享的内容分成三个部分:
第一部分是“大前端时代前端监控新的变化”,
讲述这些年来,前端监控一些新的视角以及最前沿的一些思考。
第二部分”前端监控的最佳实践”,
从使用的角度出发,介绍前端监控系统的各种使用姿势
最后是“阿里云ARMS前端监控系统架构”,
简单地剖析下,阿里云前端监控系统是怎么实现的。

摘要:
日前,阿里巴巴中间件(Aliware)旗下产品业务实时监控服务ARMS正式商用。首发商用的ARMS目前涵盖应用监控和前端监控两大功能。由此,ARMS的商业化正式填补了阿里云在APM(Application
Performance Management)领域空白。

当我们谈业务稳定性的时候,通常是指后端工程师从架构的角度来看的,例如限流和降级、流量调度、业务开关、容量压测等,但监控也是整个业务稳定性建设中不可或缺的一环,例如对业务和前端的监控,以保证出现问题的时候,可以第一时间找到根因所在。今天,我们就结合小程序的场景,来看看如何做好小程序的监控。

摘要: 这是阿里中间件 ARMS 团队推出的
“网站常见问题1分钟定位”系列文章的第三篇,作者慕扉。 » 第一篇传送门 »
第二篇传送门 一、客户投诉不断,本地却无法重现?
页面加载较慢是用户经常会反馈的问题,也是前端非常关注的问题之一。

  1. 页面是在用户端的浏览器上加载执行,复现困难

    • 页面上线前,开发同学都会进行测试,在测试环境下页面加载一般都是正常的才会正式上线。用户在访问页面时,页面的加载是在用户端的浏览器上进行的,由于页面的加载耗时与地域、网络情况、浏览器或者运营商等有关系,想知道用户在访问页面时的具体情况,复现是非常困难的。
  2. 监控信息缺少,导致无法深入排查

    • 大部分前端监控会通过PerformanceTiming对象,获取完整的页面加载耗时信息,但这类监控就缺失了页面静态资源的加载情况,无法直接复现现场,从而无法深入定位性能瓶颈。

本文来自阿里云前端监控团队,转载请注明出处

原文链接:http://click.aliyun.com/m/43720/

小程序和 H5 都属于移动端场景下的技术选择方案,那么这里介绍一下小程序与
H5 的不同。

一、客户投诉不断,本地却无法重现?

为了方便用户更快地定位性能瓶颈,阿里云ARMS前端监控推出一新功能:
会话追踪,提供页面静态资源加载的性能瀑布图,根据页面性能数据可深入定位页面资源加载情况。

本文为2018年6月21日,在北京举办的GMTC(全球大前端技术大会),下午性能与监控专场,由阿里云前端监控团队前端技术专家彭伟春带来的演讲稿,现场反馈效果非常好,地上都坐了三圈,很多人反馈根本无法挤进去。先上现场照。

日前,阿里巴巴中间件(Aliware)旗下产品业务实时监控服务ARMS正式商用。首发商用的ARMS目前涵盖应用监控和前端监控两大功能。由此,ARMS的商业化正式填补了阿里云在APM(Application
Performance
Management)领域空白。基于ARMS,用户可以高效完成应用和前端的性能管理,可视化监控各项性能指标,并做出实时预警和监控。

1、运行环境的不同

页面加载较慢是用户经常会反馈的问题,也是前端非常关注的问题之一。但定位、排查解决这类问题就通常会花费非常多的时间,主要原因如下:

在阿里云ARMS前端监控SDK上将sendResource配置为true,重新部署应用后,在页面onload时会上报当前页面加载的静态资源信息。从而在阿里云前端监控平台即可以对慢页面加载问题快速进行定位。

图片 1

图片 2

  • 传统的 H5 的运行环境是浏览器,包括 webview,其中浏览器提供
    window、document 等 BOM 对象;
  • 小程序的逻辑层和渲染层是分开的,逻辑层运行在 JSCore
    中,并没有一个完整的浏览器对象,所以缺少相关的 DOM API 和 BOM API。
  1. 页面是在用户端的浏览器上加载执行,复现困难

SDK配置

在阿里云ARMS前端监控SDK部分,默认是不上报页面加载的静态资源信息的,如果想获取页面加载的静态资源信息,只需在SDK的config部分将sendResource配置为true,重新部署后,就可以上报相关信息。具体配置如下:

<script>!(function{c[a]||;c[a].config={pid:"atc889zkcf@8cc3f63543da641",imgUrl:"https://arms-retcode.aliyuncs.com/r.png?",sendResource:true};withwithwith(insertBefore(createElement,firstChild))setAttribute("crossorigin","",src=d)})(window,document,"https://retcode.alicdn.com/retcode/bl.js","__bl");</script>

注意:静态资源加载信息的上报是在页面onload时会触发,上报信息量较大,如果对于页面性能要求很高的应用,可以不开启该配置。

正文从这里开始~

ARMS 场景示例

2、开发成本的不同

页面上线前,开发同学都会进行测试,在测试环境下页面加载一般都是正常的才会正式上线。用户在访问页面时,页面的加载是在用户端的浏览器上进行的,由于页面的加载耗时与地域、网络情况、浏览器或者运营商等有关系,想知道用户在访问页面时的具体情况,复现是非常困难的。

问题排查过程

1. 发现问题

进入访问速度菜单后,发现页面的性能较差,11点钟的页面完全加载时间达到35s,如下:

图片 3

2. 慢页面会话追踪

在慢页面会话追踪模块,提供该页面在指定时间段内加载较慢的TOP20,这样可以快速发现哪些会话加载较慢,如下图所示。在该模块,你可以快速发现在11点钟有一次会话的页面加载时间在36.72s,这次访问应该是直接导致页面加载时间详情中折线图突然暴增的原因了。

图片 4

其中在在模块有7次会话访问的页面加载时间在7s以上,点击对应的页面,可以直接进入到会话详情页面,从而直观查看页面静态资源加载的瀑布图。

图片 5

通过页面资源加载的瀑布图,可以快速定位到资源加载的性能瓶颈,同时可以查看本次访问的客户端IP地址、浏览器、操作系统等UA信息,从而进一步确认是由于网络原因还是其他原因导致的,针对性进行相应的优化。

图片 6

3. 其他发现问题入口

会话追踪

也可以进入“会话追踪”菜单,可以看到该应用下的会话列表。会话列表中会根据页面完全加载时间排序,展示TOP100,帮助用户可以快速发现耗时较长的会话信息。同时支持按照页面、会话Id、浏览器、浏览器版本号进行过滤,展示相关的会话信息。点击操作后,是该会话的页面资源加载详情。

图片 7

访问明细

如果当前会话列表中无法找到你要排查的会话信息,可以通过访问明细查找到相应的日志详细信息,在param中找到对应的sid即会话Id,然后在会话列表中查找相应的会话Id,即可以定位到想排查的会话信息。

例如:在已知用户的客户端IP的情况下,想定位相应的会话信息,即可以在访问明细中,通过t=res and 117.136.32.110
进行搜索,找到对应的会话Id。

图片 8

根据查找到的会话Id, 就可以在会话列表中进行过滤,定位到具体的会话内容。

图片 9

图片 10

大规模分布式应用全息监控

  • H5 的开发,涉及到开发工具、前端框架、模块管理工具、任务管理工具、UI
    库的选择、接口调用工具及浏览器兼容性等;
  • 小程序的开发,指定环境的小程序会提供开发者工具、API
    及规范的开发标准。由于小程序是跑在指定的环境下的,同时 API
    是指定环境下提供的,所以不用考虑浏览器的兼容性。
  1. 监控信息缺少,导致无法深入排查

使用入口指南

  1. 进入访问速度菜单,如果发现页面性能较差,可以在”慢页面会话追踪Top20″中查看访问较慢的会话情况

    • 点击详情后,可以查看具体的页面资源加载瀑布图
    • 如果Top20不满足,可以点击”更多”,从而进入”会话列表”
  2. 进入会话追踪菜单,展示的是TOP100的会话列表信息,根据页面完全加载时间从高到底排序,排查页面资源加载情况

图片 11

至此,慢页面会话追踪功能及使用方法介绍完成。该功能可以帮助你复现用户在访问页面时的页面资源加载情况,快速定位性能瓶颈问题。

  • 官网文档介绍
  • 阿里云ARMS前端监控官网

本文作者:中间件小哥

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

大家下午好,今天我给大家带来的主题是《大前端时代前端监控的最佳实践》。

应用监控是本次ARMS商业化的重点功能,该功能是企业发展在微服务改造和分布式互联网架构升级中必不可少的监控神器。

在 H5 开发中,前端常用的 HTML/CSS
在不同的小程序中都有指定的文件标准。例如:

大部分前端监控会通过PerformanceTiming对象,获取完整的页面加载耗时信息,但这类监控就缺失了页面静态资源的加载情况,无法直接复现现场,从而无法深入定位性能瓶颈。

图片 12

图片 13

  • 在微信小程序中使用 WXML/WXSS;
  • 在支付宝小程序、钉钉 E 应用中使用 AXML/ACSS;
  • 在百度智能小程序中使用 SWAN/CSS;……

为了方便用户更快地定位性能瓶颈,阿里云ARMS前端监控推出一新功能:
会话追踪,提供页面静态资源加载的性能瀑布图,根据页面性能数据可深入定位页面资源加载情况。

先做一个自我介绍,我叫彭伟春,英文名是Holden, 阿里花名是六猴,
大家都叫我猴哥。是阿里开源同构框架beidou的作者,目前是阿里云前端系统技术负责人。

ARMS应用监控功能示例

开发规范在指定的官方文档中都会有明确的使用介绍,使用方法与原来 H5
的开发大同小异,所以上手开发相对容易。

二、阿里云ARMS前端监控-会话追踪帮助你快速定位问题

图片 14

例如,如果企业发展迅速,在短时间可能就会增加应用数量,当应用数量增多时,如何对分布式应用进行有效监管?除了排查单一故障,如何从全局角度迅速找出故障根源?这些都是企业需要攻克的重要技术难点。

3、使用体验的不同

在阿里云ARMS前端监控SDK上将sendResource配置为true,重新部署应用后,在页面时会上报当前页面加载的静态资源信息。从而在阿里云前端监控平台即可以对慢页面加载问题快速进行定位。

今天我分享的内容分成三个部分:

ARMS 应用监控主要理论模型基于Google
Dapper,经过阿里内部鹰眼实践,不仅支持了双11数十万个结点规模的应用监控,并且具备各种复杂功能场景的监控经验,其功能除了常用的链路跟踪以外,还包括内部基础架构性能监控,中间件接口监控,业务全息排查,等多个场景。

  • H5
    页面需要在浏览器中渲染,在复杂的业务逻辑或者丰富的页面交互时会有卡顿情况;
  • 小程序除首次使用略慢,页面切换及跳转等非常顺滑,接近 Native。

SDK配置

第一部分是“大前端时代前端监控新的变化”,
讲述这些年来,前端监控一些新的视角以及最前沿的一些思考。

借助ARMS应用监控,用户可以轻松实现以下功能:

通过以上几点小程序和 H5 的不同的介绍,我们可以发现原来针对 H5
页面的监控无法直接监控小程序;同时由于小程序封闭性较强,不同的小程序在标准上也略有不同,如微信小程序、支付宝小程序及钉钉
E 应用等等小程序在使用标准及开放的 API
方面也会有一些差异,所以针对小程序的监控与针对 Web
应用的监控会有所不同。

在阿里云ARMS前端监控SDK部分,默认是不上报页面加载的静态资源信息的,如果想获取页面加载的静态资源信息,只需在SDK的config部分将sendResource配置为true,重新部署后,就可以上报相关信息。具体配置如下:

第二部分”前端监控的最佳实践”,
从使用的角度出发,介绍前端监控系统的各种使用姿势。

• 快速浏览某段时间各微服务应用之间的网络拓扑和调用信息。

现在针对小程序监控的大概分为以下几类:

图片 15

最后是“阿里云ARMS前端监控系统架构”,
简单地剖析下,阿里云前端监控系统是怎么实现的。

• 针对某类服务,快速统计出常见程序性能问题如慢SQL,Top异常,等。

1、小程序的数据统计分析,助力小程序运营

注意:静态资源加载信息的上报是在页面时会触发,上报信息量较大,如果对于页面性能要求很高的应用,可以不开启该配置。

图片 16图片 17


通过问题服务所关联的抽样调用链,查看详细的分布式调用堆栈信息或本地调用堆栈信息,快速定位分布式调用链中的问题点。

  • 相关产品: 微信小程序助手、阿拉丁小程序统计平台等;
  • 特点:大部分是针对微信小程序提供相应的数据统计分析能力,从多维度分析小程序相关用户数据,适用于小程序运营,但缺乏对于用户体验,小程序性能的监控。

三、问题排查过程

先进入我们第一个环节 大前端时代前端监控新的变化。


通过ARMS特制的日志API和全息排查功能,用户还可以将业务信息进一步关联到具体的调用链中,快速定位相关业务信息的调用链上下文。

2、小程序错误监控

  1. 发现问题

要了解前端监控新的变化,还得先看看前端这些年发生了哪些变化:

图片 18

  • 相关产品: FunDebug 等;
  • 特点:监控小程序使用户出现的错误,帮助开发者发现并解决小程序错误,但缺乏对于小程序全局性能的监控,对于缓慢请求,缓慢页面没法监测。

进入访问速度菜单后,发现页面的性能较差,11点钟的页面完全加载时间达到35s,如下:

  1. 首先是Gmail的横空出世,开启了SPA的时代

ARMS应用监控

3、小程序性能监控

图片 19

2.
Backbone/Angular等框架带来了MVVM模式的同时,也把JS从脚本语言提升到了工程语言

和同类APM类工具相比,基于鹰眼的ARMS应用监控功能除了能够比较好的提供分布式应用的调用链、本地调用堆栈、异常捕获、各类中间件接口调用监控功能以外,还具备以下优点:

  • 相关产品: FrontJS、听云小程序监控等;
  • 特点:主要提供性能相关数据,包括 JS
    错误、网络请求响应情况等。但是只支持微信小程序,而且没有办法把小程序的性能与后台应用的性能关联起来,没法形成端到端的监控。
  1. 慢页面会话追踪
  1. React Native/Weex把移动端开发从Hybrid模式进化到了跨端开发模式

  2. Node.js问世为前端带来了更多的可能性

• 支持接口广泛:首次推出的应用监控除支持Aliware(EDAS,
MQ)接口以外,将支持10多种通用的第三方中间件接口,最大限度做到应用的监控广度。

通过上面对现有的小程序监控产品分析,存在以下问题:

在慢页面会话追踪模块,提供该页面在指定时间段内加载较慢的TOP20,这样可以快速发现哪些会话加载较慢,如下图所示。

图片 20


日志全息排查场景:通过后续ARMS提供的API,用户可以自行将关联调用链信息的日志打出,日志既可以在ARMS中通过业务信息进行基于调用链场景的排查以外,日志也可以直接进入到日志服务中进行直接查询搜索。

  • 无法支持所有的小程序监控,主要支持微信小程序;
  • 支持多类小程序监控的产品,提供的小程序相关数据较少,主要集中在错误监控;
  • 没有后台应用服务的性能监控,无法从小程序上的性能问题追溯到后台应用代码和数据库,无法形成端到端的监控。

在该模块,你可以快速发现在11点钟有一次会话的页面加载时间在36.72s,这次访问应该是直接导致页面加载时间详情中折线图突然暴增的原因了。

前端这些年发生了翻天覆地的变化,又会给监控带来什么呢?让我们思考下以下几个问题:


和Aliware无缝集成:新推出的ARMS应用监控将和已有的Aliware如EDAS平台将无缝集成,用户可以在EDAS上一键接入ARMS,后台Agent植入完全透明化。

基于以上情况,阿里云 ARMS
前端监控重磅推出小程序监控,旨在帮助端到端的快速定位小程序问题,提升小程序的用户体验。

图片 21

  1. 传统监控模式能否适用于新的技术?比如PV统计

  2. SPA模式下首屏如何计算?

  3. 跨端开发给监控带来什么什么挑战?

  4. 前端监控的上报模式在Node.js端是否合理?

“企业需要的不仅仅是一款可以追踪单一链路故障的技术,而是一项便捷实用,全息排查,上手简便的产品,在易用性上,特别是和阿里云产品集成上,我们对ARMS进行了大量优化。”据ARMS产品负责人介绍。“例如,对EDAS的集成,用户只需要在页面上进行开通和授权,即可在ARMS上监控EDAS的应用数据,用户无需对业务程序进行任何改造。”

阿里云 ARMS 前端监控此次重点推出的小程序监控有以下特点:

其中在在模块有7次会话访问的页面加载时间在7s以上,点击对应的页面,可以直接进入到会话详情页面,从而直观查看页面静态资源加载的瀑布图。

接下来我和大家一起探讨其中的一两项

轻松提升前端用户体验

1、覆盖各类符合标准规范的小程序首先解释一下这里所说的”标准规范的小程序”,即包含
App 和 Page 两层:

图片 22

图片 23

ARMS的前端监控商业化,对于拥有快速增长的门户网站的企业来讲,也是一个利好消息。由于互联网环境越来越复杂,企业获取流量的方式也越来越多样化,同一个企业往往同时具有iOS、Android、公众号、移动Web甚至小程序等多个前端,因此前端的用户体验管理就尤为重要。

  • App 用来描述整体程序,包含: onError 事件;
  • Page 用来描述各个页面,包含: onShow、onHide、onUnload 事件。

通过页面资源加载的瀑布图,可以快速定位到资源加载的性能瓶颈,同时可以查看本次访问的客户端IP地址、浏览器、操作系统等UA信息,从而进一步确认是由于网络原因还是其他原因导致的,针对性进行相应的优化。

早些年,SPA如此盛行,我们也在业务中做了尝试,体验是大幅提升了,可业务方却吐槽PV下降了。

“ARMS前端监控对标的是APM领域的用户体验管理,即User Expeirence
Management,
简称UEM技术。”据ARMS产品负责人表示,该技术通过对网站页面上动态数据的采集监测和实时反馈,可帮助企业更高效地进行用户体验监测。

小程序的运行环境依赖于对应的客户端,各类小程序的 DSL
设计看起来很像,但细节上的差别还是比较多,并且已有了分化的趋势。在这种情况下,阿里云
ARMS 前端监控为了更好的支持小程序的监控诉求,提供以下小程序监控的场景:

图片 24

图片 25

图片 26

  • 微信小程序
  • 支付宝小程序
  • 钉钉 E 应用
  • 其他类别小程序
  1. 其他发现问题入口

那到底是什么导致了PV下降了呢?在后端直出时代,我们每一次的交互,都是向后端请求一个新的页面,PV自然就高,改成SPA模式之后,大量的页面请求变成了页内路由,或者说是页内转场。那如何解呢?这难不倒我们,大部分框架路由都是基于哈希实现的,我们只要侦听hash改变,每次改变上报一次PV就好了。也有少量的路由并不是基于哈希实现的,比如angular,
这时候就需要轻量级地hack pushState和replaceState。

ARMS前端监控

由于小程序发展迅速,现在无法针对各类小程序都提供对应的监控
SDK,所以不属于微信小程序、支付宝小程序和钉钉 E
应用的小程序可选择其他类别小程序的场景接入进行监控,但要满足上面说的”标准规范的小程序”前提,同时支持
npm 包。

会话追踪

图片 27

ARMS前端监控是阿里内部基于ARMS平台搭建的前端业务监控标准解决方案。和应用监控一样,脱胎于阿里内部产品,主打
Web 端体验数据监控,通过页面打开速度(测速)、页面稳定性(JS
Error)、外部服务调用成功率(API)三叉戟组合来监测 Web
页面的健康度。经过多年磨练,其易用性和稳定性大幅提升,非常适合大多数中小企业甚至是个人创业者。

2、完善的性能监控指标基础业务指标,帮助了解小程序应用的使用情况:

也可以进入“会话追踪”菜单,可以看到该应用下的会话列表。会话列表中会根据页面完全加载时间排序,展示TOP100,帮助用户可以快速发现耗时较长的会话信息。同时支持按照页面、会话Id、浏览器、浏览器版本号进行过滤,展示相关的会话信息。点击操作后,是该会话的页面资源加载详情。

这样就完美了吗?

ARMS的前端监控可以JS埋点方式快速接入,默认监控功能包括:

  • 应用总 PV/UV
  • 页面维度的 PV/UV

图片 28

图片 29

访问量监控:基于页面和地域等维度的PV/UV访问量监控。 

小程序各维度指标:

访问明细

我们再思考下以下几个案例

满意度监控:基于国际通用标准算法对各类页面进行各类维度视角的满意度统计。 

  • 手机型号
  • 操作系统版本
  • 微信 / 支付宝等相应的 APP 版本
  • 网络等

如果当前会话列表中无法找到你要排查的会话信息,可以通过访问明细查找到相应的日志详细信息,在param中找到对应的sid即会话Id,然后在会话列表中查找相应的会话Id,即可以定位到想排查的会话信息。

1.
某新闻类的网站,每次看完之后,都会下拉刷新,加载新的内容,这个时候是算一次PV还是多次?

API监控:与页面监控一样,ARMS前端监控还提供各类网站API监控。 

JS 错误分析:

例如:在已知用户的客户端IP的情况下,想定位相应的会话信息,即可以在访问明细中,通过t=res
and 117.136.32.110 进行搜索,找到对应的会话Id。

2.
天猫商品列表页,看完一屏之后,向上滚动会再加载新的一屏,PV该算一次还是多次?

其他跟前端监控相关的各类指标。 

  • JS 错误率、错误聚类、JS 错误堆栈及错误定位等

图片 30

3.
阿里云邮后台一直开着,每周上百次查看,是算一个PV还是每次查看都计算一次?

值得一提的是,与市面上大多浏览器端监控解决方案相比,ARMS前端监控还具有一大特点,那就是基于ARMS实时计算平台构建,任务可实现高度定制化。浏览器上报SDK开放了底层的求和、求平均、求百分比等统计接口,易于业务方在自定义场景下自行进行质量监控相关的扩展。也就是说使用者可以根据自己网站的属性,调用想要的数据,实现数据多样性。

API 请求追踪:

根据查找到的会话Id, 就可以在会话列表中进行过滤,定位到具体的会话内容。

  1. 未关闭的浏览器tab几小时之后再次浏览,该不该再计一次PV?

  2. 查找信息时,浏览器Tab之间快速切换,切换过程中要不要计一次PV?

此外,基于应用性能指标算法(APDEX),ARMS还对应用站点及页面进行了满意度评分,可以很直观地了解到用户对站点或页面的体感。 

  • API 请求成功率、API 请求耗时及 API 请求的链路追踪
  • 自定义事件统计
  • 支持业务上自定义事件 sum/avg 统计

图片 31

其实还有很多其它层出不穷的场景,具体该如何去统计PV留给大家去思考,
不再展开。

据ARMS产品负责人表示,“得益于内部技术改造和优化,ARMS推出的产品价格远低于业界产品,可以使企业监控成本大幅降低。”

3、可通过配置选择上报方式由于业务方使用监控的诉求不同,我们不仅支持优雅的静默数据上报,也支持使用开放的统计能力进行自定义上报。具体可查看官网的前端监控接入概述中的小程序场景相关文档:

使用入口指南

图片 32

图片 33

1、进入访问速度菜单,如果发现页面性能较差,可以在”慢页面会话追踪Top20″中查看访问较慢的会话情况

接下来我们探讨一个大家最感兴趣的话题:
性能。先看一组我们的统计数据,淘宝旺铺页面点击率随加载时间变长从85%的点击率逐步降低到了82%,别小看这3%,在阿里这么大的体量下,3%意味着巨大的商业价值,那站在前端监控的角度,首屏是如何统计出来的呢?

图片 34

小程序作为各大互联网公司重磅加持的方向,未来小程序的应用数量会越来越多,那么对于用户体验方面的关注与提升诉求也会不断增加,阿里云
ARMS
前端监控提供的小程序监控可帮助客户实时监控发现质量问题,为企业的小程序的稳定运行提供坚实的保障。

  • 点击详情后,可以查看具体的页面资源加载瀑布图
  • 如果Top20不满足,可以点击”更多”,从而进入”会话列表”

图片 35

阿里中间件Aliware是阿里巴巴集团生态系统技术的基石,支撑了淘宝、天猫、聚划算等99%以上的大规模应用,被称为阿里历年双11背后的秘密武器。经过10多年的技术孵化,目前消息队列MQ、企业级分布式应用服务EDAS、性能测试PTS等近10款产品已经对用户开放。

附录:

2、进入会话追踪菜单,展示的是TOP100的会话列表信息,根据页面完全加载时间从高到底排序,排查页面资源加载情况。

回到那个刀耕火种的年代,那时候要什么没什么,都是自己动手丰衣足食。这就是手动打点阶段:
手动打点,分别在页头和首屏dom节点处new
Date()打点,计算差值,作为首屏时间,再加上setTimeout(new
Date标记首屏可交互时间。

图片 36

  • 业务实时监控服务 ARMS
  • 业务实时监控服务 ARMS 前端监控
  • 小程序监控接入文档

图片 37

图片 38

“帮助用户建立更专业的企业IT架构是Aliware的使命。”据ARMS产品负责人表示,为了给用户提供更大的优惠,ARMS商业化首发阶段还为用户提供6折优惠。用户可以登录阿里云官网,在ARMS产品中享受最新优惠活动。

本文作者:中间件小哥

至此,慢页面会话追踪功能及使用方法介绍完成。该功能可以帮助你复现用户在访问页面时的页面资源加载情况,快速定位性能瓶颈问题。

随着前端的飞速发展,手工打点的模式早已满足不了需求了。为了帮助开发人员更好地衡量和改进web性能,W3C性能小组引入了
Navigation Timing API
帮我们自动,精准的实现了性能测试的打点问题,大致地过一下,性能API里面包含了最后触发load事件,通常我们把domContentLoaded作为首屏时间。Chrome最早支持,IE跟进。

识别以下二维码,阅读更多干货

阅读原文

作者:中间件小哥

图片 39

图片 40

本文为云栖社区原创内容,未经允许不得转载。

​本文为云栖社区原创内容,未经允许不得转载。返回搜狐,查看更多

在很长一段时间里,我们都享受着performance API带来的便利,
但随着SPA模式的盛行,我们再回过头来看看W3C标准是否足够了。先来看一个案例,这是阿里云某产品的管理后台。整个加载过程分成三个部分,1.
加载初始的空壳页面 2.加载JS资源并异步请求数据 3.
前端渲染中间的主体部分。按照W3C标准取值首屏时间应该是1106ms,
而实际的首屏在1976ms,也就是完成异步取数据后渲染完页面的时间点。为什么会相差如此大呢?实际上SPA的盛行让W3C标准失去了原来的意义。

责任编辑:

图片 41

针对这种情况Google lighthouse提出了FMP的概念,first meaning paint,
也就是主要内容可见时间,那什么是主要内容? 每个人得出的结论可能会不一样。

图片 42

先做一个猜想:主要内容 = 页面渲染过中元素增量最大的点。

图片 43

先通过飞猪案例做一次验证。

图片 44

猜想成立。

图片 45

再通过手淘案例做一次验证。

图片 46

猜想不成立。

图片 47

那到底是什么原因导致我们的猜想不成立?

首先是元素是否可见, 不可见的元素对用户的影响基本为0。

其次是每个元素对页面的影响是否等效?由此引出权重,不同的元素采用不同的权重计算影响。阿里云前端监控

图片 48

根据上面的修正因子。我们重新设计了一遍算法,
计算每次变化的得分,一起来看看,算法是如何实现的?

如图所示分为三个步骤

  1. 侦听页面元素的变化;

  2. 遍历每次新增的元素,并计算这些元素的得分总;

  3. 如果元素可见,得分为 1 * weight, 如果元素不可见,得分为0;

如果每次都去遍历新增元素并计算是否可见是非常消耗性能的。实际上采用的是深度优先算法,如果子元素可见,那父元素可见,不再计算。
同样的,如果最后一个元素可见,那前面的兄弟元素也可见。通过深度优先算法,性能有了大幅的提升。

图片 49

再拿之前的手淘案例来验证一遍。

图片 50

经过改良之后,第三屏主要内容的得分是最高的,符合预期。

图片 51

那么接下来首屏统计又会发生什么样的变化呢?其实统计首屏时间本身就是浏览器的职责,交由浏览器来处理是最好的。目前W3C关于首屏统计已经进入了提议阶段,坐等W3C再次标准化。大家可以在github上看到最新进。

限于篇幅,前端监控其它新的变化不再展开。讲了这么多前端监控的新变化,那什么才是打开前端监控最最正确地姿势呢?

图片 52

由此进入我们的第二个环节,“前端监控的最佳实践”。

图片 53

我用一个表达式“要是什么什么就好了”来总结。我经常会想【要是天上能掉钱就好了】,【要是有个机器人帮我写代码就好了】。同样的,每次发版之后都是提醒吊胆的,不知道用户到底能不能正常使用。要是能有双眼睛帮我盯着系统就好了;每次出错,都是用户投诉反馈问题,实际等到用户主动反馈问题,影响面已经非常大了:
要是能在第一时间发现错误就好了;

图片 54

还真有这样的案例,前年双十一凌晨值班,突然收到邮件和短信告警,于是点开了详情。

图片 55

发现在接口成功率趋势图中,接口请求量大幅上升,伴随着成功率急剧下降,再查看错误信息聚合模块,发现频率最高的错误信息是,深度排查之后,最终找出了原因,是运营配置的双十一优惠规则和平时优惠规则产生了冲突,导致下单失败。最后凌晨4点申请了紧急发布修复了冲突,解除告警。

图片 56

由此可以得出最佳实践之一:主动监控。当然主动监控的内容不仅局限于API成功率,也包括JS错误率等。稍微总结下流程:先是配置告警规则;
然后就可以放心大胆地睡觉了,如有任何风吹草动,系统马上会通知到我们,再通过错误聚类模块,精准地定位问题。再手起刀落,bug修复完成。

图片 57

再回到我们的【要是什么什么就好了】,在做性能优化的时候,有时候明明整体性能已经不错了,可偏偏有少量用户觉得很慢:要是能知道慢速用户发生了什么就好了。

图片 58

这时候我们就需要用到,打开页面性能页面,查看0
-60秒之间每个区间的性能样本分布情况,从分布图中可以看出来大部分用户加载时间都在2秒以内,极少数部分用户的页面时间在10秒左右的。

拖动下面的滑块,缩小时间范围到10S左右,这时候系统就会筛选出10秒左右的慢会话。

图片 59

点击展开某次慢会话,不仅可以看到这次慢会话的基本信息,比如网络类型等,还可以看到完整的资源加载瀑布图,可以清晰地看出来,具体是什么资源导致整个会话变慢。由此我们又可以得出最佳实践之二:慢会话追踪

图片 60

再回到我们的【要是什么什么就好了】,有时候用户提交了一条反馈,某某功能出错用不了,这时候你又不知道用户端到底报了什么错,是不是又得打电话给用户,还得手把手教用户如何通过浏览器开发者工具把错误截图下来发你。我哩个去,用户这个时候很可能因为系统太烂了,已经不堪其辱,早就把页面关了并且发誓再也不用这破系统。要是能知道用户报了什么错就好了。

图片 61

别怕,打开阿里云前端监控的搜索用户ID,直接可以看到该用户在访问过程中,到底报了什么错。

图片 62

有时候拿到了用户报错时的基本信息,也知道用户报了什么错,但是在自己电脑上调试的时候,无论如何也复现不了,这个时候是不是又得去和用户沟通,让用户描述重现路径,实际上用户可能自己都忘了具体怎么做才能重现错误。要是能重现用户行为就好了。

图片 63

我们现场来模拟一次用户出错还原,左边是用户实际操作的屏幕,为了更好地展示效果,我把用户行为实时地展示在右边的屏幕上:

第一步: 模拟用户在淘宝页面上做出了一系列的操作,
鼠标移动、滚动页面,搜索等;

第二步:假设突然出现了某某错误,这时系统会把记录的用户行为存储到服务端;

第三步:
开发人员通过会话ID查询到出错行为,最终进行还原。大家可以看到左边屏幕不再操作,右边屏幕还原出了之前出错的所有行为。

图片 64

大家一定在想这么炫酷的能力是如何实现的呢?接下来就为大家揭秘阿里云前端监控系统背后的技术架构。

图片 65

就从大家最感兴趣的错误还原讲起,大家可能在猜测,是不是把整个页面录制成视频了。其实不是这样的,视频太大了,不可能出错了把一个视频发到服务端,这样是对用户资源的严重浪费。先看示意图:

首先,每一次会话都有一个唯一的session ID,这是串联起所有行为的纽带。

其次,用户行为又分成两个部分,其一是用户的操作,比如鼠标滑动,点击,页面滚动等,其二是页面的变化。这两者我们都统称为用户行为,记录在同一个队列中。

一开始的时候,系统会记录下初始的页面作为第一帧,这是唯一的一次完整页面记录。

针对用户操作,我们会记录事件的类型,鼠标位置等关键信息,保存到队列中。

针对页面变动,我们会起一个mutationObserve侦听页面的改动,每次只记录改动的部分,保存到队列中。

无论是事件还是页面改动,都是对等的一帧,每一帧都会有当前时间,与上一帧间隔时间等基本信息用户还原。

一旦出错,SDK就把队列发送到监控系统,并清空当前队列。

还原端根据记录的行为队列,根据时间逐一播放出来。最终形成一个类似于视频的效果。

图片 66

大家可能觉得还不过瘾,接下来为大家讲一下阿里云ARMS前端监控系统的整体架构。

首先从左到右分成三个域。分别是日志采集域,日志分析域和监控告警域。在日志采集域,客户端通过SDK将信息上报到Nginx服务器,
日志服务SLS在Nginx服务器上起一个agent,去把日志信息同步过去,日志到了SLS就相当于到了一个大的蓄水池。再通过实时计算引擎的计算,结果部分存储到HBase,另一部分结果回存到SLS日志服务用于搜索。

最终通过restful API向前端提供数据,前端渲染出数据dashboard.

是不是感觉很简单地样子,有句话叫做,山看起来就在眼前,
可就算骑马过去马都会累死。那就让我们一起来揭开它的神秘面纱吧。

图片 67

接下来重点介绍跟前端同学工作密切相关的日志采集域,相比业界,我们的日志采集还是有很多可圈可点之处的。比如说:

静默采集:
只需要一行代码接入SDK就行了,所有的API请求、资源加载、JS错误、性能等都自动监控起来了。省去了繁琐的配置。

单元测试 +
自动化测试:前端监控的目的就是去监控前端的异常情况,不给页面带来新的异常这是我们的底线,对此,我们有完善的单元测试和自动化测试去保障SDK本身的质量。

:但实际上任何系统都不能保证自己不会出错,那么万一SDK本身报错了,我们还有异常隔离机制,确保出错也不会影响业务的运行。

图片 68

这些内容我都不详细展开,那接下来我重点讲一下,阿里云前端监控是如何突破局限优雅地上报日志

大家都知道,http徵求意見稿rfc2616规定浏览器对于一个域名,同时只能有 2
个连接。而PV、UV、ajax请求、JS逻辑错误、页面资源加载等等都会触发上报,同时2个连接明显不够用,可能会造成网络阻塞,上报延迟

后来在修正稿rfc7230中去掉了这个限制,
只规定了限制数量,但并未指定具体数字,浏览器也实际放宽了限制。比如Chrome是同时6个连接。

然而,一个请求独占一个连接,有时候6个连接也是不够用的

大家可能会想,
那既然规范都没有指定要限制多少条,那浏览器为什么还要限制6条呢?其实也是出于公平和安全考虑,如果不限制数量,理论上一个客户端就能占用大量服务器资源,甚至压垮服务器。

图片 69

那如何突破限制呢?有一个绝招:就是升级到http2, 利用h2的多路复用特性。

一个连接上打开多个流,还可以双向数据传输,轻松突破6路并行限制。

思考一下:在http1时代的把资源散列在不同域名下还有效吗?实际上非但不能提升性能,反而会新增连接开销。

图片 70

突破6路限制就够了吗?我们再来看看另一个很容易被忽略的部分:http头部损耗。

http请求中,每次请求都会包含一系列的请求头来描述请求的资源和特性等。而头部没经过任何压缩,每次请求都要占用200-800个字节,如果带上一个比较大的cookie,甚至会超过1K;

而我们实际的日志数据大小仅仅只有10 – 50字节,头部消耗占了90%以上;

另外,据Htpp
Archive统计数据,平均每个页面上百个请求,越来越多的流量消耗在头部;

最致命的是,UserAgent等信息不会频繁变动,每次请求都传输是一种严重的浪费。

图片 71

再次利用h2头部压缩。先来看看采用h1和h2的效果对比。

h1下请求大小295 字节, 而h2仅仅只有18
字节,大小只有区区16分之一,请求时间也从6ms降低到了4毫秒。

图片 72

太神奇了,来快速地过一下http2头部压缩是如何实现的:

首先协议里预设了一个静态字典,用来表示常用的头部字段,比如图中,2就是
method get.
以前需要把完整的key-value对发过去,现在只需要把一个数字发过去,大小大幅缩小。

其次,客户端和服务端会共同维护一个动态表,动态表用来干啥呢?举个例子,比如useragent,
每个用户的useragent值是不一样的,没法放到静态表中去约定。但是对于同一个用户会话,useragent是不会改变,这样的值,就由客户端和服务端协商决定存入动态表,这样第一次传输过去之后,以后就只需要传入动态表中的一个编码就行了,图中的62和63就是这样的情况。连接中发送的请求越多,就越能丰富动态表中的值,越到后面,请求性能越好(佐证了域名散列的方式不可取)。

还有一类情况,值总是变来变去,也没法保存到动态表中。这时候,只能直接压缩了。在h2中采用的是Huffman压缩算法,能把数字或字符最短压缩到5个字节,最大压缩率是37.5%。

图片 73

其实除了头部压缩外,还有很多办法减少体积,比如

采用http 204返回无响应体的response;

采用post请求合并多条日志,共用请求头;

错误调用堆栈中经常会出现很多的文件url,占了不少空间,可以考虑将他们抽取成一个变量;

时间关系,日志采集部分就到此为止。

图片 74

接下来我们来看看一个监控系统最核心的部分:实时计算。

实时计算采用的是业界已经非常成熟的流计算,简单地过一下概念。

这是一张表示流计算的经典结构图,有两种组件,水龙头是spout,代表数据源,
闪电是bolt, 代表处理逻辑。这里面有两个很重要的特征。

其一是计算能力弹性,如果有更大的日志量流入,能够动态调度更多的算力来保障计算的实时性;

其二是反压。每个计算节点都可以根据自己的负载情况反压上一级的计算节点,从而实现计算任务的更合理地分配。

图片 75

思考一下:如何在海量日志中实时取到限定条件的聚合数据?如图所示,我想实时拿到在走势。

分析一下,如果需要画出这样的走势图,每个小时画一个点,需要取24个点的值,每个节点写个SQL把符合条件的数据求平均,如果数据量很小的时候,取24次数据勉强性能上勉强可以忍受。

但是如果作为一个SASS系统,监控系统会接入非常多的项目,每时每刻都有大量的数据上报。系统也会积累海量的数据。取一个节点需要多少时间呢?参考离线计算大概要15分钟,
24个节点,预估需要6个小时。这明显是不可接受的。那阿里云前端监控是如何做到实时拿数据的呢?

图片 76

这就需要用到我们的大数据处理神器dataCube,我们来剖析下数据立方是如何解决实时性的问题的。

如图所示:
拿浏览器、设备、地理区域三个维度为例,组成一个三维的数据立方。立方中的每个小格子代表一个聚合数据。

请看图中数字3所在的格子,3代表三维,也就是Vivo设备、chrome浏览器在北京地区的聚合量。

再看一个黄色切面上的数字2,黄色切面代表浏览器维度的聚合,也就是上海地区Vivo设备的聚合量,包括所有的浏览器。

再看最右下角的数字0代表0维,也就是所有的聚合量,包括所有的浏览器、所有的设备、所有的地区。

数据立方的秘密就是把所有格子的值都预先计算出来,下次要取值,直接取数据立方的某个值就好了,本质上是一种空间换时间的思路。

图片 77

看一个我们实际的处理场景,元数据经过流计算之后,每个每分钟、每小时、每天都会产生一个数据立方。而这个数据立方多达90多维。回到之前的案例,如果我想限定若干个条件拿到24小时趋势图,我只需要24个数据立方中把指定位置的小格子取出来就行了。计算时间就能大幅压缩到秒级别。

原文链接

admin

网站地图xml地图