背景

之前写了一篇年终总结的文章，有些朋友对我们在做的监控比较感兴趣，特此写一篇文章来梳理我们的整体的一套思路给大家参考。

前端异常监控系统的开发其实并不复杂，开源实现方案也颇多，技术实现成本并不难，痛点有但是并不是都不能解决，根据我们的情况总结了一下：

• 前端SDK，主要是用户行为追踪，错误拦截，上报策略，API设计。
• 上报的日志实现实时查询。
• 分级分层预警。
• 日志分析策略。

前端SDK

用户行为追踪

捕获用户的操作路径，根据操作路径我们去还原用户的使用场景，来帮助我们快速定位问题的所在。

操作路径分为以下几个点：

• 事件触发。根据业务场景，只截取了用户的点击（click/change）和拉动滚动条。
• 浏览路径。这块分为2种情况，spa和多页面应用，多页面应用我们可以通过 referrer 来确认上一个页面的url。spa的页面我们是对路由进行函数进行监听来做到。

当然这块整体的数据我们会基于cookie和localstorage来存取数据。

异常

脚本通过window.onerror以及拦截angular和vue的handleError来获取。 ajax这块除了ajax报错信息之外，也会根据业务层面的需求拦截返回的错误（栗子：我们请求返回除200外都是错误，所以整体都会上报）。

异常这块其实坑还是蛮多的，不过市面上各位大大总结的够好了，大家可以看看各位大大的总结。

操作系统

这块就是整个系统的信息，以及浏览器的信息、ua等。

总结

sdk这块其实2个难点，一个是用户行为如何定义？另一个异常收集这块会有蛮多的坑要踩。 另一部分整体的上报策略，目前我们是对异常进行了分级，低级别的错误延迟并且合并上报，同一个点同一种错误去重上报。

日志收集

所有日志都打到nginx，并且nginx备份日志，请求代理到后面的node服务，node服务清洗数据后进行入库，这块有一个要注意的点，如果node服务被打死，整个数据就断掉了，所以这块我们有一个定时任务从nginx备份的日志里清洗出由于服务挂掉没有处理的请求。

为什么没有用到大家都比较爱使用的elk呢？ 答：通过调研目前我们的量级其实还没有完全要上升到需要elk的层面，我们更倾向于一种可控的状态。

预警

预警服务采用分级策略，按照组织架构，高级别的异常上来后，一段时间没有处理，预警系统会触发向上汇总的策略，直到部门负责人。

展示分析

目前这块会相对薄弱一些，基本只分析了一个周期的项目情况。整个重心还是在错误的解决层面。

总结

前端sdk更偏重于前端的异常收集。整体的后端服务，其实是面向于所有的异常来做的，我们更倾向于给公司提供一套完善的日志系统（ps：目前我们团队的后端监控的数据也逐渐的上到该系统）。

最后希望感兴趣的同学加入我们团队email:liuqing@liluo.me（除前端外，我们也招python，爬虫，大数据）, 也希望各位能给我们提些意见和建议，毕竟组内的同学们也是通过业余时间来把整体的方案完善，并且开发完成，还有很多需要提升的地方。