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

先进入我们的第一个环节 大前端时代前端监控的新变化 要了解前端监控的新变化，首先得看看这些年前端发生了哪些变化

前端这些年发生了翻天覆地的变化，它会给监控带来什么？让我们思考以下问题

早年SPA这么火，我们在业务上也尝试过，体验大大提升，但是业务方抱怨PV下降

那么是什么导致了PV下降呢？ 在后端直出的时代，我们每次交互，都向后端请求一个新的页面，PV自然就高。 改成SPA模式后，大量的页面请求变成了页面内路由，即页面路由。 向内过渡。 如何解决？ 这对我们来说并不困难。 大多数框架路由都是基于哈希实现的。 我们只需要监听hash变化，每次变化上报PV即可。 还有少量路由不是基于hash实现的，比如angular，需要轻量级的hack pushState和replaceState

这是完美的吗？

让我们考虑以下情况

接下来，我们来探讨一个大家最感兴趣的话题：性能。 先来看一组我们的统计数据。 随着加载时间的增加，淘宝旺铺页面的点击率从85%逐渐下降到82%。 不要小看这3%。 在阿里这么大的体量，3%就意味着巨大的商业价值。 从前端监控的角度来看，首屏是如何统计的？

回到刀耕火种的农耕时代，那时候什么都想要，还得自己动手，才能丰衣足食。这就是手工打点阶段：手工打点，页面打点header和首屏dom节点分别用new Date()，计算差值，作为首屏时间，加上setTimeout(new Date(), 0)标记首屏。 互动时间

随着前端的快速发展，人工管理模式已经不能满足需求。 为了帮助开发者更好地衡量和提升Web性能，W3C性能团队引入了Navigation Timing API，帮助我们自动准确地实现对性能测试的管理。 简单概括一下，性能API包括【卸载上一页】【重定向】【应用缓存】【DNS域名解析】【TCP连接】【请求页面】【响应】【页面处理】最后触发加载事件，通常我们使用 domContentLoaded 作为第一个屏幕时间。 Chrome 率先支持，IE 紧随其后

长期以来，我们享受了性能API带来的便利，但随着SPA模型的盛行，我们回过头来看看W3C标准是否足够。 先来看一个案例，是阿里云某产品的管理后台。 整个加载过程分为三部分，1.加载初始shell页面 2.加载JS资源并异步请求数据 3.中间主体部分的前端渲染。 按照W3C标准，首屏时间应该是1106ms，但实际首屏时间是1976ms，这是异步取数据完成后页面渲染的时间。 为什么会有这么大的差异？其实是SPA的盛行让W3C标准失去了本来的意义

针对这种情况，Google Lighthouse提出了FMP的概念，首先是paint的意思，即主要内容可见的时间，那么主要内容是什么？ 每个人得出的结论可能不一样

先做个猜测：主要内容=页面渲染时元素增量最大的点

我们通过飞猪案例来验证一下

猜想成立

通过手机淘宝案例再次验证

猜测不成立

那么我们的猜想不成立的原因是什么呢？

监听页面元素的变化

遍历每一个新元素，并计算这些元素的得分之和

如果元素可见，得分为1 * weight（权重），如果元素不可见，得分为0

每次都要遍历新添加的元素，计算是否可见，非常耗性能。 实际上采用的是深度优先算法。 如果子元素可见，则父元素可见，不再计算。 同样，如果最后一个元素是可见的，那么前面的兄弟元素也是可见的。 通过深度优先算法，性能得到了很大的提升。

再拿之前的手机淘宝案例来验证一下。

改进后，第三屏的主要内容得分最高，符合预期。

那么接下来第一个屏幕上的统计数据会发生什么变化呢？ 其实统计首屏时间本身就是浏览器的职责，最好让浏览器来处理。 目前W3C首屏统计已经进入提案阶段，等待W3C再次规范。可以在github上查看最新进展

限于篇幅，前端监控的其他新变化就不展开了。 说了这么多前端监控的新变化，那么打开前端监控最正确的姿势是什么？

从这里我们进入我们的第二个链接，“前端监控的最佳实践”

我用一个表达“如果它是某物”来概括它。 我经常想[要是天上掉下来钱就好了]，[要是机器人能帮我写代码就好了]。 同样，每次发布一个版本，总是提心吊胆，不知道用户能否正常使用。 （这时候你会想）要是能有一双眼睛帮我盯着系统就好了； 每次出错都是用户投诉反馈问题。 其实当用户主动反馈问题的时候，影响已经非常大了：（这时候你会想）如果能第一时间发现错误就好了；

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

发现在接口成功率趋势图中，接口请求数急剧增加，成功率急剧下降。 查看错误信息聚合模块后，发现出现频率最高的错误信息是【交易规则冲突】。 经过深入排查，最终查明原因是运营配置的双十一折扣规则与平时的折扣规则有冲突，导致无法下单。 终于在凌晨4点，申请了一个紧急发布，修复了冲突，解除了告警。

这导致了最佳实践之一：主动监控。 当然，主动监控的内容不仅限于API成功率，还包括JS错误率。 过程小结：首先配置告警规则； 然后你就可以放心大胆地睡觉了。 如果有问题，系统会第一时间通知我们，然后通过错误聚类模块来准确定位问题。 然后起刀落刀，bug修复完成。

回到我们的【whatever it is】，在做性能优化的时候，有时候整体性能已经很好了，但是有一小部分用户觉得很慢：（这时候你会想）如果你能知道会发生什么减慢用户速度是可以的

这时候我们就需要用到【性能样本分布】，打开页面性能页面，查看0~60秒每个区间的性能样本分布情况。 从分布图中可以看出，大部分用户在2秒内加载到10秒内，极少数用户拖动下方滑块将时间范围缩小到10秒左右。 此时系统会过滤掉10秒左右的慢会话。

点击展开一个慢会话，不仅可以看到这个慢会话的基本信息，如网络类型等，还可以看到完整的资源加载瀑布图，可以清楚的看到是什么资源导致了整个会话slow down .由此我们可以得出第二个最佳实践：slow session tracking

回到我们的【if it is something】，有时候用户提交反馈，某个功能因为错误无法使用。 这个时候，你并不知道用户报了什么错误。 需要再打电话吗？ 用户，你得教用户如何通过浏览器开发者工具把错误截图发给你。 放过我吧，这个时候，用户很可能因为系统太烂，太丢人了，已经关闭了页面，发誓再也不使用这个破系统了。 （这时候你会想）要是能知道用户报的是什么错误就好了

别怕，打开阿里云前端监控的【访问详情】搜索用户ID完美国际客户端BUG，就可以直接看到用户在访问过程中报了哪些错误。

有时候在用户报错的时候我得到了基本信息，我知道用户报的是什么错误，但是在我的电脑上调试的时候，无论如何也无法重现。 这个时候是不是还要再跟用户沟通，让用户再描述错误？ 事实上，用户可能已经忘记了如何重现错误。 （这时候我们会想）如果能重现用户行为就好了。

【视频演示】让我们现场模拟一次用户错误修复。 左侧是用户实际操作的画面。 为了更好的展示效果，我会在右侧屏幕实时展示用户的行为。

大家一定很好奇这么炫酷的能力是怎么实现的？ 下面我将揭秘阿里云前端监控系统背后的技术架构。

先从大家最感兴趣的错误恢复说起吧，大家可能会猜是不是整个页面都被录成视频了。 事实上，情况并非如此。 视频太大。 不可能错误地将视频发送到服务器。 这是对用户资源的严重浪费。 先看原理图（按照从左到右的箭头）

可能大家觉得还不够，下面给大家介绍一下阿里云ARMS前端监控系统的整体架构。 它首先从左到右分为三个域。 分别是日志采集域、日志分析域和监控告警域。 在日志采集域中，客户端通过SDK将信息上报给Nginx服务器，日志服务SLS在Nginx服务器上设置代理同步日志信息。 当日志到达SLS时，就相当于一个大水库。 然后通过实时计算引擎的计算，将一部分结果存储在HBase中，另一部分结果存储回SLS日志服务，以供搜索。 最后通过restful API将数据提供给前端，前端渲染出数据dashboard。 是不是感觉很简单？ 有句话叫“看山跑死马”，山好像就在眼前，但纵然骑马，马也会疲惫不堪。 那么就让我们一起揭开它的神秘面纱吧。

接下来重点介绍与前端同学工作密切相关的日志采集领域。 与业界相比，我们的日志收集还是有很多可圈可点的地方。 例如：

这些内容我就不展开了，重点说一下阿里云前端监控是如何突破限制，优雅的上报日志的。 大家都知道http咨询草案rfc2616规定一个浏览器只能同时拥有两个域名。 连接。 但是PV、UV、ajax请求、JS逻辑错误、页面资源加载等都会触发上报。 同时2个连接明显不够用，可能造成网络拥塞。 上报延迟后，在rfc7230修订草案中去掉了这个限制，只规定了数量限制，但没有具体规定数量，浏览器实际上放宽了限制。 比如Chrome同时有6个连接。 但是，一个请求占用一个连接，有时6个连接还不够。 你可能会想，既然规范没有规定限制多少个连接，为什么浏览器会限制6个连接呢？ 其实也是出于公平和安全的考虑。 如果不限制数量，理论上一个客户端可以占用大量的服务器资源，甚至压垮服务器。

那么如何突破极限呢？ 有个绝招：升级到http2，利用h2的多路复用特性，在一个连接上开多个流，还可以双向传输数据，轻松突破6路并行限制。

是否足以突破6路限制？ 再来看另外一个容易被忽略的部分：http header loss。

再次利用 h2 标头压缩。 我们先来看看使用h1和h2的效果对比。 h1下的请求大小为295字节，而h2的大小只有18字节，仅为大小的十六分之一，请求时间也从6ms减少到4ms。

太神奇了，让我们快速浏览一下 http2 标头压缩的工作原理：

其实除了头部压缩，还有很多方法可以减小音量，比如

接下来，我们来看一个监控系统的核心部分：实时计算。 实时计算采用的是流计算，在业界已经非常成熟。 让我们简要回顾一下这个概念。 这是代表流计算的经典结构图。 有两个组成部分。 水龙头是喷口，代表数据源，闪电是螺栓，代表处理逻辑。 这里有两个非常重要的特征。

想一想：如何从海量日志中实时获取条件有限的聚合数据？ 如图，我要实时分析【广东省】【最近24小时】【访问速度】【模拟页面】的走势。 如果我需要绘制这样的趋势图，我需要每小时画一个点。 对于24个点的值，每个节点写一条SQL，对符合条件的数据进行平均。 如果数据量不大，取24次数据在性能上勉强可以接受。 但是如果是SASS系统，监控系统会接入很多项目，每时每刻都会上报大量的数据。 该系统还将积累大量数据。 获取一个节点需要多少时间？ 作为参考，离线计算大约需要15分钟，24个节点，估计需要6个小时。 这显然是不能接受的。 那么阿里云的前端监控是如何实时获取数据的呢？

这就需要用到我们的大数据处理神器dataCube（数据立方体），下面分析一下数据立方体是如何解决实时性问题的。 如图： 以浏览器、设备、地理区域三个维度为例，组成一个三维数据立方体。 立方体中的每个单元格代表一个聚合数据。 请看图中数字3所在的格子。 3代表三维，即北京vivo设备和chrome浏览器的聚合量。 然后查看黄色部分的数字 2。 黄色部分代表浏览器维度的聚合，也就是上海。 按地区统计的 Vivo 设备总量，包括所有浏览器。 看右下角的数字0，代表0维度，也就是所有聚合数量，包括所有浏览器、所有设备、所有地区。 数据立方体的秘密在于预先计算所有网格的值。 下次要获取值时，只需从 Data Cube 中获取某个值即可。 它本质上是一种用空间交换时间的方式。

下面看看我们实际的处理场景。 元数据经过流计算处理后完美国际客户端BUG，每分钟、每小时或每天都会生成一个数据立方体。 而这个数据立方体有 90 多个维度。 回到之前的案例，如果我想限制几个条件得到24小时趋势图，只需要从24个数据立方体中取出指定位置的小格子即可。 计算时间可以大大缩短到秒级。 【思考案例】数据立方体本质上是预先计算出所有可能组合的结果，结果的个数是笛卡尔积。 如果某个维度的值很多（比如淘宝商品详情url中的商品id不断变化，导致url的值有几千万），直接导致爆尺寸，如何解决？

由于时间关系，今天的话题到此结束。 有兴趣的同学可以加入我们的钉钉技术交流群，谢谢。

阿里云前端监控产品接入文档：