Prometheus联邦集群不提供服务冗余，仅实现分层数据聚合；高可用需本地双实例采集+联邦汇总+统一查询入口三层配合，推荐结合Thanos构建生产级稳态方案。
搭建 Prometheus 联邦集群本身不直接提供服务冗余，它解决的是数据分层聚合与跨集群管理问题；若目标是“采集不中断、查询不断联、告警不丢失”，需明确区分：联邦 ≠ 高可用（HA），而是高可用架构中的一种协同模式。真正实现冗余，要靠“本地多实例采集 + 联邦汇总 + 统一查询入口”三层配合。
联邦集群的核心定位：分层采集，不是故障接管
联邦（Federation）本质是“上游拉取下游指标”的单向数据汇聚机制。典型结构是：多个 worker Prometheus（部署在各业务集群/区域）各自独立采集、存储、评估规则；一个 global/federate Prometheus 定期从它们的 /federate 接口拉取关键指标（如 up、http_requests_total、自定义业务成功率等），用于全局视图和跨集群告警。
这意味着：
- worker 实例宕机，global 仍可工作——但只影响该 worker 对应的局部数据，不影响其他 worker 数据展示；
- global 实例宕机，所有 worker 仍正常采集、告警、存储——只是全局视图和集中告警暂时不可用；
- worker 之间互不备份，也不同步数据，所以不能靠联邦本身避免单点采集失败。
真正实现采集层冗余：每个 worker 都要双实例
要在某个集群内做到“哪怕一台 Prometheus 挂了，监控数据也不丢”，必须在每个 worker 层部署至少两个 Prometheus 实例，且配置完全一致：
- 相同
scrape_configs，同时拉取同一组 targets（如全部 Pod、Node、Exporter）； - 启用
remote_write同步到共享后端（如 VictoriaMetrics、Thanos 对象存储），或通过 Thanos Sidecar 实现数据去重与统一查询； - 前端加 HAProxy/Nginx 或 Kubernetes Service 做负载均衡，对外暴露统一查询地址；
- Alertmanager 必须部署为集群（
--cluster.advertise-address），防止同一告警被重复发送。
联邦配置要点：只拉关键指标，避免性能反噬
global 实例若盲目拉取全部指标，会引发严重性能问题。务必严格控制联邦范围：
- 使用
params.match[]精确匹配，例如：'{__name__=~"up|probe_success|job:rate1m:sum|alert_status"}'； - 设置合理
scrape_interval（建议 ≥30s），避免高频拉取加重 worker 压力； - 开启
honor_labels: true，保留原始 job/instance 标签，便于溯源； - worker 实例的
/federate接口默认只暴露最近 5 分钟数据，无需额外配置 TTL。
推荐组合架构：联邦 + Thanos（生产级稳态方案）
单独联邦难扛大规模场景，推荐搭配 Thanos 构建完整高可用链路：
- 每个 worker 部署 Prometheus + Thanos Sidecar → 数据自动上传至对象存储（S3/GCS）；
- Sidecar 同时提供 gRPC 接口，供 Thanos Query 查询实时数据；
- Thanos Query 聚合所有 Sidecar 和对象存储历史数据，对外提供统一查询 API；
- global 层可退化为一个轻量级 Prometheus，仅用于联邦拉取 + 全局告警规则，不再承担存储压力。
这种结构既保障了每个区域的采集冗余，又实现了全局数据可查、长期可存、故障隔离，是当前云原生环境最主流的落地方式。
