Prometheus高可用通过分层协同实现：采集层双实例并行抓取+remote_write至远程存储；存储层本地仅保留热数据，长期依赖Thanos等远程存储；查询层联邦拉取关键指标；告警层Alertmanager集群化+抑制规则防风暴。
Prometheus 本身不支持原生集群，高可用不是靠它“变成分布式数据库”，而是通过分层协同设计来避免单点故障——采集不断、查询不垮、告警不漏、数据不丢。
采集层：双实例并行抓取 + 统一写入后端
单个 Prometheus 实例宕机，监控就断档。必须在每个业务域或集群内部署至少两个配置完全一致的实例：
- 两者使用相同的
scrape_configs，同时拉取同一组 targets（如所有 Pod、Node、Exporter）； - 都启用
remote_write，将数据实时推送到共享远程存储（如 Thanos、VictoriaMetrics 或 TDengine）； - 前端用 Service（K8s）或 Nginx/HAProxy 做负载均衡，对外暴露统一查询地址；
- Alertmanager 必须以集群模式运行（
--cluster.advertise-address），防止重复告警或漏发。
存储层：本地只留热数据，长期依赖远程存储
本地 TSDB 易丢数、难扩容、重启慢，不能承担长期可靠性：
- 设置
storage.tsdb.retention.time: 4h或最多 24h，仅保留近期热数据； - 关闭过长本地保留（如 90d），否则会拖慢启动和 WAL 清理；
- 通过
remote_write将指标持续推送至 Thanos Receiver、VictoriaMetrics 等，利用对象存储实现无限保留与全局查询； - 远程存储还支持自动 compaction、跨实例查、降本增效，是稳定性的基础保障。
查询与聚合层：联邦只拉关键指标，不替代冗余
联邦（Federation）不是高可用开关，而是用于跨集群汇总视图的协作机制：
- 顶层 Prometheus 从各 worker 拉取少量高价值指标，例如：
{__name__=~"up|probe_success|job:rate1m:sum"}； - 设置
scrape_interval ≥ 30s，避免对 worker 施加额外压力； - 开启
honor_labels: true，保留原始 job/instance 标签，方便定位问题来源； - worker 的
/federate接口默认只返回最近 5 分钟数据，无需额外 TTL 配置。
告警层：Alertmanager 集群化 + 抑制规则防风暴
告警系统自身也必须高可用，否则监控“看得见却没人管”：
- Alertmanager 至少部署 3 个节点，用
--cluster.advertise-address组成 gossip 集群； - 配置
group_by: [alertname, job]和inhibit_rules，抑制同源重复告警（比如双采导致的相同故障触发两次）； - 告警路由按团队/环境分级，关键路径（如 etcd leader 变更、apiserver 5xx）设高优先级通道；
- 所有告警规则应基于 recording rules 预计算，降低查询时负载，提升触发稳定性。
