Prometheus联邦集群多数据中心监控架构与远程写入配置实战

网站运维中多数据中心监控数据的统一汇聚是保障系统可观测性的基础工程。Prometheus联邦集群架构通过分层抓取机制，将各数据中心的本地指标汇总到全局Prometheus实例，配合远程写入功能可进一步将指标流式传输到长期存储后端。本文演示Prometheus联邦集群与远程写入的完整配置流程，涵盖联邦抓取、远程写入、标签管理及存储后端集成。

Prometheus联邦架构设计

联邦架构适用于以下场景：多个数据中心各自运行本地Prometheus采集区域指标，全局Prometheus从各区域实例拉取聚合数据。分层联邦（Hierarchical Federation）是在全局Prometheus之上再叠加一层跨区域联邦，适用于全球分布的规模。

架构中的角色划分：

# 两个数据中心各部署一个Prometheus（leaf节点）
# leaf节点负责本地targets抓取，本地存储
leaf-dc1 (10.0.1.10:9090) - 数据中心1
leaf-dc2 (10.0.2.10:9090) - 数据中心2

# 一个全局Prometheus（root节点）
# root节点从leaf节点联邦抓取，汇聚全局视图
root-global (10.0.0.10:9090)

联邦抓取的本质是root节点调用leaf节点的`/federate`接口，该接口返回当前采集到的所有时间序列数据。root节点将获取到的样本重新写入本地TSDB，与普通scrape的区别在于数据来源是另一个Prometheus而非exporter。

联邦抓取配置

root节点的prometheus.yml配置联邦抓取：

global:
  scrape_interval: 30s
  evaluation_interval: 30s

scrape_configs:
  # 联邦抓取数据中心1
  - job_name: 'federate-dc1'
    scrape_interval: 30s
    honor_labels: true
    metrics_path: '/federate'
    params:
      # 只抓取特定前缀的指标，避免全量抓取
      'match[]':
        - '{job="node"}'
        - '{job="kubernetes-nodes"}'
        - '{job="kubernetes-pods"}'
        - '{__name__=~"up|kube_pod_status_phase|container_cpu_usage_seconds_total"}'
    static_configs:
      - targets:
        - '10.0.1.10:9090'
    relabel_configs:
      - target_label: 'datacenter'
        replacement: 'dc1'

  # 联邦抓取数据中心2
  - job_name: 'federate-dc2'
    scrape_interval: 30s
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="node"}'
        - '{job="kubernetes-nodes"}'
        - '{job="kubernetes-pods"}'
        - '{__name__=~"up|kube_pod_status_phase|container_cpu_usage_seconds_total"}'
    static_configs:
      - targets:
        - '10.0.2.10:9090'
    relabel_configs:
      - target_label: 'datacenter'
        replacement: 'dc2'

关键配置参数说明：

honor_labels: true
# 联邦抓取时保留原始标签，防止root节点覆盖source job等标签

match[]:
# 指定要抓取的指标series selector，未匹配的series不会被拉取
# 不配置match[]会抓取leaf节点全部series，消耗大量带宽

metrics_path: '/federate'
# Prometheus内置的联邦接口路径

验证联邦抓取是否生效，在root节点执行：

curl -G 'http://10.0.0.10:9090/api/v1/label/datacenter/values'
# 预期返回: ["dc1","dc2"]

curl -G 'http://10.0.0.10:9090/api/v1/query' --data-urlencode 'query=count(up) by (datacenter)'
# 预期返回各数据中心的targets数量

远程写入配置

联邦抓取是pull模式，远程写入（Remote Write）是push模式，两者可配合使用。leaf节点的指标通过远程写入实时推送到中央存储，相比联邦抓取延迟更低。但远程写入引入了额外的网络消耗和写入压力，需配合批量和重试策略。

leaf节点的远程写入配置：

# prometheus.yml
remote_write:
  - url: 'http://10.0.0.20:9009/api/v1/write'
    remote_timeout: 30s
    queue_config:
      # 并发写入队列数
      capacity: 10000
      max_shards: 200
      min_shards: 1
      max_samples_per_send: 2000
      batch_send_deadline: 10s
      min_backoff: 1s
      max_backoff: 30s
    write_relabel_configs:
      # 过滤掉不需要远程写入的指标
      - source_labels: [__name__]
        regex: 'go_.*|process_.*|prometheus_.*'
        action: drop
    # 添加来源标签
    external_labels:
      datacenter: dc1
      cluster: prod-cluster-1

队列参数调优指南：

capacity: 10000
# 每个shard的队列缓冲区大小，过小会导致drop，过大增加内存

max_shards: 200
# 最大并发HTTP连接数，每个shard一个连接
# 200个shard下，每个shard每秒可发送2000个sample，总计40w/s

max_samples_per_send: 2000
# 每次HTTP请求携带的最大样本数，建议1000-5000

batch_send_deadline: 10s
# 即使队列未满，超过此时间也会强制发送，控制最大延迟

min_backoff / max_backoff
# 远程写入失败后的重试退避策略

远程写入接收端配置

接收端可用Prometheus本身（开启`–enable-feature=remote-write-receiver`），或使用专门的远程存储后端。使用Mimir作为接收端：

# Mimir配置 (mimir.yaml)
multikv:
  enabled: true

limits:
  ingestion_rate: 500000
  ingestion_burst_size: 1000000
  max_global_series_per_user: 5000000

distributor:
  shard_by_all_labels: true
  pool:
    health_check_ingesters: true

store_gateway:
  sharding:
    enabled: true

启用Prometheus的远程写入接收端：

prometheus     --config.file=/etc/prometheus/prometheus.yml     --storage.tsdb.path=/data/prometheus     --storage.tsdb.retention.time=90d     --enable-feature=remote-write-receiver     --web.enable-lifecycle

多数据中心标签管理

联邦架构中标签冲突是常见问题。leaf节点抓取的指标已带有`job`、`instance`等标签，root节点联邦抓取时如果再添加同名标签会覆盖原始值。`honor_labels: true`可保留原始标签，但需要通过external_labels区分数据来源。

leaf节点添加external_labels：

global:
  external_labels:
    datacenter: dc1
    cluster: prod-cluster-1
    region: us-east

联邦抓取时使用relabel补充标签：

relabel_configs:
  - target_label: 'federated_by'
    replacement: 'root-global'
  - target_label: 'federated_at'
    replacement: '2026-08'

通过Recording Rules预计算聚合指标，减少联邦抓取的数据量：

# leaf节点的recording rules
groups:
  - name: federation_aggregates
    rules:
      - record: dc1:node_cpu_utilization:avg
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

      - record: dc1:node_memory_usage:percent
        expr: 100 * (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)

      - record: dc1:container_cpu_usage:sum
        expr: sum by (namespace, pod) (rate(container_cpu_usage_seconds_total[5m]))

root节点联邦抓取时只拉取这些预计算的聚合指标：

params:
  'match[]':
    - '{__name__=~"dc1:.*|dc2:.*"}'

存储后端与长期持久化

Prometheus本地TSDB设计为短期存储（15-90天），长期存储需借助远程存储后端。Thanos架构通过Sidecar组件将Prometheus数据块上传到对象存储：

# Thanos Sidecar配置
thanos sidecar     --tsdb.path=/data/prometheus     --prometheus.url=http://localhost:9090     --objstore.config-file=/etc/thanos/objstore.yaml     --shipper.upload-compacted

# 对象存储配置 (objstore.yaml)
type: S3
config:
  bucket: prometheus-long-term
  endpoint: minio.internal:9000
  access_key: minio
  secret_key: minio123
  insecure: true

Thanos Query提供全局查询入口，同时访问本地Prometheus和远程对象存储：

thanos query     --http-address=0.0.0.0:10902     --grpc-address=0.0.0.0:10901     --store=10.0.1.10:10901     --store=10.0.2.10:10901     --store=10.0.0.30:10901

构建联邦集群时需注意网络拓扑对延迟的影响。跨数据中心联邦抓取的scrape_interval建议设为本地采集的2-3倍（如本地15s，联邦30-45s），避免联邦抓取超时。监控联邦抓取自身的健康状态，添加对`prometheus_remote_storage_samples_total`和`scrape_samples_post_metric_relabeling`的告警规则。