前端异常监控实践

背景

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

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

• 前端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，爬虫，大数据）, 也但愿各位能给咱们提些意见和建议，毕竟组内的同窗们也是经过业余时间来把总体的方案完善，而且开发完成，还有不少须要提高的地方。