1. Alertmanager概述

Alertmanager 是 Prometheus 生态中负责告警生命周期管理的核心组件。它接收 Prometheus Server 推送的告警事件,执行分组、抑制、静默、路由等策略,最终将告警通知发送到邮件、PagerDuty、Slack、Webhook 等接收端。没有 Alertmanager,Prometheus 只能产生原始告警,无法应对生产环境的告警风暴与分级响应需求。

1.1 在 Prometheus 生态中的角色

Prometheus 生态采用“采集 → 存储/查询 → 告警 → 通知”的管道架构。Alertmanager 处于告警管道的末端,承担以下职责:

  • 告警接收器:接收 Prometheus Server 通过 Alertmanager API 推送的告警。
  • 告警处理器:对告警进行去重、分组、抑制、静默等逻辑处理。
  • 通知发送器:将处理后的告警通过配置的接收器(Receiver)发送给运维人员或自动化系统。
  • 高可用协调器:支持集群模式,通过 Gossip 协议在多个 Alertmanager 实例间同步告警状态。
关键概念:Alertmanager 不负责告警规则评估(由 Prometheus Server 的 rules 模块完成),只负责告警产生后的路由与通知。两者职责分离,便于独立扩缩容与故障隔离。

1.2 核心功能详解

功能 说明 典型场景
告警分组 (Grouping) 将相同标签(如 alertname、severity、cluster)的告警合并为一条通知,避免告警风暴。 同一服务 100 个实例同时宕机,只发一条聚合通知。
告警抑制 (Inhibition) 当高优先级告警触发时,自动抑制低优先级告警,减少噪音。 节点宕机时,抑制该节点上所有进程/端口的告警。
告警静默 (Silence) 基于标签匹配规则,在指定时间段内静默特定告警,不发送通知。 计划内维护窗口,静默对应主机或服务的告警。
告警路由 (Routing) 基于告警标签(如 severity、team)将告警分发到不同的接收器(Receiver)。 Critical 告警发 PagerDuty,Warning 告警发邮件。

1.3 架构组件

Alertmanager 内部采用模块化设计,核心组件包括:

  • API 层:提供 HTTP API(/api/v2/alerts)接收 Prometheus 推送的告警,同时提供 UI 和静默管理接口。
  • 告警管道 (Pipeline):告警进入后的处理流水线,依次经过去重 → 分组 → 抑制 → 静默 → 路由。
  • 分组器 (Grouping Engine):根据 group_by 配置将告警归入不同组,等待 group_wait 时间后发送。
  • 抑制器 (Inhibition Engine):维护抑制规则,匹配源告警与目标告警,执行抑制逻辑。
  • 静默器 (Silence Engine):维护静默规则列表,检查告警是否被静默。
  • 路由树 (Route Tree):基于树形路由配置,将告警匹配到对应的接收器。
  • 通知器 (Notifier):调用接收器(邮件、Slack、Webhook 等)发送通知,并处理重试与退避。
  • 集群模块 (Cluster):基于 Gossip 协议实现多实例状态同步,保证告警不重复发送。
Alertmanager 架构组件图 Alertmanager 架构组件 API 层 告警管道 (Pipeline) 分组器 抑制器 静默器 路由树 通知器 (Notifier) 集群模块 说明:告警从 API 进入管道,依次经过分组、抑制、静默、路由,最终由通知器发送。 集群模块负责多实例状态同步,保证告警不重复发送。

1.4 告警处理流程

一条告警从 Prometheus 产生到最终通知,经历以下完整流程:

  1. Prometheus Server 评估告警规则,触发告警后通过 alertmanager 配置的地址推送至 Alertmanager API。
  2. API 层接收告警,写入告警管道。
  3. 去重:基于 fingerprint 和标签去重,避免重复告警。
  4. 分组:按 group_by 标签(如 alertname、severity)将告警归入同一组。
  5. 抑制:检查是否存在匹配的抑制规则,若存在则抑制该告警。
  6. 静默:检查是否存在匹配的静默规则,若存在则静默该告警。
  7. 路由:遍历路由树,匹配第一条符合条件的路由,将告警发送到对应的接收器。
  8. 通知器发送:调用接收器(邮件、Slack、Webhook 等)发送通知,失败则按退避策略重试。
审计要点:在生产环境中,告警分组和路由配置是导致告警丢失或重复的常见原因。后续章节将深入讲解如何通过 amtool 和日志审计路由决策路径。

1.5 路由树与接收器

路由树是 Alertmanager 配置中最核心、最复杂的部分。它采用树形结构,每个节点包含匹配规则和子节点:

route:
  receiver: 'default-receiver'
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      routes:
        - match:
            team: platform
          receiver: 'pagerduty-platform'
    - match:
        severity: warning
      receiver: 'email-warning'

每个路由节点可以指定:

  • 匹配规则:基于告警标签的 match 或 match_re 正则匹配。
  • 接收器:告警最终发送的目标(邮件、Slack、PagerDuty、Webhook 等)。
  • 分组参数:group_by、group_wait、group_interval、repeat_interval。
  • 子路由:支持嵌套,实现多级路由分发。
Alertmanager 路由树与接收器 路由树与接收器示意图 根路由 (default) severity: critical severity: warning team: platform team: sre PagerDuty PagerDuty Email 告警从根路由开始,按 severity 匹配子路由, 最终分发到对应的接收器。

1.6 本章小结

Alertmanager 是 Prometheus 告警生态的“交通枢纽”,其核心价值在于通过分组、抑制、静默、路由四大功能将原始告警转化为可执行的运维通知。理解其架构组件和路由树模型,是后续进行路由审计和故障排查的基础。下一章将深入讲解 Alertmanager 配置文件的完整结构与语法。