[ 前端监控 SDK 实战 中 | 青训营笔记]

这是我参与「第五届青训营」笔记创作活动的第二十三天

概述：前端监控之前端常见异常

异常和性能有什么差异呢：异常就是在页面运行时发生的一些预期之外的报错，有些；报错可能对我们页面影响不大，有些报错可能对我们页面造成一些不可逆的影响，比如说白屏，或一些关键的元素没有渲染出来等等。所以监控前端异常和监控前端性能指标都是同等重要的，而且异常是我们实时处理和关注的，它的紧迫程度可能比性能还要高

静态资源错误

请求异常

• 400 - 499 & 500 - 599 是我们需要监控的请求异常范围

• 不要忘记状态码也可能出现0这个特殊值

• 请求成功率越高，说明我们后端提供的Http服务更加稳定; 请求成功率越低，当然也有可能是前端传参的时候出现了错误，也有可能是后端服务发生了一些异常

JS错误

• 现在很多页面或多或少的都会发生一些JS的错误，但是我们发现有些JS错误不太会影响页面的正好使用，可能是正好命中了一些边缘的Case，然后这边缘Case又没有影响到我们关键资源的加载；还有一些JS错误，会严重影响页面的正常渲染或交互，比如说我往页面里面添加一个元素时候，然后添加失败了，给用户呈现的内容就会少了一块，所以不管这个JS错误是影响严重还是不严重的，我们在监控的时候是没办法区分的，所以我们会把所有JS错误都上报上来，它是我们监控的重中之重

白屏异常

• 由于白屏异常，浏览器并没有提供标准化方法，所以需要通过我们自己的技术方案来实现

• 一个简单的思路是通过判断DOM树的结构来粗略的判断白屏是否发生，当然具体的实现并不是这么简单

• 当然这并不是所有可能导致白屏的原因

• 做好白屏的归因也是我们前端监控很重要的一点

小试牛刀：监控前端性能与异常(实战)

性能指标监控

原理：浏览器提供的一些标准的对象，比如Performance和PerformanceObserver

在开发中我们希望同学们在实现具体的监控能力时，能多康康文档

良好的习惯：在我们做什么事之前，都先看文档，先调研，写一些技术方案，最后再来Coding，Coding放在我们的最后一步

• 由于PerformanceObserver可以比window.performance访问到更多值，所以在实战中，我们通常会先尝试使用window.performance来获取值，如果没有，再尝试使用PerformanceObserver来获取值

• 然后我们想要把它封装成一个monitor, 只有这样，之后才能被整合到我们的SDK当中

• 我们对这个monitor的需求

  0. 起名字，类似unique ID，和SDK中的其它monitor起到区分作用
  1. 监听能力
  2. 主动开启，而不是被动开启 (这里的意思是，不希望monitor一被创建就主动开启，而是希望通过SDK来管理monitor的启停)
  3. 上报能力

JS错误监控

• 监听JS错误，我们一般是在根节点或是全局对象监听(window)

• 注意第二行中的回调函数的入参e，我们需要对其进行一个过滤，以防其混入其他类型的一个错误，只有 e.error不会空时，它才是一个合法的JS错误