跳到主要内容

认识

2024年04月24日
柏拉文
越努力，越幸运

一、认识​

1.1 工作流​

Web 监控是一个全链路的监控体系， 包括数据采集、数据加工处理、削峰限流、数据上报、数据聚合、数据清洗、数据入库、数据分析与数据挖掘以及根据分析结果进行针对性的调整、消息推送等。

  1. 数据采集: 包括页面性能数据、异常数据、用户行为、资源数据、个性化指标等数据采集的过程

  2. 数据加工处理: 包括数据格式化、丰富上下文信息

  3. 削峰限流: 频率限制

  4. 数据上报: 上报方式、上报时机、上报优化

  5. 数据聚合

  6. 数据清洗

  7. 数据入库

  8. 数据分析与挖掘: 性能数据分析、异常数据分析、用户行为数据分析

  9. 消息推送

1.2 上报设计​

二、上报方式​

对于上报方面来说，SDK的数据上报可不是随随便便就上报上去了，里面有涉及到数据上报的方式取舍以及上报时机的选择等等，还有一些可以让数据上报更加优雅的优化点。

首先，日志上报并不是应用的主要功能逻辑，日志上报行为不应该影响业务逻辑，不应该占用业务计算资源；那么在往下阅读之前，我们先来了解一下目前通用的几个上报方式:

  1. 信标（Beacon API）: 可以将数据以 POST 方法将少量数据发送到服务端, 保证页面卸载之前启动信标请求, 并允许运行完成且不会阻塞请求或阻塞处理用户交互事件的任务。

  2. Ajax（XMLHttpRequest 和 fetch）

  3. Image（GIF、PNG）: 图片打点上报, 可以以向服务端请求图片资源的形式，像服务端传输少量数据，这种方式不会造成跨域

看了上面的三种上报方式，我们最终采用 sendBeacon + xmlHttpRequest 降级上报的方式，当浏览器不支持 sendBeacon 或者 传输的数据量超过了 sendBeacon 的限制，我们就降级采用 xmlHttpRequest 进行上报数据；

优先选用Beacon API: 的理由上文已经有提到：它可以保证页面卸载之前启动信标请求，是一种数据可靠，传输异步并且不会影响下一页面的加载 的传输方式。

而 降级使用 XMLHttpRequest 的原因是，Beacon API 现在并不是所有的浏览器都完全支持，我们需要一个保险方案兜底，并且 sendbeacon 不能传输大数据量的信息，这个时候还是得回到 Ajax 来

看到了这里，有的同学可能会问：为什么不用 Image 呀？那跨域怎么办呀？原因也很简单:

  1. Image 是以GET方式请求图片资源的方式，将上报数据附在 URL 上携带到服务端，而URL地址的长度是有一定限制的。规范对 URL 长度并没有要求，但是浏览器、服务器、代理服务器都对 URL 长度有要求。有的浏览器要求URL中path部分不超过 2048，这就导致有些请求会发送不完全。

  2. 至于跨域问题，作为接受数据上报的服务端，允许跨域是理所应当的

三、上报时机​

上报时机这里，一般来说:

  1. PV、错误、用户自定义行为 都是触发后立即就进行上报；

  2. 性能数据 需要等待页面加载完成、数据采集完毕后进行上报；

  3. API请求数据 会进行本地暂存，在数据量达到10条(自拟)时触发一次上报，并且在页面可见性变化、以及页面关闭之前进行上报；

  4. 如果你还要上报 点击行为 等其余的数据，跟 API请求数据一样的上报时机；

四、上报优化​

或许，我们想把我们的数据上报做的再优雅一点，那么我们还有什么可以优化的点呢？还是有的:

  1. 启用 HTTP2，在 HTTP1 中，每次日志上报请求头都携带了大量的重复数据导致性能浪费。HTTP2头部压缩 采用Huffman Code压缩请求头，能有效减少请求头的大小；

  2. 服务端可以返回 204 状态码，省去响应体

  3. 使用 requestIdleCallback ，这是一个较新的 API，它可以插入一个函数，这个函数将在浏览器空闲时期被调用。这使开发者能够在主事件循环上执行后台和低优先级工作，而不会影响延迟关键事件，如果不支持的话，就使用 setTimeout

参考资料​