Prometheus联邦集群监控的核心目标是构建“可区分、可聚合、可运维”的两级视图：中心节点看全局趋势与异常，子集群保留原始细节用于排查；通过honor_labels和Recording Rules实现高效聚合拉取，不替代本地Prometheus，而是补足跨集群协同能力。
Prometheus 联邦集群监控的核心目标不是复制全部数据，而是构建“可区分、可聚合、可运维”的两级视图：中心节点看全局趋势与异常，各子集群保留原始细节用于深度排查。它不替代本地 Prometheus，而是补足跨集群协同能力。
上游（子集群）只需暴露关键指标
每个子集群的 Prometheus 实例无需额外部署组件，只需确保 /federate 接口（默认端口 9090）对中心节点可达。重点配置两点：
-
开启 honor_labels: true：让中心节点拉取时保留原始标签，例如自动带上
cluster="bj-prod"、job="kubernetes-pods"，避免指标来源混淆 -
预计算高频聚合指标：在子集群上用 Recording Rules 提前生成如
job:node_cpu_usage:avg1m、job:pod_count、probe_success等摘要型指标，减少联邦拉取压力和网络传输量
下游（中心联邦）按需拉取，不贪多
中心 Prometheus 的 scrape_configs 中为每个子集群定义独立 job，通过 params.match[] 精确控制拉取范围：
- 只拉健康信号：
match[]: '{__name__=~"up|probe_success"}' - 只拉业务级聚合：
match[]: '{__name__=~"http_requests_total|http_request_duration_seconds"}'，再配合 rate() 或 histogram_quantile() 计算 QPS/P95 - 避免拉原始指标（如单个 Pod 的 cpu_usage_seconds_total），这类数据应留在本地查
统一视图靠查询与可视化协同落地
有了带 cluster 标签的联邦数据，真正形成“一眼看清全貌”需要三层配合：
-
查询层：PromQL 显式分组，例如
sum(rate(http_requests_total[5m])) by (cluster, job)或avg_over_time(up[1h]) by (cluster) -
告警层：在中心 Prometheus 配置全局规则，如
count by (cluster) (up == 0) > 0持续 2 分钟，触发“某集群整体失联”告警 -
可视化层：Grafana Dashboard 使用
$cluster变量筛选，支持单集群聚焦或并列对比；大盘标题注明“联邦汇总（延迟约 30–60 秒）”，管理用户预期
哪些场景不适合联邦？
联邦不是万能方案。当出现以下情况时，应考虑 Thanos 或 Prometheus Agent + Remote Write：
- 集群数量超过 5–7 个，中心节点 CPU/内存持续超载
- 要求秒级实时性（如 SLO 熔断联动），而联邦抓取间隔无法压缩到 10 秒内
- 需要长期存储（>15 天）或跨集群回溯分析，联邦本身不提供持久化能力
- 子集群网络不稳定，频繁超时导致联邦 job 报红，干扰真实告警判断
