Grafana Mimir 实战：Prometheus 大规模长期存储的终极方案

痛点

运维监控体系发展到一定规模后，Prometheus 单机存储瓶颈就成了无法回避的问题：

存储容量有限：默认本地 TSDB 保留 15 天数据，磁盘扩到 TB 级后性能急剧下降
无法水平扩展：单个 Prometheus 实例承载上万 series 后内存飙升，OOM 频发
多集群数据孤岛：10+ 个 K8s 集群各跑一套 Prometheus，跨集群查询基本不可能
高可用缺失：Prometheus 挂了就丢数据，双副本方案数据不一致

Thanos 是早期方案，但 Sidecar 模式运维复杂、Compactor 单点问题让人头疼。2022 年 Grafana Labs 开源了 Grafana Mimir，一个为大规模生产环境设计的 Prometheus 长期存储方案——原生多租户、水平扩展、兼容 PromQL，目前已成为 CNCF 生态中最成熟的远程存储选择之一。

方案：Mimir 核心架构

Grafana Mimir 采用微服务架构，核心组件分三层：

层级	组件	职责
写入层	Distributor → Ingester	接收 remote_write，分片写入内存，定期刷盘到对象存储
存储层	Object Storage (S3/GCS/MinIO)	持久化 TSDB Block，成本低至 $0.023/GB/月
查询层	Query-frontend → Querier → Store-gateway	拆分/缓存/并行查询，从 Ingester + 对象存储聚合结果

关键优势： - 所有组件无状态（Ingester 有 WAL 做短暂缓冲），挂了自动恢复 - 原生多租户隔离，一套集群服务所有团队 - 兼容 Prometheus remote_write v1/v2 协议，零改造接入

实操步骤

第 1 步：部署 Mimir（Helm 方式）

生产环境推荐使用官方 Helm Chart 的微服务模式：

# 添加 Grafana Helm 仓库
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

# 创建 namespace
kubectl create namespace mimir

# 安装（微服务模式）
helm install mimir grafana/mimir-distributed \
  --namespace mimir \
  --set mimir.structuredConfig.common.storage.backend=s3 \
  --set mimir.structuredConfig.common.storage.s3.endpoint=s3.amazonaws.com \
  --set mimir.structuredConfig.common.storage.s3.bucket_name=mimir-tsdb-prod \
  --set mimir.structuredConfig.common.storage.s3.region=us-east-1 \
  --set mimir.structuredConfig.limits.ingestion_rate=150000 \
  --set mimir.structuredConfig.limits.max_global_series_per_user=5000000 \
  --values mimir-values.yaml

关键 values 文件配置（mimir-values.yaml）：

# mimir-values.yaml
ingester:
  replicas: 3
  persistentVolume:
    size: 50Gi          # WAL 缓冲，不需太大
  resources:
    requests:
      memory: 8Gi
      cpu: "2"

distributor:
  replicas: 2

querier:
  replicas: 3

store_gateway:
  replicas: 2
  persistentVolume:
    size: 20Gi          # Block 索引缓存

query_frontend:
  replicas: 2

compactor:
  replicas: 1
  persistentVolume:
    size: 100Gi         # 压缩临时空间

第 2 步：配置 Prometheus Remote Write

在已有 Prometheus 上添加 remote_write 配置，零侵入接入：

# prometheus.yml 追加
remote_write:
  - url: http://mimir-distributor.mimir.svc:8080/api/v1/push
    headers:
      X-Scope-OrgID: "team-infra"    # 租户标识
    queue_config:
      max_samples_per_send: 5000
      batch_send_deadline: 5s
      max_shards: 20                  # 并发写入分片数
    write_relabel_configs:
      - source_labels: [__name__]
        regex: "go_.*"                # 过滤无用指标，节省存储
        action: drop

多集群场景下，每个集群的 Prometheus 使用不同的 external_labels 区分来源：

global:
  external_labels:
    cluster: "prod-us-east-1"
    environment: "production"

第 3 步：Grafana 对接查询

在 Grafana 中添加 Mimir 作为 Prometheus 类型数据源：

URL: http://mimir-query-frontend.mimir.svc:8080/prometheus
Custom HTTP Headers:
  X-Scope-OrgID: team-infra

此时即可用标准 PromQL 查询跨集群、跨时间段的数据——查 1 年前的 CPU 趋势和查 5 分钟前一样流畅。

第 4 步：配置数据保留与压缩策略

# Mimir 运行时配置
limits:
  compactor_blocks_retention_period: 365d   # 保留 1 年
  max_global_series_per_user: 5000000       # 总 series 上限
  ingestion_rate: 150000                    # 样本/秒 写入速率

compactor:
  compaction_interval: 1h
  deletion_delay: 12h                        # 延迟删除，防误操作

避坑指南

1. Ingester OOM —— 最常见的翻车场景

原因：高基数（high cardinality）指标爆炸，比如把 user_id、request_id 放进 label。

解决：

# 限制每个租户的活跃 series
limits:
  max_global_series_per_user: 3000000
  max_label_names_per_series: 30
  max_label_value_length: 2048

# 在 Prometheus 端用 relabel 提前过滤
write_relabel_configs:
  - source_labels: [__name__]
    regex: "(apiserver_request_duration_seconds_bucket)"
    action: drop    # histogram bucket 占 series 大户

2. 查询超时 —— 大范围查询返回空

原因：Query-frontend 默认拆分粒度太大，或 Store-gateway 冷启动未加载索引。

解决：

query_frontend:
  split_queries_by_interval: 24h    # 按天拆分大查询
  max_retries: 3
  cache_results: true
  results_cache:
    backend: memcached
    memcached:
      addresses: "memcached.mimir.svc:11211"

3. S3 成本失控 —— 存储费没多少，请求费吓死人

原因：未开启 Compactor 压缩，2h 小 Block 堆积，GET 请求爆炸。

解决： - 确保 Compactor 正常运行，将小 Block 合并为 24h 大 Block - 启用 Store-gateway 的索引缓存（bucket index），减少 LIST/GET 调用 - 使用 S3 Intelligent-Tiering，冷数据自动降级

# 检查 Compactor 状态
kubectl logs -n mimir deploy/mimir-compactor --tail=50 | grep -i "compaction"
# 正常应看到：level=info msg="compaction completed"

生产规模参考

规模	活跃 Series	写入速率	Ingester	月存储成本 (S3)
小型	100 万	2 万样本/秒	3 副本 × 4Gi	~$15
中型	500 万	10 万样本/秒	3 副本 × 16Gi	~$80
大型	2000 万	50 万样本/秒	6 副本 × 32Gi	~$350

总结

Prometheus 长期存储选型：2026 年生产环境首选 Grafana Mimir，架构成熟、社区活跃
核心收益：无限水平扩展 + 对象存储低成本 + 原生多租户 + 完全兼容 PromQL
迁移路径：remote_write 一行配置接入，不动现有 Prometheus 部署
成本关键：控制 series 基数 > 压缩策略 > 存储层选择，三管齐下

对比 Thanos：Mimir 无需 Sidecar、Compactor 原生支持多租户隔离、查询性能更优。如果你的监控规模超过 200 万活跃 series 或需要 90 天以上数据保留，Mimir 是目前最省心的选择。