稳定性建设之监控告警

此文偏前端视角

背景（监控告警的重要性）

监控告警是稳定性建设的重要一环，原因有以下：

1. 真实用户的浏览器环境多种多样，我们需要有监控线上真实用户异常的能力。

   • 比如：js错误数过多，影响用户数过多

2. 项目从小到大，从简单到复杂，谁也不能保证永远不会出线上问题。出问题不可怕，可怕的是出了问题后，不能及时感知，进而导致损失扩大。

   • 比如：xx成功率过低，服务CPU/内存过高

3. 业务站点放在公网后，随时都可能会遭受DDOS攻击，当流量激增时，我们应当有所感知。

   • 比如：流量环比30分钟前，增大5倍

4. 有些情况，问题或许不是出在自己身上，而是在上下游某环节出问题，我们也应当有感知错误的能力，减少业务损失的风险。

   • 比如：流量掉0，接口错误率过高

我们需要哪些告警？

首先有个概念要分清楚是：分前端和后端

前端的话，主要监控以下指标：

1. js错误率
2. js错误影响用户数
3. 业务类告警，比如
   1. x分钟内，xx成功率过低、小于xx%
   2. x分钟内，pv掉0

后端的话（比如SSR项目、node bff），主要监控以下指标：

1. x分钟内，服务状态码200 掉0
2. x分钟内，服务状态码（4xx/5xx）任一错误率超过x%
3. x分钟内，环比前x分钟，状态码200 上升超过x00%，且qps>x
4. x分钟内，服务 单实例/集群 的 内存/cpu 负载超过x%
5. 服务实例进程退出/错误/中断/频繁重启
6. x分钟内，核心服务上游请求失败率超过x%
7. x分钟内且qps>x，核心服务下游失败率超过x%
8. x分钟内，下游时延大于x
9. 错误日志占比xx
10. SQL、redis等对应告警

如何配置告警

大体的流程是：

• 接入相关平台的SDK -> 打点 -> 去对应平台看打点是否生效 -> 在对应平台 配置对应的告警规则 -> 验证告警是否有效

这一环就不过多的讲了，一般公司都会有相关的基建，也会有如何配置告警的详细文档

我们需要哪些监控（看板）？

告警毕竟比较抽象，我们平时还需监控一下服务的状态，所以我们需要关注一些看板，比如：

1. QPS
2. 时延
3. 整体错误率（4xx + 5xx）
4. 各错误码的QPS
5. 异常流量（限流、waf、封禁）
6. 上游调用情况（各上游的QPS，成功率，时延）
7. 下游调用情况（各下游的QPS，成功率，时延）
8. CPU、内存使用率

通过这些看板，我们可以更好的了解我们服务的状况，可以对应设计出更合理的告警规则。当某项数据异常时，可以更快速的定位问题

如何搭看板

大体的流程是：

• 接入相关平台的SDK -> 打点 -> 去对应平台看打点是否生效 -> 在对应平台配置打点的指标，生成对应看板

这一环和告警类似，一般也依赖公司相关的基建及对应配置文档。

---

欢迎补充

码字不易，点赞鼓励！