prometheus高可用需分层实现：采集层双实例冗余、联邦层仅聚合关键指标、存储层分离热冷数据、告警层alertmanager集群化，各层协同保障采集不断、查询不垮、告警不漏、数据不丢。
Prometheus 本身不内置集群能力，所谓“高可用”不是靠它自己变成一个分布式数据库，而是通过合理分层、冗余部署和协同组件共同实现的。核心目标是：采集不断、查询不垮、告警不漏、数据不丢。
本地采集层：双实例 + 一致配置
单个 Prometheus 实例挂掉，监控就断档——这是最常见故障点。解决办法是在每个业务集群或监控域内部署至少两个完全相同的 Prometheus 实例：
- 两者使用完全一致的 scrape_configs，同时拉取同一组 targets（如所有 Pod、Node、Exporter）；
- 启用 remote_write，将采集数据实时写入共享后端（如 Thanos Sidecar、VictoriaMetrics 或对象存储）；
- 前端用 Service（K8s）或 HAProxy/Nginx 做负载均衡，对外暴露统一查询地址；
- Alertmanager 必须以集群模式运行（
--cluster.advertise-address），避免重复告警或漏发。
联邦层：只聚合关键指标，不替代冗余
联邦（Federation）不是高可用的“开关”，而是用于跨集群汇总视图的协作机制。global Prometheus 从各 worker 拉取指标，但仅限于：
-
少量高价值指标，例如：
{__name__=~"up|probe_success|job:rate1m:sum|alert_status"}； - 设置
scrape_interval ≥ 30s，避免对 worker 施加额外压力； - 开启
honor_labels: true，保留原始 job/instance 标签，方便定位问题来源； - worker 的
/federate接口默认只返回最近 5 分钟数据，无需额外 TTL 配置。
存储与查询层：分离热数据与冷数据
本地 TSDB 只存近期热数据（建议保留 15–30 天），长期数据必须外移：
- 通过 remote_write 将指标同步到远程存储（Thanos、VictoriaMetrics、InfluxDB 等）；
- Thanos Query 或 VictoriaMetrics 的全局查询网关，可聚合多个 Prometheus 实例的数据，提供统一查询入口；
- 若使用 Thanos，推荐搭配 Sidecar 模式，自动上传 block 到对象存储，并支持去重、降采样与跨集群查询。
告警与可视化：统一入口 + 容错路由
告警不能依赖单点，可视化也不能只连一个 Prometheus：
- Alertmanager 至少部署 3 个副本，通过 gossip 协议组成集群，任意节点宕机不影响告警路由；
- Grafana 数据源应配置为 Thanos Query 或 VictoriaMetrics 查询地址，而非直连某个 Prometheus 实例；
- 告警规则建议放在 Git 中管理，配合 Prometheus Operator 自动同步更新，避免配置漂移。
不复杂但容易忽略。真正稳的高可用，不在“多跑几个实例”，而在每一层都明确谁负责什么、谁备份谁、数据流向是否闭环。
