异常监控系统设计背景

不同于后端服务有日志可查询可追溯，对于前端而言，前台出现的异常和报错，往往在用户发现之后才能通知到开发，消息滞后，处理不及时，而且单纯从用户反馈描述去定位也有一定难度。当然，按业务场景来说，前后端也应该有一套完善监控系统，前端实现具体的前台监控方案，但对于上报日志的数据入库、分析、预警等，也需要后端的支持。有些前台出现的错误，例如数据类型报错，可能是前端数据处理出错，也可能是后端返回数据报错导致的逻辑错误，如果将前后端串联起来，可以方便及时发现线上异常，定位错误解决问题。

版本更新日志

版本 更新内容 备注
1.1.0 增加IP字段，控制钉钉消息频率，修复undefined级错误显示，增加UUID字段识别设备 运行分析文档

系统版本

  • 2018.10.20 version 1.0.0

  • 2018.11.XX version 1.1.0

    系统设计

    日志采集

    • 前台监控异常，收集日志，在本地做好数据处理之后，上报服务器。

      数据入库

    • 后端接收前端上报的异常日志进行存储。

      预警

    • 根据异常级别，触发报警，通过钉钉通知到开发。

      分析

    • 搭建一个可视化的数据看板，开发可以看到具体的日志数据，从而对项目进行异常分析和复盘。

对于目前的用户量来说，第一阶段做好预警即可，根据实际情况来决定是否需要设计入库和分析的环节。

错误采集

前端常见异常：白屏（崩溃），样式错乱，渲染正常但执行某步操作后页面卡死，页面交互正常但某个资源无法加载（如图片显示报错，音频无法播放），前后端交互报错（如ajax请求40X或者50X）等。

异常等级

等级 异常类别 定级描述 异常产生常见原因
0 白屏、样式错乱，某步操作导致页面卡死崩溃 用户完全无法使用或中断操作，最严重 a. js运行时逻辑报错或数据类型错误（频率最高）b. 项目静态资源加载异常，资源跨域，非安全环境（频率较低）c. js语法错误（频率极低）d. 系统错误（频率极低）
1 媒体资源无法使用 不影响产品交互，但用户无法使用完整功能，很严重 a. 主站资源404（频率较低）b. 弱网环境（频率较低）c. 后台运营配置出错（频率较高）
2 提交表单或发起请求失败，图片不可用 不影响产品交互，但对于部分场景会中断用户的操作步骤，对于ajax请求报错后端会先于前台系统报警，较严重 a. 提交或返回数据类型出现变动，与约定格式不符（频率较低）b. 第三方基础服务报错（频率较低）c. 图片资源被删除（频率较低）

tips: 0级和1级异常需要开发者快速响应。

信息采集

前端捕捉到的错误信息比较杂乱，需要在前台做一次数据过滤。

  • 用户信息
    • 在登录状态的维度进行定位。收集用户当前的登录状态，uid等。
  • 设备信息
    • 以系统类型、设备类型进行定位。收集报错机型和系统型号，便于复现并优化设备兼容性问题。
  • 页面信息
    • 根据当前页面信息和操作路径历史，定位报错页面，便于复现报错环节。
  • 日志信息
    • 收集错误类型、错误等级、操作错误的dom节点。直接定位修复bug的重要依据。

      错误日志数据结构

  1. interface ErrorLog {   
  2.   tag: string; 
  3.   appName: string;  
  4.   userInfo: {     
  5.     isLogin: boolean;
  6.     uid: string   
  7.   };
  8.   deviceInfo: {     
  9.     client: 'h5';
  10.     ua: string;
  11.     system: string;
  12.     isWeixin: boolean;
  13.     isApp: boolean;
  14.     version: string   
  15.   };
  16.   pageInfo: {     
  17.     url: string;
  18.     title: string;
  19.     routerLength: number   
  20.   };
  21.   errorInfo: {     
  22.     type: number;
  23.     desc: string;
  24.     level: number;
  25.     filename: string;
  26.     message: string;
  27.     errorStack: object;
  28.     lineno: number;
  29.     colno: number;
  30.     t: number   
  31.   };
  32.   dingTalkInfo: string 
  33. }

日志上报

随着后期完善，用户体量增大，异常报错信息会变得越来越复杂，这就需要考虑到日志上报的量和频率问题，即需要做前端数据持久化存储。

根据错误等级进行频率控制，例如：

等级为0和1的错误应该即时上报。
等级为2的错误可以在前端作本地存储（IndexedDB或Storage)，每5条打包批量上传一次，或者按照时间间隔进行单条上传，降低对服务器的压力。
除此之外，还可以增加用户反馈机制，弹出弹层，当非紧急异常在短时间内快速累积时，让用户选择手动反馈bug，并帮助用户自动刷新页面，防止页面卡死导致死机崩溃。

错误日志前端存档归档

前台收集的日志后在本地进行存档归档，上报后端之后，此条日志将进入归档区，记录并设立失效时间此条日志间结束后会对store进行清洗。

预警

后端接收到紧急异常上报后，立即以钉钉方式推送错误消息，需要展示最直观的信息，可以前后端进行约定。
规则：每分钟累计超过10条则发送一次消息。