Prometheus联邦集群与remote_write多机房监控架构设计

Prometheus是云原生监控领域事实标准，单实例可处理百万级时间序列。但跨多机房、多Kubernetes集群场景下，单点Prometheus存在网络延迟、存储瓶颈和单点故障风险。Prometheus联邦（Federation）和remote_write远程写入是两种主流的多机房监控方案，搭配合理的监控告警体系，能构建覆盖数千节点的高可用监控架构。日志分析与指标聚合在多集群环境中尤为关键。

Prometheus单实例能力边界与扩展需求

单实例Prometheus建议采集目标不超过1万个exporter，活跃时间序列不超过200万条。超出后会出现查询超时、内存溢出和写入延迟。扩展方案根据地域分布和数据量选择：

联邦模式：每个机房部署独立Prometheus采集本地数据，中心Prometheus通过 federation接口拉取聚合指标。适合地域分散、需本地快速查询的场景。

remote_write模式：各机房Prometheus采集数据后实时远程写入中心存储（Thanos/VM/Mimir），适合统一查询和长期存储。

联邦集群架构部署

联邦架构由边缘Prometheus和中心Prometheus两层组成。边缘节点采集本地targets，中心节点定期从边缘节点federate接口拉取关键指标。

边缘Prometheus配置（机房A）：

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'kubernetes-nodes'
    kubernetes_sd_configs:
      - role: node
    relabel_configs:
      - source_labels: [__address__]
        regex: '(.*):.*'
        target_label: __address__
        replacement: '${1}:9100'

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

中心Prometheus配置（拉取各边缘节点）：

global:
  scrape_interval: 30s
  evaluation_interval: 30s

scrape_configs:
  - job_name: 'federate-dc1'
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="kubernetes-nodes", datacenter="dc1"}'
        - '{__name__=~"up|node_cpu_seconds_total|node_memory_MemAvailable_bytes"}'
    static_configs:
      - targets: ['prometheus-dc1.internal:9090']

  - job_name: 'federate-dc2'
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="kubernetes-nodes", datacenter="dc2"}'
        - '{__name__=~"up|node_cpu_seconds_total|node_memory_MemAvailable_bytes"}'
    static_configs:
      - targets: ['prometheus-dc2.internal:9090']

联邦接口的match[]参数是核心：只拉取关键聚合指标而非全量数据，避免中心节点过载。

remote_write远程写入配置

remote_write模式将数据实时推送到远端存储，不依赖Pull模型，网络中断时本地缓存重试。适合统一存储和查询场景。

remote_write:
  - url: 'https://thanos-receiver.central.internal/api/v1/receive'
    remote_timeout: 30s
    queue_config:
      capacity: 10000
      max_shards: 200
      min_shards: 1
      max_samples_per_send: 2000
      batch_send_deadline: 5s
    write_relabel_configs:
      - source_labels: [__name__]
        regex: 'go_.*|process_.*'
        action: drop
      - target_label: datacenter
        replacement: 'dc1'

remote_write的queue_config是性能调优关键。max_shards控制并发写入连接数，大集群建议设为50-200。capacity决定网络中断时本地缓存能力，10000约可缓存2分钟数据。过高capacity会增大内存占用，需监控容器/进程内存。

Recording Rules预聚合规则配置

联邦和remote_write场景下，预聚合规则能减少中心节点的数据量和查询压力。在边缘Prometheus上将高频原始指标聚合为低频汇总指标。

groups:
  - name: node_aggregation
    interval: 30s
    rules:
      - record: node:cpu_usage:ratio
        expr: |
          1 - avg by (instance, datacenter) (
            rate(node_cpu_seconds_total{mode="idle"}[5m])
          )

      - record: node:memory_usage:ratio
        expr: |
          1 - (
            node_memory_MemAvailable_bytes
            / node_memory_MemTotal_bytes
          )

      - record: node:disk_usage:ratio
        expr: |
          1 - (
            node_filesystem_avail_bytes{fstype=~"ext4|xfs"}
            / node_filesystem_size_bytes{fstype=~"ext4|xfs"}
          )

      - record: container:cpu_usage:sum_by_ns
        expr: |
          sum by (namespace, datacenter) (
            rate(container_cpu_usage_seconds_total[5m])
          )

      - record: pod:restart_rate
        expr: |
          increase(kube_pod_container_status_restarts_total[1h])

命名格式遵循level:metric:operations规范，中心Prometheus通过联邦接口拉取这些预聚合指标，而非原始counter，大幅减少传输数据量。

多集群告警路由与Alertmanager高可用

多机房场景下Alertmanager需要高可用部署和告警去重。边缘节点产生告警发送到中心Alertmanager集群，通过group_by和route配置实现去重和分级。

route:
  group_by: ['alertname', 'datacenter', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - matchers:
        - severity = critical
      receiver: 'pagerduty'
      group_wait: 10s
    - matchers:
        - severity = warning
      receiver: 'slack-critical'
    - matchers:
        - datacenter = dc1
      receiver: 'dc1-team'

receivers:
  - name: 'default'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/xxx'
        channel: '#ops-alerts'
  - name: 'pagerduty'
    pagerduty_configs:
      - service_key: 'xxx'
        severity: critical

Alertmanager集群部署3节点，通过–cluster.peer参数组成HA集群：

alertmanager \
  --config.file=alertmanager.yml \
  --storage.path=/data/alertmanager \
  --web.listen-address=:9093 \
  --cluster.listen-address=0.0.0.0:9094 \
  --cluster.peer=alertmanager-02:9094 \
  --cluster.peer=alertmanager-03:9094

故障应急响应与监控数据量估算

规划多集群监控前需估算数据量。每个采集目标约500-1000个series，每series约2KB/天存储空间。1000节点集群约80万series，日数据量约1.6GB，90天数据约144GB（压缩后SSD占用）。加上Kubernetes Pod指标（10000 pods * 200 series/pod = 200万series），90天数据约360GB。

存储策略建议：边缘Prometheus本地保留7-15天，中心存储（VM/Thanos）保留90天-1年，超过1年数据归档到对象存储（S3/MinIO）。VictoriaMetrics集群版推荐配置：vmstorage节点每100万活跃series分配16GB内存和500GB SSD。