Prometheus 告警（Alerting）详解：从规则到通知的完整闭环
Prometheus 告警（Alerting）详解：从规则到通知的完整闭环
Prometheus 的告警系统由 Prometheus Server 和 Alertmanager 两个核心组件协同工作，构成一个完整的告警闭环。它不仅能检测异常，还能通过去重、分组、静默等机制，避免告警风暴，确保关键问题能被及时处理。
本文将深入详解 Prometheus 告警的整体架构、告警规则配置、Alertmanager 工作机制以及最佳实践。
一、告警系统架构
核心流程
Prometheus Server 定期评估 alerting.rules当 expr 表达式为真且持续 for 时间，触发告警告警发送到 AlertmanagerAlertmanager 执行 去重、分组、静默、抑制最终通过 接收器（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告警名称（唯一标识）exprPromQL 表达式，返回布尔值或标量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：已触发，发送到 AlertmanagerResolved：表达式变为假，发送“已解决”通知（如果 send_resolved: true）
五、最佳实践
✅ 推荐做法
告警规则命名清晰
alert: HighRequestLatency
使用 for 避免瞬时抖动
for: 5m # 避免 1s 抖动就告警
合理设置分组
group_by: [alertname, cluster]
使用 inhibit_rules 减少噪音
# 节点宕机时，抑制其上所有 Pod 的告警
inhibit_rules:
- source_match:
alert: NodeDown
target_match:
job: kubelet
equal: [instance]
提供 runbook_url
annotations:
runbook_url: "https://runbooks.example.com/high-latency"
启用 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，你可以构建一个低噪音、高可用、可维护的告警体系，真正实现“有问题能发现，发现问题能解决”。