告警设计入门：怎么定阈值、怎么分级，才不吵又不漏

告警设计入门：怎么定阈值、怎么分级，才不吵又不漏

监控上线第一周，群里被告警刷屏；一个月后，大家都学会了"已读不回"。这就是告警设计失败的典型：告警疲劳。反过来，为了不吵把阈值调得过高，故障又会在用户投诉后才被发现。好的告警设计要同时做到"不吵"（有效信息）和"不漏"（关键故障必达）。本文讲清三件事：阈值怎么定、分级怎么做、闭环怎么跑，并附一组可直接照抄的规则示例。

一、阈值怎么定：别拍脑袋

阈值定太低，天天误报；定太高，真出事也不知道。三个实用方法：

1. 基线法：先跑 1-2 周只采集不告警，观察指标的"正常波动区间"，再把阈值设在区间之外留出缓冲。比如 CPU 平时 20%-40% 波动，阈值定 80% 就合理；定 45% 就会天天响。
2. 双阈值法（预警+严重）：比如磁盘 >80% 发"预警"通知，>90% 才"严重"告警。给处理留出缓冲时间，避免一上来就最高级别。
3. 持续时间法：单次瞬时超过阈值可能是抖动，加上"持续 5 分钟"才触发。例如"CPU >90% 持续 10 分钟"比"CPU >90%"可靠得多，可过滤绝大多数瞬时毛刺。

一个原则：告警要能落在"你可以做点什么"的地方。如果收到告警后只能看着、什么都做不了，这个告警就是噪音。

二、告警分级 P1-P4：让"紧急"真的紧急

把所有告警混在一个级别，等于没有级别。通用分级如下：

关键点：P1/P2 走电话/短信等强提醒，P3/P4 走群消息/邮件等弱提醒。别让"明天再处理"的事半夜把值班人吵醒——把 P3/P4 的通知时间窗设成工作时间。

三、避免告警疲劳的五个动作

1. 告警去重：同一故障不要反复触发同一条告警。例如"错误率 >5%"每 5 分钟查一次，触发后应"静默"，等恢复再重置，而不是每小时刷 12 条。
2. 分组与路由：把告警按团队/系统分组（基础设施、支付、营销），只通知相关的人；谁负责的才发给谁。
3. 抑制与依赖：服务器挂了会连带几十条服务告警——用"父告警抑制子告警"：主机不可达时，其上的所有服务告警自动抑制。
4. 分级降噪：用 P1-P4 分级决定通知渠道和对象，见上表。
5. 定期评审：每月看一次告警统计，删掉"从未行动过"的规则，修正反复误报的阈值。

告警疲劳的完整治理与值班机制，见告警疲劳与值班实践。

四、告警→通知→响应：闭环才算数

一条告警只有走完"产生 → 通知 → 有人响应 → 处理 → 关闭 → 复盘"整个闭环才有价值。落地要点：

1. 产生：规则触发，带上足够上下文（哪台机器、哪个指标、当前值、时间）。
2. 通知：按级别走对应渠道（P1 电话/短信，P3 群消息），消息里写清"是什么、影响多大、先看哪里"。
3. 响应：有人认领（acknowledge），超时未认领自动升级（如 15 分钟没响应，通知主管）。
4. 处理：按预案操作；事件复盘模板见事件响应手册。
5. 关闭与复盘：确认恢复后关闭，事后记录"为什么会发生、告警有没有漏、阈值合不合理"。

另一个进阶概念：给告警绑定 SLO（服务等级目标），只对"会影响 SLO 的故障"告警，能显著降低噪音，详见SLO 与错误预算实践。

五、告警规则示例：可直接照抄

以 Prometheus 语法风格为例（具体字段随平台略有差异）：

- name: infra-critical
  rules:
    - alert: DiskWillFill
      expr: disk_usage_percent > 90
      for: 5m
      labels: { severity: P2 }
      annotations:
        summary: "磁盘使用率超过 90%（当前 {{ $value }}%）"
        runbook: "清理日志或扩容，步骤见 wiki/DiskRunbook"

    - alert: High5xxRate
      expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
      for: 3m
      labels: { severity: P1 }
      annotations:
        summary: "5xx 错误率超过 5%"
        runbook: "查看最近发布与错误日志"

    - alert: ApiLatencyP99High
      expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 2
      for: 5m
      labels: { severity: P2 }
      annotations:
        summary: "接口 P99 延迟超过 2 秒"

三条例子分别覆盖：容量（磁盘）、可靠性（错误率）、体验（延迟）。更完整的规则设计方法论见Prometheus 告警规则设计，搭建整套监控报警见Prometheus + Grafana 基础。

六、常见问题

Q1：没有专人值班，告警设计还要做分级吗？
要，甚至更重要。个人或小团队没有值班，分级决定"这条要不要半夜爬起来"。P3/P4 设成工作时间通知，能保住睡眠，也不会漏掉真故障。

Q2：怎么判断告警设计是否健康？
看两个数字：告警量趋势（应下降或稳定）和漏报事件数（用户先于你发现的问题）。最好的告警是"想起来的少，但每次都有用"。

Q3：误报太多，直接调高阈值行吗？
先找误报根因（是阈值问题、采集问题还是抖动），再决定。直接调高阈值会把真故障一起"调没"。建议配合持续时间法和双阈值法。

Q4：更多监控报警内容去哪看？
本站监控报警分类下有监控搭建、指标体系、SLO 等完整体系，可与本文化为一条学习路径。