Prometheus+Alertmanager告警渠道配置

Prometheus 负责采集指标和触发告警规则，Alertmanager 负责接收告警并发送到指定渠道。
很多新手配完 Prometheus 规则后发现收不到通知，问题大多出在 Alertmanager 的路由和接收器配置上。
本文从零开始，带你完成邮件和企业微信两种最常用告警渠道的配置，并给出验证和排错方法。

先理清告警链路和前置条件

Prometheus 的告警流程分三步：
Prometheus 按 alert.rules 评估规则，
触发后推送到 Alertmanager，
Alertmanager 再根据 route 匹配到对应的 receiver 并发送。只要中间任一环节配置错误，
通知就不会到达。

开始前请确认：

• Prometheus 和 Alertmanager 已安装并能正常启动，默认端口分别是 9090 和 9093。
• 服务器能访问外网，邮件和企微接口都需要出网。
• 有一个可用的邮箱账号，并已获取授权码（不是登录密码）。
• 企业微信已创建群机器人，拿到 Webhook 地址。

如果你还没有 Alertmanager，可以用 Docker 快速启动一个用于测试：

docker run -d --name alertmanager -p 9093:9093 \
  -v /opt/alertmanager:/etc/alertmanager \
  prom/alertmanager:latest

配置邮件告警渠道

邮件渠道依赖 SMTP，推荐使用邮箱的授权码而不是账户密码。
以下以常见邮箱为例，编辑 /opt/alertmanager/alertmanager.yml：

global:
  smtp_smarthost: 'smtp.example.com:465'
  smtp_from: 'alert@example.com'
  smtp_auth_username: 'alert@example.com'
  smtp_auth_password: '你的授权码'
  smtp_require_tls: false

route:
  receiver: 'email-notify'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h

receivers:
  - name: 'email-notify'
    email_configs:
      - to: 'ops@example.com'
        send_resolved: true

几个容易忽略的点：

• smtp_smarthost 端口要和加密方式匹配，465 通常配 smtp_require_tls: false，587 则建议开启 TLS。
• send_resolved: true 表示告警恢复时也发通知，生产环境建议开启。
• repeat_interval 控制重复提醒频率，设太短会被邮件服务商限流。

改完后重载配置：

curl -X POST http://localhost:9093/-/reload

接入企业微信机器人

企业微信机器人本质是一个 Webhook，Alertmanager 需要通过 webhook_configs 发送。
先在企业微信群中添加机器人，复制 Webhook 地址，然后追加 receiver：

receivers:
  - name: 'wechat-notify'
    webhook_configs:
      - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=你的key'
        send_resolved: true

注意企业微信机器人接收的是固定 JSON 格式，
直接发送 Alertmanager 默认格式可能不显示内容。如果消息为空，
需要部署一个转换服务，
把 Alertmanager 的 payload 转成企微要求的 msgtype:
text 结构。 常见做法是用开源的 prometheus-webhook-dingtalk 或自写一个轻量转发脚本。

然后在 route 中把 receiver 指向 wechat-notify，或者用 routes 按告警级别分流：

route:
  receiver: 'email-notify'
  routes:
    - match:
        severity: critical
      receiver: 'wechat-notify'

验证告警是否真的发出

配置完成后不要等真实故障，手动触发一条测试告警更高效。
方法是在 Prometheus 所在服务器执行：

curl -H "Content-Type: application/json" -d '[{"labels":{"alertname":"TestAlert","severity":"critical"},"annotations":{"summary":"测试告警"}}]' \
  http://localhost:9093/api/v1/alerts

打开 http://服务器IP:9093，在 Alerts 页面应能看到这条告警，状态为 active。
如果邮件或企微收到消息，说明链路正常。

另外检查 Prometheus 的 prometheus.yml 中是否正确指向 Alertmanager：

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['localhost:9093']

常见故障与避坑提醒

收不到邮件：
先看 Alertmanager 日志 docker logs alertmanager，
常见原因是授权码错误、
SMTP 端口被防火墙拦截、smtp_from 与认证账号不一致。

企微消息为空或格式错误：确认是否使用了转换服务，直接发原始 payload 通常不可用。

告警重复轰炸：检查 group_wait、group_interval、repeat_interval 三个参数，合理设置分组和抑制规则。

改了配置不生效：Alertmanager 不会自动加载，必须执行 /-/reload 或重启容器。
如果启动时报 YAML 语法错误，用 amtool check-config alertmanager.yml 先校验。

告警渠道配好后，建议先用测试告警跑通全流程，再逐步接入真实规则。
这样出问题时能快速判断是规则问题还是渠道问题。
如果你还在搭建监控体系，可以继续了解 Prometheus 告警规则编写和分组抑制的进阶用法。