📚 课程目录第3章告警产生机制

第3章告警产生机制：规则触发、阈值报警与异常检测

告警是怎么产生的？说白了就三条路：规则触发、阈值报警、异常检测。

我见过不少团队，上来就搞复杂算法，结果基础规则都没写好。你想想看，连明确的错误都没抓到，谈何异常检测？所以这一章，我们把三种机制掰开揉碎了讲清楚。

规则触发，就是"如果日志里出现某段文字，就报警"。听起来简单吧？但坑比想象的多。

最常见的做法是关键词匹配。比如日志里有 FATAL、OOM、NullPointerException 这些明显的错误关键字，直接触发告警。我个人习惯把这些关键词维护成一个列表，按业务模块分类，方便后期扩展。

小技巧：关键词列表建议用配置文件管理，不要硬编码在代码里。这样每次新增规则不用重新部署。

再进阶一点，用正则表达式。比如匹配 "连接超时" 类错误：

ERROR.*(timeout|连接超时|Connection refused)
\[\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\] FATAL .+

我在项目中遇到过一件事：有个服务偶尔报 SocketTimeoutException，但并不是每次都需要告警——它发生在重试逻辑里，是正常现象。结果我们没加排除规则，半夜告警炸了好几次。后来加了白名单过滤，世界清净了。

避坑指南：我曾经因为规则写得不够严谨，把"正在重启服务"的INFO日志误判为ERROR告警。从此我定了一条铁律——规则上线前，先用历史日志跑一遍回测，确认没有误报再部署。

阈值报警，就是当某个指标超过预设的"红线"时触发告警。比如 CPU > 90%、平均响应时间 > 5s、错误率 > 1%。

这里有个很实际的问题：阈值设多少才合理？

设得太低，告警轰炸你。我记得有个项目上线第一天，把 CPU 阈值设在 50%，结果业务高峰时告警几千条。设得太高呢？又可能漏掉真正的风险。

类型	优点	缺点	适用场景
固定阈值	简单、直观、易配置	无法适应业务波动，容易误报或漏报	系统水位、硬件指标、基础监控
动态阈值	能自适应，减少误报	实现复杂，需要历史数据	流量波动大、有周期性规律的业务

动态阈值怎么做的？说白了就是用历史数据算出一个"合理区间"。比如取过去7天的数据，用 均值 ± 3倍标准差 作为动态边界。一旦指标跌出这个区间就报警。

  我的经验：阈值报警最关键的不是"用什么算法"，而是先收集足够多的正常数据。我在一个电商项目里，先用了两周的业务数据做基线，才把动态阈值调稳。否则，算法再好，没有数据也是白搭。

避坑指南：我曾经在阈值规则里忘了考虑"凌晨业务低谷"的情况——固定阈值导致每天凌晨都被"指标过低"告警轰炸。后来加了时间段分段阈值，才解决问题。

规则触发和阈值报警，都需要你"提前知道"问题长什么样。那如果遇到没见过的情况呢？这就是异常检测的用武之地了。

常见的方法有两类：

举个例子，用 3-sigma 检测流量突增：

均值 = 1000 QPS
标准差 = 100 QPS

当前值 = 1500 QPS
差值 = 500 > 3 * 100 → 触发告警

这个逻辑很直观对吧？但要注意：数据必须是正态分布或近似正态，否则 3-sigma 会失效。我在项目中遇到过这种情况：业务流量是双峰分布，用 3-sigma 天天报警，换了箱线法才正常。

小技巧：如果团队刚接触异常检测，建议从统计方法入手，成本低、可解释性强。等积累足够数据后，再上机器学习模型。

三种机制不是互斥的，而是互补的。我一般这么选：

实际项目中，我习惯先用规则触发兜底已知风险，再用阈值报警覆盖指标波动，最后用异常检测查漏补缺。三层叠加，告警覆盖率才能上去。

  核心观点：没有一种机制是银弹。规则触发守住底线，阈值报警控制范围，异常检测探索未知——这才是告警产生机制的正确打开方式。

嗯，这部分就讲到这里。三种机制的底层逻辑清楚了，后面聊"告警聚合"和"抑制"的时候，你才能理解为什么要那样设计。

第3章 告警产生机制：规则触发、阈值报警与异常检测