前端监控实践 #

前言 #

对于前端监控体系的兴趣还是起源于之前分享的字节的一次分享会...

这应该会是一个系列专栏...吧。

为什么要去做前端监控？ #

或者说是，我们前端监控的目的何在？

1. 更快的发现问题，解决问题
2. 为业务拓展提供了更多的可能性
3. 能够了解业务数据，做产品的决策依据。（数据驱动）
4. 提高前端工程师的技术深度和广度

指的是通过一定的手段来获取用户行为以及跟踪产品在用户端的使用情况，并以监控数据为基础，为产品优化指明方向，为用户提供更加精确、完善的服务。

前端监控有哪些方向？ #

1. 数据监控（监听用户行为）
2. 性能监控（监听应用性能）
3. 异常监控（监控代码异常）

前端监控有哪些流程？ #

用一句话来总结：采集数据>>上报数据>>分析数据>>报警通知

其中最重要的步骤就是 前端埋点 和 数据上报 ，也就是数据的收集阶段，而数据收集的丰富性和准确性会影响对产品线上效果的判别结果

前端埋点 #

埋点主流方案包括无痕埋点（全埋点），代码埋点，可视化埋点。

先鸽，下次有机会再分享

数据采集 #

大概了解了一下，这种库开源的有很多，但是各大厂里大多都采用自己制造的，因为关注的指标大概不同，使用开源就不如去自定义化，方便后续的设置阈值和异常报警，以及数据分析、监控、统计等。

这两天撸了半个库，简单说下这种库的工作流程以及内容。

目前只做了针对性的做了关于性能监控部分的基础Api，基于 Performance 开发。

针对于页面性能，主要是去算加载时长，耗时越短，说明网页性能越好。

数据上报 #

1. 直接发送请求上报（Axios） #

cosnt url = 'https://api.wangez.site/reception/monitor'
axios.post(url, data)

问题： 但这种方法有一个问题，就是在页面卸载或刷新时进行上报的话，请求可能会在浏览器关闭或重新加载前还未发送至服务端就被浏览器 cancel 掉，导致数据上报失败。

我们可以将请求改为同步方法，这样就能保证请求一定能发送到服务端。

实在不是一个好方案

2. Img 方式上报（目前常用） #

第二种方式就是利用图片的 src 属性发送请求进行数据上报，因为大部分浏览器会延迟卸载（unload）文档以加载图像（只是大多数浏览器，还是存在兼容性的），所以用图片上报就可以解决第一种方法的漏洞。

用图片上报还有以下优点：

1. 图片请求方式不会出现跨域问题，因为打点域名经常不是当前域名；
2. 防止阻塞页面加载，影响用户体验；
3. 一般采用 1*1 像素的透明 GIF 进行上报，因为 GIF 图片格式体积小（最小的 BMP 文件需要74个字节，PNG 需要67个字节，而合法的GIF，只需要43个字节）

3. sendBeacon（推荐） #

同样为了解决页面卸载时，数据不能完成上报等问题，web底层新增了sendBeacon方法。

MDN：Navigator.sendBeacon

这个方法主要用于满足统计和诊断代码的需要，这些代码通常尝试在卸载（unload）文档之前向 Web 服务器发送数据。过早的发送数据可能导致错过收集数据的机会。

然而，对于开发者来说保证在文档卸载期间发送数据一直是一个困难。

使用 sendBeacon() 方法会使用户代理（浏览器）在有机会时异步地向服务器发送数据，同时不会延迟页面的卸载或影响下一导航的载入性能，这意味着：

1. 数据发送是可靠的。
2. 数据异步传输。
3. 不影响下一个页面的载入。

navigator.sendBeacon(url, data);

数据监控以及预警 #

先鸽，下次有机会再分享

最后 #

这个website-monitoring库，会在学习前端监控体系的知识过程中逐渐开发维护，大概会围绕着个人风格来进行封装，如果你也想要学习这方面的知识，可以Fork到你自己的仓库，之后按照自己的习惯开发就好。

欢迎大家存个 star 呀~

https://github.com/wangenze267/monitor