前端的守望者：阿里岳鹰 Web 全景监控平台的建设之路_前端_陈周勉

PCon全球产品创新大会即将开幕，抢占最后的交流席位！了解详情 



 写点什么

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

大前端时代

前端开发的痛点

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

兼容性
终端
用户体验

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

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

在硝烟中诞生

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

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

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

岳鹰平台的探索之路

传统的监控解决方案

传统的解决方案，大致会有这几步：

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

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

传统解决方案的弊端

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

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

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

我们的思考

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

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

内核 SDK 的原理和优势

内核是如何工作的呢？

传统方案的 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 里面分析性能的时候，如果得到的信息是首屏加载比较慢，那么当你想要了解原因的时候是无迹可寻的，而内核会收集或定义更多时间段的信息，从而了解页面的问题。

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

白屏采集原理

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

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

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

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

一次真实的案例

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

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

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

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

节流

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

支持降级

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

（动态）采样

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

安全

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

Web 平台打造

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

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

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

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

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

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

接入场景

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

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