前端异常监控体系

背景

目前所有前端项目（无论测试 / 上产）均无异常监控, 导致了以下几个典型问题：

• 无法获知用户使用的浏览器类型

• 无法获知用户端是否可以正常使用（有无前后端Bug阻塞用户）

  • 上线后无法主动获得用户使用情况， 只能通过人工咨询
  • 无法进行Bug追踪
• 用户报Bug后（非技术人员）, 缺少问题定位所需的必要信息，复现问题成本极高.
• 无法对比历史版本的Bug情况
• 出现线上Bug后，无法获知Bug影响范围，无法进一步决定是否需要紧急发版
• 失去监控的线上Bug如果没人上报，会影响用户实际业务，影响用户满意度，进而影响公司业务

概括来说：1. 线上错误无感知；2. 错误定位成本高；3. 降低用户满意度

目标

• 给研发团队问题感知能力
• 给研发团队快速定位技术问题的能力
• 给研发团队 / 产品经理对比版本质量，持续改进产品的基础能力
• 给研发团队 / 产品经理是否做hotfix的决策能力
• 降低问题反馈的沟通成本，优化问题反馈链路（CSM —  产品经理 —  技术负责人 —   研发工程师 —  测试工程师）
• 补充测试团队未覆盖的场景

投入产出评估

方案比较

方案	年费价格（规模：支撑BIV部门的少量应用）	年费价格（规模：支撑整个研发中心）	其他 优势 / 劣势 比较
使用三方服务 (Fundebug)	159 * 12 = 1908 数据保存在三方 数据仅保留一个月	30万起步 数据保存保留在公司
使用三方服务 (Sentry)	80 7 12 = 6720 数据保存在三方 数据可以保留三个月	900 7 12 = 7.56万起步 数据保存在三方 数据可以保留三个月
自建监控体系

 

自建异常监控体系（第一版），需要完成以下组成部分，以完成体系的最小闭环.

组成部分	角色功能	研发资源	是否一期必需
异常上报SDK	JS库，每个项目中引入后，手动 / 自动完成上报		是
日志处理（清洗 + 聚合 + 持久化）	服务，ES清洗 / 聚合 + MySQL持久化		是（但一期可以没有数据清洗 / 数据聚合部分）
监控平台	上报数据可视化，Nodejs服务 + 前端单页应用		是
告警机器人	服务，根据特定条件，触发钉钉报警等.		否

需求拆解

1. SDK for Web

功能列表：

	描述	备注
支持快速接入	SDK通过npm方式引入, 并通过简单配置可以快速引入项目
支持手动上报错误	开发者可以在项目中自行选择上报位置，进行自定义错误上报

研发计划