告警基础概念：定义、类型与生命周期
告警是什么？说白了，就是系统在告诉你：“我出问题了，你快来看看。” 我刚开始做运维那会儿，觉得告警就是一堆红字弹窗，后来被线上事故狠狠教育过几次，才明白告警背后藏着整个系统的健康密码。
这一章我们先把地基打牢。告警的定义、分类、以及它从出生到死亡的完整生命周期——搞懂这些，后面的实战才有落脚点。
告警的定义
告警（Alert）是指监控系统检测到异常状态后，主动通知人的一种机制。它不是一个简单的日志，也不是一条消息，而是一个有明确触发条件、有预期响应动作的事件。
举个例子：服务器CPU使用率超过90%，监控平台就会产生一条告警。这条告警背后包含了：
- 触发条件：CPU > 90% 持续5分钟
- 告警内容：主机IP、指标值、时间
- 预期响应：工程师介入排查或自动化恢复
告警的类型
告警按检测方式，主要分两大类：阈值告警和异常检测告警。当然还有更细的分法，但这两类基本覆盖了90%的场景。
阈值告警
阈值告警是最传统、最直观的一种。你设一个上限或下限，指标一越界就报警。比如：
# Prometheus 阈值告警规则示例
- alert: HighCPUUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
for: 5m
labels:
severity: critical
annotations:
summary: "Instance {{ $labels.instance }} CPU usage > 90%"阈值告警的优点：简单、可靠、容易解释。缺点也很明显——静态阈值很难适应业务波峰波谷。我曾在618大促时被误报淹没过，原因是日常阈值没调，业务流量一涨就全红了。
| 类型 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 固定阈值 | 配置简单，运维成本低 | 不灵活，容易误报/漏报 | 硬件指标（内存、磁盘） |
| 动态阈值 | 基于历史数据自动调整 | 需要历史数据积累，实现复杂 | 业务流量、响应时间 |
| 多条件组合阈值 | 降低误报率 | 规则编写相对复杂 | 关键业务链路告警 |
异常检测告警
异常检测不再依赖固定阈值，而是通过算法识别“与历史模式不符”的行为。比如一个接口响应时间平时是100ms，突然变成500ms，即使没超过任何阈值，系统也能感知到异常。
我曾经踩过一个坑：用3-sigma检测QPS突降，结果促销活动结束后流量自然回落，算法连续报警了一下午。后来加了业务时段特征才消停。说白了，异常检测不是银弹，它需要结合业务上下文才能用好。
告警的生命周期
一条告警从产生到关闭，会经历若干个阶段。理解这个周期，能帮你设计清晰的告警处理流程。我习惯把它画成一个闭环：
每个阶段我都踩过坑，简单说说：
- 告警产生：不是所有异常都要进告警系统。我见过有人把info日志级别也设成告警，结果告警平台变成了日志平台。记住：产生之前先问“这个是否需要人处理”。
- 触发条件确认：尤其是阈值告警，一定要加上“持续时间”。我曾经只设了瞬时值，CPU突然飙一下又恢复，告警来了又自动恢复，反而把值班人溜了一圈。
- 通知与升级：通知要有层次。一般告警发群，严重告警打电话，关键故障还得拉会。你自己想想，半夜收到一条“磁盘使用率51%”的推送，是不是想骂人？
- 响应与处置：这里最容易出问题的是“告警疲劳”。一旦响应不及时，告警就会堆积。我建议给每条告警配一个SLA，超时自动升级。
- 恢复确认与关闭：恢复≠关闭。必须确认指标持续正常一段时间，才能标记为已恢复。关闭时最好记录根因，方便复盘。
告警的生命周期状态机
为了更规范地管理，业内通常用以下几个状态：
| 状态 | 含义 | 典型动作 |
|---|---|---|
| Firing | 告警正在触发中，尚未处理 | 触发通知、进入值班流转 |
| Acknowledged | 已认领，正在排查 | 值班人确认接收，开始定位 |
| Resolved | 指标恢复正常 | 系统检测到指标回稳后自动标记 |
| Closed | 确认问题解决，关闭记录 | 人工或自动关闭，写入历史库 |
你会发现，这个状态机跟上面流程图是对应的。嗯，这里要注意的是：Acknowledged 和 Resolved 之间可能还会出现 Re-firing，也就是问题反复。这种告警就是毒瘤，必须深挖根因，不能只做表面恢复。
我刚开始做运维时，根本不关心什么生命周期，有告警就去修，修完就完事。后来发现同样的故障反复发生，才意识到：告警不只是通知，它应该是一个闭环——从检测到修复，再到根因分析，最后反哺监控规则。 这一章的内容看似基础，但真正吃透的人才会在后面的实战里打出漂亮的组合拳。