Prometheus 高可用（HA）部署详解

Prometheus 高可用（HA）部署详解

Prometheus 默认是单节点、单实例架构，虽然稳定可靠，但在生产环境中存在单点故障风险。一旦 Prometheus 实例宕机，将导致：

• ❌ 指标采集中断
• ❌ 告警无法触发
• ❌ 可视化数据缺失

因此，高可用（High Availability, HA）部署是生产环境的必要实践。

本文将详解 Prometheus 的 HA 架构方案，包括 Prometheus Server HA 和 Alertmanager 集群模式，帮助你构建一个真正可靠的监控系统。

---

一、Prometheus Server 高可用（HA）方案

目标

• 避免单点故障
• 保证监控持续运行
• 支持故障自动切换

1. 基本 HA 方案：双实例 + 服务发现

最简单有效的 HA 方案是运行 两个配置完全相同的 Prometheus 实例，同时抓取相同的目标。

✅ 优点

• 配置简单，易于实施
• 单个实例宕机不影响整体监控
• 与 Alertmanager 集群天然集成

❌ 缺点

• 数据重复采集（双倍网络和存储）
• 不解决长期存储和联邦问题

✅ 这是大多数生产环境推荐的起点方案。

---

2. 配置示例

两个 Prometheus 实例使用相同的 prometheus.yml：

# prometheus.yml（两个实例共用）
global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

rule_files:
  - "rules/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager-0:9093', 'alertmanager-1:9093']

✅ 两个实例都向 同一个 Alertmanager 集群发送告警。

---

3. Grafana 中的高可用配置

在 Grafana 中添加两个 Prometheus 数据源，并启用 “Load Balancing” 或使用反向代理。

方式一：Grafana 轮询多个数据源

• 添加两个数据源：Prometheus-HA-1, Prometheus-HA-2
• 在 Dashboard 中选择任一数据源（手动切换）

方式二：使用反向代理（推荐）

# Nginx 配置（prometheus-proxy.conf）
upstream prometheus_ha {
  least_conn;
  server prometheus-ha-1:9090 max_fails=3 fail_timeout=30s;
  server prometheus-ha-2:9090 max_fails=3 fail_timeout=30s;
}

server {
  listen 9090;
  location / {
    proxy_pass http://prometheus_ha;
    proxy_set_header Host $host;
  }
}

然后在 Grafana 中只配置一个数据源：http://prometheus-proxy:9090

✅ 实现透明的负载均衡和故障转移。

---

二、Alertmanager 高可用（集群模式）

Alertmanager 负责告警去重、分组和通知，如果单点运行，一旦宕机将导致：

• ❌ 告警丢失
• ❌ 无法去重，产生告警风暴

Alertmanager 集群模式（Mesh Cluster）

Alertmanager 支持通过 Gossip 协议组成集群，实现：

• ✅ 告警去重（Deduplication）在集群内同步
• ✅ 高可用：任一节点收到告警，其他节点知晓
• ✅ 自动故障转移

✅ 三个 Alertmanager 组成集群，Prometheus 可向任意节点发送告警。

---

1. Alertmanager 集群配置

启动参数（每个节点）

# alertmanager-0
--cluster.peer=alertmanager-0:9094
--cluster.peer=alertmanager-1:9094
--cluster.peer=alertmanager-2:9094
--cluster.listen-address=0.0.0.0:9094

Docker Compose 示例

version: '3'
services:
  alertmanager-0:
    image: prom/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--cluster.listen-address=0.0.0.0:9094'
      - '--cluster.peer=alertmanager-1:9094'
      - '--cluster.peer=alertmanager-2:9094'
    ports:
      - "9093:9093"
      - "9094:9094"

  alertmanager-1:
    image: prom/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--cluster.listen-address=0.0.0.0:9094'
      - '--cluster.peer=alertmanager-0:9094'
      - '--cluster.peer=alertmanager-2:9094'
    ports:
      - "9095:9093"
      - "9096:9094"

  alertmanager-2:
    image: prom/alertmanager
    command:
      - '--config.file=/etc/alertmanager/alertmanager.yml'
      - '--cluster.listen-address=0.0.0.0:9094'
      - '--cluster.peer=alertmanager-0:9094'
      - '--cluster.peer=alertmanager-1:9094'
    ports:
      - "9097:9093"
      - "9098:9094"

✅ 所有节点使用相同的 alertmanager.yml 配置。

---

2. Prometheus 配置发送到集群

# prometheus.yml
alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - 'alertmanager-0:9093'
            - 'alertmanager-1:9093'
            - 'alertmanager-2:9093'

✅ Prometheus 会轮询发送告警，任意 Alertmanager 节点收到后，通过 Gossip 同步到集群。

---

3. Alertmanager 集群工作原理

• Gossip 协议：节点间通过 TCP 端口（默认 9094）交换状态
• 去重：告警哈希值在集群内广播，避免重复通知
• Leader Election：选举主节点处理某些操作（如静默）
• 数据持久化：静默（Silences）和抑制（Inhibitions）存储在本地，通过 Gossip 同步

---

三、Prometheus HA 的局限性

问题	说明	解决方案
数据不一致	两个 Prometheus 可能抓取时间略有偏差	使用 external_labels 区分来源（不推荐）
无全局视图	无法聚合两个实例的数据	使用 Thanos 或 Cortex 实现联邦
存储有限	本地 TSDB 不支持无限扩展	结合对象存储（S3/GCS）
配置同步	需确保两个实例配置一致	使用 GitOps、ConfigMap

✅ 对于更高级的 HA 和长期存储需求，应使用 Thanos 或 Cortex。

---

四、高级 HA 方案（进阶）

方案	说明
Thanos	基于对象存储的全局查询、长期存储、高可用
Cortex / Mimir	多租户、水平扩展的 Prometheus-as-a-Service
VictoriaMetrics	高性能、低成本的 Prometheus 兼容存储

✅ 适用于大规模、多集群、长期存储场景。

---

五、最佳实践总结

✅ Prometheus Server HA 推荐做法

实践	说明
运行 两个实例	最简单有效的 HA
配置 完全相同	包括 scrape_configs、rules、alertmanagers
使用 反向代理 接入 Grafana	实现透明故障转移
监控 Prometheus 自身状态	up{job="prometheus"}

---

✅ Alertmanager 集群最佳实践

实践	说明
至少 3 个节点	避免脑裂
跨可用区部署	提升容灾能力
使用 持久化存储	保存 silences/inhibitions
定期备份 data/ 目录	防止数据丢失
配置 反向代理 供 Prometheus 访问	负载均衡

---

六、总结

Prometheus 高可用的核心是 冗余 + 集群：

组件	HA 方案
Prometheus Server	双实例并行抓取
Alertmanager	3 节点 Gossip 集群
Grafana	通过反向代理接入多个 Prometheus

黄金法则：

“不要让监控系统本身成为单点故障。”

通过实施基本的 HA 方案，你可以构建一个稳定、可靠、可维护的监控体系，确保在任何故障情况下，你的告警和可视化能力依然可用。

📌 生产环境必须部署 HA，即使是小规模系统。