3. 告警源与分类：基础设施告警、应用告警、安全告警、业务告警
告警分类这件事，说白了就是给不同来源的异常信号贴上标签。我刚开始做运维那会儿，告警都是混在一起的——一个端口 down 了跟一个订单失败走同一个通道，结果就是值班的人根本分不清优先级。后来我慢慢意识到，分类不是做给监控系统看的，是做给人看的。
这一章我们就把告警源拆开来看。我个人习惯把告警分成四大类：基础设施、应用、安全、业务。每一类的特征、典型场景、处理方式都不一样。你想想看，如果连告警从哪来、属于什么类型都搞不清楚，后面的分级和响应机制就是空中楼阁。
3.1 基础设施告警
基础设施告警是最「硬」的一类。它直接告诉你：你的服务器、网络、存储、机房环境出问题了。这类告警的特点是物理性和确定性——CPU 高了就是高了，磁盘满了就是满了，没有模糊地带。
我在项目中遇到过最典型的一次：凌晨三点，一堆宿主机磁盘 IO 延迟告警涌进来。值班同事以为是偶发，直接忽略了。结果半小时后，整个数据库集群开始雪崩。后来查原因，就是一块 SSD 盘在慢慢坏掉。嗯，这里要注意：基础设施告警往往有「温水煮青蛙」的特性，初期指标只是轻微偏离，但如果不处理，会引发连锁反应。
常见的基础设施告警源
| 告警源 | 典型指标 | 常见触发条件 |
|---|---|---|
| 服务器 | CPU、内存、磁盘、负载 | CPU > 90% 持续 5 分钟；磁盘使用率 > 85% |
| 网络 | 带宽、丢包率、延迟、连接数 | 丢包率 > 1%；核心交换机端口 down |
| 存储 | IOPS、吞吐量、延迟、容量 | 磁盘 IO 延迟 > 100ms；存储池剩余 < 10% |
| 机房环境 | 温度、湿度、电力、UPS | 机柜温度 > 35°C；UPS 切换到电池供电 |
3.2 应用告警
应用告警比基础设施告警复杂得多。它不直接告诉你「哪里坏了」，而是告诉你「某个功能不正常了」。这类告警的根因往往需要结合代码逻辑、依赖关系、数据状态来排查。
说白了，应用告警是业务逻辑层面的异常信号。比如接口返回 500、请求超时、消息队列堆积、数据库连接池耗尽。这些告警的背后，可能是代码 bug、配置错误、依赖服务故障，甚至是基础设施问题传导上来的。
我记得有一次，一个支付接口频繁报超时告警。应用团队查了半天代码，没发现问题。最后发现是底层 Redis 集群在做主从切换，导致缓存访问偶尔卡顿。这就是典型的告警传导——基础设施的问题，最终以应用告警的形式暴露出来。
应用告警的常见分类
- 接口/API 告警：HTTP 状态码异常、响应时间超标、错误率上升
- 中间件告警：消息队列堆积、数据库连接池耗尽、缓存命中率下降
- 进程/服务告警：进程挂掉、服务不可用、健康检查失败
- 日志告警：ERROR 级别日志激增、特定异常关键字出现
3.3 安全告警
安全告警是四类告警里最「紧急」的。因为它往往意味着正在发生的攻击或入侵。这类告警的处理窗口非常短——晚处理一分钟，损失可能就扩大一分。
安全告警的来源很广：WAF、IDS/IPS、主机安全 Agent、漏洞扫描器、审计日志。常见的告警类型包括暴力破解、SQL 注入、WebShell 上传、异常登录、数据外传等。
我经历过一次比较惊险的：某天晚上，安全告警系统突然报出「疑似数据外传」的告警——一个内部服务在凌晨向一个境外 IP 发送大量数据。我们立刻切断了该服务的网络，然后开始排查。最后发现是某个开发同学在测试环境配了一个定时任务，不小心把数据同步到了公网。虽然是误报，但那次之后，我们给所有安全告警都加了自动封禁的响应动作。
安全告警的典型特征
| 特征 | 说明 | 示例 |
|---|---|---|
| 突发性 | 短时间内大量出现 | 1 分钟内 1000 次登录失败 |
| 关联性 | 多个告警指向同一攻击链 | 扫描告警 → 注入告警 → 数据外传告警 |
| 时效性 | 处理窗口极短 | 勒索软件加密文件只需几分钟 |
| 误报率高 | 安全规则容易产生误报 | 正常业务行为被判定为攻击 |
3.4 业务告警
业务告警是离用户最近的一类告警。它不关心 CPU 高不高、接口慢不慢，它只关心一件事：用户能不能正常用我们的产品。
这类告警的指标通常来自业务系统本身：订单量、支付成功率、注册转化率、核心页面 PV/UV。业务告警的触发条件往往是「指标偏离预期」——比如订单量突然下降 50%，或者支付成功率从 99% 掉到 80%。
我个人觉得，业务告警是运维团队最容易忽视的一类。很多团队把精力都放在基础设施和应用层面，觉得「服务器没挂就是正常的」。但你想，服务器好好的，接口也正常，可用户就是下不了单——这才是最要命的。
业务告警的典型场景
- 交易类：订单创建失败率上升、支付超时、退款异常
- 用户类：登录失败率上升、注册流程中断、用户反馈激增
- 内容类：核心页面加载失败、推荐接口无数据、搜索无结果
- 运营类：活动页面流量异常、优惠券发放失败、数据报表延迟
3.5 四类告警的关系与联动
这四类告警不是孤立的。它们之间有一条清晰的传导链：
基础设施问题 → 应用性能下降 → 安全风险增加 → 业务指标异常
举个例子：一台数据库服务器的磁盘 IO 延迟升高（基础设施告警），导致应用层查询变慢（应用告警），攻击者利用这个窗口发起慢速攻击（安全告警），最终用户下单超时（业务告警）。
所以，告警分类不是终点，而是起点。分类的目的是让我们能快速定位根因，而不是被表象牵着走。
3.6 分类落地：标签体系
理论说完了，咱们聊聊怎么落地。我建议在告警系统中建立一套标签体系，每条告警至少打上三个标签：
- 来源标签：infra / app / security / business
- 严重程度标签：critical / warning / info
- 对象标签：具体的主机名、服务名、接口名
有了这套标签，后续的告警分级、路由、自动处置就都有了依据。举个例子：一条打了 security + critical 标签的告警，可以直接触发自动封禁 + 电话通知安全负责人。而一条 infra + info 的告警，可能只需要记录到日志里，第二天再看。