4、Prometheus 告警体系概述:Prometheus 架构、Alertmanager 组件、告警生命周期

Prometheus 告警体系是 CI/CD 流水线 Runbook 联动告警的核心数据源与事件引擎。理解 Prometheus 的整体架构、Alertmanager 的组件职责以及告警从产生到关闭的完整生命周期,是构建可靠自动化响应流程的前提。

4.1 Prometheus 整体架构

Prometheus 采用拉取(Pull)模式采集指标,并通过服务发现或静态配置确定目标。其核心组件包括:

  • Prometheus Server:负责指标抓取、存储与告警规则评估。
  • Exporters:将应用或系统指标转换为 Prometheus 格式。
  • Alertmanager:处理告警去重、分组、静默与路由通知。
  • Pushgateway:用于短期任务或无法直接拉取的场景。
  • Service Discovery:动态发现监控目标(Kubernetes、Consul、EC2 等)。
架构要点: Prometheus Server 定期从 Exporters 或目标应用拉取指标,将数据存入本地时序数据库(TSDB),同时根据加载的告警规则持续评估。当规则触发时,告警被推送到 Alertmanager 进行后续处理。
Prometheus 整体架构图 Prometheus 整体架构 Service Discovery Exporters / Targets Pushgateway Prometheus Server 抓取 · 存储 · 规则评估 Alertmanager 去重 · 分组 · 通知 通知渠道 Grafana / 可视化 说明: Prometheus Server 通过 Pull 模式从 Exporters 拉取指标,同时接收 Pushgateway 推送的数据。告警规则评估后发送至 Alertmanager,最终由通知渠道分发。

4.2 Alertmanager 组件详解

Alertmanager 是 Prometheus 告警体系中的“事件路由器”,负责接收来自 Prometheus Server 的告警,并执行以下核心操作:

组件/功能 职责描述 配置示例
Inhibition 告警抑制:当某个告警已触发时,抑制其他相关的低优先级告警,减少告警风暴。 inhibit_rules
Silencing 告警静默:基于标签匹配,在指定时间段内静默特定告警,常用于维护窗口。 silences (API/UI)
Grouping 告警分组:将相似告警合并为一条通知,避免信息轰炸。 group_by: ['alertname', 'severity']
Routing 告警路由:根据标签匹配将告警分发到不同的接收器(Receiver)。 route 树形匹配
Receiver 通知接收器:支持 Email、Slack、PagerDuty、Webhook 等。 receivers 配置
实践建议: 在 CI/CD 流水线 Runbook 联动场景中,Webhook Receiver 是最常用的通知方式。Alertmanager 可以将告警以 JSON 格式 POST 到 Runbook 的 Webhook 端点,触发自动化响应流程。

4.3 告警生命周期

一个告警从产生到关闭,经历以下关键状态:

  1. Pending(待处理):告警规则首次触发,但尚未满足持续时长(for 参数),处于观察期。
  2. Firing(触发中):告警条件持续满足超过 for 时长,Prometheus 将告警发送至 Alertmanager。
  3. Resolved(已解决):告警条件不再满足,Prometheus 发送 resolved 通知。
  4. Silenced(已静默):告警被手动或自动静默,不触发通知。
  5. Inhibited(已抑制):告警被其他高优先级告警抑制,不发送通知。
告警生命周期状态机 告警生命周期状态机 Pending Firing Resolved Silenced Inhibited 条件持续满足 条件恢复 手动/自动静默 被高优告警抑制 再次触发 关键点: 告警生命周期中的 Silenced 和 Inhibited 状态由 Alertmanager 管理,而 Pending、Firing、Resolved 由 Prometheus Server 控制。Runbook 联动通常关注 Firing 和 Resolved 事件。

4.4 告警生命周期与 Runbook 联动

在 CI/CD 流水线 Runbook 联动场景中,告警生命周期中的 Firing 和 Resolved 事件是最关键的触发点:

  • Firing 事件:触发 Runbook 自动化响应流程,例如自动回滚、扩容、重启服务或创建 Jira 工单。
  • Resolved 事件:触发 Runbook 恢复流程,例如关闭工单、恢复副本数、发送恢复通知。
  • Silenced / Inhibited:通常不触发 Runbook 联动,避免不必要的自动化操作。
注意: 告警生命周期中的 for 参数(Pending 持续时间)应合理设置。过短会导致告警抖动,过长会延迟 Runbook 响应。建议根据业务容忍度设置 1-5 分钟。

4.5 告警规则示例

以下是一个典型的 Prometheus 告警规则配置,用于监控 CI/CD 流水线中的部署失败率:

groups:
  - name: cicd_alerts
    rules:
      - alert: HighDeployFailureRate
        expr: |
          rate(deploy_failure_total[5m]) / rate(deploy_total[5m]) > 0.1
        for: 2m
        labels:
          severity: critical
          team: platform
        annotations:
          summary: "部署失败率超过 10%"
          description: "过去 5 分钟部署失败率为 {{ $value | humanizePercentage }},请立即检查流水线。"
          runbook: "https://runbook.example.com/deploy-failure"
Runbook 联动配置: 在 Alertmanager 的 receiver 中配置 Webhook,将告警 JSON 发送到 Runbook 引擎的 Webhook 端点。Runbook 根据告警标签(如 severity、team)匹配对应的自动化流程。