3. 告警接收器(Receiver)详解

告警接收器是 Alertmanager 路由树的最终执行节点。当告警经过分组、抑制、静默处理后，Receiver 负责将告警通知发送到指定的目标系统。本章深入剖析内置接收器类型与自定义接收器的配置方法。

3.1 内置接收器类型与配置

Alertmanager 原生支持多种接收器，覆盖邮件、即时通讯、事件平台等场景。下表列出最常用的内置接收器及其核心参数：

3.2 核心接收器配置实战

3.2.1 Email 接收器

Email 是最基础的告警通道，配置时需注意 SMTP 认证与 TLS 设置。以下为完整示例：

receivers:
- name: 'ops-email'
  email_configs:
  - to: 'ops@example.com'
    from: 'alertmanager@example.com'
    smarthost: 'smtp.example.com:587'
    auth_username: 'alertmanager@example.com'
    auth_password: 'smtp-password-here'
    auth_identity: 'alertmanager@example.com'
    require_tls: true
    send_resolved: true
    headers:
      subject: '【告警】{{ .GroupLabels.alertname }} - {{ .Status }}'
    html: '{{ template "email.default.html" . }}'

3.2.2 Webhook 接收器

Webhook 是最灵活的接收器，支持将告警以 JSON 格式 POST 到任意 HTTP 端点。配置示例如下：

receivers:
- name: 'custom-webhook'
  webhook_configs:
  - url: 'http://alert-bridge.internal:8080/webhook'
    send_resolved: true
    http_config:
      basic_auth:
        username: 'webhook-user'
        password: 'webhook-pass'
      tls_config:
        insecure_skip_verify: false
    max_alerts: 50

Webhook 的请求体结构包含完整的告警分组信息，字段包括 status、labels、annotations、startsAt、endsAt 等。接收端可根据这些字段实现自定义处理逻辑。

3.2.3 Slack 接收器

Slack 接收器需要预先创建 Incoming Webhook 或使用 Bot 。推荐使用 Bot 方式以获得更丰富的消息格式：

receivers:
- name: 'slack-oncall'
  slack_configs:
  - api_url: 'https://slack.com/api/chat.postMessage'
    channel: '#alerts-production'
    username: 'Alertmanager'
    icon_emoji: ':warning:'
    title: '{{ .GroupLabels.alertname }}'
    text: '{{ .CommonAnnotations.description }}'
    fields:
      - title: 'Severity'
        value: '{{ .CommonLabels.severity }}'
        short: true
      - title: 'Instance'
        value: '{{ .CommonLabels.instance }}'
        short: true
    actions:
      - type: button
        text: '查看告警详情'
        url: '{{ .ExternalURL }}'
    send_resolved: true

3.2.4 PagerDuty 接收器

PagerDuty 是 SRE 领域的事件管理标准，配置时需获取 Routing Key（集成密钥）：

receivers:
- name: 'pagerduty-critical'
  pagerduty_configs:
  - routing_key: 'your-pagerduty-routing-key'
    service_key: 'deprecated-use-routing-key'
    severity: 'critical'
    images:
      - src: 'https://monitor.example.com/grafana/dashboard.png'
        alt: '当前指标面板'
    links:
      - href: 'https://runbook.example.com/incident-response'
        text: '事件处理 Runbook'
    send_resolved: true

3.3 自定义接收器配置

当内置接收器无法满足需求时，Alertmanager 提供两种自定义扩展方式：

• Webhook 桥接模式： 通过 Webhook 将告警转发到自研中间件，由中间件完成格式转换、多平台分发、工单创建等逻辑。
• Prometheus Receiver 插件： 使用 Go 语言编写自定义 Receiver 插件，编译后集成到 Alertmanager 二进制中。

以下是一个 Webhook 桥接模式的典型架构：

3.4 接收器配置最佳实践

3.5 多接收器并行与故障转移

Alertmanager 支持在同一个 Receiver 中配置多个同类型或不同类型的接收器，实现并行通知或故障转移：

receivers:
- name: 'multi-channel-critical'
  email_configs:
  - to: 'oncall@example.com'
    smarthost: 'smtp.example.com:587'
    send_resolved: true
  webhook_configs:
  - url: 'http://alert-bridge.internal:8080/critical'
    send_resolved: true
  pagerduty_configs:
  - routing_key: 'pd-critical-key'
    severity: 'critical'

当 Receiver 包含多个配置块时，Alertmanager 会并行向所有配置发送告警。如果某个通道失败，不会影响其他通道的投递。这种设计保证了告警通知的高可用性。

3.6 接收器配置验证与调试

配置完成后，使用以下方法验证接收器是否正常工作：

• amtool 命令行工具： amtool check-config alertmanager.yml 检查配置语法
• 测试告警发送： 使用 curl 向 Alertmanager API 发送测试告警：
  curl -X POST http://alertmanager:9093/api/v1/alerts -d '[{"labels":{"alertname":"TestAlert","severity":"critical"}}]'
• 日志监控： 查看 Alertmanager 日志中的 notify 相关条目，确认投递状态
• 指标监控： 通过 /metrics 端点观察 alertmanager_notifications_total 和 alertmanager_notifications_failed_total 指标

接收器是告警管道的最后一公里，配置的准确性直接影响告警的触达率。建议在生产环境上线前，对每种接收器类型进行完整的端到端测试。