如何实现 Prometheus 的高可用和联邦架构？
Prometheus 本身是单机架构，不内置集群能力。生产环境中，单点 Prometheus 面临两个核心风险：实例宕机导致监控盲区，单机存储和采集能力无法支撑大规模集群。解决思路分两条线——高可用保证不丢数据不中断，联邦架构保证能横向扩展。
高可用方案：从简单到可靠
多副本冗余
最直接的方式是部署两个或更多 Prometheus 实例，配置完全相同的目标列表。它们各自独立采集、独立存储、独立告警。查询时通过负载均衡（如 Nginx、HAProxy）将请求分散到不同实例。
优点是部署简单，缺点是每个实例都存全量数据，存储成本翻倍，且两个实例的告警可能同时触发造成重复通知。需要配合 Alertmanager 的 cluster 模式做告警去重。
Thanos 方案：高可用的标准答案
Thanos 在 Prometheus 之上增加四个核心组件，解决长期存储和全局查询问题：
- Sidecar：与 Prometheus 部署在同一 Pod，每隔 2 小时将 TSDB 块上传到对象存储（S3/OSS），同时提供 StoreAPI 让 Query 组件直接读取 Prometheus 的近端数据
- Store Gateway：从对象存储中读取历史数据块，响应 Query 的查询请求
- Query：聚合多个数据源（Sidecar + Store Gateway），对外提供统一的 PromQL 查询接口，自动去重 HA 副本的数据
- Compact：对对象存储中的历史块做降采样和合并，减少存储占用和查询扫描量
数据流：Prometheus 采集 → Sidecar 上传到对象存储 → Query 同时查询 Sidecar（热数据）和 Store Gateway（冷数据）→ 返回合并结果。Query 的 --deduplicate 参数会基于 replica label 自动去重，解决多副本数据重复问题。
关键配置：每个 Prometheus 实例必须设置不同的 external_labels（如 replica: A / replica: B），这是 Query 去重的依据。
联邦架构：横向扩展的分层设计
联邦是 Prometheus 原生的数据汇总机制。每个 Prometheus 实例暴露 /federate 端点，上级 Prometheus 可以像抓取 Exporter 一样从该端点拉取指标。
层级联邦
典型三层架构：
- 边缘层（Edge）：每个集群部署独立的 Prometheus，采集本集群所有目标的详细指标，scrape_interval 设为 15s
- 区域层（Regional）：从多个边缘实例拉取聚合后的指标（通过 recording rules 预聚合），scrape_interval 放宽到 30-60s
- 全局层（Global）：汇总所有区域的关键指标，用于跨集群看板和全局告警
关键点：上级不需要拉取全量指标，通过 match[] 参数只拉取需要的指标，大幅降低数据量。
联邦配置示例
scrape_configs: - job_name: 'federate' scrape_interval: 30s honor_labels: true metrics_path: '/federate' params: 'match[]': - '{job="prometheus"}' - '{__name__=~"job:.*"}' static_configs: - targets: - 'edge-prometheus-cluster1:9090' - 'edge-prometheus-cluster2:9090'
honor_labels: true 确保源实例的标签不被覆盖，避免数据来源混淆。match[] 只拉取 job="prometheus" 和 recording rules 产生的聚合指标，而非全量 raw metrics。
跨服务联邦
另一种场景：不同的 Prometheus 分别监控不同业务域（基础设施、中间件、业务应用），通过联邦在全局实例上汇聚跨域指标，做关联分析和统一看板。与层级联邦不同，这里不是按地域分层，而是按功能域分片。
Thanos vs Cortex vs VictoriaMetrics：如何选择
Thanos
适合中大规模（10-100 个集群），核心优势是与原生 Prometheus 无缝集成——现有 Prometheus 不需要改动，加 Sidecar 即可。依赖对象存储做长期持久化，Query 组件天然支持 HA 去重。缺点是组件多、运维复杂度高，Query 查询冷数据时延迟较大（需要从对象存储加载块）。
Cortex
适合多租户场景（SaaS 平台、大型组织内部多团队共用）。完全分布式架构，数据写入和查询都可以水平扩展，通过分布式 kv-store（Consul/etcd）做成员管理。支持多租户隔离，每个租户有独立的速率限制和存储策略。但部署和运维门槛最高，需要依赖多个基础设施组件。
VictoriaMetrics
适合性能优先、资源有限的场景。单二进制即可部署（也支持集群模式），兼容 Prometheus 的查询和采集协议，可以直接替换 Prometheus。写入和查询性能优于 Prometheus，内存占用更低。缺点是生态不如 Thanos 成熟，高级特性（如多租户）需要在集群版中才能使用。
决策参考
| 规模 | 推荐方案 | 理由 |
|---|---|---|
| 1-5 个集群 | 多副本 + 负载均衡 | 运维最简，够用 |
| 5-50 个集群 | Thanos | 生态成熟，HA + 长期存储一体化 |
| 多租户需求 | Cortex | 原生多租户支持 |
| 性能优先/资源紧张 | VictoriaMetrics | 低资源高吞吐 |
生产环境注意事项
数据持久化：Prometheus 默认数据存在本地磁盘，实例销毁数据即丢失。必须配置远程写入（remote_write）到外部存储，或使用 Thanos Sidecar 定期上传到对象存储。
监控的监控：Prometheus 自身的健康状态需要有独立的监控方案。常见做法是用一个轻量级 Prometheus 或 Grafana Agent 监控主 Prometheus 的 up 指标和采集延迟。
告警去重：多副本部署下，两个实例会触发相同告警。必须配置 Alertmanager 集群模式，并设置 group_by 包含告警名称和关键标签，确保同一告警只通知一次。
联邦的性能开销：每增加一层联邦，上级实例的内存增加约 5%。全局 Prometheus 的资源规划要预留余量，特别是当边缘集群数量超过 50 个时。
逐步上线：先在测试环境验证联邦配置和 match[] 规则是否符合预期，确认数据量和延迟在可接受范围内，再推广到生产环境。