Alertmanager 告警治理

接收告警（HTTP POST /api/v2/alerts）
        到
去重（Deduplication）—— 多个 Prometheus 副本推来的同一条告警合并成一条
        到
静默检查（Silencing）—— 命中静默规则的直接丢弃，不通知
        到
抑制检查（Inhibition）—— 被更严重告警压制的，暂时不通知
        到
路由（Routing）—— 沿着 route 树找到该由谁接收
        到
分组（Grouping）—— 同一组的告警攒在一起，合并成一条通知
        到
等待与节流（group_wait / group_interval / repeat_interval）
        到
发送（Notification）—— email / webhook / slack / pagerduty ...

# alertmanager.yml
global:
  resolve_timeout: 5m                          # 没有 EndsAt 的告警多久后视为已恢复
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alert@example.com'
  smtp_auth_username: 'alert@example.com'
  smtp_auth_password_file: '/etc/alertmanager/smtp_pass'
  smtp_require_tls: true
  slack_api_url_file: '/etc/alertmanager/slack_url'
 
templates:
  - '/etc/alertmanager/templates/*.tmpl'       # 自定义通知模板
 
route:                                          # 路由树的根节点（必须存在）
  receiver: 'default-email'
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes: []                                    # 子路由
 
inhibit_rules: []                               # 抑制规则
 
receivers:                                      # 接收器定义
  - name: 'default-email'
    email_configs:
      - to: 'ops@example.com'

./alertmanager \
  --config.file=/etc/alertmanager/alertmanager.yml \
  --storage.path=/var/lib/alertmanager \
  --web.listen-address=0.0.0.0:9093 \
  --web.external-url=https://am.example.com

# prometheus.yml
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 'am-1.internal:9093'
            - 'am-2.internal:9093'
            - 'am-3.internal:9093'

route:
  receiver: 'default'                    # 兜底：什么都没匹配上时用它
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
 
  routes:
    # 1) 监控系统自身的告警，单独一个通道
    - receiver: 'monitoring-team'
      matchers:
        - job =~ "prometheus|alertmanager"
 
    # 2) 所有 critical 级别，先抄送一份到值班电话
    - receiver: 'pagerduty'
      matchers:
        - severity = "critical"
      group_wait: 10s                    # 紧急，少等一会儿
      continue: true                     # 关键：继续往下匹配
 
    # 3) 按团队分流
    - receiver: 'team-backend'
      matchers:
        - team = "backend"
      routes:
        # 后端团队内部，数据库相关的再细分
        - receiver: 'dba-group'
          matchers:
            - component =~ "mysql|redis|postgres"
 
    - receiver: 'team-frontend'
      matchers:
        - team = "frontend"

根节点 → 检查子节点 1：job 不匹配，跳过
       → 检查子节点 2：severity=critical 匹配！
                       进入 pagerduty，且 continue: true
       → 因为 continue，继续检查子节点 3：team=backend 匹配！
                       进入 team-backend，检查它的子节点：
                       component=mysql 匹配 → 最终落在 dba-group
       → 子节点 3 没有 continue，停止
 
结果：这条告警会同时发给 pagerduty 和 dba-group 两个接收器

# 旧写法（0.22 起标记为废弃，但仍可用）
- receiver: 'team-backend'
  match:                          # 精确相等，键值对形式
    team: backend
    severity: critical
  match_re:                       # 正则匹配
    service: '^(api|worker)$'
 
# 新写法（推荐）
- receiver: 'team-backend'
  matchers:
    - team = "backend"
    - severity = "critical"
    - service =~ "api|worker"

route:
  receiver: 'default'
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  repeat_interval: 4h
  routes:
    - receiver: 'pagerduty'
      matchers: [ 'severity = "critical"' ]
      group_wait: 10s              # 只覆盖这一项
      repeat_interval: 30m         # 和这一项
      # group_by 和 group_interval 继承自根节点

group_by: ['alertname', 'cluster', 'service']

10:00:00  第一条 InstanceDown 到达 → 新组建立，开始等 group_wait
10:00:05  又来了 30 条同组告警 → 一起攒着
10:00:30  group_wait 到期 → 发出第 1 条通知，包含 31 条告警
10:01:00  又来了 19 条同组告警 → 组内容变了，但要等 group_interval
10:05:30  group_interval 到期 → 发出第 2 条通知，包含全部 50 条
10:05:30  之后组内容不再变化
14:05:30  repeat_interval 到期 → 发出第 3 条通知（提醒「还没解决」）

inhibit_rules:
  # 规则 1：机房级故障压掉实例级故障
  - source_matchers:
      - alertname = "DatacenterDown"
    target_matchers:
      - alertname = "InstanceDown"
    equal: ['cluster']
 
  # 规则 2：同一个服务上，critical 压掉 warning
  - source_matchers:
      - severity = "critical"
    target_matchers:
      - severity = "warning"
    equal: ['alertname', 'cluster', 'service']
 
  # 规则 3：实例宕机时，不用再报它上面的服务不可用
  - source_matchers:
      - alertname = "InstanceDown"
    target_matchers:
      - alertname = "ServiceUnavailable"
    equal: ['instance']

# 创建静默：支付服务静默 2 小时
amtool silence add \
  --alertmanager.url=http://localhost:9093 \
  --duration=2h \
  --author="zhangsan" \
  --comment="发布 v2.3.1，变更单 CHG-1024" \
  service=payment cluster=prod-bj
 
# 用正则匹配
amtool silence add 'alertname=~"NodeDisk.*"' --duration=6h --comment="磁盘扩容中"
 
# 查询当前生效的静默
amtool silence query
 
# 查询即将过期的
amtool silence query --within=1h
 
# 提前结束一个静默
amtool silence expire <SILENCE_ID>
 
# 批量结束所有静默（慎用）
amtool silence expire $(amtool silence query -q)

receivers:
  - name: 'ops-email'
    email_configs:
      - to: 'ops@example.com, sre@example.com'
        from: 'alert@example.com'
        smarthost: 'smtp.example.com:587'
        auth_username: 'alert@example.com'
        auth_password_file: '/etc/alertmanager/smtp_pass'
        require_tls: true
        send_resolved: true            # 默认 false！恢复时也发一封
        headers:
          Subject: '[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }} ({{ .Alerts | len }} 条)'
        html: '{{ template "email.default.html" . }}'

receivers:
  - name: 'webhook-dingtalk'
    webhook_configs:
      - url: 'http://dingtalk-webhook:8060/dingtalk/ops/send'
        send_resolved: true            # webhook 默认就是 true
        max_alerts: 0                  # 单次最多带多少条告警，0 表示不限
        http_config:
          authorization:
            credentials_file: '/etc/alertmanager/webhook_token'

{
  "version": "4",
  "groupKey": "{}:{alertname=\"HighErrorRate\", cluster=\"prod-bj\"}",
  "truncatedAlerts": 0,
  "status": "firing",
  "receiver": "webhook-dingtalk",
  "groupLabels": {
    "alertname": "HighErrorRate",
    "cluster": "prod-bj"
  },
  "commonLabels": {
    "alertname": "HighErrorRate",
    "cluster": "prod-bj",
    "severity": "critical",
    "team": "backend"
  },
  "commonAnnotations": {
    "runbook_url": "https://wiki.internal/runbooks/high-error-rate"
  },
  "externalURL": "https://am.example.com",
  "alerts": [
    {
      "status": "firing",
      "labels": {
        "alertname": "HighErrorRate",
        "cluster": "prod-bj",
        "service": "order-api",
        "severity": "critical",
        "team": "backend"
      },
      "annotations": {
        "summary": "order-api 错误率超过 5%",
        "description": "当前错误率 7.32%，已持续 5 分钟以上。"
      },
      "startsAt": "2026-08-02T10:15:30.123Z",
      "endsAt": "0001-01-01T00:00:00Z",
      "generatorURL": "https://prom.example.com/graph?g0.expr=...",
      "fingerprint": "a1b2c3d4e5f67890"
    }
  ]
}

receivers:
  - name: 'slack-critical'
    slack_configs:
      - api_url_file: '/etc/alertmanager/slack_webhook_url'
        channel: '#alerts-critical'
        send_resolved: true            # 默认 false
        title: '[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }}'
        text: >-
          {{ range .Alerts }}
          *{{ .Labels.service }}*: {{ .Annotations.summary }}
          {{ .Annotations.description }}
          {{ end }}
        actions:
          - type: button
            text: '查看 Runbook'
            url: '{{ .CommonAnnotations.runbook_url }}'

receivers:
  - name: 'pagerduty-oncall'
    pagerduty_configs:
      - routing_key_file: '/etc/alertmanager/pd_routing_key'   # Events API v2
        severity: '{{ if eq .CommonLabels.severity "critical" }}critical{{ else }}warning{{ end }}'
        description: '{{ .CommonLabels.alertname }} - {{ .CommonLabels.cluster }}'
        send_resolved: true            # 默认 true
        details:
          service: '{{ .CommonLabels.service }}'
          runbook: '{{ .CommonAnnotations.runbook_url }}'

【Prometheus 侧】
 
T+0     规则求值，expr 首次返回结果 → 状态 pending
        写入 ALERTS 序列，alertstate="pending"
        此时不会推送给 Alertmanager
 
T+for   持续满足 for 时长 → 状态 firing
        ALERTS 的 alertstate 变为 "firing"
 
T+for   POST 到所有 Alertmanager 的 /api/v2/alerts
        每条告警带 StartsAt 和一个未来的 EndsAt
 
之后    只要还在 firing，就周期性重发（至少每 resend-delay 一次，默认 1m）
        每次都把 EndsAt 往后推
 
恢复时  expr 返回空 → 状态回到 inactive
        Prometheus 会继续推送这条告警约 15 分钟，
        但把 EndsAt 设成「实际恢复时刻」，明确告知已解决
 
【Alertmanager 侧】
 
接收    按标签集的指纹（fingerprint）去重，
        多个 Prometheus 副本推来的同一条会被合并
 
静默    命中 silence 的 matcher → 记录状态，不通知
 
抑制    命中 inhibit_rules 的 target 且存在活跃 source → 不通知
 
路由    沿 route 树找到接收器（可能多个，靠 continue）
 
分组    按 group_by 归组
 
等待    新组等 group_wait（默认 30s）
        老组有变化等 group_interval（默认 5m）
        无变化每 repeat_interval 重发（默认 4h）
 
发送    调用 receiver 配置的渠道
 
恢复    收到 EndsAt 已过期或明确标记 resolved 的告警
        → 该告警移出组
        → 若整组全部恢复且 send_resolved 为 true，发一条恢复通知