前端异常监控体系

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万起步
数据保存在三方
数据可以保留三个月
自建监控体系

 

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

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

需求拆解

1. SDK for Web

功能列表:

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

研发计划

以上是关于前端异常监控体系的主要内容,如果未能解决你的问题,请参考以下文章

前端劝退之前端知识体系(前端面试体系)

快速接入业务监控体系,grafana监控的艺术

监控体系之运维

排查效率提升80%!百亿级数据量的实时日志监控优化

告警运维中心|构建高效精准的告警协同处理体系

大型运维知识体系v2.0