prometheus联邦实现多集群统一视图的核心是分层拉取与选择性聚合：上游各集群暴露预聚合指标（如job:.*、up等），下游中心节点通过/federate端点按需拉取并保留cluster等标识标签，聚焦任务级摘要、健康信号和跨集群关联指标，避免原始细粒度数据搬运。
用 Prometheus 联邦机制实现多集群统一视图，核心不是“把所有数据搬过去”，而是有选择地聚合关键指标，构建轻量、稳定、可运维的全局层。它适合中小规模（≤5 个集群）、网络相对可靠、对秒级延迟不敏感的场景。
联邦架构怎么搭：上游和下游各做什么
联邦是“拉模型”——中心节点主动向各集群的 Prometheus 实例发起请求，只取需要的部分数据。
-
上游（各集群 Prometheus）：无需额外配置，只要保证
/federate接口（默认:9090/federate）可被中心节点访问即可；建议通过honor_labels: true保留原始标签（如cluster="shanghai"），方便后续区分来源 -
下游（中心联邦 Prometheus）：在
scrape_configs中为每个集群定义一个 job，指定目标地址、路径和要拉取的指标范围；避免全量拉取，用params.match[]精确过滤
拉什么指标：聚焦聚合型、业务型、稳定性指标
联邦不是镜像复制，而是做“指标瘦身”。重点拉三类：
-
任务级摘要：如
job:node_cpu_usage:avg1m、job:pod_count（需配合 Recording Rules 预计算） -
服务健康信号：如
up{job="kubernetes-pods"}、probe_success、http_requests_total的 rate/sum -
跨集群关联指标：如按
cluster和service标签分组的延迟、错误率、QPS
不建议拉原始细粒度指标（如单个 Pod 的 CPU 使用率），这类数据应保留在本地查询。
统一视图怎么落地：查询、告警、可视化三步走
有了联邦数据，真正形成“统一视图”还需配套动作：
-
查询层：在 Grafana 中直接使用中心 Prometheus 作为唯一数据源；写 PromQL 时带上
by (cluster)或group_left(cluster)显式聚合，例如：sum(rate(http_requests_total[5m])) by (cluster, job) -
告警层：在中心 Prometheus 上配置全局规则，比如“任意集群
up == 0持续 2 分钟”或“跨集群平均 P95 延迟 > 1s”；避免在每个子集群重复定义相同逻辑 -
可视化层：Dashboard 模板中用变量（如
$cluster）控制筛选，支持一键切换或并列对比；关键大盘标题注明“联邦汇总（非实时）”，管理预期
避坑要点：别让联邦变成单点瓶颈
联邦容易出问题的地方往往不在配置，而在运行态：
- 抓取间隔错配：上游采集频率（如 15s）远高于下游联邦抓取频率（如 60s），会导致部分数据丢失；建议下游抓取间隔 ≥ 上游采集间隔的 2–4 倍
-
目标不可达静默失败：某个集群 Prometheus 宕机时，联邦 job 会持续报错但不中断；需监控
prometheus_target_interval_length_seconds和up{job=~"federated.*"}是否全部为 1 -
标签冲突覆盖：多个上游都上报
instance="localhost:9090"，又没加cluster标签，会导致指标被覆盖；务必确保external_labels在上游配置中设好，如cluster: "beijing"
