prometheus演进路径为：单机部署→高可用双副本+远程写入→联邦架构→thanos/victoriametrics。单机适合小规模；双副本提升可靠性；联邦按维度分片支撑千节点；thanos等提供统一查询与长期存储，适配大规模多租户场景。
Prometheus 从单机起步，走向大规模集群监控，并不是简单堆机器，而是围绕数据规模、可用性、运维效率三个核心问题逐步演进。关键在于每一步扩展都解决一个具体瓶颈，而不是提前过度设计。
单机部署：适合小规模、固定环境
初始阶段直接运行一个 Prometheus 实例，配置 static_configs 或少量 file_sd 即可覆盖几十个目标。它的优势是轻量、易调试、无依赖。但局限也很明确：存储受限于本地磁盘，查询随数据增长明显变慢，且单点故障无法避免。当指标基数超过 10 万、日增数据超 5GB 时，就该考虑下一步了。
高可用双副本 + 远程写入：解决可靠性与存储压力
为规避单点风险，常见做法是部署两个配置一致的 Prometheus 实例，各自独立采集并写入远端存储（如 Thanos Receiver、VictoriaMetrics 或 Cortex）。Alertmanager 负责统一处理告警，避免重复通知。这种方式不提升采集能力，但保障了数据不丢、服务不中断。注意两点：两个实例不能共用同一份本地存储；远程写入需开启 remote_write 并配置重试策略和队列大小。
联邦架构：按维度分片，支撑千节点级集群
当单个 Prometheus 实例无法承载全部指标时，联邦（Federation）成为主流选择。通常采用分层结构：下层按业务或区域部署多个“采集层”Prometheus（如每个 Kubernetes 集群一个），只保留短期高频指标；上层“聚合层”通过 federate 接口定期拉取关键聚合指标（如 sum by(job) (http_requests_total)）。这种模式降低单实例压力，也便于权限隔离和故障域划分。但要注意：联邦只适合汇总型查询，原始明细数据仍需保留在下层。
Thanos 或 VictoriaMetrics：统一查询+长期存储的现代化替代
联邦虽有效，但查询需手动指定目标、缺乏全局视图。Thanos 和 VictoriaMetrics 提供了更完整的解决方案：通过对象存储（如 S3、MinIO）保存历史数据，Sidecar 组件将本地 TSDB 与远端存储打通，Querier 统一聚合所有数据源结果。它们支持跨集群、跨地域的无缝查询，自动去重、降采样和生命周期管理。对于 3000+ 节点、多租户、需要保留 6 个月以上指标的企业，这是目前最主流的生产级架构。
