前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

发布于:2020 年 5 月 12 日 09:50

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

线上监控作为产品质量的最后一道屏障,其意义和影响都十分重大。阿里岳鹰团队从内部业务痛点出发,沉淀了一套 Web 前端全景监控方案。在监控方面,实现了常规的 JS 异常、资源加载异常、页面性能以及接口请求监控,并且支持自定义上报,以满足全链路中更多的场景。同时,团队联合 UC 浏览器内核团队,独创了基于 V8 的“页面白屏”监控。在问题分析和解决方面,打造了一套高效的问题分析和智能预警体系。本文整理自阿里巴巴前端技术专家陈周勉在 GMTC 2019 深圳站的演讲,本次演讲结合大量实践案例分享了平台一路走来的历程,希望能对大家有所启发。

大前端时代

前端开发的痛点

我们正身处于一个大前端时代。以目前来说,我们的技术还是比较主流的,在 PC 端或移动端,还有很多新的 IoT 客户端上都有着广泛的应用。同时,我们的新技术、新框架的发展也十分迅猛。引用贺老的话来讲就是:“前端,在这个阶段,感觉是有点学不动了。”那么,这个时候会面临哪些挑战呢?主要有以下三点:

  • 兼容性
  • 终端
  • 用户体验

除此之外,再加上前面的“学不动”,就导致了前端开发群体的现状——我太“南”了。那么,针对于这些问题,我们有没有改善甚至完全解决的办法呢?答案显然是有。

事实上,我们可能只是需要一个 Web 监控分析平台,以达到线上监控的目的。一方面,线上监控可以对应用的健康状况做实时的监控和预警;另一方面,在预警出来后可以合理、及时地分析和解决问题。而岳鹰做的就是这件事情。

在硝烟中诞生

回顾这个大前端时代,业界方面,在整个监控领域内已经催生了很多监控产品。不过这些产品大都趋于同质化,他们可能更多还是基于应用这一层的 SDK 去实现,一旦在某些方面(例如白屏之类的问题)有更深层次的要求,就没有办法很好地满足了。

阿里的前端业务量级是众所周知的,体量非常庞大。由此催生出了对于前端监控的诉求,尤其是白屏问题,因为阿里的用户基数特别大,一旦出现白屏现象,对于整个用户体验的伤害极大。

UC 在互联网算是老兵了,而且是排头兵,UC 长年深耕于浏览器领域,所以 UC 的内核团队在底层方面已经有了比较深厚的积淀。比如说 H5、Web 容器这些方面都有着比较深厚的功底,这些再加上部分业务场景的触发和 UC 自身的优势,就构成了 UC 做监控平台的思路。紧接着,岳鹰就在 UC 内部开始孵化,逐渐在自己的业务里锤炼、沉淀,最后发展到可以为外部用户提供服务。

岳鹰平台的探索之路

传统的监控解决方案

传统的解决方案,大致会有这几步:

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

首先是前端的上报,我们通常是通过 JS SDK 进行数据的采集和上报,在经过后端的链路时,我们会做一些聚合分析然后展示到我们的 Web 监控平台;平台直接面向开发者,为开发者提供一系列聚合分析的手段;最后给我们的开发者赋能,让他们可以更容易地发现线上的问题,同时也辅助他们高效地分析问题。

那么,这样的方案是不是足够完美呢?未必。

传统解决方案的弊端

传统的解决方案存在一些弊端:

  • 监控维度有限
  • 问题分析能力弱
  • 需要前端埋点

首先是监控维度上受限,因为 JS SDK 在偏上层,所以它在实现功能的时候会有比较大的局限性;其次是我们在遇到问题的时候,如果没有足够的信息辅助分析,就会束手束脚,JS SDK 在此是没有办法获取更多有用的信息来辅助我们进行问题分析的;最后一点就是这种解决方案需要提前进行手动埋点,虽然不是致命的弊端,但是对于一些体量大的业务来说就意味着高成本和低效率。

我们的思考

针对于传统解决方案的不足,我们进行了思考。传统解决方案有一个天然的优势,那就是 JS SDK,因为它是跨端的,这一点很多方案都无法弥补。所以我们留下了 JS SDK 作为基础的跨端方案。其实我们完全可以通过另外一个方式,再结合 JS SDK 这个方案来构成整体的监控方案。

通过什么方式呢?答案是浏览器的内核。打造一个可以做深度能力补充的监控 SDK,再结合我们的 JS SDK 的跨端能力,就可以实现整个场景的覆盖。

内核 SDK 的原理和优势

内核是如何工作的呢?

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

传统方案的 JS SDK 是工作于顶部的 Web 页面这一层,但其实无论是 Web 还是 App,JS 最终都是在 JS 引擎里面执行。如果没有这一层的话,当 JS 有异常透出的时候,它会通过一层过滤之后到 SDK,最终到运营平台。为什么要加上中间这一层呢?因为中间的这个过滤器,如果有用过监控平台的同学可能会发现,有时候拿到了一个堆栈的栈顶信息是 Script Error,因为它跨域了,所以最终 V8 出来的异常是比较抽象的,对于我们定位问题没有什么帮助。而内核工作在底层,通过一个链路进行上报,弥补了 JS SDK 的不足,这也是我们最终采用这个方案的一个原因。

无论 JS 异常,还是资源加载,或者是一些接口、页面性能都是依靠浏览器给我们透出来的全局 API 去做的。比如我们需要做 API 监控的时候,需要一个这样的接口,做页面性能分析的时候,需要通过接口拿到数据然后才能进行一些聚合的分析。但更细致的信息我们是得不到的,因为通过这种方案我们得到的信息是经过过滤之后的信息。

由此就能看出内核 SDK 的优势,首先它会有更全面的堆栈信息,也会有更细致的错误码,我们在排查问题的时候更加方便。同时,JS SDK 没有跨域的限制。除此之外,还有两个更核心的点,就是首屏性能和白屏监控。

首先,我们整个统计出来的首屏是比较贴近于用户感官的体验,在实验室里准确率达到了 85%,远高于以往的分析方式;其次,我们在白屏监控方面也做了创新,以往的 JS SDK 方式进行白屏监控,更多是通过前端页面的动节点这种相对低效且耗性能的方式,而使用内核则会规避这样的问题。在问题的信息以及辅助定位方面,内核也更强一些。就拿首屏性能来说,以往我们在 JS SDK 里面分析性能的时候,如果得到的信息是首屏加载比较慢,那么当你想要了解原因的时候是无迹可寻的,而内核会收集或定义更多时间段的信息,从而了解页面的问题。

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

黄色部分就是内核所带来的提升

白屏采集原理

什么是白屏?白屏就是用户在界面上看到一片空白,追加一种场景就是页面加载时有一些小动画,但是长时间仍然没有内容出来,这种情况就是白屏。我们对白屏的定义就是:页面加载完成三秒内,没有任何汇集指令,我们就会把它视为白屏的现象。那我们是如何对白屏进行采集或者处理的呢?整个页面是一个渲染的过程,上文提到我们会分析汇集指令来判断是否白屏,在指令汇集之前,我们画一个分布式,来判断是否有汇集指令,从而判断是否为白屏。

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

常见的白屏原因有哪些呢?通过我们目前所沉淀的数据,大概归结为四类:

  • JS 逻辑异常
  • 核心资源加载失败
  • 客户端或内核的问题
  • 性能

前两类可能跟业务有关,比如说自己 JS 逻辑存在异常,或者核心资源加载失败,都会导致白屏现象的出现。而客户端的问题也就是性能问题,页面长时间没有出现内容,这样的情况也是需要优化的。

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

一次真实的案例

上图的案例是钉钉平台的某一个业务,这张图是岳鹰监控平台上的一个大盘,在某个时间节点数据会突然出现暴涨的情况,这种情况下白屏率就比较高了。这时,我们的平台进行了预警,那对于钉钉来说,该如何解决呢?当时,通过岳鹰提供的一些工具,发现了问题所在:

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

上图为钉钉页面的主文档,可以看到它加载 SaaS 时出现了 size 异常的问题,主文档出现异常,页面肯定是无法加载的。然后,我们进一步去分析原因的时候发现内容已经被劫持了,但是返回的是 0,这就有可能是端内或是容器上出现了问题,从而导致最终出现了白屏,被岳鹰捕获到,这是一个比较典型且相对简单的案例。

自定义上报 - 满足多样的上报诉求

我们的监控平台在有了 JS 异常、资源加载、API、首屏性能和白屏这些全方位的监控之后是不是就足够了呢?答案也是未必。在不同的业务中,除了这些基础的监控之外,还会有更大、更复杂的或者更不一样的监控诉求,例如均值、成功率 / 失败率等等,这些诉求就可以通过我们的自定义方式去实现。同时,这样也可以把我们整个 Web 监控平台的功能最大化。最后,可以通过扩展来实现我们任意的一个自定义。

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

  • 节流

那么在上报方面我们会关注哪些关键的点呢?在移动互联网时代,我们还是比较注意流量方面的问题,所以第一个问题肯定是节流的问题,有同学可能会说 ,上一个 HDB2,有一个多路的复用会节省流量。但除此之外,在业务方面也就是 SDK,我们会做一些努力,比如异常的去重、请求的合并等等,目的是为了让我们整个请求的数降下来,以达到节流的目的。

  • 支持降级

另一个问题就是上报的方式,以往我们大多会采用比较传统的方式,用 Image 或者一些其他的方式上报,而缺点也比较明显。所以我们采用如上图的方式,两者结合可以做一个降级。

  • (动态)采样

在上报的时候,如果是体量较大的业务,对于岳鹰的冲击还是比较大的,如果我们没有有效的手段就会导致整个监控平台垮塌,所以我们提出了动态采样,通过在云端下发的配置,采集到每一个跟它相关的端,最终达到动态采样的目的。

  • 安全

在安全方面,HBS 这里也不必赘述,是一定要保障的。

Web 平台打造

再来看 Web 平台的打造,这是和开发者息息相关的。我们看一个平台的核心能力主要是看四个方面:

  • 实时监控
  • 实时预警
  • 多维分析
  • 领域工具

其中,实时监控与实时预警这两点是最核心的,这两点做的好,我们就不用担心因为错过了线上的某些问题而导致风险的发生。当我们拿到监控数据之后,对数据进行分析的时候不能一蹴而就,这个时候我们需要有多维的分析手段去提供给开发者做决策。而在分析的过程中,我们需要涉及到 JS 异常、性能等各个领域,在分析的时候也会遇到不同的诉求。所以,我们通过各领域内的工具进行打造,以提升我们整体的对于问题的定位以及分析问题的能力。

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

上图为岳鹰监控平台的实时大盘,从图中可以看到很多监控的指标,比如页面性能、异常、API、流量等,我们通过大盘就可以对应用的健康情况有一个大致的了解。同时,在报警方面,我们更多会关注报警规则的支撑,还有其自身的实时性、正确性。

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

岳鹰监控平台有很多的项目,其中性能大盘是其中比较主要的项目之一。我们每一个监控项的闭环里也需要给开发者提供更细致的信息。如上图,图中的数据会告诉我们应用的整体性能情况,因为如果单独去看某一个小时、某一天的性能情况可能意义不大,这时就需要进行对比,用监控的数据与数据来源做对比,才能知道整个的趋势是怎样的。

最后是代码追踪,在发生异常后,我们需要知道具体是业务上的哪段代码出现了问题,这也是比较重要的一个分析维度。而上文提到的代码分析,通常是没办法直接看出问题在哪些堆栈上。这时候,如果我们有 Native 文件,就可以通过一定的映射方式,直接把业务代码还原出来,并找到具体是哪一段代码出现了问题,找到代码后,我们可以直面开发者并给他修复建议。

接入场景

对于上文提到的前端埋点的弊端,通常情况下监控的多为应用级,接入单个应用或单个页面,我们每新建一个页面、新建一个应用,就可以让开发者直接复用我们的监控代码,把这段代码植入后就可以进行监控了。在很多场景下还可以对效率加以提升,例如容器级的接入,例如在 UC 的内核上面做全方位的自动监控,还有饿了么 APP,因为没有接内核,直接用 Webview 注入我们的 JS SDK,以达到自动监控的目的。所以,通过这样的深度支持,我们在效率方面有了比较大的提升。

除了这两个例子,在内部我们还有支付宝这样大体量的业务,支付宝用的就是我们的内核,目前直接做到了对小程序的自动监控,开发者不必手动添加多余的代码就可以达到自动监控的效果。还有与钉钉平台的深度合作,钉钉采用了我们 JS SDK 加内核的方案来服务整个开发平台的监控方案。而且,岳鹰在经历了双十一、双十二这些大流量的活动后,也凸显出了服务大体量用户的能力。

岳鹰平台的未来展望

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

目前为止,岳鹰已经能做到实时预警,但未来我们希望可以做到更加智能的预警方式。比如说,有时预警出现一些高峰,当采样数据不足的时候,是否可以忽略掉,不做噪音的干扰之类的更加智能化的预警。

另一方面,目前前端的技术和框架层出不穷,对于监控平台来说,我们的愿景是能够真切地帮助到开发者,所以,在未来我们还是会对新型的语言框架做进一步的支持,真正的为开发者带来便利。

总结

前端的守望者:阿里岳鹰 Web 全景监控平台的建设之路

上图为岳鹰平台的产品架构,目前运营平台大概分为这么几个部分,还有一些简单的辅助性功能,最核心的还是监控预警和问题分析方面的能力。我们在每一个场景都提供了比较好的闭环。最后总结一下:

  • Web 监控平台闭环:采集 - 上报 - 解析 - 计算 - 多维分析 - 实时预警
  • 白屏监控原理:页面加载完成 3s 内无绘制指令
  • 领域工具的打造,可极大提升体验及问题分析解决的效率

嘉宾介绍

陈周勉,阿里巴巴前端技术专家,目前就职于阿里 UC 事业部,担任研发效能组的前端负责人。近年来主要专注于云机以及前端监控领域,已对外推出两款产品——岩鼠云设备平台和岳鹰全景监控平台。曾主导部门的前端体系建设,精通 Vue 和 React,在前端架构、工程化、性能等方面有较丰富的经验。

阅读数:733 发布于:2020 年 5 月 12 日 09:50

评论

发布
暂无评论