本系列围绕Web端实时异常分析监控系统展开。上一篇讲解了页面性能、API接口指标聚合统计，以及可视化大盘的整体设计。本篇为系列第六篇，聚焦告警模块。监控系统如果告警设计不合理，很容易产生告警风暴，开发人员对消息麻木，真正严重故障被淹没。本文讲解三级告警等级定义、各类异常告警基线配置、责任人关联匹配、企业微信/短信多渠道推送，同时重点介绍告警降噪、抑制重复告警的实现思路。后续收官篇将讲解异常闭环流程、工程取舍以及和主流开源产品横向对比。
1. 前言
很多自研或者商用监控系统，最大的痛点不是采集不到数据，而是告警策略失控。线上稍微出现一点波动，就疯狂推送大量消息。
JS少量报错、个别用户接口超时就触发告警，企业微信消息连续刷屏，短信不断推送。久而久之，开发人员会对告警消息产生疲劳，甚至直接屏蔽监控通知。等到真正发生重大线上故障的时候，反而没有人关注告警，监控系统也就失去了本身的价值。
告警不等于只要出现异常就通知人。告警模块要解决几个核心问题：
第一，区分故障严重程度，严重故障需要快速触达，轻微问题仅做记录不需要高频打扰；
第二，告警基线不能写死硬编码，不同业务、不同页面、不同接口容忍度不一样，支持自定义配置阈值；
第三，把告警消息精准推送给对应负责人，而不是群发全员；
第四，做好告警降噪，抑制短时间内重复告警，避免告警风暴；
第五，告警附带足够的上下文信息，让开发点开消息就可以快速定位问题，不需要再去系统里面到处找线索。
本篇主要讲解告警体系整体设计思路，只介绍业务规则与架构方案，不输出短信、企业微信接口完整调用代码，做技术保留，适合工程学习参考。
2. 三级告警等级定义与SLA约束
本系统将告警划分为红色、橙色、黄色三个等级。不同等级对应不同通知渠道、响应时间、故障恢复SLA。并且全部等级、SLA指标都支持配置化，不需要修改代码。
2.1 红色告警（严重故障）
代表线上发生影响大量用户的重大故障。
- 通知渠道：短信 + 企业微信同时推送；
- 建议响应时间：0.5小时以内；
- 建议故障恢复时间：3小时以内；
- 触发示例：JS错误率超过20%；核心接口大面积报错；核心页面加载耗时严重超时。
2.2 橙色告警（重点关注）
属于较严重问题，影响部分用户，需要开发重点跟进处理，但不需要电话级别的紧急响应。
- 通知渠道：企业微信推送；
- 建议响应时间：3小时以内；
- 建议故障恢复时间：6小时以内；
- 触发示例：JS错误率大于10%小于20%；部分非核心接口成功率大幅下降；大量用户出现页面慢加载。
2.3 黄色告警（一般关注）
轻微异常，影响范围小，不会造成大规模业务受损，不需要紧急处理，在工作时段迭代修复即可。
- 通知渠道：企业微信推送；
- 建议响应时间：4小时以内；
- 建议故障恢复时间：8小时以内；
- 触发示例：JS错误率大于5%小于10%；少量用户出现性能不达标；个别浏览器版本偶现报错。
重要说明：以上响应时间、恢复时间仅为系统内置参考模板。实际落地中，运维人员可以在后台修改每个等级对应的通知方式、响应SLA，适配不同团队的运维规范。
3. 各类异常告警基线规则设计
告警基线就是触发告警的阈值条件。分为JS Error异常基线、页面性能基线、API接口基线三大类。不同业务项目、页面、接口可以单独覆盖默认基线。
3.1 JavaScript Error告警基线
以JS错误率作为核心判断指标，错误率=JS错误发生次数 / PV访问量。
- 红色：JS‑Error异常/PV ＞ 20%
- 橙色：10% ＜ JS‑Error异常/PV ≤ 20%
- 黄色：5% ＜ JS‑Error异常/PV ≤ 10%
同时结合前面第四篇提到的统计逻辑：通过异常发生次数与受影响用户数做判断。如果报错和受影响用户数成正比，说明问题具备扩散性，告警等级提升；如果报错只集中在极个别用户，即便次数多，也可以降低告警等级。
3.2 页面性能告警基线
以页面整体加载耗时onload时间作为主要判断依据。
- 红色：页面加载时间 ＞ 1000ms
- 橙色：600ms ＜ 页面加载时间 ≤1000ms
- 黄色：400ms ＜ 页面加载时间 ≤600ms
注意：复杂报表、大数据页面本身渲染重，可以单独调高该页面的告警阈值，不使用全局默认基线。
3.3 API接口告警基线
接口告警分为成功率基线、接口性能耗时基线两套规则。
- 红色：接口报错数量与受影响用户数量成正比，属于大面积接口故障；
- 橙色：报错只发生在部分特定用户、特定环境下；
- 黄色：少量偶发报错，对整体业务几乎无影响。
- 红色：接口响应时间 ＞5s；
- 橙色：3s ＜ 接口响应时间 ≤5s；
- 黄色：1s ＜ 接口响应时间 ≤3s；
对于大数据查询、导出类接口，支持单独配置耗时基线，不受全局阈值约束。
4. 告警责任人关联匹配机制
告警不能一股脑发给所有开发人员，需要精准匹配责任人。系统提供两种责任人匹配模式，可以同时生效。
4.4.1 代码自动匹配（优先候选）
就是第四篇讲到的，通过Source‑Map定位源码位置，调用git‑blame拿到代码最近提交人。把提交人作为告警优先通知对象。
局限：git‑blame拿到的最后提交人，不一定就是BUG引入者，仅作为候选，不能作为唯一判定。
4.2 业务人工绑定
在后台可以预先做绑定配置：
- 页面维度：给页面路由绑定维护人；
- 接口维度：给API接口路径绑定维护开发人员；
当页面或者接口触发告警，直接通知预先绑定的负责人。
4.3 责任人兜底策略
如果自动匹配失败，同时页面、接口也没有人工绑定责任人，则推送给项目组默认接收人，保证告警消息不会丢失，不会出现告警产生但是无人收到通知的情况。
同时系统支持人工修改异常对应的责任人，当自动匹配错误时，运维可以手动切换负责人。
5. 多渠道消息推送与告警消息体设计
系统支持企业微信、短信两种主流通知渠道。红色告警才会启用短信，橙色、黄色仅走企业微信，避免短信成本过高。
5.1 告警消息体内容设计
一条合格的告警通知，不能只简单写一句“系统出现异常”，需要携带足够关键信息：
开发人员收到消息，点击链接可以直接跳转系统查看完整堆栈、上下文环境、统计图表，省去人工查找问题的时间。
5.2 短信渠道使用约束
短信有成本，并且有发送频率限制。因此只给红色严重故障开启短信推送。同时做短信频率限制，同一个项目短时间内不要疯狂发送多条短信，防止短信被运营商限流。
6. 告警降噪，解决告警风暴核心策略
告警风暴是监控系统最大的坑点，需要一套降噪、抑制重复告警的策略。
6.1 告警合并聚合
短时间内同一种异常大量触发，不每产生一次就发送一次告警。在时间窗口内，把同一类异常做聚合，汇总统计次数、影响用户之后再发送一条告警，而不是多条消息刷屏。
6.2 告警冷却抑制
某一类异常已经推送告警之后，进入冷却窗口期。窗口期内，同一异常不再重复推送消息。哪怕指标持续触发阈值，也不再反复通知，避免消息轰炸。冷却时间支持后台配置。
举例：某JS错误触发橙色告警推送之后，接下来30分钟，该异常即便持续报错，也不会继续重复发企业微信，等到冷却结束，再次判断指标，如果还在异常才会二次告警。
6.3 告警屏蔽能力
后台支持临时屏蔽指定异常、指定页面、指定接口告警。例如版本发布期间，已知问题正在修复，可以临时屏蔽告警，避免干扰开发。问题修复完成再解除屏蔽。
6.4 恢复通知
当异常指标回落，恢复到正常基线以内，系统可以发送告警恢复通知，告知开发该故障已经自动恢复，形成消息闭环。
7. 告警模块现实局限
8. 本篇小结与系列后续内容预告
本篇讲解三级告警等级SLA模板，JS错误、页面性能、API接口各类告警基线，两种责任人匹配机制，企业微信+短信多渠道消息推送，重点介绍告警降噪、抑制重复告警的方案，解决监控告警风暴痛点。
告警消息推送出去，不等于整个问题处理完毕。下一篇是系列收官文章，讲解完整异常处理闭环任务管理，整套系统工程落地权衡，同时和Sentry等主流开源产品做横向对比总结。
- 第七篇【系列收官】：Web实时异常监控系统：异常闭环流程、工程取舍，与Sentry方案横向对比总结。
本文为系列第六篇，讲解分级告警、多渠道推送以及告警降噪策略。下一篇为本系列收官篇。
版权声明：本文为技术思路探讨，相关方案仅做学习交流，请勿直接复制用于生产环境。
