AlertManager告警规则配置

本文目录导读：

1. 第一部分：定义告警规则（在 Prometheus 端）
2. 第二部分：AlertManager 配置文件（alertmanager.yml）
3. 第三部分：高级配置与最佳实践
4. 第四部分：实际部署检查清单
5. 总结：需要记住的 3 件事

AlertManager 本身不负责定义告警规则，它负责接收来自 Prometheus 或其他客户端的告警，并进行去重、分组、抑制、静默和路由通知。

真正定义“触发条件”的规则文件，是在 Prometheus 服务器 的 rules 配置中完成的（即 PrometheusRule）。

以下是一个完整的配置指南,涵盖 Prometheus 告警规则 和 AlertManager 的路由与通知。

第一部分：定义告警规则（在 Prometheus 端）

文件通常叫 rules.yml 或 alerts.yml，在 prometheus.yml 中用 rule_files 引入。

# rules.yml
groups:
  - name: 基础服务告警
    rules:
      # 1. 实例存活告警
      - alert: InstanceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Instance {{ $labels.instance }} down"
          description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 1 minutes."
      # 2. CPU 使用率过高
      - alert: HighCpuUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "CPU usage > 80% on {{ $labels.instance }}"
          description: "CPU usage is at {{ $value }}% for 5 minutes."
      # 3. 内存使用率过高
      - alert: HighMemoryUsage
        expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 90
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "Memory usage > 90% on {{ $labels.instance }}"
          description: "Memory usage is at {{ $value | humanizePercentage }}."
      # 4. 磁盘空间不足
      - alert: DiskSpaceFull
        expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) * 100 < 10
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Disk space < 10% on {{ $labels.instance }}"
          description: "Filesystem {{ $labels.mountpoint }} has only {{ $value | humanizePercentage }} free."

关键字段说明：

第二部分：AlertManager 配置文件（alertmanager.yml）

AlertManager 的配置主要围绕 路由（route） 和 接收器（receivers）。

# alertmanager.yml
global:
  # 基础设置
  resolve_timeout: 5m  # 告警解决后，保留 resolved 通知的时间
  # SMTP 配置（如使用邮件）
  smtp_from: 'alertmanager@example.com'
  smtp_smarthost: 'smtp.example.com:587'
  smtp_auth_username: 'alertmanager@example.com'
  smtp_auth_password: 'your_password'
  smtp_require_tls: true
# 根路由（所有告警第一个匹配这里）
route:
  group_by: ['alertname', 'cluster']  # 按告警名称和集群分组，防止刷屏
  group_wait: 30s                     # 同一组内的告警等待 30s 再发送，旨在合并
  group_interval: 5m                  # 同一组内新告警的发送间隔
  repeat_interval: 4h                 # 成功通知后，重复告警的最小间隔
  receiver: 'default-receiver'        # 默认接收人
  # 子路由（根据标签匹配，匹配第一个即停止）
  routes:
    # 优先级 1：严重告警走 PagerDuty/钉钉/电话
    - match:
        severity: critical
      receiver: 'pager-duty'
      repeat_interval: 10m  # 降低重复间隔，持续提醒
    # 优先级 2：数据库相关的告警发给 DBA 组
    - match_re:
        job: '^(mysql|postgres|redis).*'
      receiver: 'db-team'
      group_by: ['job', 'instance']  # 按 job 分组
    # 优先级 3：警告级别告警发邮件即可
    - match:
        severity: warning
      receiver: 'email'
# 接收器定义
receivers:
  # 1. 默认：邮件
  - name: 'default-receiver'
    email_configs:
      - to: 'team@example.com'
        headers:
          Subject: '[AlertManager] {{ .GroupLabels.alertname }}'
  # 2. 严重告警：企微/钉钉/Slack 机器人
  - name: 'pager-duty'
    webhook_configs:
      - url: 'http://your-webhook-server:8080/alert'
        send_resolved: true
    # 也可以配置 Slack：
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/TXXXX/BXXXX/XXXXXXXX'
        channel: '#alerts-critical'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.description }}'
  # 3. 数据库告警
  - name: 'db-team'
    email_configs:
      - to: 'dba@example.com'
    webhook_configs:
      - url: 'http://ops-platform/api/alert'

核心配置要点：

1. group_by（分组）

   • 必须设置,否则每个告警单独发一条，造成消息轰炸。
   • 通常按 alertname, severity, job 分组。

2. group_interval vs repeat_interval

   • group_interval：新告警加入已有分组后的通知最小间隔。
   • repeat_interval：同一告警已经通知过，再次通知的间隔。

3. 路由匹配优先级

   • 从上到下匹配,匹配到第一个后停止。
   • match：精确匹配标签。
   • match_re：正则匹配。

4. send_resolved

   • 在 webhook_configs、slack_configs 等中设置 send_resolved: true，可以让接收方知道问题已恢复。

第三部分：高级配置与最佳实践

抑制规则（Inhibition）

避免因一个根因告警导致大量派生告警,例如服务器宕机后，不要再发 CPU/内存告警。

inhibit_rules:
  - source_match:          # 源告警
      severity: 'critical'
    target_match:          # 目标告警（被抑制）
      severity: 'warning'
    equal: ['instance']    # 当 instance 相同时，警告被抑制

静默规则（Silence）

在 AlertManager UI 中手动添加，用于已知维护窗口，也可以通过 API 添加。

告警模板（Templates）

AlertManager 支持 Go 模板，自定义通知格式。

# 在 alertmanager.yml 中引入模板
templates:
  - '/etc/alertmanager/templates/*.tmpl'

模板文件示例（telegram.tmpl）：

{{ define "telegram.default" }}
🔔 *Alert: {{ .CommonLabels.alertname }}*
Status: {{ .Status }}
Severity: {{ .CommonLabels.severity }}
Instance: {{ .CommonLabels.instance }}
Description: {{ .CommonAnnotations.description }}
{{ end }}

第四部分：实际部署检查清单

1. Prometheus 配置文件 确保包含 rule_files：

   rule_files:
     - "/etc/prometheus/rules/*.yml"

2. 检查告警规则语法：

   promtool check rules /etc/prometheus/rules/*.yml

3. 测试 AlertManager 配置：

   amtool check-config alertmanager.yml

4. 验证告警是否触发：

   • 在 Prometheus UI 中查看 Alerts 标签页。
   • 查看 AlertManager UI 中的 Alerts 标签页。

需要记住的 3 件事

1. 告警规则 写在 Prometheus 的 rules.yml 里，AlertManager 不写规则。
2. 告警严重级别 通过 labels 设定，AlertManager 的 route 通过 match 标签来进行路由。
3. group_by 和 repeat_interval 是防止告警风暴的关键，务必合理配置。