prometheus高可用核心是分层设计：采集层冗余（多实例联邦）、存储层持久（remote_write至thanos/victoriametrics）、查询层聚合（federate拉取关键指标）、告警层分离（alertmanager集群）。
Prometheus 本身不自带集群能力，单实例部署存在单点故障和存储瓶颈，稳定性依赖合理配置高可用架构与数据保留策略。关键不是“堆机器”，而是分层设计：采集层冗余、存储层持久、查询层聚合、告警层分离。
多实例联邦：最实用的高可用模式
这是生产环境推荐的轻量级高可用方案，适合中小到中大规模场景。核心思路是多个 Prometheus 实例并行采集，再由一个顶层实例做联邦聚合，避免单点失效。
- 底层 Prometheus（Worker）各自独立采集子集目标，例如按集群、区域或业务线划分，配置 external_labels 标识来源，如
region: "shanghai"或cluster: "prod-k8s-01" - 顶层 Prometheus（Primary）通过 federation 定期拉取各 Worker 的关键指标（非全量），路径为
/federate?match[]=...，只拉聚合后指标（如sum by(job)(rate(http_requests_total[5m]))），降低带宽压力 - Worker 实例建议至少部署 2 个，相同目标可被双采，即使一个宕机，监控数据不断；但注意避免重复告警，需在 Alertmanager 中用 group_by + inhibit_rules 抑制同源告警
远程存储：解决本地存储不可靠问题
本地 TSDB 虽快但易丢数、难扩容，长期运行必须对接远程存储。这不是“可选优化”，而是稳定性的基础保障。
- 启用 remote_write 将指标实时推送至 Thanos Receiver、VictoriaMetrics 或 Cortex。以 Thanos 为例，在 Prometheus 配置中添加：
- url: "http://thanos-receiver:19291/api/v1/write"
queue_config:
max_samples_per_send: 10000
max_shards: 10
- 远程存储支持无限时长保留（如对象存储 S3）、跨实例查全局视图、自动 compaction 降本增效。本地只需保留最近 2–4 小时热数据，既减轻磁盘压力，又提升查询响应
- 务必关闭本地 storage.tsdb.retention.time 的过长设置（如 90d），否则会拖慢启动和清理，建议设为
4h或24h，让远程承担长期存储职责
数据保留与采集精简：从源头控稳
稳定性问题常源于“什么都采”，而非配置不当。控制采集范围和保留周期，比后期调优更有效。
- 删除无效 job：检查
scrape_configs，移除已下线服务、测试环境、无意义的 debug 目标。每个多余 job 增加 CPU/内存开销和 WAL 写入压力 - 调低非关键指标抓取频率：基础设施类（如 Node Exporter）可设为
scrape_interval: 60s；业务指标按 SLA 设定，如支付成功率用30s，后台批处理用300s - 限制标签基数：避免用
user_id、request_id等高基数字段做 label。改用user_type="vip"或env="prod"这类低基数维度，防止 series 数爆炸拖垮 TSDB
告警与查询分离：防止单点过载
Alertmanager 和 Prometheus Server 必须独立部署，且 Alertmanager 要多副本。否则告警风暴会直接压垮 Prometheus 查询接口。
- Alertmanager 至少部署 3 副本，通过 cluster.peer 参数组成集群，实现告警去重、静默同步和高可用路由
- Grafana 查询应直连 Alertmanager 或 Thanos Query，而非直接查 Prometheus Server；对历史数据或大范围聚合，强制走远程读（remote_read）
- 禁用 Prometheus 自带的 UI 查询入口（
--web.enable-admin-api关闭），防止误操作触发全量扫描式 PromQL，引发 OOM
