Prometheus多集群监控Federation架构与远程写入配置实战

Prometheus多集群监控是云原生运维中的常见需求。当Kubernetes集群数量增长到十几个甚至上百个时，单一Prometheus实例无法覆盖所有集群，需要在每个集群内部署Prometheus采集指标，再通过Federation或远程写入（Remote Write）将数据汇聚到中心存储。本文从架构选型到配置落地，拆解多集群监控体系的搭建过程。

多集群监控架构选型：Federation与Remote Write对比

Prometheus官方提供两种跨集群数据汇聚机制，各有适用场景：

Federation（联邦）：中心Prometheus通过/metrics接口从各子集群Prometheus拉取指标，采用Pull模式。优点是实现简单、子集群无需公网暴露Push端点；缺点是中心Prometheus的抓取间隔决定了数据延迟，且子集群只暴露当前内存中的最近数据，历史数据无法联邦。

Remote Write（远程写入）：子集群Prometheus将采集到的样本通过HTTP POST推送到中心端的远程写入接收器，采用Push模式。优点是数据实时性高、支持持久化存储、可与Thanos或VictoriaMetrics集成；缺点是需要子集群能访问中心端点，网络配置更复杂。

对于10个以上集群的规模，推荐Remote Write方案配合VictoriaMetrics作为中心存储。VictoriaMetrics原生支持Prometheus远程写入协议，数据压缩率和查询性能优于原生Prometheus，且支持长时间存储。

子集群Prometheus配置Remote Write

每个子集群内部署Prometheus，配置远程写入指向中心端。在prometheus.yml中添加remote_write配置：

# prometheus.yml
global:
  scrape_interval: 30s
  external_labels:
    cluster: cluster-beijing-1
    region: cn-north

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

关键配置说明：

external_labels中的cluster标签是区分不同集群数据的核心标识，所有从该实例发出的指标都会带上这个标签。在中心端查询时，通过cluster标签过滤即可定位到特定集群。

write_relabel_configs使用drop动作过滤掉以go_开头的Prometheus自身运行时指标，减少无效数据传输量。实际场景中可根据需要过滤更多非业务指标，降低中心存储压力。

queue_config控制远程写入的队列行为。capacity设置内存队列容量，max_shards动态调整并发写入分片数，min_shards保证最低并发度。当中心端响应变慢时，队列自动增加shard数以维持吞吐；当中心端不可用时，样本在队列中缓存，max_backoff控制重试间隔。

中心端VictoriaMetrics集群部署

VictoriaMetrics集群版由vminsert、vmselect、vmstorage三个组件组成，分别负责数据写入、查询和存储。部署在中心Kubernetes集群中：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vminsert
spec:
  replicas: 3
  selector:
    matchLabels:
      app: vminsert
  template:
    metadata:
      labels:
        app: vminsert
    spec:
      containers:
      - name: vminsert
        image: victoriametrics/vminsert:v1.102.0
        args:
        - --storageNode=vmstorage-0.vmstorage-svc:8400
        - --storageNode=vmstorage-1.vmstorage-svc:8400
        - --storageNode=vmstorage-2.vmstorage-svc:8400
        - --maxLabels=500000
        ports:
        - containerPort: 8480

---
apiVersion: v1
kind: Service
metadata:
  name: vminsert-svc
spec:
  selector:
    app: vminsert
  ports:
  - port: 8480
    targetPort: 8480
  type: LoadBalancer

vmstorage使用StatefulSet部署3节点副本，数据持久化到PVC。vminsert前面挂LoadBalancer类型Service，对外暴露8480端口，接收来自各子集群的远程写入请求。

Grafana统一看板与多集群告警

中心端Grafana添加VictoriaMetrics数据源，通过cluster标签实现多集群指标聚合展示：

# 数据源配置
URL: http://vmselect-svc:8480/select/0/prometheus/

# 跨集群Pod重启告警
sum by (cluster, namespace) (rate(kube_pod_container_status_restarts_total[15m])) > 0

告警规则统一在中心端配置，使用Alertmanager路由到不同团队的接收渠道：

# alertmanager.yml
route:
  group_by: ['cluster', 'alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
  - match:
      cluster: cluster-shanghai-1
    receiver: 'shanghai-team'
  - match:
      cluster: cluster-beijing-1
    receiver: 'beijing-team'

receivers:
  - name: 'beijing-team'
    webhook_configs:
    - url: 'http://dingtalk-webhook/api/v1/send?team=beijing'
  - name: 'shanghai-team'
    webhook_configs:
    - url: 'http://dingtalk-webhook/api/v1/send?team=shanghai'

通过cluster标签路由告警到不同团队，避免上海集群的告警发到北京团队的群组。group_by中将cluster作为一级分组键，确保不同集群的同类告警不会被合并到一起，丢失定位信息。

数据写入优化与故障排查

当子集群数量超过50个时，中心端写入压力显著增加。VictoriaMetrics的vmstorage节点支持水平扩展，通过增加vmstorage副本并更新vminsert的–storageNode列表即可线性扩展写入能力。每个vmstorage节点建议配置SSD存储，磁盘IO是写入性能的主要瓶颈。

常见的远程写入故障排查：子集群Prometheus日志中出现”Error sending request to remote write”——检查网络连通性，确认中心端vminsert的Service端点可达，TLS证书有效。使用mtr或tcpdump排查网络中间链路，特别注意NAT网关和防火墙规则是否放行8480端口。

队列积压导致数据延迟——查看Prometheus的/prometheus API中remote_storage指标的samples_pending和samples_failed计数。如果samples_pending持续接近queue capacity，说明写入速率跟不上采集速率，需要增加max_shards或降低scrape频率。

指标基数爆炸——大量集群的指标汇入中心存储后，时间序列基数可能急剧增长。使用VictoriaMetrics的–dedup.minScrapeInterval参数去重，或在子集群端配置metric_relabel_configs丢弃低价值的高基数指标，如HTTP请求的path标签等。

Prometheus多集群监控的核心在于数据通路设计和告警路由策略。Remote Write配合VictoriaMetrics的方案在百集群规模下仍能保持稳定的写入吞吐和查询性能，配合Grafana的多变量看板，运维团队可以实现对全局基础设施的统一可观测性。