摘要
前端的日志采集是收集用户行为信息和错误监控的重要一环，为后续的上层决策、监控报警提供了基础的数据依据，因而对日志的采集上报也提出了更高的要求，既不影响用户体验的前提下又要尽可能高的保证准确率、成功率。
那么日志上报采集应该用那种上报方式呢？那种方式才是最好呢？
日志上报分析
日志采集前提
-
**资源隔离 ：**为了避免影响业务，那么理所当然，为了不占用业务计算资源，日志上报需要单独设定后端服务。
同时也不能使用与业务相同的域名，这跟页面尽量使用CDN引入资源的原理相似，浏览器会对同一个域名有一定的并发数限制。
而页面性能、资源加载、初始化API、PV/UV、初始化js逻辑错误等日志都是页面初始化的时候触发上报，这种短时间大量的上报可能会造成网络请求延时。例如chrome对同一个域名的最大并发连接数为6个，如果日志同时上报了6次以上，就会对同域名的业务造成影响；更坏的情况如页面有一些错误、网络连接质量质量不高会让日志上报阻碍页面渲染。
-
**不阻塞页面：**在一些特殊情况下或者特殊事件的上报应该不阻塞页面，保证用户的体验和交互流畅，比如页面离开、页面关闭等，既要保证上报的成功率，又要不影响用户行为。
-
**兼容性、适用性：**作为日志的采集上报，根据宿主环境的不同对兼容性提出了更高的要求，能够使用不同的场景，或者在不同场景下自主降级采用的上报方式。
上报方式分析
接口请求
接口请求指通过Ajax/Fetch等方式，将收集到的数据通过固定的接口发送给服务端，即我们业务中通常向后端请求接口发送数据的方式。这种方式发送数据相对来说比较简单，使用post接口可以发送比较大量的数据。这种方式是异步，不会阻塞和影响页面正常渲染，但是，还是会占用一定的客户端资源，且需要特殊处理跨域限制。
图片打点
图片打点方式即通过请求一个图片，通常为1乘1px大小图片，然后将收集的数据拼接在这个图片的url后面，这样，静态资源服务器（比如nginx服务器）就能记录到请求的信息，将其存入日志。之后，便可以通过分析存入的日志，获取到所收集到的信息。这种方式可以说是一条蹊径，简单，占用资源低且天然可跨域，目前大部分前端监控上报产品都采用了类似的方式，进行数据的收集。但是，由于是get请求，对上报的数据量有一定的限制。
sendBeacon
navigator.sendBeacon是一个比较新的API，它能异步的以post方式发送数据到服务端，且不会影响页面渲染和阻塞页面，即使页面关闭，也不会影响其数据的发送，浏览器会对其进行调度，以确保其可靠性和最低影响性。并且不受跨域限制，浏览器兼容性也比较好，可以支持除IE之外的几乎所有浏览器。其采集数据方式，即可以像请求一样直接拿到上报的数据进行存储，也可以像图片打点一样，来存储日志，再做分析。
上报抉择
1、post接口
如果日志上报配置了相关跨域的设置，并且在通用的页面点击、展示等事件上报时，要求日志采集合并上报，对上报的包体积有更更高的要求，此时应该采集post接口方式。
2、sendBeacon
信标（Beacon）可以异步与非阻塞的数据传输，从而最大限度地减少与其他关键操作的资源争用，同时它可以确保这些请求一定会被处理并将其传递到服务端：
-
信标请求优先避免与关键操作和更高优先级的网络请求竞争。
-
信标请求可以有效地合并，以优化移动设备上的能量使用。
-
保证页面卸载之前启动信标请求，并允许运行完成且不会阻塞请求或阻塞处理用户交互事件的任务。
信标的使用非常简单：
var data = jsON.stringify({
name: 'Berwin'
});
navigator.sendBeacon('/haopv', data)
navigator.sendBeacon()方法主要用于满足统计和诊断代码的需要。这些代码通常会在卸载文档之前，尝试通过HTTP将少量数据异步传输到Web服务器。它解决了日志上报在unload时成功率很低的问题。我们在埋点时有很多对离开页面时上报的需求，因为SendBeacon是异步的，不会影响当前页到下一个页面的跳转速度，可以更可靠地保障事件上报成功率，并且不影响路由切换。
3、图片img.src方式
当浏览器不支持navigator.sendBeacon时，我们可以采用模拟图片加载的方式发送日志上报事件，且不会存在跨域问题，等兼容性要求较高等，此时采用图片打点的方式。
总结
前端业务场景和浏览器的兼容性千差万别，所以日志上报要兼容多种方式；页面生命周期、业务逻辑影响了日志是否可获取和是否漏报，所以对应的日志类型和上报时机要严格把握；前端业务逻辑快速迭代且场景多样，所以日志上报要做到与业务解耦合同时可以自定义上报…
这些大大小小的坑促使我们把前端日志监控沉淀为一个独立且系统性的工程来做，在打磨这个工程的过程中我们同样还在探索是否有更加高效、稳定的日志上报方式。
