prometheus联邦模式适用于中小规模多集群场景（≤5个集群），核心是分层聚合关键指标而非全量复制；上游暴露/federate接口并保留标识标签，下游按需拉取任务摘要、健康信号及跨集群可比指标，避免细粒度数据上浮。
Prometheus 联邦模式不是为“堆机器”而设计的，而是为有层次、有取舍的指标聚合服务的。它适合中小规模多集群场景（通常 ≤5 个集群），核心目标是构建轻量、稳定、可运维的全局视图，而不是把所有原始数据搬过来。
联邦架构的关键分工
联邦本质是“下游主动拉、上游按需曝”，上下游职责清晰：
-
上游（各集群 Prometheus）：只需确保
/federate接口（默认:9090/federate）可被中心访问；建议启用honor_labels: true，让cluster="bj"、region="cn-north"这类标识标签原样保留 -
下游（中心联邦 Prometheus）：在
scrape_configs中为每个集群定义独立 job，指定目标地址、metrics_path: "/federate"，并通过params.match[]精确限定要拉的指标，例如：- '{__name__=~"job:.*|up|probe_success"}'
只拉三类真正需要的指标
联邦的价值在于“瘦身”，不是镜像复制。重点拉：
-
任务级摘要：如预计算好的
job:node_cpu_usage:avg1m、job:pod_count（需配合 Recording Rules） -
健康信号：如
up{job="kubernetes-pods"}、probe_success、rate(http_requests_total[5m]) -
跨集群可比指标：如按
cluster和service分组的 P95 延迟、错误率、QPS
单个 Pod 的 CPU、容器日志行数等细粒度指标，应留在本地查询，不进联邦链路。
统一视图落地三件事
有了联邦数据，还需配套动作才能形成可用视图：
-
查询：Grafana 直连中心 Prometheus；写 PromQL 时显式带
by (cluster)或group_left(cluster)，例如：sum(rate(http_requests_total[5m])) by (cluster, job) -
告警：在中心节点配置全局规则，比如“任意集群
up == 0持续 2 分钟”或“跨集群平均延迟 > 1s”，避免各集群重复定义 -
可视化：Dashboard 使用
$cluster变量支持筛选或并列对比；关键大盘标题注明“联邦汇总（非实时）”，管理用户预期
容易踩的几个运行态坑
配置写对只是起点，运行中更需注意：
- 抓取间隔错配：若上游采集间隔为 15s，下游联邦抓取设为 30s，可能漏掉部分瞬时峰值；建议下游间隔 ≥ 上游间隔的 2–4 倍（如上游 15s，下游设为 60s）
-
全量 match[]：误写
match[]: ['{__name__=~".*"}']会触发大量低效拉取，引发上游负载飙升甚至超时 -
标签爆炸风险：未过滤高基数标签（如
pod_name、request_id）就拉入联邦层，会导致中心 Prometheus 内存与查询性能急剧恶化
