数据埋点、监控方案

本文最后更新于：2022/03/01 , 星期二 , 00:12

最近在设计我司的日志系统，虽然最终没有采用我的这个方案，而是使用的美团Logan日志体系。但是还是记录一下自己设计思考的过程，还是学习到了很多的。

数据埋点、监控是什么？

数据埋点就是在应用中特定的流程收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑。

一般流程为：数据采集 -> 上报 -> 分析 -> 监控

一般需要采集什么信息？

1. 埋点的标识信息, 比如 eventId, eventType。eventId 用来唯一标识事件 ID，eventType 用来标识事件类型，如 click，scroll 等等等

2. 业务自定义的信息, 比如 SKU。

3. 通用的设备信息, 比如用户的 userId, userAgent, deviceId, timestamp, locationUrl 等等。

PS：userAgent 在前端中有着非常重要的作用，如果需要用一些新的 API，考虑兼容性的问题时，查看用户占比有数据支撑会更容易说服别人。locationUrl 的话方便把用户行为串联起来，另外一点比较重要的是排查一下问题会比较方便，比如我们遇到过的一个问题，因为 chrome 插件，对我们的 url 变化有影响，导致我们的应用只剩下一个侧边栏了，在没有记录 locationUrl 之前跟用户沟通还是很麻烦的，沟通成本很大。

一般怎么上报？

1. 实时上报, 业务方调用发送埋点的 api 后, 立即发出上报请求

2. 延时上报, sdk 内部收集业务方要上报的信息, 防抖或在浏览器空闲时间或者页面卸载前统一上报，上报失败会做补偿措施。

   • PS：重要埋点不要选择页面卸载前，有的浏览器可能监听不到关闭的行为，可能请求确确实实发出去了，但是关闭窗口后，请求会直接 abort 掉。

PS：为什么有延时上报，比如如果设计不规范，收集服务域名与业务服务域名相同，然后还恰好时 HTTP/1.1，那当有大量请求的时候，会有请求卡住的问题，阻塞业务请求。

目前一般都会无埋点 + 代码埋点一起用，一些普适性的按钮都采用无埋点，具有业务属性的逻辑使用代码埋点。

但是我们只使用了代码埋点，因为我们使用了tailwind的css方案，好多地方都没进行属性的封装，导致className可能对不上特定节点，还需要手动去加一些标识。

• 可定制化高，数据准确

• 时间、人力成本大。

比较好理解，代码里都写了注释了，这里就不想写说了。

实现的关键：

1. 校验数据
   简易版代码埋点SDK

无埋点并不是真正的字面意思，其真实含义其实是，不需要研发去手动埋点。

一般会有一个 sdk 封装好各种逻辑, 然后业务方直接引用即可。

sdk 中做的事情一般是监听所有页面事件, 上报所有点击事件以及对应的事件所在的元素，然后通过后台去分析这些数据。

还一种叫可视化埋点其实也属于无埋点，这种没深入了解过，我的理解就是：在可视化操作时可以设置个埋点，然后就按照无埋点的形式进行上报了。

方便省时，前端开发人员只需要监听最外层事件就可以了。

• 数据分析层会麻烦，需要根据唯一标识来匹配内容。

• 性能可能存在问题：比如使用的实时上报，然后用户疯狂点击空白处，就会造成无意义的上报

• 无法太个性化：通用方案。