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 报红，干扰真实告警判断