Prometheus告警规则设计与多级通知路由方案

告警规则的核心设计原则

监控告警的价值不在于数量而在于精准度。一条告警被触发后如果没有明确的处理动作，那就是噪音。设计告警规则时遵循两条硬标准：一是每条告警必须有对应的处理SOP或至少一个oncall负责人，二是告警级别必须能直接映射到响应时效。

告警分级通常按P0-P3划分：P0指服务完全不可用，要求5分钟内响应；P1指核心功能受损，15分钟响应；P2指性能劣化但可用，1小时内处理；P3指信息性告警，工作时间处理。分级一旦确定，通知路由就围绕这个体系构建。

Prometheus告警规则编写规范

告警规则YAML文件的命名约定：规则文件按服务维度拆分，不要把所有规则塞进一个文件。目录结构如下：

alerts/

├── node-exporter.yaml

├── kube-state-metrics.yaml

├── api-gateway.yaml

└── database.yaml

规则模板示例，以Node内存使用率为例：

- alert: NodeMemoryUsageHigh

expr: 100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) > 85

for: 5m

labels:

severity: P1

team: infra

annotations:

summary: "节点 {{ $labels.instance }} 内存使用率超过85%"

runbook: "https://wiki.internal/runbook/node-memory"

几个关键点：for字段必须设置，避免瞬时毛刺触发告警；severity用P级别而非warning/critical，和运维体系对齐；annotations中的runbook链接指向处理手册。

多条件组合告警

单指标告警误报率高，多条件组合能显著提升精度。例如CPU使用率超过90%且load5大于CPU核数才告警：

- alert: HighCPUAndLoad

expr: |

(100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90)

and

(node_load5 > on(instance) count(node_cpu_seconds_total{mode="idle"}) by(instance))

for: 10m

labels:

severity: P1

annotations:

summary: "{{ $labels.instance }} CPU高负载持续10分钟"

这种组合逻辑把单纯的CPU利用率告警升级为”真正影响服务”的告警。

Alertmanager通知路由配置

Alertmanager的路由树决定了告警发往哪里。核心配置：

route:

receiver: default-slack

group_by: [alertname, cluster]

group_wait: 30s

group_interval: 5m

repeat_interval: 4h

routes:

- match:

severity: P0

receiver: pagerduty-oncall

group_wait: 10s

repeat_interval: 15m

- match:

severity: P1

receiver: phone-and-slack

group_wait: 30s

repeat_interval: 1h

- match:

severity: P3

receiver: daily-digest

repeat_interval: 24h

group_by控制告警聚合维度，同一组的告警合并为一条通知，避免风暴。group_wait是第一条告警等待聚合的时间，group_interval是同组新告警的聚合间隔，repeat_interval是重复通知间隔。

告警抑制与静默策略

告警抑制（inhibit_rules）避免低级别告警在高级别已触发时重复通知：

inhibit_rules:

- source_match:

severity: P0

target_match:

severity: P1

equal: [alertname, instance]

当同一alertname和instance的P0告警存在时，抑制对应的P1告警。典型场景：节点宕机触发NodeDown(P0)，同时触发CPU High(P1)，后者显然多余。

静默（silences）用于计划内维护。通过API或Web UI设置，支持正则匹配。例如etcd集群滚动升级期间静默所有etcd告警：

amtool silence add --matcher=alertname=~etcd.* --duration=2h --comment="etcd rolling upgrade"

告警质量度量指标

告警系统的健康度需要持续度量。核心指标包括：告警触发率（触发次数/时间）、确认率（收到告警后实际处理的比例）、误报率（告警触发但无需处理的比例）、MTTR（从告警触发到恢复的平均时间）。

在Prometheus中记录这些元数据：

alertmanager_alerts_received_total

alertmanager_alerts_invalid_total

alertmanager_notifications_failed_total

定期用这些指标构建告警质量看板。当某条规则的误报率超过40%时，说明阈值或条件需要调整；当确认率低于60%时，说明规则本身缺乏可操作性，应考虑删除或合并。