前端异常监控解决方案研究

我们前面提到，我们并不单单采集异常本身日志，而且还会采集与异常相关的用户行为日志。单纯一条异常日志并不能帮助我们快速定位问题根源，找到解决方案。但如果要收集用户的行为日志，又要采取一定的技巧，而不能用户每一个操作后，就立即将该行为日志传到服务器，对于具有大量用户同时在线的应用，如果用户一操作就立即上传日志，无异于对日志服务器进行DDOS攻击。因此，我们先将这些日志存储在用户客户端本地，达到一定条件之后，再同时打包上传一组日志。

那么，如何进行前端日志存储呢？我们不可能直接将这些日志用一个变量保存起来，这样会挤爆内存，而且一旦用户进行刷新操作，这些日志就丢失了，因此，我们自然而然想到前端数据持久化方案。

目前，可用的持久化方案可选项也比较多了，主要有：Cookie、localStorage、sessionStorage、IndexedDB、webSQL 、FileSystem 等等。那么该如何选择呢？我们通过一个表来进行对比：

综合之后，IndexedDB是最好的选择，它具有容量大、异步的优势，异步的特性保证它不会对界面的渲染产生阻塞。而且IndexedDB是分库的，每个库又分store，还能按照索引进行查询，具有完整的数据库管理思维，比localStorage更适合做结构化数据管理。但是它有一个缺点，就是api非常复杂，不像localStorage那么简单直接。针对这一点，我们可以使用hello-indexeddb这个工具，它用Promise对复杂api进行来封装，简化操作，使IndexedDB的使用也能做到localStorage一样便捷。另外，IndexedDB是被广泛支持的HTML5标准，兼容大部分浏览器，因此不用担心它的发展前景。

接下来，我们究竟应该怎么合理使用IndexedDB，保证我们前端存储的合理性呢？

上图展示了前端存储日志的流程和数据库布局。当一个事件、变动、异常被捕获之后，形成一条初始日志，被立即放入暂存区（indexedDB的一个store），之后主程序就结束了收集过程，后续的事只在webworker中发生。在一个webworker中，一个循环任务不断从暂存区中取出日志，对日志进行分类，将分类结果存储到索引区中，并对日志记录的信息进行丰富，将最终将会上报到服务端的日志记录转存到归档区。而当一条日志在归档区中存在的时间超过一定天数之后，它就已经没有价值了，但是为了防止特殊情况，它被转存到回收区，再经历一段时间后，就会被从回收区中清除。

3.2 前端整理日志

上文讲到，在一个webworker中对日志进行整理后存到索引区和归档区，那么这个整理过程是怎样的呢？

由于我们下文要讲的上报，是按照索引进行的，因此，我们在前端的日志整理工作，主要就是根据日志特征，整理出不同的索引。我们在收集日志时，会给每一条日志打上一个type，以此进行分类，并创建索引，同时通过object-hashcode计算每个log对象的hash值，作为这个log的唯一标志。

• 将所有日志记录按时序存放在归档区，并将新入库的日志加入索引
• BatchIndexes：批量上报索引（包含性能等其他日志），可一次批量上报100条
• MomentIndexes：即时上报索引，一次全部上报
• FeedbackIndexes：用户反馈索引，一次上报一条
• BlockIndexes：区块上报索引，按异常/错误（traceId，requestId）分块，一次上报一块
• 上报完成后，被上报过的日志对应的索引删除
• 3天以上日志进入回收区
• 7天以上的日志从回收区清除

rquestId：同时追踪前后端日志。由于后端也会记录自己的日志，因此，在前端请求api的时候，默认带上requestId，后端记录的日志就可以和前端日志对应起来。

（编辑：惠州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!