前端监控体系

背景

目前c端无实时监控，导致事故响应时长很慢，产品可用性不达标，亟需改进。

方案

整体系统交互图：

c端上报SDK逻辑图：

影响前端可用性的几个部分：

• 前端代码可用性
  • 技术架构单点问题(SPOF)
  • 业务逻辑覆盖率 & 代码健壮性：
    • 逻辑覆盖不完善
    • 空指针
    • 低级错误：
      • 大小写
      • 数据写死
      • ...
  • 兼容性
• 数据接口服务可用性
  • 接口挂掉 / 性能差
  • 接口返回数据结构和约定不一致
• CDN静态资源服务可用性
  • Js
  • Css
  • html
  • Image
• 网络链路可用性
  • DNS劫持
  • 网络性能
  • SSL问题
• 端/容器的稳定性
  • App crash

改进措施

• 技术架构：
  • 完善页面模块隔离方案，杜绝单点故障(SPOF)
    • Action:
      • Vue体系去单点方案
      • React体系去单点方案
      • Thanos跨端体系去单点方案
        • 该体系方案需要和Native同学一起去探索
  • 考虑引入TypeScript，编译期排除因js弱类型语言的一些问题
    • Action：
      • 需要进一步探索
• 单元测试
  • 核心业务逻辑均要有单测case覆盖保证
  • Action：
    • 前台 + 中后台统一的测试框架选型：
• 自动化测试
  • 第一阶段：数据接口自动化测试方案
    • 全量 Mock 或部分 Mock 后端的数据响应，根据响应拆分出不同的数据结构 Case 分支进行页面功能覆盖测试
    • Action：
      • 技术方案调研：
  • 第二阶段：UI自动化测试方案：
    • 实现通过Page UI Diff的方式进行UI自动化测试
    • Action：
      • 先等第一阶段完善，再做研究投入
• 监控报警
  • 错误监控：
    • warning、error、空数据 等监控上报
    • 覆盖同步错误 & 尽可能多的覆盖异步错误
  • 性能监控
    • 性能相关数据上报
  • 监控大盘dashboard:
    • 友好的可视化错误信息检索、查看
    • 性能情况查看
  • Action：
    • 监控SDK：
    • 监控后台：
    • 数据可视化：
• 流程、规范
  • [代码书写规范]：
    • 脚手架fde lint 规范显性化 背景：目前 fde lint 规则不可见，fde项目开发时没有规范参考，需要推动 fde lint显性
    • Action:
      • 推动显性化
  • [最佳实践]：
    • Thanos：
      • Action：
    • React
      • Action:
    • VSCode to do 处理插件 背景：特殊情况下，代码中含有测试代码时，人工CR没有注意到，需要统一的插件处理 TODO
      • Action:
    • editor config 统一 背景：团队内部编辑器代码格式化、提示配置各自不同，相互接手项目或合作项目时，符合规范，但风格不统一
      • Action:
    • .eslintrc 文件
    • 核心业务逻辑必须写注释
    • 无用代码删除 ，不要注释
    • console.log — 全部删除
    • 通用库 版本统一 各项目之间 同样功能的通用库需要统一，如 moment.js day.js 之间的选择等
      • Action:
  • [代码健壮性]
    • 考虑代码逻辑对于数据的覆盖率
    • 多层级取值必须使用 _.get
    • 对于可能存在的异常点必须使用 try catch 包裹
    • Vue 未挂载到根组件的请求方法报错， 无法被 Vue.config.errorHandler 方法捕获？？（通用请求库）
    • 数值计算必须使用浮点数计算 —— 这里必须统一计算库
    • 和后端约定大数相关使用字符串（JS上限 2^53）
    • 代码中对于统一变量的大小写书写问题，使用 工具检查(待调研)
    • 开发过程中需要写死变量时必须有环境标识 (process.NODE.ENV )
  • 充分自测保证
  • 牵扯到代码级别的测试方案：
    • 需要团队层面过测试方案
  • 发布规范：
    • 核心逻辑功能发布灰度间隔30分钟
• Review机制：
  • "结对编程"：
    • 自己先进行diff，进行review操作
    • 和partner提前沟通需求背景
    • 和partner讲解改动代码逻辑
    • partner进行代码review
  • 对于核心链路逻辑：周会增加集体review环节
• 兜底、降级
  • 功能降级：
    • 出错模块：
      • 非核心模块：隐藏显示
      • 核心模块：显示兜底数据 / 空数据UI交互，同时友好异常提示
  • 数据兜底：
    • 网络情况不好，接口慢/超时
      • 显示兜底数据，同时友好异常提示
• 持续集成
  • 结合TC、lint校验等，通过持续集成保证整体代码覆盖率、可维护性
  • Action:
    • 调研方案

sdk自动上报策略

• js错误自动上报： h5下监听window.onError事件获得全局js报错事件，通过重载addEventListener方法解决window.onError无法获取跨域js的详细报错信息问题 小程序下监听wx.onError事件，在其中注入自动上报代码
• api事件自动上报 h5下重载fetch方法，在其中注入自动上报代码 小程序下重载wx.request方法，在其中注入自动上报代码

SDK上报频率控制

为防止并发请求过多，每次上报只做事件入栈，当事件栈长度超过一定数量，或上报间隔超过一定时间，或页面退出才发生一次实际上报，每次上报一批数据

采样率控制

采样率控制主要针对接口成功事件，接口成功事件上报主要用于统计RT，因数量巨大所以要做采样率控制，经讨论决定在服务端入库之前进行采样率筛选。

一期统计维度

• 页面js报错数量
• 接口成功率
• 接口平均耗时