前端线上监控体系设计

为何

线上监控可让咱们方便的了解到业务产品的真实指标，如访问量、用户交互数据、页面错误、性能等关键信息。对于应用的体验优化和用户精细化运营相当重要。

线上监控是个比较复杂的体系，包括数据采集、处理计算、可视化等方面。这里篇幅和知识所限，只说端上的数据采集方面。

作什么

咱们已经了解到监控的所须要的数据指标，基于此咱们要采集哪些类型的数据呢？

具体以下：

• 应用加载、卸载，这是访问量
• 路由切换，对于单页面很重要
• 性能，包括加载时，运行时
• 错误，接口错误，JS 错误
• 用户交互数据，点击、眼球曝光埋点

不作什么

咱们整个线上监控体系设计的目标是稳定（不会影响正常业务，埋点不会轻易失效），高效（不会对应用产生性能负担），无侵入性（不会限制业务）。基于此咱们放弃如下方案。

不作无埋点/可视化埋点

无埋点和可视化埋点的原理都是利用 DOM 属性或 css 选择器将埋点和元素一一对应。而页面结构变更反过来会影响埋点的定位。这也是它们不稳定的根本缘由。抛弃这类方案的缘由在于：它提供的收益（埋点开发效率）和成本（埋点失效后的排查、反馈、修复）不成正比。

数据模型

咱们如今已经知道了线上监控所关心的具体指标和数据类型，那么具体到某一条数据，咱们关系哪些参数、用一个什么样的数据模型来指导咱们的采集和分析呢？

总的来看，咱们关注这些数据：

• 用户是谁 用户的设备ID，帐号
• 用户的设备信息，什么系统，什么浏览器，4G 仍是 WIFI
• 时间信息，错误，用户交互产生的时间
• 用户产生了什么行为，点击，眼球曝光，页面切换
• 其余上下文信息，IP，业务自定义数据

采集原理

应用加载卸载

固然是监听 load 、beforeunload 事件

路由切换

固然能够使用 hashchange 、hack history API，但这些很难获取到动态路由的信息。好比若是一个路由的 path 为 blog/:id。就很难将 blog/a 和 blog/b 作数据聚合。这方面能够提供一个 sendPageView 方法给到业务，业务本身在路由钩子内调用该方法便可。

性能数据

使用 performance API，具体不在赘述。

错误信息

能够使用 window.onerror 来监听一部分错误，但这个方法兼听不到 promise 错误和 script error 。一些前端框架的错误，如 react 的 componentDidCatch 也须要作特殊定制。

用户交互数据

用户交互数据也就是一般所说的埋点，实现起来其实很是简单。

好比咱们经过声明式埋点来上报数据，埋点标识为属性中带 data-track-id 的元素。

document.addEventListener('click', (e) => {
    if (e.path.some(el => el.matches('[data-track-id]'))) {
    // 上报数据
    }
}, true)
复制代码

数据上报

以前也说到，监控方案的目标是稳定和高效。为了避免影响业务应用的性能，咱们会把采集的关键逻辑使用 window.requestIdleCallback 包裹起来。

为了在浏览器关闭时也能上报数据，咱们会使用 Navigator.sendBeacon 来上报数据，对于不支持这个 API 的浏览器，咱们使用构造 image 请求来作 fallback 和跨域。

为了减小流量和服务器压力，在采集端也会作缓存，请求协议上也会作一些优化，这里再也不赘述。

总结

这里简单介绍了一些前端监控体系的方向和经验之谈。没有涉及大数据处理，也不包括数据的聚合展现，数据采集只是这个体系中很小的一环。而线上监控其实也只是整个前端工程体系中的一小部分。做为一个前端工程师，若是不懂运维，不懂后端，那么能在整个前端工程体系中发挥的做用就颇有限。