Prometheus 负责告警规则的计算与触发，Alertmanager 负责告警通知的管理与发送，两者是互补关系而非替代关系，生产环境中通常必须配合使用。

核心区别对比表

为了更直观地理解两者差异，以下是核心功能对比：

核心配置示例

以下是实现完整告警链路所需的三个关键配置片段，请根据实际环境调整地址和参数。

1. Prometheus 告警规则 (rules.yml)

groups:
- name: node_alerts
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} down"
      description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minute."

2. Prometheus 主配置 (prometheus.yml)

global:
  scrape_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets:
          - alertmanager:9093

rule_files:
  - "rules.yml"

3. Alertmanager 配置 (alertmanager.yml)

route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

receivers:
  - name: 'default-receiver'
    email_configs:
      - to: 'admin@example.com'
        from: 'alertmanager@example.com'
        smarthost: 'smtp.example.com:587'
        auth_username: 'alertmanager@example.com'
        auth_password: 'your_password'

架构设计原理

Prometheus 的架构设计将“告警检测”与“告警通知”进行了职责分离。Prometheus Server 周期性计算告警规则，当表达式满足条件时，告警状态变为 Pending 或 Firing，但它本身不负责将这个消息发送给人类或外部系统。Alertmanager 作为一个独立组件，专门接收来自 Prometheus 的告警信息，负责去重、分组、抑制以及路由到不同的通知渠道。

这种设计的好处是解耦。监控数据的计算逻辑（PromQL）与通知策略（谁来收、什么时候收）分开管理。如果通知渠道变更（例如从邮件改为 Slack），只需修改 Alertmanager 配置，无需改动 Prometheus 的采集和规则逻辑。

验证步骤

配置完成后，请按以下顺序验证告警链路是否通畅：

1. 检查 Prometheus 界面：访问 Prometheus 的 /alerts 页面，确认规则状态是否从 inactive 变为 pending 或 firing。
2. 检查 Alertmanager 界面：访问 Alertmanager 的 Web UI（默认 9093 端口），查看 Alerts 列表，确认是否接收到了来自 Prometheus 的告警。
3. 检查通知渠道：查看邮箱、即时通讯工具或 Webhook 接收端，确认是否收到具体的告警消息。
4. API 验证：若 UI 无法访问，可通过 curl 检查 API 状态：

   curl http://localhost:9093/api/v1/alerts

5. 查看日志：如果未收到通知，检查 Alertmanager 容器或进程日志，查找是否有发送失败或配置错误的报错信息。

常见坑

1. 网络不通：Prometheus 容器无法解析或访问 Alertmanager 的域名或 IP，导致告警发送失败。建议在容器内使用 ping 或 telnet 测试连通性。
2. 时间同步：Prometheus 和 Alertmanager 所在服务器时间不一致，可能导致静默（Silence）或抑制（Inhibition）规则失效。请确保所有节点配置 NTP 同步。
3. For 持续时间：Prometheus 规则中的 for 参数设置过短，导致瞬时抖动产生大量告警；设置过长则可能导致故障发现延迟。生产环境建议至少设置 1m 以上。
4. 配置未重载：修改配置文件后，未发送 SIGHUP 信号或未重启服务，导致新配置未生效。Prometheus 支持热重载，Alertmanager 部分配置修改需重启。
5. 标签不匹配：Alertmanager 的路由匹配依赖标签，若 Prometheus 发出的告警缺少关键标签，可能导致告警落入默认路由或被丢弃。

参考文档

• Prometheus Alerting Overview
• Alertmanager Official GitHub
• Prometheus Alerting Rules Configuration