Prometheus Alertmanager告警规则配置与告警风暴抑制实战

监控告警体系中，Prometheus负责指标采集与告警规则评估，Alertmanager负责告警路由、分组、抑制和通知。两者协作构成完整的告警闭环。在SRE稳定性工程实践中，告警规则的设计质量直接影响故障响应效率——告警太少导致漏报，告警太多产生告警疲劳。本文从PromQL告警规则编写到Alertmanager路由配置，覆盖告警体系搭建的核心环节。

PromQL告警规则编写与阈值设计

Prometheus告警规则定义在rules.yml中，每条规则包含名称、PromQL表达式、持续时间（for）和标签/注释。告警分为两类：报警（alert）记录当前问题，记录规则（recording rule）预计算高频查询。

# prometheus.yml 告警规则引用
rule_files:
  - "rules/node_alerts.yml"
  - "rules/service_alerts.yml"

# rules/node_alerts.yml
groups:
  - name: node_resource_alerts
    rules:
      # CPU使用率持续5分钟超过80%
      - alert: HighCPUUsage
        expr: |
          100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
          team: ops
        annotations:
          summary: "CPU使用率过高: {{ $labels.instance }}"
          description: "实例 {{ $labels.instance }} CPU使用率已达 {{ $value | printf "%.1f" }}%，持续超过5分钟"

      # 内存使用率超过90%
      - alert: HighMemoryUsage
        expr: |
          (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 90
        for: 3m
        labels:
          severity: critical
          team: ops
        annotations:
          summary: "内存不足: {{ $labels.instance }}"
          description: "可用内存仅剩 {{ $value | printf "%.1f" }}%"

      # 磁盘空间不足
      - alert: DiskSpaceLow
        expr: |
          (1 - node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} 
            / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) * 100 > 85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "磁盘空间不足: {{ $labels.instance }} {{ $labels.mountpoint }}"
          description: "挂载点 {{ $labels.mountpoint }} 使用率 {{ $value | printf "%.1f" }}%"

告警阈值设计遵循”可操作性”原则：每个告警都应对应明确的运维操作。避免设置无法采取行动的告警（如”CPU使用率>50%”），这类告警只会消耗注意力。推荐采用多级阈值：warning（需关注但不紧急）和critical（需立即处理）。

Alertmanager路由与告警分组配置

Alertmanager接收来自Prometheus的告警后，根据路由规则（route）将告警分发到不同的接收器（receiver）。路由支持标签匹配和嵌套配置，实现精细化的告警分发。

# alertmanager.yml
route:
  # 顶级路由：默认接收器
  receiver: default-webhook
  # 告警分组：相同group_by标签的告警合并为一条通知
  group_by: ['alertname', 'cluster', 'service']
  # 分组等待时间：收到第一个告警后等待多久再发送
  group_wait: 30s
  # 分组间隔：同一组新告警的合并间隔
  group_interval: 5m
  # 重复发送间隔
  repeat_interval: 4h

  routes:
    # critical级别告警立即发送，不等待分组
    - matchers:
        - severity = critical
      receiver: pagerduty-critical
      group_wait: 0s
      repeat_interval: 1h

    # 按团队路由
    - matchers:
        - team = ops
      receiver: ops-dingtalk
      routes:
        - matchers:
            - service = database
          receiver: dba-slack

    - matchers:
        - team = dev
      receiver: dev-slack

receivers:
  - name: default-webhook
    webhook_configs:
      - url: 'http://localhost:9099/alerts'

  - name: pagerduty-critical
    pagerduty_configs:
      - service_key: 'your-key'
        severity: critical

  - name: ops-dingtalk
    webhook_configs:
      - url: 'https://oapi.dingtalk.com/robot/send?access_token=xxx'

  - name: dba-slack
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/xxx'
        channel: '#dba-alerts'

group_by的配置直接影响通知体验。按alertname分组时，同类型告警合并；加入instance后，不同实例的同类告警分开通知。建议按业务维度分组：['cluster', 'service', 'alertname']，同一集群同一服务的问题聚合为一条通知。

告警风暴抑制与静默规则

告警风暴是指因底层故障引发大量关联告警的场景。例如数据库主库宕机，会导致依赖该数据库的所有服务超时告警同时触发。Alertmanager通过抑制规则（inhibition）和静默规则（silence）处理这一问题。

# alertmanager.yml 抑制规则
inhibit_rules:
  # 当数据库主库宕机时，抑制其下游服务的告警
  - source_matchers:
      - alertname = DatabaseDown
      - severity = critical
    target_matchers:
      - alertname = ServiceLatencyHigh
      - service =~ "user-service|order-service|payment-service"
    equal: ['cluster']

  # 当节点宕机时，抑制该节点上的其他告警
  - source_matchers:
      - alertname = NodeDown
    target_matchers:
      - alertname =~ "HighCPUUsage|HighMemoryUsage|DiskSpaceLow"
    equal: ['instance']

  # 当集群不可达时，抑制该集群的所有warning级别告警
  - source_matchers:
      - alertname = ClusterUnreachable
      - severity = critical
    target_matchers:
      - severity = warning
    equal: ['cluster']

抑制规则的逻辑：当source告警触发时，满足匹配条件的目标告警被静默。这要求告警标签设计规范，cluster、service、instance等标签在所有规则中保持一致。

静默规则用于计划内维护期间的告警屏蔽。通过amtool或API创建静默规则：

# 使用amtool创建静默规则
amtool silence add   --comment "数据库主从切换维护"   --duration 2h   --author "admin"   alertname=DatabaseMasterSwitch

# API方式创建静默
curl -X POST http://alertmanager:9093/api/v2/silences   -H "Content-Type: application/json"   -d '{
    "matchers": [
      {"name": "alertname", "value": "DatabaseMasterSwitch", "isRegex": false}
    ],
    "startsAt": "2026-08-19T10:00:00Z",
    "endsAt": "2026-08-19T12:00:00Z",
    "createdBy": "admin",
    "comment": "数据库维护窗口"
  }'

# 查看活跃静默
amtool silence query
# 查看告警状态
amtool alert query

告警通知渠道集成与告警闭环

告警通知不仅要送达，还需包含足够的诊断信息。通过annotations注入Prometheus表达式查询链接和Grafana面板链接，帮助值班人员快速定位问题：

# 在告警规则中注入诊断链接
- alert: HTTP5xxRateHigh
  expr: |
    sum(rate(http_requests_total{status=~"5.."}[5m])) by(service) 
    / sum(rate(http_requests_total[5m])) by(service) > 0.05
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "HTTP 5xx错误率过高: {{ $labels.service }}"
    description: "服务 {{ $labels.service }} 5xx错误率 {{ $value | printf "%.2f" }}"
    runbook: "https://wiki.internal/runbooks/http-5xx"
    grafana: "https://grafana.internal/d/service-overview?var-service={{ $labels.service }}"
    prometheus: "https://prometheus.internal/graph?g0.expr={{ .Expr | urlquery }}"

告警闭环要求每条告警都有对应的处理流程。推荐使用Alertmanager的Webhook接收器将告警推送至ITSM系统（如Jira Service Desk），自动创建工单并跟踪处理进度。告警恢复时Prometheus发送resolved事件，Alertmanager自动关闭对应工单。

# Webhook接收器发送完整告警上下文
receivers:
  - name: itsm-webhook
    webhook_configs:
      - url: 'http://itsm-webhook:8080/alerts'
        send_resolved: true
        max_alerts: 0  # 不限制单次发送告警数

# webhook payload示例（POST到ITSM）
# {
#   "status": "firing",
#   "alerts": [...],
#   "groupLabels": {...},
#   "commonLabels": {...},
#   "externalURL": "https://alertmanager.internal"
# }

在CI/CD流水线中引入告警规则验证步骤，使用promtool check rules检查规则语法，使用amtool check-config验证Alertmanager配置，确保配置变更不会导致告警系统失效。这是DevOps实践中”基础设施即代码”在监控告警领域的落地。