Prometheus 告警路由与通知管理：从告警风暴到精准触达，通知的最后一公里

Prometheus 告警路由与通知管理：从告警风暴到精准触达，通知的最后一公里

一、告警通知的工程困境：告警风暴与通知疲劳

Prometheus Alertmanager 是告警通知的最后一公里，负责将 Prometheus 产生的告警路由到正确的接收方。然而，在告警风暴期间，数百条告警在短时间内涌入，如果路由配置不当，可能导致：所有告警发送到同一频道（信息过载）、低级别告警淹没高级别告警、值班人员收到大量无关告警（通知疲劳）、重复告警反复触发（噪音放大）。

告警路由与通知管理的核心目标是：确保每条告警精准触达正确的接收方，在告警风暴中保持信号与噪声的分离，避免通知疲劳导致有效告警被忽视。

二、Alertmanager 的路由树与通知策略

flowchart TD A[告警进入 Alertmanager] --> B[路由树匹配] B --> C{匹配规则} C -->|severity=critical| D[紧急通道: 电话+短信] C -->|severity=warning, team=infra| E[基础设施组: Slack] C -->|severity=warning, team=app| F[应用组: Slack] C -->|severity=info| G[低优先级: 仅记录] D --> H[分组: 按 cluster+alertname] E --> H F --> H H --> I[抑制: 抑制衍生告警] I --> J[静默: 维护期间静默] J --> K[通知发送] subgraph 分组策略 H1[group_by: [cluster, alertname]] H2[group_wait: 30s] H3[group_interval: 5m] end subgraph 抑制规则 I1[节点宕机 → 抑制该节点上的服务告警] I2[数据库宕机 → 抑制依赖数据库的应用告警] end

路由树的核心概念：分组（Grouping）将相关告警合并为一条通知、抑制（Inhibition）在高级别告警触发时静默低级别衍生告警、静默（Silencing）在维护期间临时关闭特定告警。三者协同，将告警风暴压缩为可操作的通知。

三、工程实现：Alertmanager 生产级配置

# alertmanager.yml — Alertmanager 路由与通知配置 global: resolve_timeout: 5m slack_api_url: 'https://hooks.slack.com/services/xxx' smtp_smarthost: 'smtp.example.com:587' smtp_from: 'alerts@example.com' # 路由树：按标签匹配告警到不同接收方 route: receiver: 'default-slack' group_by: ['cluster', 'alertname', 'namespace'] group_wait: 30s # 首次通知等待时间（凑批） group_interval: 5m # 同组后续通知间隔 repeat_interval: 4h # 重复通知间隔 routes: # P0 紧急告警：电话 + 短信 + Slack - match: severity: critical receiver: 'critical-pagerduty' group_wait: 10s # 紧急告警快速通知 group_interval: 1m repeat_interval: 30m routes: # 数据库相关紧急告警路由到 DBA - match: severity: critical team: dba receiver: 'dba-pagerduty' # 网络相关紧急告警路由到网络组 - match: severity: critical team: network receiver: 'network-pagerduty' # P1 警告告警：Slack 通知 - match: severity: warning receiver: 'warning-slack' group_wait: 30s group_interval: 5m repeat_interval: 2h routes: - match_re: namespace: ^(prod|staging)$ receiver: 'prod-warning-slack' # 低优先级：仅记录 - match: severity: info receiver: 'log-only' group_wait: 5m # 抑制规则：高级别告警抑制衍生告警 inhibit_rules: # 节点宕机时，抑制该节点上的所有服务告警 - source_match: alertname: NodeDown severity: critical target_match: severity: warning equal: ['instance'] # 数据库主库宕机时，抑制依赖该数据库的应用告警 - source_match: alertname: MySQLMasterDown severity: critical target_match: alertname: AppErrorRateHigh equal: ['cluster'] # API 网关异常时，抑制下游服务的延迟告警 - source_match: alertname: APIGatewayDown severity: critical target_match_re: alertname: .+LatencyHigh equal: ['cluster'] # 接收方配置 receivers: - name: 'default-slack' slack_configs: - channel: '#alerts-default' title: '{{ .GroupLabels.alertname }}' text: >- {{ range .Alerts }} *告警*: {{ .Annotations.summary }} *详情*: {{ .Annotations.description }} *开始时间*: {{ .StartsAt }} {{ end }} - name: 'critical-pagerduty' pagerduty_configs: - service_key: '<pagerduty-service-key>' severity: '{{ .GroupLabels.severity }}' slack_configs: - channel: '#alerts-critical' title: '🔴 紧急: {{ .GroupLabels.alertname }}' - name: 'dba-pagerduty' pagerduty_configs: - service_key: '<dba-pagerduty-key>' - name: 'network-pagerduty' pagerduty_configs: - service_key: '<network-pagerduty-key>' - name: 'warning-slack' slack_configs: - channel: '#alerts-warning' - name: 'prod-warning-slack' slack_configs: - channel: '#alerts-prod' - name: 'log-only' webhook_configs: - url: 'http://alert-logger:8080/log'

# Prometheus 告警规则示例 groups: - name: node-alerts rules: - alert: NodeDown expr: up{job="node-exporter"} == 0 for: 2m labels: severity: critical team: infra annotations: summary: "节点 {{ $labels.instance }} 宕机" description: "节点已宕机超过 2 分钟" - alert: HighCPUUtilization expr: 100 - (avg by(instance)(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85 for: 10m labels: severity: warning team: infra annotations: summary: "节点 {{ $labels.instance }} CPU 使用率过高" description: "CPU 使用率持续超过 85% 已达 10 分钟"

四、告警路由的边界与权衡

路由规则的维护成本：随着团队与服务的增长，路由规则持续膨胀，维护成本增加。建议定期审查路由规则，删除过时规则，并使用match_re正则匹配减少规则数量。

抑制规则的误杀风险：抑制规则可能意外抑制有效告警。例如，节点宕机时抑制了该节点上的所有服务告警，但某个服务的告警可能由其他原因触发（而非节点宕机导致）。建议在抑制规则中使用更精确的匹配条件（如equal: ['instance']），避免过度抑制。

静默规则的遗忘风险：维护期间的静默规则如果忘记删除，可能导致真实告警被持续静默。建议为静默规则设置过期时间（如 2 小时），超时自动失效。

通知渠道的可靠性：Slack、邮件等通知渠道可能存在延迟或丢失。P0 告警建议使用多通道冗余（电话 + 短信 + Slack），确保至少一个通道触达。

五、总结

Alertmanager 的路由树、分组、抑制与静默机制，是告警通知精准触达的核心保障。路由树按标签匹配告警到接收方，分组合并相关告警减少通知数量，抑制消除衍生告警噪音，静默临时关闭维护期间告警。工程落地的关键在于：P0 告警多通道冗余保障触达、抑制规则精确匹配避免误杀、静默规则设置过期时间防止遗忘、定期审查路由规则控制维护成本。告警通知不是"发了就行"，而是"发对了才行"——精准触达比广撒网更有效。