4. 多集群监控架构设计：全局视图 vs 联邦集群、Thanos/Cortex/VictoriaMetrics 选型对比、数据隔离与租户模型
随着企业基础设施从单集群向多集群、多区域演进，Prometheus 原生架构在全局聚合、长期存储和多租户隔离方面暴露出明显短板。本章从架构设计视角出发，系统对比全局视图与联邦集群的适用场景，深入分析 Thanos、Cortex、VictoriaMetrics 三大主流方案的选型差异，并给出数据隔离与租户模型的最佳实践。
4.1 全局视图 vs 联邦集群：两种聚合策略
多集群监控首先需要解决“如何从分散的 Prometheus 实例中获取统一视图”的问题。目前主流方案分为两类：Prometheus 联邦集群（Hierarchical Federation）和全局视图层（Global View Layer）。
| 对比维度 | Prometheus 联邦集群 | 全局视图层（Thanos/Cortex/VM） |
|---|---|---|
| 架构模式 | 树形层级拉取 | Sidecar/Agent 推送或拉取 + 统一查询 |
| 数据流向 | 子 Prometheus → 父 Prometheus | Prometheus → 对象存储 / 长期存储 |
| 全局查询 | 仅聚合预定义的 up 指标 | 支持任意 PromQL 跨集群查询 |
| 存储扩展 | 受限于父节点本地磁盘 | 无限扩展（对象存储） |
| 高可用 | 父节点单点故障风险 | 无状态查询 + 多副本 |
| 适用场景 | 小规模、同区域、指标量 < 50 万 | 大规模、多区域、长期存储需求 |
4.2 Thanos / Cortex / VictoriaMetrics 选型对比
全局视图层目前有三个主流开源方案：Thanos、Cortex 和 VictoriaMetrics（VM）。三者都解决了 Prometheus 的长期存储和全局查询问题，但在架构复杂度、多租户能力和运维成本上存在显著差异。
| 对比维度 | Thanos | Cortex | VictoriaMetrics |
|---|---|---|---|
| 核心组件 | Sidecar / Querier / Store / Compactor / Ruler | Distributor / Ingester / Querier / Compactor | vmstorage / vmselect / vminsert / vmagent |
| 存储后端 | 对象存储（S3/GCS/MinIO） | 对象存储 + 本地缓存 | 本地磁盘 + 可选对象存储 |
| 多租户 | 弱（需额外组件） | 原生支持（租户 ID 隔离） | 企业版支持；开源版需自行实现 |
| 查询性能 | 中等（依赖对象存储延迟） | 中等（Ingester 热数据） | 高（本地磁盘 + 内存索引） |
| 运维复杂度 | 中（组件多，但成熟） | 高（微服务架构，依赖 Consul/ETCD） | 低（单二进制部署） |
| 社区活跃度 | 高（CNCF 毕业） | 中（CNCF 孵化，Grafana 主导） | 高（开源 + 企业版） |
| 典型场景 | 已有 Prometheus 的平滑扩展 | 大规模 SaaS 多租户平台 | 高性能、低运维的监控平台 |
- 如果已有大量 Prometheus 实例，希望最小化改造 → 选择 Thanos，通过 Sidecar 模式无缝接入。
- 如果构建多租户 SaaS 平台，需要原生租户隔离 → 选择 Cortex。
- 如果追求极致性能和低运维成本，集群规模中等（< 1000 节点） → 选择 VictoriaMetrics。
4.3 数据隔离与租户模型
在多集群监控中，数据隔离是安全合规和成本分摊的基础。不同方案对租户模型的支持程度不同，需要根据业务需求选择合适策略。
4.3.1 租户隔离的三种模式
| 隔离模式 | 实现方式 | 优点 | 缺点 |
|---|---|---|---|
| 物理隔离 | 每个租户独立部署 Prometheus + 存储 | 完全隔离，故障域独立 | 资源利用率低，运维成本高 |
| 逻辑隔离 | 共享存储 + 标签/租户 ID 区分 | 资源利用率高，统一管理 | 查询需过滤，存在性能干扰 |
| 混合隔离 | 核心租户物理隔离 + 普通租户逻辑隔离 | 兼顾安全与效率 | 架构复杂，需统一治理 |
4.3.2 基于标签的租户模型（Thanos / VM 方案）
在 Thanos 和 VictoriaMetrics 中，租户隔离通常通过 Label 注入 实现。每个指标在采集时强制注入 tenant_id 或 cluster 标签，查询时通过 PromQL 的 {tenant_id="xxx"} 过滤。
# Prometheus 采集配置示例：注入租户标签
scrape_configs:
- job_name: 'node_exporter'
relabel_configs:
- source_labels: [__address__]
target_label: tenant_id
replacement: 'tenant-a'
- source_labels: [__address__]
target_label: cluster
replacement: 'cluster-01'
# 查询时过滤
rate(node_cpu_seconds_total{tenant_id="tenant-a", cluster="cluster-01"}[5m])4.3.3 Cortex 原生多租户模型
Cortex 在架构层面原生支持多租户。每个请求通过 HTTP Header X-Scope-OrgID 标识租户，Distributor 和 Ingester 根据租户 ID 进行数据分片和隔离。
# 向 Cortex 写入数据时指定租户
curl -H "X-Scope-OrgID: tenant-a" \
-X POST http://cortex-distributor:9009/api/v1/push \
-d '...'
# 查询时同样需要指定租户
curl -H "X-Scope-OrgID: tenant-a" \
"http://cortex-querier:9009/api/v1/query?query=up"Cortex 的租户隔离是存储级隔离：不同租户的数据写入不同的 Ingester 分片和对象存储前缀，查询时 Querier 只扫描对应租户的数据块，性能干扰最小。
4.4 多集群监控架构设计要点总结
- 全局视图优先选择全局视图层方案：联邦集群仅适合小规模场景，生产环境推荐 Thanos 或 VictoriaMetrics。
- 存储选型决定扩展能力：对象存储（S3/MinIO）是长期存储的基础，本地磁盘方案（VM）适合高性能但需规划容量。
- 租户隔离需在架构层规划：Cortex 原生多租户适合 SaaS 平台；Thanos/VM 通过标签隔离，需配合查询路由和权限控制。
- 查询性能与运维复杂度需平衡：VM 性能最优但多租户弱；Cortex 功能全面但运维重；Thanos 折中方案适合大多数企业。