4、告警路由与通知：告警路由策略、通知渠道配置（邮件、钉钉、短信）、升级策略

告警路由与通知，说白了就是解决两个问题：告警该发给谁？怎么发？

我刚开始做运维那会儿，告警都是全量发。凌晨三点，开发、测试、运维、甚至产品经理，所有人手机一起响。结果呢？没人看，没人处理。因为大家都觉得「反正别人会处理」。这就是典型的告警疲劳。

所以，告警路由的核心思想就一句话：让正确的人，在正确的时间，收到正确的告警。

告警路由策略：谁该知道这件事？

告警路由不是简单的「按级别分一分」，它需要结合业务、团队、时间、甚至当前值班情况来动态决策。

我个人习惯把路由策略分为三层：

1. 基于标签的路由：告警自带标签，比如 service=nginx、env=prod、severity=critical。路由引擎根据标签匹配对应的通知组。
2. 基于时间窗口的路由：白天和晚上，工作日和节假日，通知的人不一样。比如凌晨的告警，优先通知值班人员，而不是全组。
3. 基于依赖关系的路由：这个比较高级。比如数据库挂了，那所有依赖数据库的服务告警，先不急着发，等数据库恢复后再统一通知。避免告警风暴。

举个例子，我在项目中遇到过这样的情况：一个磁盘告警，运维组所有人都收到了。但实际只需要存储组的人处理。结果存储组的人以为别人会处理，其他人又不懂存储。最后磁盘写满了，业务挂了。嗯，这就是路由没做好。

通知渠道配置：邮件、钉钉、短信

不同的告警，用不同的渠道。这个道理大家都懂，但实际配置时，很多人会踩坑。

渠道	适用场景	优点	缺点
邮件	低级别告警、日报、周报	信息量大，可追溯	延迟高，容易被忽略
钉钉/企业	中级别告警、日常通知	实时性好，支持交互	容易被群消息淹没
短信	高级别告警、P0/P1事故	强制提醒，几乎不会错过	成本高，信息量有限

邮件配置：我个人习惯用 SMTP 协议，配置一个专用的告警邮箱。注意，邮件内容要结构化，标题要包含告警级别、服务名、简要描述。比如：[CRITICAL] [nginx-prod] 连接数超过阈值。这样收件人扫一眼就知道要不要点开。

钉钉配置：钉钉机器人是主流方式。配置 Webhook 地址，然后设置关键词或签名。我建议每个服务建一个独立的告警群，而不是所有告警都往一个群里丢。你想想看，一个群一天几百条告警，谁还看？

短信配置：短信成本高，所以只用于最高级别的告警。配置时要注意频率限制，比如同一个告警 30 分钟内最多发 3 条短信。我曾经遇到过短信网关被告警刷爆的情况，嗯，那天的账单很感人。

升级策略：告警没人处理怎么办？

告警发出去，没人响应，这是最可怕的。升级策略就是为了解决这个问题。

升级策略的核心逻辑是：如果告警在规定时间内未被确认或处理，就自动升级到更高层级的人或团队。

我常用的升级策略是这样的：

1. 第一级：值班人员。告警发出后，值班人员需要在 5 分钟内确认（Acknowledge）。
2. 第二级：如果 5 分钟内未确认，告警升级到值班组组长，同时发送短信。
3. 第三级：如果 10 分钟内仍未处理，告警升级到部门负责人，同时触发电话通知。
4. 第四级：如果 15 分钟内还没人管，告警升级到 CTO/VP 级别。嗯，这一步通常意味着事故已经很大了。

我曾经在一个项目中，把 P2 告警也加了升级策略。结果呢？值班人员每天被升级通知轰炸，最后直接屏蔽了告警系统。这比没有告警更可怕。

配置示例：Prometheus + Alertmanager

说这么多，不如看个实际配置。我用 Prometheus + Alertmanager 来演示一下告警路由和通知配置。

# alertmanager.yml
route:
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'critical-team'
      repeat_interval: 5m
    - match:
        severity: warning
      receiver: 'warning-team'
      repeat_interval: 30m

receivers:
  - name: 'critical-team'
    email_configs:
      - to: 'critical@company.com'
        headers:
          subject: '[CRITICAL] 请立即处理'
    webhook_configs:
      - url: 'https://oapi.dingtalk.com/robot/send?access_token=xxx'
    pagerduty_configs:
      - routing_key: 'xxx'

  - name: 'warning-team'
    email_configs:
      - to: 'warning@company.com'
        headers:
          subject: '[WARNING] 请关注'

这个配置很简单：critical 级别的告警走钉钉 + 邮件 + PagerDuty，warning 级别的只发邮件。注意 repeat_interval，critical 每 5 分钟重复一次，warning 每 30 分钟重复一次。避免告警刷屏。

总结

告警路由与通知，看似简单，但做得好不好，直接决定了你的告警系统是「救命稻草」还是「噪音制造机」。记住三个要点：

• 路由要精准：让对的人收到对的告警。
• 渠道要分层：低级别用邮件，中级别用钉钉，高级别用短信。
• 升级要克制：只有真正重要的告警才需要升级，别让所有人疲劳。

嗯，做到这三点，你的告警系统至少能打 80 分。剩下的 20 分，靠实战慢慢磨。