Prometheus高可用集群部署与Thanos长期存储方案配置实战

小编 • • 网站运维

Prometheus作为云原生监控的事实标准，其单点架构在大型生产环境中存在两个痛点：实例宕机导致监控数据丢失、本地TSDB无法支撑长期存储。Thanos通过Sidecar或Receiver模式扩展Prometheus，实现全局查询、长期存储和高可用。在生产中部署Prometheus+Thanos集群是构建企业级监控告警体系的标准方案。

Thanos架构组件与部署模式选型

Thanos由多个松耦合组件构成：

– Sidecar：部署在每个Prometheus实例旁，上传TSDB block到对象存储，并代理StoreAPI查询
– Query：全局查询聚合器，从多个StoreAPI数据源拉取并去重
– Store Gateway：从对象存储读取历史block提供查询
– Compactor：对对象存储中的block做降采样压缩
– Receiver：可选模式，直接接收remote_write数据，替代Sidecar

两种部署模式的选型：

Sidecar模式适合已有Prometheus集群的增量改造，每个Prometheus保留本地存储，Sidecar异步上传。Receiver模式适合全新部署，Prometheus不存本地数据，通过remote_write直发Receiver，更易实现高可用。

Sidecar模式部署配置

以docker-compose部署双Prometheus+Thanos集群为例：

version: '3.8'
services:
  prometheus-1:
    image: prom/prometheus:v2.54.0
    volumes:
      - ./prometheus1.yml:/etc/prometheus/prometheus.yml
      - prom-data-1:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--storage.tsdb.retention.time=48h'
      - '--web.enable-lifecycle'

  thanos-sidecar-1:
    image: thanosio/thanos:v0.36.0
    volumes:
      - prom-data-1:/prometheus
    command:
      - 'sidecar'
      - '--tsdb.path=/prometheus'
      - '--prometheus.url=http://prometheus-1:9090'
      - '--objstore.config-file=/etc/thanos/objstore.yml'
    depends_on:
      - prometheus-1

  thanos-query:
    image: thanosio/thanos:v0.36.0
    command:
      - 'query'
      - '--endpoint=thanos-sidecar-1:10900'
      - '--endpoint=thanos-sidecar-2:10900'
      - '--endpoint=thanos-store:10900'
      - '--query.replica-label=prometheus_replica'
    ports:
      - '9091:10902'

  thanos-store:
    image: thanosio/thanos:v0.36.0
    command:
      - 'store'
      - '--data-dir=/data'
      - '--objstore.config-file=/etc/thanos/objstore.yml'
    volumes:
      - store-data:/data

  thanos-compactor:
    image: thanosio/thanos:v0.36.0
    command:
      - 'compact'
      - '--data-dir=/data'
      - '--objstore.config-file=/etc/thanos/objstore.yml'
      - '--retention.resolution-raw=90d'
      - '--retention.resolution-5m=180d'
      - '--retention.resolution-1h=365d'
    volumes:
      - compactor-data:/data

volumes:
  prom-data-1:
  prom-data-2:
  store-data:
  compactor-data:

对象存储配置与MinIO本地化部署

Thanos支持S3、GCS、Azure Blob等多种对象存储。生产环境可使用MinIO部署兼容S3的本地存储：

# /etc/thanos/objstore.yml
type: S3
config:
  endpoint: minio:9000
  access_key: thanos-access-key
  secret_key: thanos-secret-key
  bucket: thanos-blocks
  insecure: true
  trace:
    enable: true

MinIO的docker-compose配置：

services:
  minio:
    image: minio/minio:latest
    ports:
      - '9000:9000'
      - '9001:9001'
    environment:
      MINIO_ROOT_USER: minio-admin
      MINIO_ROOT_PASSWORD: minio-admin-secret
    command: server /data --console-address ':9001'
    volumes:
      - minio-data:/data

初始化MinIO bucket：

mc alias set local http://minio:9000 minio-admin minio-admin-secret
mc mb local/thanos-blocks
mc policy set none local/thanos-blocks

Prometheus双副本配置与外部标签去重

高可用部署两个Prometheus实例采集相同目标，Thanos Query通过replica label去重。两个Prometheus配置文件：

# prometheus1.yml
global:
  scrape_interval: 15s
  external_labels:
    prometheus_replica: 'replica-1'
    cluster: 'production'

scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']
  - job_name: 'kubernetes-apiservers'
    kubernetes_sd_configs:
      - role: endpoints
    scheme: https
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
# prometheus2.yml - 仅external_labels不同
global:
  scrape_interval: 15s
  external_labels:
    prometheus_replica: 'replica-2'
    cluster: 'production'

关键点：两个Prometheus的external_labels中prometheus_replica值不同，cluster值相同。Thanos Query的–query.replica-label=prometheus_replica参数告诉Query按此label去重，对外暴露单一数据视图。

Thanos Query全局查询与数据去重机制

Thanos Query收到查询请求后，并行从所有StoreAPI endpoint拉取数据，然后按replica label去重。去重策略可选择：

thanos query   --endpoint=thanos-sidecar-1:10900   --endpoint=thanos-sidecar-2:10900   --endpoint=thanos-store:10900   --query.replica-label=prometheus_replica   --query.timeout=30s   --query.max-concurrent=20   --query.default-evaluation-interval=30s

去重算法：对于同一时间戳同一labelset的多个样本，Thanos默认取一个。可配置deduplication interval控制去重粒度：

--query.replica-label=prometheus_replica --query.partial-response=false

生产环境建议开启partial-response，单个StoreAPI故障不影响全局查询可用性。

Compactor降采样与长期存储优化

Compactor对对象存储中的TSDB block执行两层降采样：

– 5分钟粒度：原始数据聚合为5分钟间隔，保留90天
– 1小时粒度：5分钟数据再聚合为1小时间隔，保留365天

降采样大幅减少长期查询的数据扫描量。查询最近1小时数据走Sidecar实时数据，查询30天数据走Store Gateway的5分钟降采样block，查询1年数据走1小时降采样block。

Compactor配置中retention.resolution参数控制各级降采样数据的保留期。raw数据保留90天已足够覆盖大部分告警排查需求，更长的历史数据使用降采样版本即可。

Grafana对接Thanos Query与告警规则配置

Grafana直接将Thanos Query作为数据源：

# Grafana data source provisioning
apiVersion: 1
datasources:
  - name: Thanos
    type: prometheus
    access: proxy
    url: http://thanos-query:10902
    isDefault: true
    jsonData:
      timeInterval: '15s'

告警规则使用Thanos Ruler组件，独立于Prometheus运行，从Thanos Query拉取数据评估规则：

thanos rule   --data-dir=/data   --rule-file=/rules/alerts.yml   --alertmanagers.url=http://alertmanager:9093   --query=http://thanos-query:10902

告警规则示例：

# /rules/alerts.yml
groups:
  - name: node-resources
    rules:
      - alert: HighCPUUsage
        expr: |
          100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "CPU usage above 80% on {{ $labels.instance }}"

      - alert: PrometheusDown
        expr: |
          up{job="prometheus"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Prometheus instance {{ $labels.instance }} is down"

Receiver模式高可用部署

Receiver模式适合大规模部署，Prometheus通过remote_write将数据直接发送给Receiver，不再依赖本地存储：

# prometheus.yml (Receiver模式)
remote_write:
  - url: http://thanos-receiver:19291/api/v1/receive
    queue_config:
      capacity: 10000
      max_shards: 200
      max_samples_per_send: 5000

remote_read:
  - url: http://thanos-query:10902/api/v1/read
# Receiver配置
thanos receive   --remote-write.address=0.0.0.0:19291   --grpc-address=0.0.0.0:10900   --http-address=0.0.0.0:10902   --data-dir=/data   --objstore.config-file=/etc/thanos/objstore.yml   --label=receive_replica=="receiver-1"

Receiver模式需要部署多副本并通过Hashring路由实现分片，每个Receiver只处理一部分租户数据，避免单点瓶颈。Receiver收到数据后写入本地TSDB，再由自身上传到对象存储，角色上替代了Sidecar。

集群运维与故障排查

常见故障排查命令：

# 检查Thanos组件健康状态
curl http://thanos-query:10902/-/healthy
curl http://thanos-sidecar-1:10902/-/healthy

# 查看Sidecar上传状态
curl http://thanos-sidecar-1:10902/api/v1/info | jq

# 查看Store Gateway缓存命中
curl http://thanos-store:10902/metrics | grep thanos_store_

# 查询全局指标（验证去重）
curl 'http://thanos-query:10902/api/v1/query?query=up'

Sidecar上传失败的常见原因：对象存储权限不足、bucket不存在、网络不通。排查步骤：

# 查看Sidecar日志
docker logs thanos-sidecar-1 2>&1 | grep -i error

# 手动测试S3连接
mc ls local/thanos-blocks

# 检查block上传情况
curl http://thanos-sidecar-1:10902/api/v1/blocks | jq '.blocks | length'

Query延迟过高通常因Store Gateway从对象存储拉取大量block，可增加Store Gateway的缓存配置：

thanos store   --index-cache-size=1GB   --chunk-pool-size=2GB   --max-concurrency=20

合理的cache配置可将Store Gateway查询延迟从秒级降至百毫秒级。对于超过30天的历史查询，1小时降采样数据量已极小，延迟通常在200ms以内。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/prometheus-gao-ke-yong-ji-qun-bu-shu-yu-thanos-chang-qi-cun/

赞 (0)
小编小编
0
上一篇 13小时前
下一篇 13小时前

相关推荐