2. 告警体系基础：告警的定义、告警级别（P0-P4）、告警生命周期、告警与监控的关系
2.1 告警的定义与本质
告警（Alert）是监控系统在检测到服务或基础设施的某项指标超出预设阈值、或发生特定事件时，主动向运维/研发人员发送的通知。告警的本质是“信息降噪后的决策信号”——它从海量监控数据中筛选出需要人为介入的异常状态。
核心公式： 告警 = 监控数据 + 阈值规则 + 通知策略
一个有效的告警必须具备三个要素：
- 可观测性：告警内容必须包含足够上下文（实例、时间、指标值、阈值），便于快速定位。
- 可操作性：收到告警后，接收者应能执行明确的响应动作（如重启、扩容、回滚）。
- 可闭环性：告警必须有明确的恢复条件或人工确认机制，避免“僵尸告警”。
2.2 告警级别（P0-P4）
告警级别定义了异常的严重程度和响应时效。业界通用分级标准如下：
| 级别 | 名称 | 影响范围 | 响应时间 | 典型场景 |
|---|---|---|---|---|
| P0 | 紧急（Critical） | 核心业务完全不可用，或用户数据丢失 | 立即响应（≤5分钟） | 支付链路中断、数据库主库宕机、全站502 |
| P1 | 严重（Major） | 核心功能严重受损，影响大量用户 | ≤15分钟 | 下单接口超时率>50%、缓存集群大面积故障 |
| P2 | 一般（Warning） | 非核心功能异常，或核心功能部分受损 | ≤1小时 | 非关键页面加载慢、单机房部分机器CPU满载 |
| P3 | 提示（Info） | 不影响用户，但需关注潜在风险 | ≤24小时 | 磁盘使用率超过70%、证书即将过期 |
| P4 | 记录（Debug） | 无业务影响，仅用于趋势分析 | 不强制响应 | 日志中出现特定错误码、定时任务执行时长波动 |
调优建议： 在压力测试复盘阶段，应重点审查 P0/P1 告警的误报率和漏报率。若压测期间 P0 告警频繁触发但实际业务未受损，说明阈值过于敏感，需上调阈值或增加持续时间条件。
2.3 告警生命周期
一个告警从产生到关闭，经历完整的生命周期状态机。理解各状态有助于设计自动化处理流程：
各状态说明：
- 触发：监控指标首次突破阈值，系统生成告警记录。
- 告警中：告警持续处于未恢复状态，可能伴随重复通知（如每5分钟重报一次）。
- 已确认：运维人员手动确认收到告警，系统暂停重复通知，但异常仍未解决。
- 已恢复：指标回到正常范围，系统自动标记恢复。
- 已关闭：告警生命周期结束。可通过自动恢复、手动关闭或超时关闭三种方式进入此状态。
2.4 告警与监控的关系
监控是告警的“上游数据源”，告警是监控的“输出动作”。两者在架构上存在明确的层次关系：
两者在工程实践中的关键区别：
| 维度 | 监控 | 告警 |
|---|---|---|
| 目标 | 持续记录系统状态，提供可视化与历史数据 | 在异常发生时主动通知，驱动人为干预 |
| 数据量 | 海量（每秒百万级指标点） | 极少（每天几十到几百条有效告警） |
| 存储周期 | 原始数据保留数天至数月 | 告警记录保留数月至数年（审计需求） |
| 消费方式 | 仪表盘、报表、API查询 | 电话、短信、IM推送、工单系统 |
| 调优重点 | 采集精度、存储成本、查询性能 | 阈值准确性、降噪策略、响应时效 |
常见误区： 很多团队将“监控”与“告警”混为一谈，导致监控面板上堆满告警规则，或告警系统直接输出原始监控数据。正确的做法是：监控负责“看清”，告警负责“叫醒”。在压力测试复盘时，应分别评估监控数据的完整性和告警规则的合理性，两者不可互相替代。