在很多早期的 Kubernetes 集群或多机房监控建设中，每当讨论到“如何统一管理多个机房的 Prometheus 数据、构建全局统一监控大屏”时，官方文档推荐的 分层联邦（Hierarchical Federation） 几乎是唯一的经典标准方案。
典型的传统联邦拓扑通常设计为：在每个机房或边缘集群部署一套本地的 Prometheus，负责采集当前集群的原始监控；随后在中心机房搭建一个高规格的全局全局 Prometheus（Global Master），通过配置 job_name: 'federate'，定时轮询访问下层每个 Prometheus 的 /federate HTTP 端点，拉取聚合后的关键时序。
然而，随着微服务数量的爆发式增长、Pod 生命周期的极速缩短以及活跃时序（Active Time Series）跨入千万级别，这套老迈的联邦架构在生产深水区遭遇了灾难性的崩溃与瘫痪。
为什么分层联邦必须从现代化监控体系中退役？在当今云原生生态中，我们应当如何在 Thanos 与 Grafana Mimir (前身 Cortex) 之间做出最契合企业业务架构的技术选型？本文将全面复盘这场跨越数年的架构演化史。
1. 传统分层联邦（Federation）的“四大生产死穴”
要彻底破除对联邦模式的执念，必须看清其在物理底层无法克服的技术局限：
+-------------------------------------------------------------------------------+
| 传统分层联邦架构的瓶颈崩塌 |
+-------------------------------------------------------------------------------+
| |
| [ 全局 Global Prometheus Master ] |
| (面临超大 HTTP 包解析、内存频频 OOM、单点崩溃) |
| / \ |
| (GET /federate) / \ (GET /federate) |
| v v |
| [ IDC-A 本地 Prometheus ] [ IDC-B 本地 Prometheus ] |
| (执行千万样本串行序列化, (数据量暴增，拉取耗时 > 60s |
| CPU 瞬间打满 100%) 触发 Context Deadline Exceeded!) |
| |
+-------------------------------------------------------------------------------+
- 拉取通道的网络吞吐黑洞：
/federate本质上是一个单次同步的 HTTP GET 请求。当底层集群有数十万个时序需要汇总时，下层节点需要在内存中一次性将上百兆的文本序列化，上层节点也需要一次性反序列化并写入 TSDB。在生产中，这一过程极易突破scrape_timeout，频繁报context deadline exceeded，导致监控数据大面积断档； - 缺乏原生高可用去重（Deduplication）：
在生产环境中，底层的本地 Prometheus 通常以主备双副本（HA Pair: Prometheus-0 与 Prometheus-1）运行。联邦模式无法原生识别这两个副本，上层要么必须二选一（失去冗余意义），要么把两边的数据全拉上来导致指标翻倍与折线毛刺； - 计算冗余与精度割裂：
由于拉取开销巨大，下层必须提前配置复杂的 Recording Rules 进行强制降采样聚合。如果业务临时需要排查一个未提前聚合的微服务 Pod 容器指标，全局联邦节点根本没有该数据，工程师不得不肉身登录到底层各个 IDC 的单机控制台去分别翻看，全局视图形同虚设； - 单点存储天花板：
上层 Global Prometheus 依然是一个受限于单机磁盘与单机内存的单体程序，面对海量汇总数据，它注定会成为整个监控大盘的致命单点。
2. 现代化替代双雄技术选型：Thanos vs. Grafana Mimir
为了彻底解决“海量时序的全局查询、无限长期存储与高可用去重”，业界诞生了两大巅峰架构体系：
+-------------------------------------------------------------------------------+
| Thanos vs. Mimir 核心维度对比 |
+----------------------+--------------------------+-----------------------------+
| 核心指标 | Thanos (CNCF 毕业项目) | Grafana Mimir (前身 Cortex) |
+----------------------+--------------------------+-----------------------------+
| 架构设计哲学 | 基于原生 Prometheus 的 | 彻底微服务化解耦的 |
| | "外挂式增强" (Sidecar) | "独立分布式时序集群" |
| 写入方式 | 本地 TSDB + 异步对象存储 | Remote-Write 主动推模式 |
| 运维复杂度 | 极低 (无状态组件为主) | 中到高 (依赖 Consul/Memberlist|
| 多租户强隔离 | 弱 (依赖 Label 逻辑隔离) | 强 (原生多租户与配额硬限制) |
| 查询引擎 | 跨存储散射聚集 (Scatter- | 分布式查询引擎 (Query- |
| | Gather + Deduplication) | Frontend 细粒度并行切分) |
| 典型适用场景 | 业务线已有 Prometheus， | 超大型企业私有云、监控平台组|
| | 追求低维护成本与全局视图 | 统一对外提供 SaaS 级可观测性|
+----------------------+--------------------------+-----------------------------+
- 选择 Thanos 的黄金场景：企业已经广泛部署了 Prometheus Operator，希望以最小的侵入代价快速获取全局视图和廉价的 S3 长期存储。Thanos Sidecar 像影子一样附着在现存 Prometheus 旁边，架构演进极其平滑。
- 选择 Mimir 的黄金场景：企业拥有专门的监控基础设施团队，需要支撑上百个业务部门的多租户隔离、千人并发查询以及每秒数千万样本的主动推送（Remote Write）。
3. 从 Federation 平滑迁移至 Thanos 全局架构实战
以下展示我们如何将一套濒临崩溃的老旧联邦集群，平滑重构为高可用的 Thanos 现代化全局视图。
+-------------------------------------------------------------------------------+
| Thanos 现代化无中心全局拓扑 |
+-------------------------------------------------------------------------------+
| |
| [ Grafana 统一监控控制台 ] |
| | |
| v |
| [ Thanos Query (无状态无单点) ] |
| - 执行跨集群聚合 PromQL |
| - 自动根据 replica 标签执行毫秒级去重 (Deduplication) |
| / \ |
| v v |
| [ Thanos Store Gateway ] [ Thanos Sidecar 集群 ] |
| (负责读取 Ceph/S3 历史数据) (负责近实时内存直读与上传) |
| | | |
| v v |
| [ 廉价对象存储 (S3/MinIO) ] [ 本地高可用 Prometheus HA 对 ] |
| |
+-------------------------------------------------------------------------------+
3.1 步骤一：为本地 Prometheus 注入 HA 标签并挂载 Sidecar
在 Prometheus Operator 的 CRD 声明中，为各集群赋予全局唯一集群名，并为 HA 副本配置区分标签：
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: k8s-infra
namespace: monitoring
spec:
replicas: 2 # 开启双副本高可用
# 核心全局外部标签: Thanos 据此识别数据源并去重!
externalLabels:
cluster: "cn-hangzhou-prod-01"
prometheus_replica: $(POD_NAME) # 动态注入副本名: prometheus-0 / prometheus-1
# 挂载 Thanos Sidecar 容器
thanos:
version: v0.35.0
objectStorageConfig:
key: thanos.yaml
name: thanos-objstore-secret
3.2 步骤二：部署无状态 Thanos Query 并开启全局去重
Thanos Query 作为统一的 PromQL 接入网关，它不存储任何本地数据。它通过 gRPC 协议并发向各个机房的 Sidecar 扇出查询请求（Scatter-Gather），并自动合并去重：
apiVersion: apps/v1
kind: Deployment
metadata:
name: thanos-query
namespace: monitoring
spec:
replicas: 3 # 多副本保证全局查询的高可用
template:
spec:
containers:
- name: thanos-query
image: quay.io/thanos/thanos:v0.35.0
args:
- "query"
- "--log.level=info"
- "--grpc-address=0.0.0.0:10901"
- "--http-address=0.0.0.0:9090"
# 核心参数: 开启双副本自动去重! 彻底消灭折线毛刺
- "--query.replica-label=prometheus_replica"
# 挂载各个 IDC 边缘集群的 Sidecar gRPC 服务端点
- "--store=dnssrv+_grpc._tcp.thanos-sidecar.monitoring.svc.cluster.local"
- "--store=thanos-sidecar-idc2.corp:10901"
# 挂载对象存储网关，透明无感查询过去 1 年的历史冷数据
- "--store=thanos-storegateway.monitoring.svc:10901"
4. 架构升级收益与实战成效
全面退役传统分层联邦、上线 Thanos 架构后，生产监控平台迎来了质的飞跃：
- 彻底瓦解中心单点瓶颈：原本每天 OOM 崩溃两三次的 Global Master 被彻底废弃，Thanos Query 采用纯无状态部署，支持水平无限扩展；
- 查询性能提速 10 倍：原本跨 IDC 查询经常遭遇的 60 秒抓取超时彻底绝迹，通过 gRPC 二进制流式传输与服务端过滤，跨集群大盘查询延迟稳定在 800 毫秒以内；
- 海量历史数据零成本留存：结合底层 S3 对象存储与自动 Compaction 降采样，监控历史数据的留存期从原来的 15 天暴增至 3 年，而存储开销仅为原先本地 SSD 方案的十分之一。
5. 总结
技术的演进永远遵循着“解决旧矛盾、迎接新挑战”的必然规律。
Prometheus 联邦架构在单体与小规模集群时代立下了赫赫战功，但在海量分布式的云原生深水区，退役是它最体面的归宿。拥抱基于对象存储解耦的 Thanos 或分布式原生的 Mimir，构建真正高可用、强去重、无单点的现代化时序底座，才是保障大型生产系统稳定可观测的必由之路。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/qwe0iop0/article/details/168013432
