Alertmanager 通过告警标签实现按来源分发，需在 Prometheus 告警规则中主动定义 env、service 等标签，并在 Alertmanager route 树中用 match/match_re 匹配，结合 receiver 和 group_by 实现多级路由与渠道对接。
Prometheus 本身不直接分发告警，真正做路由决策的是 Alertmanager。所谓“根据来源分发”，本质是利用告警携带的标签（labels），在 Alertmanager 的 route 配置中做匹配和分流。
识别并打上“来源”标签
来源不是默认字段，需要你在 Prometheus 告警规则里主动定义。常见做法是按监控对象、环境或业务线打标：
-
按环境区分：在 rule 中加
labels: {env: "prod"}或{env: "dev"} -
按服务归属区分：例如
labels: {service: "payment-api", team: "finance"} -
按基础设施层区分：如
labels: {job: "node-exporter", instance: "10.0.1.5:9100"}
这些标签会随告警一起发送到 Alertmanager，成为后续路由的唯一依据。
用 route 树实现多级匹配
Alertmanager 的 route 是树状结构，从根节点开始逐层向下匹配。关键配置项包括：
-
match：精确匹配键值对，比如env: "prod" -
match_re：正则匹配，适合批量匹配多个值，如service: "mysql|redis|postgresql" -
receiver：指定该分支最终发给谁（比如"db-pager"） -
group_by：决定哪些标签用于合并告警，避免刷屏，常用[alertname, env, service]
示例：所有生产环境数据库类告警走电话+钉钉，开发环境只发邮件：
在SEO发布前，从路由清单生成XML网站地图和robots.txt
下载
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
route:
receiver: default-email
group_by: [alertname, env]
routes:
- match:
env: prod
service: mysql|redis
receiver: db-critical
group_by: [alertname, instance]
- match:
env: dev
receiver: dev-email对接不同接收渠道
每个 receiver 名称需在 receivers 区块中真实存在，并绑定具体通知方式：
- 邮件：配置 SMTP 和收件人地址
- 钉钉/企微/飞书：通过 Webhook 接入，填入机器人地址
- 电话/短信：需集成第三方网关（如阿里云语音、Twilio），通常也走 Webhook 封装
- Slack/PagerDuty：官方支持，直接填 token 和 channel
注意：Alertmanager 原生不支持钉钉，但 Webhook 方式完全可替代，且更灵活。
验证与调试技巧
路由是否生效，不能只看配置语法是否正确，要实测：
- 在 Alertmanager UI 的 Status → Routing tree 页面查看当前生效的路由结构
- 触发一条带明确标签的测试告警（如手动 curl 向 Alertmanager /api/v2/alerts 发送 JSON）
- 检查日志：
journalctl -u alertmanager -f | grep "matched route"看匹配路径 - 确认目标接收器是否收到 —— 如果没收到，先查 receiver 名称拼写是否一致，再查网络连通性
不复杂但容易忽略。
