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

traceId：追踪一个异常发生前后的相关日志。当应用启动时，创建一个traceId，直到一个异常发生时，刷新traceId。把一个traceId相关的requestId收集起来，把这些requestId相关的日志组合起来，就是最终这个异常相关的所有日志，用来对异常进行复盘。

上图举例展示了如何利用traceId和requestId找出和一个异常相关的所有日志。在上图中，hash4是一条异常日志，我们找到hash4对应的traceId为traceId2，在日志列表中，有两条记录具有该traceId，但是hash3这条记录并不是一个动作的开始，因为hash3对应的requestId为reqId2，而reqId2开始于hash2，因此，我们实际上要把hash2也加入到该异常发生的整个复盘备选记录中。总结起来就是，我们要找出同一个traceId对应的所有requestId对应的日志记录，虽然有点绕，但稍理解就可以明白其中的道理。

我们把这些和一个异常相关的所有日志集合起来，称为一个block，再利用日志的hash集合，得出这个block的hash，并在索引区中建立索引，等待上报。

3.3 上报日志

上报日志也在webworker中进行，为了和整理区分，可以分两个worker。上报的流程大致为：在每一个循环中，从索引区取出对应条数的索引，通过索引中的hash，到归档区取出完整的日志记录，再上传到服务器。

按照上报的频率（重要紧急度）可将上报分为四种：

a. 即时上报

收集到日志后，立即触发上报函数。仅用于A类异常。而且由于受到网络不确定因素影响，A类日志上报需要有一个确认机制，只有确认服务端已经成功接收到该上报信息之后，才算完成。否则需要有一个循环机制，确保上报成功。

b. 批量上报

将收集到的日志存储在本地，当收集到一定数量之后再打包一次性上报，或者按照一定的频率（时间间隔）打包上传。这相当于把多次合并为一次上报，以降低对服务器的压力。

c. 区块上报

将一次异常的场景打包为一个区块后进行上报。它和批量上报不同，批量上报保证了日志的完整性，全面性，但会有无用信息。而区块上报则是针对异常本身的，确保单个异常相关的日志被全部上报。

d. 用户主动提交

在界面上提供一个按钮，用户主动反馈bug。这有利于加强与用户的互动。

或者当异常发生时，虽然对用户没有任何影响，但是应用监控到了，弹出一个提示框，让用户选择是否愿意上传日志。这种方案适合涉及用户隐私数据时。

即时上报虽然叫即时，但是其实也是通过类似队列的循环任务去完成的，它主要是尽快把一些重要的异常提交给监控系统，好让运维人员发现问题，因此，它对应的紧急程度比较高。

批量上报和区块上报的区别：批量上报是一次上报一定条数，比如每2分钟上报1000条，直到上报完成。而区块上报是在异常发生之后，马上收集和异常相关的所有日志，查询出哪些日志已经由批量上报上报过了，剔除掉，把其他相关日志上传，和异常相关的这些日志相对而言更重要一些，它们可以帮助尽快复原异常现场，找出发生异常的根源。

用户提交的反馈信息，则可以慢悠悠上报上去。

为了确保上报是成功的，在上报时需要有一个确认机制，由于在服务端接收到上报日志之后，并不会立即存入数据库，而是放到一个队列中，因此，前后端在确保日志确实已经记录进数据库这一点上需要再做一些处理。

上图展示了上报的一个大致流程，在上报时，先通过hash查询，让客户端知道准备要上报的日志集合中，是否存在已经被服务端保存好的日志，如果已经存在，就将这些日志去除，避免重复上报，浪费流量。

3.4 压缩上报数据

一次性上传批量数据时，必然遇到数据量大，浪费流量，或者传输慢等情况，网络不好的状态下，可能导致上报失败。因此，在上报之前进行数据压缩也是一种方案。

对于合并上报这种情况，一次的数据量可能要十几k，对于日 pv 大的站点来说，产生的流量还是很可观的。所以有必要对数据进行压缩上报。lz-string是一个非常优秀的字符串压缩类库，兼容性好，代码量少，压缩比高，压缩时间短，压缩率达到惊人的60%。但它基于LZ78压缩，如果后端不支持解压，可选择gzip压缩，一般而言后端会默认预装gzip，因此，选择gzip压缩数据也可以，工具包pako中自带了gzip压缩，可以尝试使用。

4.1 接入层与消息队列

一般通过提供独立的日志服务器接收客户端日志，接收过程中，要对客户端日志内容的合法性、安全性等进行甄别，防止被人攻击。而且由于日志提交一般都比较频繁，多客户端同时并发的情况也常见。通过消息队列将日志信息逐一处理后写入到数据库进行保存也是比较常用的方案。

（编辑：吕梁站长网）

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