Prometheus告警规则编写与Alertmanager多渠道通知路由配置实战

Prometheus告警规则结构与PromQL表达式编写

Prometheus告警体系由两部分构成：Prometheus Server负责规则评估和告警触发，Alertmanager负责告警去重、分组、路由和通知分发。监控告警体系的核心价值不在于收集数据，而在于在故障发生时准确、及时地通知到正确的人。

Prometheus告警规则定义在rules文件中，每条规则包含告警名称、表达式、持续时间、标签和注解。一个完整的告警规则示例如下：

groups:
- name: node_alerts
  rules:
  - alert: HighCPUUsage
    expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 5m
    labels:
      severity: warning
      team: ops
    annotations:
      summary: "CPU使用率过高 {{ $labels.instance }}"
      description: "实例 {{ $labels.instance }} 的CPU使用率已超过85%持续5分钟，当前值: {{ $value }}%"

  - 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: "实例 {{ $labels.instance }} 内存使用率超过90%，当前值: {{ $value }}%"

  - 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 }} 使用率超过85%，当前值: {{ $value }}%"

expr字段使用PromQL表达式定义触发条件。rate()函数计算5分钟内的平均速率，for字段指定告警触发前需持续满足条件的时间。for: 5m表示连续5分钟满足条件才触发告警，避免瞬时波动造成误报。labels中的severity字段用于后续Alertmanager路由决策。

Alertmanager路由配置与通知分发机制

Alertmanager接收Prometheus发送的告警后，根据路由规则（route）将告警分发到不同的接收器（receiver）。路由配置是Alertmanager的核心，通过标签匹配实现精细化的告警分发。以下是一个覆盖多渠道通知的配置示例：

global:
  resolve_timeout: 5m
  smtp_smarthost: 'smtp.example.com:587'
  smtp_from: 'alertmanager@example.com'
  smtp_auth_username: 'alertmanager@example.com'
  smtp_auth_password: 'password'

route:
  group_by: ['alertname', 'cluster', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
  # critical级别告警发送到企业微信+邮件
  - matchers:
    - severity="critical"
    receiver: 'wechat-critical'
    group_wait: 10s
    repeat_interval: 1h
    continue: true
  # warning级别告警只发邮件
  - matchers:
    - severity="warning"
    receiver: 'email-warning'
    repeat_interval: 3h
  # 按团队路由
  - matchers:
    - team="db"
    receiver: 'dba-team'
  - matchers:
    - team="frontend"
    receiver: 'frontend-team'

receivers:
- name: 'default'
  email_configs:
  - to: 'ops-team@example.com'

- name: 'wechat-critical'
  webhook_configs:
  - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxx'
    send_resolved: true
  email_configs:
  - to: 'oncall@example.com'

- name: 'email-warning'
  email_configs:
  - to: 'ops-team@example.com'

- name: 'dba-team'
  webhook_configs:
  - url: 'https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=db-key'

inhibit_rules:
- source_matchers:
  - severity="critical"
  target_matchers:
  - severity="warning"
  equal: ['instance', 'alertname']

group_by控制告警分组维度，同一组告警合并为一条通知发送，避免告警风暴。group_wait是首次发送前的等待时间，收集同组告警。group_interval是同组新告警的发送间隔。repeat_interval是重复发送未解决告警的间隔。continue: true表示匹配后继续匹配后续路由，实现多渠道同时通知。

inhibit_rules定义告警抑制规则——当critical告警触发时，自动抑制同实例的warning级别告警。例如某节点宕机触发critical告警后，该节点上的CPU过高、磁盘空间不足等warning告警会被自动抑制，避免告警轰炸。

告警规则测试与验证方法

编写告警规则后需要验证表达式是否正确、触发条件是否合理。Prometheus提供了promtool工具用于规则验证：

# 语法检查
promtool check rules /etc/prometheus/alert_rules.yml

# 测试规则文件
promtool test rules test_rules.yml

test_rules.yml是一个测试用例文件，定义输入数据和期望结果：

rule_files:
- alert_rules.yml

evaluation_interval: 1m

tests:
- interval: 1m
  input_series:
  - series: 'node_cpu_seconds_total{instance="10.0.0.1", mode="idle"}'
    values: '0+100x10'
  - series: 'node_memory_MemAvailable_bytes{instance="10.0.0.1"}'
    values: '1000000000x10'
  - series: 'node_memory_MemTotal_bytes{instance="10.0.0.1"}'
    values: '16000000000x10'
  
  alert_rule_test:
  - eval_time: 6m
    alertname: HighCPUUsage
    exp_alerts:
    - exp_labels:
        severity: warning
        instance: "10.0.0.1"
      exp_annotations:
        summary: "CPU使用率过高 10.0.0.1"

这种方式可以在不部署Prometheus的情况下离线验证告警规则的正确性，特别适合CI/CD流水线中集成规则测试。

生产环境告警优化实践

告警过多导致”狼来了”效应是运维团队的常见痛点。优化策略包括：合理设置for持续时间过滤瞬时抖动、使用动态阈值替代静态阈值、配置告警抑制减少衍生告警。动态阈值可以通过记录规则（recording rules）实现，先计算历史基线再与当前值比较：

# 记录规则：计算7天前同时段的平均CPU使用率
groups:
- name: baseline_rules
  rules:
  - record: cpu:usage:avg_7d
    expr: avg_over_time((100 - (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100))[7d:1h])
  
  # 告警规则：当前值超过基线2倍时触发
  - alert: AnomalyCpuUsage
    expr: (100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)) > (cpu:usage:avg_7d * 2)
    for: 10m
    labels:
      severity: warning

告警发送渠道的选择也需要分层：critical级别通过即时通讯工具（企业微信、钉钉、飞书）加电话告警，warning级别通过邮件或工单系统，info级别仅记录到日志不主动通知。repeat_interval根据严重程度递减——critical每1小时重复、warning每3小时、info不重复。这种分层策略在保证关键告警及时送达的同时，有效降低告警疲劳。