Prometheus多集群联邦监控架构与远程写入存储方案实战

多集群监控的架构选型与联邦方案设计

当Kubernetes集群数量超过3个，独立部署Prometheus的维护成本急剧上升——每套Prometheus有独立的规则文件、告警配置和Grafana数据源。联邦（Federation）方案通过层级Prometheus收集全局指标，既保留了各集群的自治能力，又提供了统一视图。

典型架构：每个集群运行一个Prometheus Server采集本地指标（叶子节点），中心Prometheus通过federation接口从各叶子节点拉取关键指标（根节点）。两级架构足够应对20个以内的集群；超过20个建议增加中间聚合层。

叶子节点Prometheus联邦端点配置

每个集群的Prometheus需要暴露federation接口，同时限制中心节点只拉取必要指标，避免全量传输消耗带宽：

# 叶子节点 prometheus.yml
global:
  external_labels:
    cluster: "prod-east"
    env: "production"

scrape_configs:
  - job_name: "federate"
    scrape_interval: 15s
    honor_labels: true
    metrics_path: "/federate"
    params:
      "match[]":
        - '{job="kubelet"}'
        - '{job="kube-state-metrics"}'
        - '{__name__=~"kube_pod_container_status_restarts_total|kube_deployment_status_replicas"}'
        - '{__name__=~"node_cpu_seconds_total|node_memory_MemAvailable_bytes"}'
    static_configs:
      - targets:
          - "prometheus-central:9090"

honor_labels: true确保叶子节点的external_labels不被中心节点覆盖，这是区分指标来源的关键。match[]参数控制联邦拉取范围，按job和metric name精确匹配。

中心节点Prometheus联邦拉取配置

# 中心节点 prometheus.yml
scrape_configs:
  - job_name: "federate-prod-east"
    scrape_interval: 30s
    honor_labels: true
    metrics_path: "/federate"
    params:
      "match[]":
        - '{job="kubelet"}'
        - '{job="kube-state-metrics"}'
        - '{__name__=~"node_cpu_seconds_total|node_memory_MemAvailable_bytes|kube_pod_container_status_restarts_total"}'
    static_configs:
      - targets:
          - "prometheus-prod-east:9090"
        labels:
          cluster: "prod-east"

  - job_name: "federate-prod-west"
    scrape_interval: 30s
    honor_labels: true
    metrics_path: "/federate"
    params:
      "match[]":
        - '{job="kubelet"}'
        - '{job="kube-state-metrics"}'
        - '{__name__=~"node_cpu_seconds_total|node_memory_MemAvailable_bytes|kube_pod_container_status_restarts_total"}'
    static_configs:
      - targets:
          - "prometheus-prod-west:9090"
        labels:
          cluster: "prod-west"

中心节点的scrape_interval建议比叶子节点长（30s vs 15s），减少联邦拉取对叶子节点的压力。中心节点只存聚合指标，不做本地采集，存储压力可控。

远程写入（Remote Write）方案与长期存储集成

联邦方案解决的是多集群可见性问题，长期历史数据仍需远程写入到专用存储。Prometheus原生支持remote_write，常见后端：Thanos Receive、Mimir、VictoriaMetrics。

# prometheus.yml - 远程写入配置
remote_write:
  - url: "https://mimir.example.com/api/v1/push"
    headers:
      X-Scope-OrgID: "prod-east"
    queue_config:
      max_samples_per_send: 5000
      max_shards: 100
      capacity: 10000
      batch_send_deadline: 5s
    write_relabel_configs:
      - source_labels: [__name__]
        regex: "go_.*"
        action: drop

write_relabel_configs过滤掉无用指标（如go_.*运行时指标），减少远程写入量。queue_config控制发送速率：max_shards按网络带宽调整，capacity过大浪费内存，过小则排队延迟高。网络抖动场景建议max_shards设为50以下，batch_send_deadline设为10s。

Thanos Sidecar与Receive模式对比选型

Thanos提供两种长期存储接入方式：Sidecar模式直接读取Prometheus本地TSDB块并上传对象存储，适合2小时数据块粒度；Receive模式接收remote_write数据流实时写入对象存储，延迟更低。

Sidecar模式优势：零配置变更，Prometheus无需开启remote_write，Sidecar以Sidecar容器挂载同一路TSDB目录。劣势：依赖Prometheus完成2小时块的压缩和上传，最近2小时数据不在对象存储中。Receive模式适合需要跨集群即时查询的场景，但引入额外组件和故障点。

Grafana多数据源统一视图与告警规则管理

中心Prometheus注册为Grafana数据源后，在Dashboard中用cluster标签变量过滤不同集群的指标：

# Grafana变量定义
# 变量cluster: label_values(cluster)
# 变量namespace: label_values(kube_pod_status_phase, namespace)

# Panel查询示例
sum by (namespace) (rate(container_cpu_usage_seconds_total{cluster=~"$cluster", namespace=~"$namespace"}[5m]))

告警规则统一在中心节点管理。每个集群的叶子节点保留本地告警（P0级故障秒级响应），中心节点负责跨集群聚合告警（容量规划、SLO违反等低频高价值告警）。告警路由用Alertmanager的route树按cluster标签分发到不同接收渠道。