Prometheus多集群联邦监控架构：远程写入与Thanos长周期存储方案

Prometheus是云原生监控告警体系的事实标准。单实例Prometheus在处理多集群、长时间窗口指标时存在本地存储容量限制和查询性能瓶颈。通过Prometheus联邦配合Thanos或VictoriaMetrics构建多集群监控体系，能实现跨集群聚合查询和PB级历史数据存储。这套架构在DevOps实践和故障应急响应场景中广泛使用。

Prometheus联邦架构设计：层级federation与远程写入对比

Prometheus原生支持federation机制，通过/federate接口从下级Prometheus抓取聚合后的指标。层级联邦适合按区域或功能分层的监控场景，但存在级联延迟和单点放大问题——上级Prometheus的抓取间隔决定了数据的真实新鲜度上限。

# 上级Prometheus抓取下级联邦端点
scrape_configs:
  - job_name: 'federate-cluster-east'
    scrape_interval: 30s
    honor_labels: true
    metrics_path: '/federate'
    params:
      'match[]':
        - '{job="kubernetes-nodes"}'
        - '{job="kubernetes-pods"}'
        - '{__name__=~"job:.*"}'  # 仅抓取Recording Rules产物
    static_configs:
      - targets: ['prom-east.internal:9090']

联邦方案的局限在于：match[]表达式限制了可抓取的指标范围，上级Prometheus拉取大量序列时自身内存压力大，且无法保证Exactly-once语义。远程写入（Remote Write）方案更可靠——每集群Prometheus通过remote_write将全量指标推送到中心化存储：

# 各集群Prometheus配置远程写入
remote_write:
  - url: 'http://thanos-receive.global:19291/api/v1/receive'
    queue_config:
      capacity: 10000
      max_samples_per_send: 2000
      max_shards: 200
      min_shards: 10
    write_relabel_configs:
      - source_labels: [__name__]
        regex: 'go_.*'  # 过滤不需要的指标
        action: drop
    remote_timeout: 30s

queue_config是远程写入的核心调优参数。capacity控制内存缓冲样本数，max_samples_per_send决定单次HTTP请求的批量大小，shard数量动态调整并发度。在1000节点集群的实测中，min_shards从1调到10后，远程写入的P99延迟从8s降至200ms。

Thanos组件部署：Sidecar与Receive模式选型

Thanos提供两种数据接入模式。Sidecar模式在每个Prometheus实例旁部署Sidecar容器，通过Prometheus的TSDB快照接口上传Block到对象存储，同时通过Store API提供实时查询。Receive模式则通过Remote Write协议接收指标，不依赖本地Prometheus的TSDB。

Sidecar模式的部署示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: thanos-sidecar
spec:
  template:
    spec:
      containers:
      - name: thanos-sidecar
        image: thanosio/thanos:v0.36.0
        args:
        - sidecar
        - --tsdb.path=/prometheus
        - --prometheus.url=http://localhost:9090
        - --objstore.config-file=/etc/thanos/objstore.yaml
        - --shipper.upload-compacted
        volumeMounts:
        - name: prometheus-data
          mountPath: /prometheus
      volumes:
      - name: prometheus-data
        persistentVolumeClaim:
          claimName: prometheus-data

Sidecar模式要求Prometheus启用–storage.tsdb.min-block-duration=2h和–storage.tsdb.max-block-duration=2h，使本地Block与上传Block对齐。Sidecar的–shipper.upload-compacted参数允许上传已压缩的Block，减少首次同步延迟。

Receive模式适用于不直接暴露Store API或需要中心化写入的场景。Thanos Receive通过HashRing实现水平扩展：

thanos receive --grpc-address=0.0.0.0:10901
  --http-address=0.0.0.0:10902
  --remote-write.address=0.0.0.0:19291
  --objstore.config-file=/etc/thanos/objstore.yaml
  --label=receive_replica="$(hostname)"
  --tsdb.path=/var/thanos/receive
  --hashring.config-file=/etc/thanos/hashring.json

HashRing配置文件定义Receive节点列表及其负责的哈希范围。当某个Receive节点宕机时，其负责的指标通过一致性哈希自动重新分配到其他节点。该机制依赖etcd或文件-based HashRing同步路由表。

对象存储Block管理与数据降采样

Thanos Store Gateway从对象存储读取Block并暴露gRPC查询接口。长时间跨度查询（如30天或数月）直接扫描原始2小时Block会产生大量IO，Compactor组件通过降采样解决此问题——将多个2小时Block合并为更大的Block，并对非关键时间戳进行降采样。

thanos compact --data-dir=/var/thanos/compact
  --objstore.config-file=/etc/thanos/objstore.yaml
  --compact.concurrency=4
  --deduplication.replica-label=receive_replica
  --retention.resolution-raw=30d
  --retention.resolution-5m=180d
  --retention.resolution-1h=365d

降采样策略分三个层级：原始数据（raw）保留30天，5分钟降采样数据保留180天，1小时降采样数据保留365天。5分钟降采样将每5分钟内的样本聚合为min/max/sum/count，1小时降采样进一步压缩。查询时Querier根据时间范围自动选择合适层级的数据源。

deduplication.replica-label指定去重标签，当多副本Receive写入相同指标时，Compactor根据该标签识别并去除重复样本。不配置此参数会导致查询结果出现2倍数据。

跨集群查询路由：Thanos Query与Store API

Thanos Query是查询入口，通过gRPC连接多个Store API端点（Sidecar Store / Receive Store / Store Gateway），在查询时并行分发到各端点并合并结果。配置示例：

thanos query --grpc-address=0.0.0.0:10901
  --http-address=0.0.0.0:9090
  --store=thanos-sidecar-cluster-a:10901
  --store=thanos-sidecar-cluster-b:10901
  --store=thanos-receive:10901
  --store=thanos-store-gateway:10901
  --query.replica-label=receive_replica
  --query.max-concurrency=20
  --query.timeout=2m

query.replica-label与Compact的deduplication.replica-label保持一致，Query在查询时对多副本数据做实时去重。query.max-concurrency控制并行查询数，在高并发查询场景下适当调大可提升吞吐，但会增加各Store后端的压力。

Store API端点通过–store参数注册。Query维护各端点的健康状态，若某个端点连续3次健康检查失败（默认间隔5s），将被暂时摘除并周期性重试。该机制保证了单集群故障不影响全局查询可用性。

查询性能优化与常见问题排查

跨集群查询的延迟主要来自三个环节：Store端点响应、网络传输、Query端合并。通过Thanos Query UI的/api/v1/status/buildinfo和prometheus_query_duration_seconds指标可定位瓶颈环节：

# 查询各阶段延迟分布
histogram_quantile(0.99,
  sum(rate(thanos_query_duration_seconds_bucket{operation="query"}[5m])) by (le)
)

# Store端点连接状态
thanos_store_nodes_grpc_connections{state="ACTIVE"}
thanos_store_nodes_grpc_connections{state="DISCONNECTED"}

常见问题之一是大范围时间查询OOM。查询90天数据时Store Gateway从对象存储拉取数百个Block，内存峰值可达数十GB。解决方法是缩小查询范围、使用降采样数据、或在Store Gateway前增加查询缓存层。Thanos 0.35+版本支持Lazy Block Loading，仅加载Block的元数据和索引，按需加载实际数据，有效降低内存峰值。

另一个常见问题是Series基数爆炸。某集群因暴露了高基数标签（如Pod名包含随机后缀），导致单个指标产生数十万条Series。Thanos的Store API对单次查询返回的Series数有上限（默认500000），超限时返回partial响应。通过Recording Rules预聚合或relabel_configs去除高基数标签是标准解决方案。