深入浅出前端监控

Posted 2022-03-25 ELab团队

采集的监控数据一般都会设置一些通用的环境信息，这些环境信息可以提供更多的维度以帮助用户发现问题和解决问题。下图列举了一些常见的环境信息：

的字样，这种情况一般都是 JSON.parse 解析出错或浏览器兼容性问题导致，属于运行时错误并非编译时错误。

对于异常监控我们主要关注 JS 运行时错误，多数场景下的处理手段如下：

错误场景	如何上报
场景一：自行感知的同步运行时异常	try-catch 后进行错误上报
场景二：没有手动 catch 的运行时异常（包括异步但不包括 promise 异常）	通过 window.onerror进行监听
场景三：自行感知的 promise 异常	promise catch 进行捕获后进行错误上报
场景四：没有手动 catch 的 promise 异常	监听 window 对象的 unhandledrejection 事件

整体来看，监控 SDK 会在全局帮助用户去捕获他们没有自行感知的异常并上报，对于自行捕获的异常一般会提供手动上报接口进行上报。

方法中处理。

2. 资源加载异常触发的error事件不会冒泡，因此使window.addEventListener(\'error\', cb, true) 在事件捕获阶段进行捕获。

第一种方式侵入性太强，不够优雅，目前主流方案均采用第二种方式进行监控：

捕获静态资源加载异常

APM 平台一般会有所有静态资源加载的明细，其原理是通过 PerformanceResourceTiming API 来采集静态资源加载的基本情况，这里不做展开。

对象和 fetch 方法进行重写，从而在代理对象中实现状态码的监听和错误上报：

重写 XMLHttpRequest 对象

重写 fetch 方法

当然了，重写上述方法后除了异常请求可以被监控到之外，正常响应的请求状态自然也能被采集到，比如 Slardar 会将对所有上报请求的持续时间进行分析从而得出慢请求的占比：

PS：如果通过 XHR 或 fetch 来上报监控数据的话，上报请求也会被被拦截，可以有选择地做一层过滤处理。

方法模拟实现，浏览器会在下一次重绘之前执行 rAF 的回调，因此可以通过计算每秒内 rAF 的执行次数来计算当前页面的 FPS。

通过 rAF 计算 FPS

FPS 持续低于预期：当前页面连续 3s FPS 低于 20。