Prometheus 高可用部署方案：集群架构及冗余配置

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 自动同步更新，避免配置漂移。

不复杂但容易忽略。真正稳的高可用，不在“多跑几个实例”，而在每一层都明确谁负责什么、谁备份谁、数据流向是否闭环。