近期建设了前端项目的监控告警，此文做思路的总结

什么时候需要做前端监控告警

当项目流量逐步增大，业务价值达到一定量级，偶发出现前端的线上故障，造成少量业务损失时，就需要考虑建设前端的监控告警，以避免后期发生严重故障造成不可接受的业务损失

监控告警的建设能够使开发者快速发现线上故障、快速解决，保障业务稳定发展

其可以认为是项目稳定性的线上策略。平时团队对技术评审、Code Review、RD 自测、QA 回归测试的要求，是线下的保障项目稳定性的手段

什么是前端监控告警

监控：上报项目运行时产生的各种信息，在发生线上故障时，开发者能够根据信息快速发现、定位、解决问题

告警：从上报的信息中，根据一定的规则，进行消息的通知，使开发者不必用肉眼观察是否发生线上故障，从而提高发现问题的效率

监控

前端主要包括应用监控（白盒）与业务监控（黑盒）

应用监控：

1. Node 服务器：CPU、磁盘、内存等运行状态，对外提供的接口响应状况
2. 客户端：静态资源成功率、运行时异常、接口请求与响应状况、依赖服务状态

黑盒监控：业务流程关键节点访问量

告警

1. 将信息进行细分：针对上报的异常信息，划分各维度：页面、异常级别、异常名称等，组合出告警指标
2. 配置告警方式：根据故障对业务的影响严重程度，划分告警级别

如何做前端监控告警

首先要有目标，没有目标则结果无法衡量

目标可以是：避免某个较低程度的业务损失发生，例如50个订单损失

接着寻找业务流程中能够达到此线上故障损失的场景，推算对应的异常数据上报数量，保证在临界值到达前，监控告警能够发现问题

监控

主要关注的监控上报内容，可以划分为：

1. 请求：静态资源、接口
2. 异常：运行时异常
3. 业务：核心流程的关键节点访问量

附带上报的信息一般有：时间、页面 URL、接口 URL、错误信息、错误类型、错误级别、User Agent、gated（灰度流量）、webVersion（版本）、userId（用户标识）

其中 gated 参数，能够使开发者在灰度流量验证阶段，拉取灰度流量上报数据，提高问题发现效率

请求

1. 重写 xhr open、send，进行请求的拦截，监听 load、error、abort、onreadystatechange 事件
2. 重写 fetch，获取请求的信息

将拦截到的信息进行上报至数据平台，一般需要配置

1. 网络成功率：反映网络状况，关注 xhr status
2. 业务成功率：反映业务状况，关注 xhr status 200 时的业务 code 码

异常

监听 error 事件，上报 非 Promise 错误
监听 unhandledrejection 事件，上报 Promise 错误

业务

梳理业务流程，找到每个流程的关键节点，比如核心业务流程的结果页面曝光，发送请求上报至数据平台

告警

两个原则

1. 宁多不少：核心流程的告警可以有冗余，但不可缺少（即便后端有告警，前端也有必要做，个人遇到过线上严重故障发生，但后端告警恰好失效的情况）
2. 核心先行：实施过程中人力、时间有限，先做核心流程，积累数据上报与告警配置经验，形成最佳实践，再逐步扩大范围

告警配置

1. 请求：静态资源成功率、核心流程接口网络成功率、核心流程接口业务成功率、Network Error、timeout、xhr 非 200、xhr 200 但业务 code 错误
2. 异常：unhandledrejection、非 unhandledrejection
3. 业务：各个核心流程的首页曝光、关键组件曝光、结果页曝光

告警规则

1. 维度：根据核心业务情况，按不同维度划分告警规则，常用的有页面、异常名称、异常级别
2. 指标：常用的指标有错误量、连续波动百分比。需要依据 有故障 及 无故障 场景的数据波动情况，配置指标阈值

告警方式

1. 级别：级别依次递减可以划分为为 P0、P1、P2。不同级别对应着故障的紧急程度、通知的速度、开发者的响应时间和处理时长、可接受的误报程度
2. 方式：通讯 App、短信、电话

以 P1 为例：核心路径有波动、通讯 App 及短信进行通知、需立即处理、要求0误报

一个 P1 的例子：JS 异常、Error 级别、页面排除XX页、错误总量原始值在最近5分钟内触发3次、使用通讯 App、短信进行通知

故障演练

针对定下的目标，书写自测 case，使用 puppeteer 进行故障演练，以测试监控告警的有效性、演练者的故障处理意识

1. 上报请求异常：拦截请求、重写请求返回值
2. 上报 JS 运行时异常：注入 JS 故障