如何做好前端稳定性监控？

 

1.监控的核心能力是什么？

报警的有效覆盖率、线上问题的发现能力以及如何快速定位问题。

2.安全生产的整体目标是什么？

1-5-10，1 分钟发现问题、5 分钟定位问题、10 分钟修复问题。

3.为什么多数故障不能被发现？

业务未接入监控：安全意识缺乏、基础设施并不完备

核心指标未订阅：多数页面引入了监控，但是没有订阅报警，或者指标订阅不全。

监控指标不完整：只关注了页面运行时的异常，没有关注 CDN 节点异常、页面加载白屏、页面执行 Crash 等问题。

4.为什么快速恢复很难？

一个完整的开发流程包含 ：开发  -> 发布 -> 线上验证回归流程

如下图所示：

 

 

按这个流程很难做到 10 分钟恢复，怎么办呢？

聚焦到页面发布之前的开发阶段和发布阶段：

发布之前：完整的自动化测试流程，例如在发布之前对资源异常、JSError 等做检测拦截。

发布过程：页面发布过程具有可灰度、可监控、可回滚的完整过程。

5.整体方案是什么？

5.1 提升监控覆盖率

1. 提升接入覆盖率

完善基础设施：在搭建层做默认统一接入，在源码层统一采集规范和数据规范。

业务治理推动：通过统计团队维度的覆盖分布和指标情况，度量页面安全分（度量&红黑榜），引导和推动其快速接入。

2. 提升订阅覆盖率：

订阅指标补齐：通过治理流程，统计页面未订阅关系分布，走一键订阅指标补齐。

完善发布流程：页面发布后，订阅发布消息，对核心指标做增量订阅。

3. 提升指标覆盖率：从安全视角来看，整个链路（从容器启动 -> air渲染 -> 页面加载执行）的稳定性都需要做到可监控。

容器层：比如 webview 容器等，加载运行过程可以检测页面加载是否白屏 和 crash。

源站层：在 CDN 就出现异常，从前端的视角是无法感知的。

页面层，依赖本身 SDK 的能力，全局捕捉过程异常点作为监控指标点。

全链路保障过程，在数据链路层对数据指标过程做了统一接入，通过页面地址对齐指标：

 

 

5.2 灰度监控区分新版问题

快速恢复的核心是需要更快发现问题，更快的对变更进行回滚。数据表明，80% 的线上问题是由变更导致的，而这些故障都有监控，只是新版本的问题在错误量上不明显，又没有专门的区分，导致被忽略。

所以对于变更的过程的监控【灰度监控】需要标识异常日志，判断是否是新版本带来的。

解决方案如下：

 

指标采集：采集脚本通过读取模板全局变量获取，容器层通过 response header 拿到灰度标识。

监控指标：采集脚本和容器层需要统一和标准化灰度字段规范，在日志上报过程中携带，小程序通过版本号区分。

灰度应用：主要表现在指标灰度实时日志呈现和报警。