第4章告警路由与分发

4. 告警路由与分发：基于标签/分组的告警路由、告警通知渠道配置

告警收进来了，然后呢？

说实话，很多团队在告警处理上踩过最大的坑，就是「告警轰炸」。所有告警往同一个群里丢，运维同学手机震到没电，最后干脆把通知关了——这其实就失去了告警系统的意义。

我个人习惯，在搭建告警平台时，第一件事不是配通知渠道，而是先设计好路由规则。说白了，就是让正确的告警，找到正确的人，用正确的方式发出去。

4.1 基于标签的告警路由

标签（Label）是告警路由的灵魂。我在项目中遇到过，有些团队把所有告警都打上「critical」标签，结果就是所有告警都走最高优先级通道，反而淹没了真正重要的故障。

合理的做法是这样的：

来源标签：标识告警来自哪个系统（如：nginx、mysql、k8s）
严重级别标签：critical、warning、info
业务标签：标识影响哪个业务线（如：支付、用户中心）
环境标签：prod、staging、dev

嗯，这里要注意：标签的命名规范一定要统一。我曾经见过一个团队，有人用「prod」，有人用「production」，还有人用「正式环境」——结果路由规则匹配不上，告警全丢了。

  核心原则：标签是键值对，必须严格区分大小写，建议全小写+下划线格式。

4.2 基于分组的告警路由

分组是标签的进阶用法。你想想看，一个微服务架构可能有几十个实例，每个实例都发告警，那不得炸了？

分组的作用就是：把相似的告警合并成一条。

我建议这样配置分组策略：

按告警名称分组：相同类型的告警合并，显示触发次数
按实例分组：同一个服务的多个实例告警，合并展示
按时间窗口分组：5分钟内相同的告警，只发一次

举个例子，假设你的Nginx集群有10台机器同时报502错误：

# 分组前（10条告警）
[CRITICAL] nginx-01 502错误率超过阈值
[CRITICAL] nginx-02 502错误率超过阈值
[CRITICAL] nginx-03 502错误率超过阈值
...

# 分组后（1条告警）
[CRITICAL] Nginx集群502错误率异常（10/10实例受影响）

你看，这样是不是清爽多了？

4.3 告警通知渠道配置

渠道配置这块，我踩过的坑最多。每个渠道都有自己的脾气，咱们一个一个说。

4.3.1 邮件通知

邮件适合非紧急的告警，比如日常巡检报告、周报汇总。为什么？因为邮件有延迟，而且大家现在很少实时看邮件。

配置要点：

SMTP服务器建议用独立的告警邮箱，别用个人邮箱
设置发送频率限制，防止被邮件服务商封禁
邮件标题要包含关键信息，方便搜索

小技巧：邮件正文用纯文本格式，别用HTML。有些运维同学在手机上收邮件，HTML渲染容易出问题。

4.3.2 钉钉通知

钉钉机器人是我个人最常用的渠道。配置简单，而且支持Markdown格式。

配置步骤：

在钉钉群添加自定义机器人
获取Webhook地址
设置关键词过滤（防止无关消息）

我曾经犯过一个错误：把所有告警都发到同一个钉钉群。结果半夜被低频告警吵醒，一看是个info级别的磁盘使用率告警。后来我改成：

critical告警 → 发到「核心告警群」（全员@）
warning告警 → 发到「运维值班群」
info告警 → 只发邮件

4.3.3 企业微信通知

企业微信和钉钉类似，但有个优势：支持应用消息，可以精确推送到个人。

配置示例：

# 企业微信告警配置
{
  "corpid": "你的企业ID",
  "agentid": 1000002,
  "secret": "应用密钥",
  "touser": "@all",  # 或指定用户ID
  "msgtype": "markdown",
  "markdown": {
    "content": "## 告警通知\n**级别**: {{.Level}}\n**内容**: {{.Message}}"
  }
}

注意：企业微信的API调用频率有限制，每分钟最多60次。如果告警量很大，建议加一层缓冲队列。

4.3.4 短信通知

短信是最后一道防线。说实话，短信成本高、内容有限制，我只在真正紧急的情况下用：

核心服务宕机超过5分钟
数据库主从同步中断
支付链路完全不可用

短信配置要注意：

内容控制在70个汉字以内（超过会按两条计费）
必须包含「退订」字样（工信部要求）
设置每日发送上限，防止被刷

4.4 路由与分发的完整流程

说了这么多，咱们画个图把整个流程串起来：

整个流程其实就三步：

打标签：告警进来先分类
分组聚合：把相似的告警合并
路由分发：根据规则选择渠道

4.5 实战配置示例

最后，给一个我在生产环境用过的配置模板，基于Prometheus Alertmanager：

# alertmanager.yml
route:
  receiver: 'default'
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  
  routes:
  - match:
      severity: critical
    receiver: 'critical-team'
    repeat_interval: 10m
    
  - match:
      severity: warning
    receiver: 'ops-team'
    
  - match:
      severity: info
    receiver: 'email-only'

receivers:
- name: 'critical-team'
  webhook_configs:
  - url: 'https://oapi.dingtalk.com/robot/send?access_token=xxx'
    send_resolved: true
    
- name: 'ops-team'
  webhook_configs:
  - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx'
    
- name: 'email-only'
  email_configs:
  - to: 'ops@company.com'
    from: 'alert@company.com'
    smarthost: 'smtp.company.com:587'

我的建议：刚开始别搞太复杂。先配好critical和warning两级路由，跑一个月再优化。一口吃不成胖子，告警系统也是慢慢迭代出来的。

好了，告警路由和分发这块就聊到这儿。记住一句话：告警不是越多越好，而是越准越好。把正确的告警，用正确的方式，发给正确的人——这才是告警系统的终极目标。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

4. 告警路由与分发：基于标签/分组的告警路由、告警通知渠道配置

4.1 基于标签的告警路由

4.2 基于分组的告警路由

4.3 告警通知渠道配置

4.3.1 邮件通知

4.3.2 钉钉通知

4.3.3 企业微信通知

4.3.4 短信通知

4.4 路由与分发的完整流程

4.5 实战配置示例