高可用与长期存储

Prometheus 单节点简单可靠，但节点、磁盘、进程或配置故障都会造成采集与告警盲区。本章说明常见高可用和长期存储方案，重点是明确数据保留、查询范围、故障切换和运维成本。

1. 单节点问题

单 Prometheus 的风险包括实例故障、数据盘故障、配置误发布、长时间 WAL 重放和查询负载挤占规则评估。将其放在高配置机器上只能降低概率，不能消除单点。

2. 双 Prometheus 方案

两个副本使用相同抓取配置，独立抓取同一批目标，并通过不同 replica 外部标签区分：

global:
  external_labels:
    cluster: production-a
    replica: prometheus-a

任意一台故障时，另一台继续采集和发送告警；Alertmanager 应依据告警标签去重。两副本可能因网络、服务发现和配置重载时机不同而产生轻微数据差异，不能假设每个样本完全一致。

3. Federation

Federation 让上层 Prometheus 从下层 Prometheus 抓取经过筛选或聚合的时间序列。它适合分层汇总、跨团队边界和区域级概览，不适合把所有原始数据无选择地级联上送。

scrape_configs:
  - job_name: federate
    honor_labels: true
    metrics_path: /federate
    params:
      match[]:
        - '{__name__=~"job:.*"}'
    static_configs:
      - targets: [regional-prometheus.internal:9090]

Federation 前先通过 Recording Rule 确定上送口径，避免中心实例被原始高基数序列压垮。

4. Thanos

Thanos 通过 Sidecar、对象存储、Store Gateway、Compactor、Query 和 Ruler 等组件为 Prometheus 提供长期存储、全局查询和副本去重。适合已有 Prometheus 生态、需要对象存储和多集群统一查询的团队。

代价是对象存储、组件版本兼容、下采样、Compactor 单例和网络权限的额外运维。上线前必须演练对象存储不可用、副本去重、查询回退和数据恢复。

5. VictoriaMetrics

VictoriaMetrics 提供 Prometheus 兼容写入和查询接口，可作为单机或集群时序存储与查询后端。它适合希望降低时序存储资源消耗、使用 PromQL 兼容接口并进行长期保留的场景。

迁移前应验证 PromQL 兼容性、标签/租户模型、Remote Write 队列、备份恢复、告警规则执行位置和 Grafana Dashboard。不要只做吞吐压测，还要验证典型长时间范围查询与故障恢复。

6. 长期存储设计

需求	常见选择	必须验证
近期单集群监控	本地 Prometheus TSDB	容量、备份、单点与恢复时间
多层汇总	Federation	上送指标口径、标签冲突、中心容量
多集群全局查询	Thanos / Mimir / Cortex	副本去重、对象存储、租户与查询延迟
高压缩长期保留	VictoriaMetrics	兼容性、备份、集群拓扑与访问控制

先定义查询保留期、允许丢失窗口、恢复目标和预算，再选系统。架构复杂度应与实际规模和业务风险匹配。