17.8.1 Prometheus高可用架构模式与部署拓扑

Prometheus 高可用架构的核心目标是避免单点故障、提升采集与查询可用性，并为长期存储与多集群扩展奠定基础。本节给出可落地的 HA 模式、部署拓扑、安装与验证、排错与练习。

1. 原理草图与架构模式#

HA Pair（双实例冗余）：同一目标被两套 Prometheus 抓取，保证采集可用。
Federation 分层：下层采集、上层聚合，降低全局压力。
远端存储接入：Thanos/Cortex/VictoriaMetrics 实现去重与长期存储。

2. 双实例冗余（HA Pair）部署示例#

2.1 安装（两台 Prometheus 节点）#

假设两台主机：10.0.0.11、10.0.0.12，系统为 Linux。

# 1) 安装 Prometheus
useradd -r -s /sbin/nologin prometheus
mkdir -p /opt/prometheus /etc/prometheus /var/lib/prometheus
cd /opt/prometheus
curl -LO https://github.com/prometheus/prometheus/releases/download/v2.48.0/prometheus-2.48.0.linux-amd64.tar.gz
tar -xf prometheus-2.48.0.linux-amd64.tar.gz
cp -a prometheus-2.48.0.linux-amd64/{prometheus,promtool} /usr/local/bin/
cp -a prometheus-2.48.0.linux-amd64/consoles /etc/prometheus/
cp -a prometheus-2.48.0.linux-amd64/console_libraries /etc/prometheus/

# 2) 生成统一配置（两台一致，仅 external_labels 变化）
cat >/etc/prometheus/prometheus.yml <<'EOF'
global:
  scrape_interval: 15s
  external_labels:
    cluster: "prod"
    replica: "A"   # 另一台改为 B
scrape_configs:
  - job_name: "node"
    static_configs:
      - targets: ["10.0.0.21:9100","10.0.0.22:9100"]
EOF

# 3) 创建 systemd 服务
cat >/etc/systemd/system/prometheus.service <<'EOF'
[Unit]
Description=Prometheus
After=network.target

[Service]
User=prometheus
Group=prometheus
ExecStart=/usr/local/bin/prometheus \
  --config.file=/etc/prometheus/prometheus.yml \
  --storage.tsdb.path=/var/lib/prometheus \
  --web.listen-address=:9090
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now prometheus

命令解释
- external_labels：用于去重（A/B 需不同），同时标识来源。
- --storage.tsdb.path：本地 TSDB 存储路径。
- --web.listen-address：Prometheus 监听端口。

2.2 验证#

# 访问指标状态页面
curl -s http://10.0.0.11:9090/-/healthy
curl -s http://10.0.0.12:9090/-/healthy

# PromQL 测试（指标是否被采集）
curl -G 'http://10.0.0.11:9090/api/v1/query' --data-urlencode 'query=up'

预期：返回 status=success 且 up=1。

3. 分层架构（Federation）示例#

3.1 全局 Prometheus 配置#

# /etc/prometheus/prometheus.yml (Global)
global:
  scrape_interval: 30s

scrape_configs:
  - job_name: "federate"
    honor_labels: true
    metrics_path: "/federate"
    params:
      'match[]':
        - '{job="node"}'
        - '{job="kubelet"}'
    static_configs:
      - targets:
        - "10.0.0.11:9090"
        - "10.0.0.12:9090"

命令解释
- metrics_path: /federate：使用联邦接口。
- match[]：定义聚合的指标过滤规则。

3.2 验证联邦#

curl -G 'http://10.0.0.30:9090/api/v1/query' --data-urlencode 'query=up'

预期：能看到来自多个实例的 up 指标。

4. 远端存储接入示例（Thanos Sidecar）#

4.1 Prometheus 启动参数增加外部标签（去重关键）#

global:
  external_labels:
    cluster: "prod"
    replica: "A"

4.2 Thanos Sidecar 启动（示例）#

# 假设 Thanos 二进制已安装
thanos sidecar \
  --tsdb.path=/var/lib/prometheus \
  --prometheus.url=http://127.0.0.1:9090 \
  --objstore.config-file=/etc/thanos/objstore.yml \
  --http-address=0.0.0.0:10902 \
  --grpc-address=0.0.0.0:10901

预期效果：Thanos Querier 可查询到多副本数据，并按 external_labels 去重。

5. 关键排错思路与命令#

5.1 抓取失败排错#

# 查看 Prometheus 目标状态
curl -s http://10.0.0.11:9090/api/v1/targets | jq '.data.activeTargets[] | {scrapeUrl,health,lastError}'

常见原因：
- Connection refused：目标服务未启动或端口未开放
- context deadline exceeded：网络不通或超时

5.2 配置语法检查#

promtool check config /etc/prometheus/prometheus.yml

5.3 时间同步问题#

timedatectl status
# NTP 修复（示例）
sudo chronyc -a makestep

说明：HA 与去重依赖时间一致性，时间漂移会造成告警抖动。

6. 练习与实战任务#

搭建 HA Pair：两台 Prometheus 指向同一组 Node Exporter，验证 up 指标一致。
实现 Federation：新增全局 Prometheus，聚合 node 指标并在 Grafana 上展示。
模拟故障切换：停止 A 实例 systemctl stop prometheus，验证 B 实例继续采集。
远端存储实验：接入 Thanos Sidecar，验证去重与历史查询。

7. 关键实施要点#

external_labels 必须统一且区分副本（replica=A/B）。
Alertmanager 推荐集群部署并配置 --cluster.listen-address。
查询层可通过 Nginx/HAProxy 负载均衡统一入口。
NTP 必须全链路统一，避免时间漂移导致指标错位。