Prometheus 告警（Alerting）详解：从规则到通知的完整闭环

Prometheus 告警（Alerting）详解：从规则到通知的完整闭环

Prometheus 的告警系统由 Prometheus Server 和 Alertmanager 两个核心组件协同工作，构成一个完整的告警闭环。它不仅能检测异常，还能通过去重、分组、静默等机制，避免告警风暴，确保关键问题能被及时处理。

本文将深入详解 Prometheus 告警的整体架构、告警规则配置、Alertmanager 工作机制以及最佳实践。

---

一、告警系统架构

核心流程

1. Prometheus Server 定期评估 alerting.rules
2. 当 expr 表达式为真且持续 for 时间，触发告警
3. 告警发送到 Alertmanager
4. Alertmanager 执行 去重、分组、静默、抑制
5. 最终通过 接收器（Receiver） 发送到通知渠道

✅ Prometheus 负责“判断是否告警”，Alertmanager 负责“如何通知”

---

二、1. 配置告警规则（Alerting Rules）

告警规则定义在 .rules.yml 文件中，并在 prometheus.yml 中加载。

2.1 在 prometheus.yml 中加载规则文件

# prometheus.yml
rule_files:
  - "rules/alerts.yml"
  - "rules/k8s/*.yml"
  - "rules/business/*.yml"

✅ 支持通配符，便于模块化管理。

2.2 告警规则文件结构

# rules/alerts.yml
groups:
  - name: example-alerts
    rules:
      - alert: HighRequestLatency
        expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 1
        for: 10m
        labels:
          severity: warning
          team: backend
        annotations:
          summary: "High latency on {{ $labels.job }}"
          description: "The 99th percentile request latency for {{ $labels.job }} is above 1s for more than 10 minutes."
          value: "{{ $value }}s"
          runbook_url: "https://runbooks.example.com/high-latency"

---

2.3 告警规则字段详解

字段	说明
alert	告警名称（唯一标识）
expr	PromQL 表达式，返回布尔值或标量
for	持续时间，只有持续满足条件才触发
labels	附加标签，用于路由和分组
annotations	详细信息，用于通知内容

关键说明：

• ✅ expr：必须返回非零值才表示触发（如 up == 0）
• ✅ for: 10m：防止瞬时抖动误报
• ✅ labels：用于 Alertmanager 路由（如 severity: critical）
• ✅ annotations：支持模板变量 {{ $labels.xxx }}, {{ $value }}

---

2.4 常见告警规则示例

1. 实例宕机

- alert: InstanceDown
  expr: up == 0
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Instance {{ $labels.instance }} down"
    description: "{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes."

2. 高错误率

- alert: HighErrorRate
  expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.1
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "High error rate on {{ $labels.job }}"
    description: "HTTP 5xx error rate is {{ $value | printf \"%.2f\" }} for {{ $labels.job }}"

3. 磁盘空间不足

- alert: DiskWillFillIn24Hours
  expr: node_filesystem_avail_bytes / rate(node_filesystem_avail_bytes[1h]) < 24 * 60 * 60
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "Disk will fill in 24h on {{ $labels.instance }}"
    description: "Filesystem {{ $labels.mountpoint }} on {{ $labels.instance }} will fill up in less than 24 hours."

---

三、2. Alertmanager：告警管理中枢

Alertmanager 是独立于 Prometheus 的组件，负责处理告警的生命周期管理。

3.1 安装与配置

# alertmanager.yml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 3h
  receiver: 'slack-notifications'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'

receivers:
  - name: 'slack-notifications'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/XXX/YYYY/ZZZ'
        channel: '#alerts'
        send_resolved: true
        text: "{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}"

  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: 'your-pagerduty-routing-key'
        send_resolved: true

inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['alertname', 'cluster', 'service']

---

3.2 Alertmanager 核心功能

功能	说明
去重（Deduplication）	相同告警在 group_interval 内只通知一次
分组（Grouping）	将相似告警合并发送（如多个实例宕机）
静默（Silences）	临时屏蔽告警（如维护期）
抑制（Inhibition）	某告警触发时，抑制其他相关告警（如节点宕机时抑制 Pod 告警）
通知（Notifications）	支持 Slack、Email、Webhook、PagerDuty 等

---

3.3 route 配置详解

route:
  group_by: ['alertname', 'job']           # 按 alertname 和 job 分组
  group_wait: 30s                         # 第一个告警到达后等待 30s，看是否有更多告警
  group_interval: 5m                      # 同一分组的告警每 5m 发送一次
  repeat_interval: 3h                     # 已解决的告警，3 小时后才重新通知
  receiver: 'default-receiver'            # 默认接收器
  routes:                                 # 子路由
    - match:
        severity: 'critical'
      receiver: 'critical-team'
    - match_re:
        service: '^(foo1|foo2)$'
      receiver: 'team-foo'

✅ 支持精确匹配 match 和正则匹配 match_re

---

四、告警生命周期

• Pending：表达式为真，但未达到 for 时间
• Firing：已触发，发送到 Alertmanager
• Resolved：表达式变为假，发送“已解决”通知（如果 send_resolved: true）

---

五、最佳实践

✅ 推荐做法

1. 告警规则命名清晰

   alert: HighRequestLatency
   

2. 使用 for 避免瞬时抖动

   for: 5m  # 避免 1s 抖动就告警
   

3. 合理设置分组

   group_by: [alertname, cluster]
   

4. 使用 inhibit_rules 减少噪音

   # 节点宕机时，抑制其上所有 Pod 的告警
   inhibit_rules:
     - source_match:
         alert: NodeDown
       target_match:
         job: kubelet
       equal: [instance]
   

5. 提供 runbook_url

   annotations:
     runbook_url: "https://runbooks.example.com/high-latency"
   

6. 启用 send_resolved

   slack_configs:
     - send_resolved: true
   

---

❌ 避免的问题

• ❌ 告警没有 for，导致频繁触发
• ❌ 使用高基数标签分组（如 instance）
• ❌ 告警信息不完整（缺少 description）
• ❌ 没有配置静默和抑制，导致告警风暴

---

六、测试与验证

1. 检查规则语法

promtool check rules rules/*.yml

2. 查看 Prometheus 中的告警状态

访问 http://prometheus:9090/alerts 查看当前告警是 Pending 还是 Firing。

3. 手动触发告警测试通知

# 临时让 up == 0
vector(1) > bool 0

---

七、总结

Prometheus 告警系统是一个分层协作的架构：

组件	职责
Prometheus Server	评估规则，判断是否触发告警
Alerting Rules	定义“什么情况下告警”
Alertmanager	管理“如何通知”，去重、分组、抑制
Receiver	实际发送通知到 Slack、Email 等

黄金法则：

“告警要少而精，通知要准而明。”

通过合理配置告警规则和 Alertmanager，你可以构建一个低噪音、高可用、可维护的告警体系，真正实现“有问题能发现，发现问题能解决”。