互联网科技

当前位置:4858美高梅 > 互联网科技 > GMTC 大前端时代前端监控的最佳实践

GMTC 大前端时代前端监控的最佳实践

来源:http://www.savourminto.com 作者:4858美高梅 时间:2019-11-17 04:39

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

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

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

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

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

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

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

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

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

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

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

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

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

图片 1

  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时会触发,上报信息量较大,如果对于页面性能要求很高的应用,可以不开启该配置。

正文从这里开始~

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

问题排查过程

1. 发现问题

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

图片 2

2. 慢页面会话追踪

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

图片 3

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

图片 4

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

图片 5

3. 其他发现问题入口

会话追踪

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

图片 6

访问明细

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

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

图片 7

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

图片 8

图片 9

  1. 监控信息缺少,导致无法深入排查

使用入口指南

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

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

图片 10

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

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

本文作者:中间件小哥

阅读原文

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

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

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

图片 11

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

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

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

图片 12

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

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

SDK配置

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

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

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

图片 13

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

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

图片 14图片 15

三、问题排查过程

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

  1. 发现问题

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

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

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

图片 16

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

  1. 慢页面会话追踪
  1. React Native/Weex把移动端开发从Hybrid模式进化到了跨端开发模式

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

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

图片 17

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

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

图片 18

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

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

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

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

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

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

图片 19

图片 20

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

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

图片 21

图片 22

  1. 其他发现问题入口

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

会话追踪

图片 23

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

这样就完美了吗?

图片 24

图片 25

访问明细

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

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

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

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

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

图片 26

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

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

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

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

图片 27

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

使用入口指南

图片 28

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

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

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

图片 29

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

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

图片 30

图片 31

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

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

作者:中间件小哥

图片 32

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

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

责任编辑:

图片 33

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

图片 34

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

图片 35

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

图片 36

猜想成立。

图片 37

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

图片 38

猜想不成立。

图片 39

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

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

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

图片 40

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

如图所示分为三个步骤

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

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

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

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

图片 41

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

图片 42

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

图片 43

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

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

图片 44

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

图片 45

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

图片 46

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

图片 47

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

图片 48

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

图片 49

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

图片 50

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

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

图片 51

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

图片 52

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

图片 53

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

图片 54

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

图片 55

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

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

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

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

图片 56

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

图片 57

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

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

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

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

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

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

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

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

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

图片 58

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

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

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

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

图片 59

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

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

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

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

图片 60

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

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

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

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

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

图片 61

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

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

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

图片 62

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

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

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

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

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

图片 63

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

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

图片 64

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

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

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

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

图片 65

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

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

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

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

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

图片 66

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

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

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

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

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

图片 67

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

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

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

图片 68

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

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

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

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

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

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

图片 69

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

原文链接

本文由4858美高梅发布于互联网科技,转载请注明出处:GMTC 大前端时代前端监控的最佳实践

关键词: 4858美高梅