4. Prometheus 部署与高可用方案：单机部署、Thanos 架构、VictoriaMetrics 对比、联邦集群
在生产环境中，Prometheus 的部署架构直接决定了监控系统的可靠性、数据持久性和查询性能。本章从单机部署入手，逐步深入联邦集群、Thanos 与 VictoriaMetrics 三种主流高可用方案，帮助你在不同规模场景下做出合理选型。
4.1 单机部署：快速搭建与资源评估
单机部署适用于小规模测试环境或节点数少于 50 的轻量场景。Prometheus 以二进制或容器方式运行，所有数据存储在本地磁盘。
关键参数：
--storage.tsdb.retention.time：默认 15d，建议根据磁盘容量调整。--storage.tsdb.retention.size：限制 TSDB 最大磁盘占用，超过后自动删除旧数据。--storage.tsdb.path：数据存储路径，建议使用独立 SSD 或高性能云盘。
# 使用 docker 快速启动单机 Prometheus
docker run -d \
--name prometheus \
-p 9090:9090 \
-v /data/prometheus:/prometheus \
-v /etc/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus:v2.53.0 \
--config.file=/etc/prometheus/prometheus.yml \
--storage.tsdb.retention.time=30d \
--storage.tsdb.retention.size=50GB
单机局限： 单点故障、存储容量有限、查询性能随数据量增长急剧下降。当采集目标超过 200 个或每秒样本数超过 10 万时，必须考虑高可用方案。
4.2 联邦集群：水平扩展与多级聚合
联邦集群（Federation）是 Prometheus 原生支持的扩展方案，通过分层架构将采集压力分散到多个子 Prometheus，再由全局 Prometheus 聚合关键指标。
最佳实践： 联邦集群适合按地域、业务线或机房维度拆分。全局层只拉取
up、node_cpu_seconds_total、http_requests_total 等核心指标，避免全量数据重复传输。
4.3 Thanos 架构：长期存储与全局视图
Thanos 在 Prometheus 之上构建了高可用、无限存储和全局查询的能力。核心组件包括 Sidecar、Store Gateway、Compactor、Query 和 Receiver。
| 组件 | 职责 | 部署方式 |
|---|---|---|
| Sidecar | 与 Prometheus 同 Pod 部署，将本地数据上传到对象存储，并提供 /federate 端点 | 每个 Prometheus 实例旁挂载 |
| Store Gateway | 从对象存储读取历史数据，暴露 StoreAPI 供 Query 查询 | 独立部署，可水平扩展 |
| Compactor | 对对象存储中的 TSDB 块进行压缩、降采样和清理 | 单实例或主备 |
| Query | 接收 PromQL 查询，合并 Sidecar 和 Store Gateway 的结果，返回全局视图 | 无状态，可水平扩展 |
| Receiver | 接收远程写入数据，替代 Sidecar 模式，适合无 Prometheus 的场景 | 可选组件，按需部署 |
Thanos 优势：
- 无限存储：历史数据存入对象存储，本地只保留短期热数据。
- 全局查询：通过 Thanos Query 跨集群聚合指标，无需手动切换数据源。
- 降采样：Compactor 自动生成 5m/1h 粒度的降采样数据，加速大范围查询。
4.4 VictoriaMetrics：高性能替代方案
VictoriaMetrics 是专为 Prometheus 兼容性设计的高性能时序数据库，在写入吞吐、查询速度和资源占用方面显著优于原生 Prometheus。
| 对比维度 | Prometheus 单机 | Thanos | VictoriaMetrics |
|---|---|---|---|
| 写入吞吐 | 约 50 万样本/秒 | 受 Sidecar 和对象存储延迟影响 | 约 200 万样本/秒（单节点） |
| 存储压缩比 | 1:1.3（原始） | 1:3（对象存储） | 1:5 ~ 1:10 |
| 查询延迟（30天范围） | 高（需全量扫描） | 中（依赖 Store Gateway） | 低（索引优化 + 预聚合） |
| 部署复杂度 | 低 | 高（5+ 组件） | 中（单二进制或集群） |
| 高可用方案 | 无原生支持 | Sidecar + 对象存储 | vmselect/vminsert 多副本 + 共享存储 |
| PromQL 兼容性 | 完全兼容 | 完全兼容 | 99% 兼容（少数边缘函数有差异） |
选型建议：
- 已有 Prometheus 生态且需要长期存储 → Thanos（兼容性最好，迁移成本低）。
- 大规模集群（>500 节点）且对查询性能敏感 → VictoriaMetrics（资源占用低，查询快）。
- 中小规模且预算有限 → 联邦集群（零额外组件，原生支持）。
4.5 高可用方案对比总结
| 方案 | 数据持久性 | 查询性能 | 运维成本 | 适用规模 |
|---|---|---|---|---|
| 单机部署 | 低（本地磁盘） | 中等 | 低 | < 50 节点 |
| 联邦集群 | 低（依赖子节点） | 中等 | 中 | 50 - 200 节点 |
| Thanos | 高（对象存储） | 良好 | 高 | 200 - 1000 节点 |
| VictoriaMetrics | 高（多副本） | 优秀 | 中 | 500 - 5000+ 节点 |
避坑提醒：
- 联邦集群不要超过 3 层，否则查询延迟和配置复杂度会指数级上升。
- Thanos 的 Compactor 必须独占资源，避免与 Query 或 Store Gateway 混部导致 OOM。
- VictoriaMetrics 的 vmstorage 节点之间不共享数据，扩容时需要重新分片，建议初始规划好分片数。