Prometheus告警规则编写指南：Alertmanager告警分组与抑制配置

Prometheus告警体系是SRE稳定性工程的核心组件。一条好的告警规则要做到三点：能在问题影响用户之前触发、告警内容包含足够的排查上下文、不产生告警风暴。Alertmanager作为告警分发引擎，配合Prometheus的告警规则实现告警分组、抑制、静默和路由分发。

Prometheus告警规则语法结构

告警规则定义在rules文件中，包含alert名称、表达式、持续时间、标签和注释：

groups:
- name: node_alerts
  rules:
  - alert: NodeHighCpuUsage
    expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
    for: 5m
    labels:
      severity: warning
      team: infra
    annotations:
      summary: "CPU使用率过高: {{ $labels.instance }}"
      description: "实例 {{ $labels.instance }} 的CPU使用率已达 {{ $value }}%，持续5分钟"
      runbook_url: "https://wiki.internal/runbooks/high-cpu"

for字段设置持续时间，避免瞬时抖动触发告警。expr表达式中$labels引用时间序列标签，$value引用表达式计算值。runbook_url指向运维手册，帮助值班人员快速定位处理步骤。

多维告警规则设计实践

实际生产环境中需要覆盖多个维度。以下示例覆盖CPU、内存、磁盘、服务状态四个核心指标：

groups:
- name: infrastructure_alerts
  interval: 30s
  rules:
  - alert: NodeHighMemoryUsage
    expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 > 85
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "内存使用率过高: {{ $labels.instance }}"
      description: "内存使用率 {{ $value }}%，可用内存不足15%"

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

  - alert: ServiceDown
    expr: up{job="node_exporter"} == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "节点不可达: {{ $labels.instance }}"
      description: "node_exporter已掉线1分钟"

severity标签区分告警级别，critical级别会直接触发电话通知，warning级别走IM通知。interval设置规则评估间隔，默认30秒足够覆盖大部分场景。

Alertmanager告警分组配置

告警分组把同一类型的告警合并成一条通知，避免告警风暴。核心配置在alertmanager.yml的route段：

route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default-webhook'
  routes:
  - matchers:
    - severity="critical"
    receiver: 'pagerduty-critical'
    group_wait: 0s
    repeat_interval: 1h
  - matchers:
    - severity="warning"
    receiver: 'slack-warning'
    group_wait: 30s
    group_interval: 5m

group_by指定按哪些标签分组，相同标签值的告警合并为一条。group_wait是首次告警的等待时间，在这段时间内收到的同组告警会合并发送。group_interval是同一组告警的两次通知间隔。repeat_interval是重复告警的最小间隔。

告警抑制规则实战

抑制（Inhibition）用于在某些告警已触发时，静默其他关联告警。典型场景是机房断电导致所有节点掉线，只需要一条机房级告警而非几十条节点告警：

inhibit_rules:
- source_matchers:
  - alertname="ServiceDown"
  target_matchers:
  - alertname=~"Node.*"
  equal: ['instance']

- source_matchers:
  - alertname="ServiceDown"
  target_matchers:
  - alertname=~"NodeDisk.*|NodeHigh.*"
  equal: ['instance']

- source_matchers:
  - alertname="ClusterDown"
  target_matchers:
  - alertname=~"Node.*|Service.*"
  equal: ['cluster']

source_matchers指定触发抑制的告警，target_matchers指定被抑制的告警，equal指定哪些标签必须相同才触发抑制。配置后，当ServiceDown告警触发时，同一instance的其他Node告警自动静默。

告警路由分发到不同渠道

不同团队负责不同服务，告警需要精确路由。通过标签匹配实现：

route:
  routes:
  - matchers:
    - team="infra"
    receiver: 'infra-slack'
  - matchers:
    - team="db"
    receiver: 'db-pagerduty'
  - matchers:
    - service=~"frontend|gateway"
    receiver: 'frontend-webhook'

receivers:
- name: 'default-webhook'
  webhook_configs:
  - url: 'http://alert-router:8080/alert'
- name: 'infra-slack'
  slack_configs:
  - api_url: 'https://hooks.slack.com/services/xxx'
    channel: '#infra-alerts'
- name: 'db-pagerduty'
  pagerduty_configs:
  - routing_key: 'xxx'

路由匹配从上到下，命中第一条后停止。子路由可以设置自己的group_by和repeat_interval，覆盖父路由配置。告警路由配合CI/CD流水线部署规则文件，实现告警配置的版本化管理。

告警质量治理与迭代

告警配置上线后需要持续治理。关键指标包括告警量趋势、告警恢复时间（MTTR）、告警噪声比。通过Prometheus自身查询告警触发统计：

# 过去24小时每条规则触发次数
increase(ALERTS{alertstate="firing"}[24h]) by (alertname)

# 当前firing告警数量
count(ALERTS{alertstate="firing"})

# 噪声指标：触发后1分钟内恢复的告警
(ALERTS{alertstate="firing"} and on(alertname,instance)
 ALERTS{alertstate="resolved"} offset 1m)

噪声告警占比超过20%时，应该调整for持续时间或expr阈值。故障应急响应体系建设中，告警规则的持续优化是保障系统稳定性的重要环节，定期审查并清理无效规则能显著降低值班压力。