在多云或多集群监控场景下，架构选型直接影响运维成本与数据一致性。如果你的场景是多集群全局查询或需要长期低成本存储，优先选 Thanos；如果是简单的层级数据汇聚且不需要全局视图，Prometheus 联邦可以考虑。
先说结论：Thanos 更适合云原生多集群统一监控与长期存储，联邦方案适合简单的层级数据汇聚。
- 适合：跨集群全局视图、对象存储长期保留、不修改 Prometheus 代码
- 重点看：查询效率、存储成本、架构复杂度
- 别忽略：数据去重逻辑、组件维护成本、对象存储配置
架构核心对比
选型前建议通过以下维度评估，避免盲目跟风：
| 维度 | Prometheus 联邦 | Thanos 架构 |
|---|---|---|
| 全局查询 | 不支持原生全局 PromQL，需手动聚合 | 支持全局视图，自动去重 |
| 长期存储 | 依赖本地磁盘，扩展性差 | 支持对象存储（S3/OSS），成本低 |
| 高可用 | 配置复杂，易出现数据不一致 | 组件冗余设计，容错性强 |
| 运维复杂度 | 低（仅 Prometheus） | 中（需维护 Sidecar/Querier/Store 等） |
Prometheus 联邦配置实操
联邦集群通过 `/federate` 接口拉取数据，需在顶层 Prometheus 配置 `scrape_configs`：
scrape_configs:
- job_name: 'federate'
scrape_interval: 15s
metrics_path: '/federate'
params:
'match[]':
- '{job="prometheus"}'
- '{__name__=~"job:.*"}'
static_configs:
- targets:
- 'prometheus-cluster-1:9090'
- 'prometheus-cluster-2:9090'注意：联邦模式不会自动去重，若多个联邦节点采集同一目标，数据会重复。
Thanos 部署关键配置
Thanos 需在每个 Prometheus 旁部署 Sidecar 组件，并将数据上传至对象存储。以下是 Kubernetes Deployment 片段：
containers:
- name: thanos-sidecar
image: quay.io/thanos/thanos:v0.32.5
args:
- "sidecar"
- "`--prometheus`.url=http://localhost:9090"
- "`--tsdb`.path=/prometheus"
- "`--objstore`.config=$(OBJSTORE_CONFIG)"
volumeMounts:
- name: data
mountPath: /prometheus对象存储配置需通过 Secret 注入，确保 Access Key 与 Bucket 权限正确（需具备读写权限）。
验证与排查
部署完成后，按以下步骤验证连通性与数据流：
- 检查 Sidecar 日志：确认无上传错误，看到 "uploaded block" 字样。
- 验证对象存储：登录 S3 控制台，确认桶内生成类似 "01HQZ..." 的 TSDB 块文件夹。
- 全局查询测试：在 Thanos Querier 界面执行 PromQL，对比单集群数据是否完整。
- 接口连通性：使用 curl 测试联邦接口
curl http://<prometheus-ip>:9090/federate?match[]=up。
常见风险与误区
- 联邦数据重复：联邦方案中若配置不当，同一 metric 可能被多个上层节点采集，导致查询结果翻倍，需规划好采集关系。
- 版本兼容性：Thanos 依赖 Prometheus 2.0+ 数据格式，升级前需确认 TSDB 兼容性。
- 存储权限问题：对象存储配置错误会导致数据上传失败，Sidecar 日志会报 403 或 404 错误，需仔细检查 IAM 策略。
- 查询性能：Thanos 全局查询涉及多个 Store Gateway，若数据量过大未配置 downsampling，查询延迟可能较高。
参考文档：Prometheus Official Documentation, Thanos Official Documentation.