前端异常监控体系
Posted 一吃三大碗
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了前端异常监控体系相关的知识,希望对你有一定的参考价值。
背景
目前所有前端项目(无论测试 / 上产)均无异常监控, 导致了以下几个典型问题:
- 无法获知用户使用的浏览器类型
无法获知用户端是否可以正常使用(有无前后端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方式引入, 并通过简单配置可以快速引入项目 | |
支持手动上报错误 | 开发者可以在项目中自行选择上报位置,进行自定义错误上报 |
研发计划
以上是关于前端异常监控体系的主要内容,如果未能解决你的问题,请参考以下文章