Prometheus 长期存储详解：突破本地存储限制，实现无限留存与全局查询

Prometheus 长期存储详解：突破本地存储限制，实现无限留存与全局查询

Prometheus 默认使用本地时间序列数据库（TSDB） 存储指标数据，虽然性能优异，但存在存储周期有限、不支持水平扩展、缺乏高可用等局限。在生产环境中，通常需要保留数月甚至数年的监控数据用于趋势分析、合规审计和根因回溯。

本文将深入解析 Prometheus 的本地存储限制，并详解主流的远程长期存储方案，包括 Thanos、Cortex、M3DB 等，帮助你构建一个可扩展、高可用、支持长期存储的监控体系。

---

一、Prometheus 本地存储的限制

1. 默认保留策略

# prometheus.yml
storage:
  tsdb:
    retention.time: 15d  # 默认 15 天

• ✅ 可配置为 30d, 90d 等
• ❌ 无法无限存储
• ❌ 存储受限于本地磁盘容量

2. 主要局限

问题	说明
存储周期有限	通常保留 15 天到 3 个月，超出后自动删除
单节点架构	无高可用，宕机即丢失写入能力
无法水平扩展	不能通过增加节点来扩展存储容量
无全局视图	多个 Prometheus 实例的数据无法聚合查询
备份恢复困难	需手动备份 data/ 目录，恢复复杂

✅ 本地存储适合短期、高性能监控，但不满足生产级长期存储需求。

---

二、远程存储（Remote Storage）集成方案

为解决上述问题，Prometheus 提供了 Remote Write 和 Remote Read 接口，可将数据发送到外部系统进行长期存储和查询。

核心机制

• Remote Write：Prometheus 将样本数据推送到远程存储系统
• Remote Read：Prometheus 或查询层从远程系统拉取历史数据

✅ 支持与多种长期存储后端集成

---

三、主流长期存储方案对比

方案	类型	架构	存储后端	是否支持全局查询	高可用
Thanos	开源扩展	Sidecar + Querier + Store Gateway	S3, GCS, MinIO	✅ 支持（Global View）	✅
Cortex / Mimir	多租户平台	分布式微服务	S3, GCS, Cassandra	✅ 支持	✅
VictoriaMetrics	高性能替代	单机或集群	本地或 S3	✅ 支持	✅
M3DB	时序数据库	分布式 TSDB	本地或云存储	✅ 支持	✅
InfluxDB	商业/开源 TSDB	单机或集群	本地	❌（需 Flux 聚合）	✅

✅ Thanos 和 Cortex 是云原生生态中最主流的选择。

---

四、1. Thanos：最流行的 Prometheus 扩展方案

Thanos 是 CNCF 毕业项目，为 Prometheus 提供长期存储、全局查询、高可用和压缩能力。

4.1 架构组件

核心组件

组件	作用
Sidecar	部署在 Prometheus 旁，支持 Remote Write 和 TSDB 快照上传
Store Gateway	从对象存储读取历史数据，供查询
Querier	实现全局 PromQL 查询，聚合 Sidecar 和 Store Gateway 的数据
Compactor	对对象存储中的数据进行压缩和降采样
Ruler	远程评估 Recording/Alerting Rules

4.2 优势

• ✅ 无限存储：基于对象存储（S3/GCS）
• ✅ 全局查询：跨多个 Prometheus 实例聚合查询
• ✅ 高可用：多副本、自动故障转移
• ✅ 降采样：长期数据自动聚合（如 1h avg）
• ✅ 兼容 Prometheus API

4.3 部署方式

• Kubernetes：使用 Helm Chart（thanos-community/thanos）
• 二进制：直接运行组件
• Operator：Thanos Operator

✅ 适合多集群、多环境统一监控。

---

五、2. Cortex / Mimir：多租户 Prometheus as a Service

Cortex 最初由 Grafana Labs 开发，Mimir 是其演进版本，提供多租户、水平扩展、SaaS 风格的 Prometheus 存储。

5.1 架构特点

核心组件

组件	作用
Distributor	接收写入请求，做一致性哈希
Ingester	暂存近期数据，定期刷盘到对象存储
Querier	查询历史和实时数据
Store Gateway	从对象存储读取数据
Ruler	评估告警和记录规则

5.2 优势

• ✅ 多租户支持：适合 SaaS 或多团队环境
• ✅ 水平扩展：可扩展到 PB 级数据
• ✅ 与 Grafana 深度集成
• ✅ 支持长期存储和高可用

5.3 适用场景

• 多租户平台
• 大型企业统一监控
• 作为 Prometheus 托管服务

---

六、3. VictoriaMetrics：高性能、低成本替代方案

VictoriaMetrics 是一个高性能、低成本的 Prometheus 兼容监控系统，支持单机和集群模式。

特点

• ✅ 写入和查询性能是 Prometheus 的 10-50 倍
• ✅ 存储压缩率高（磁盘占用更小）
• ✅ 支持 Remote Write/Read
• ✅ 集群版支持水平扩展和长期存储
• ✅ 资源消耗低（适合边缘环境）

架构

✅ 适合资源受限或对性能要求极高的场景。

---

七、4. M3DB：Uber 开源的分布式 TSDB

M3DB 是 Uber 开发的分布式时序数据库，支持 Prometheus 协议。

特点

• ✅ 分布式架构，支持水平扩展
• ✅ 强一致性、高可用
• ✅ 支持降采样和保留策略
• ✅ 适用于大规模指标存储

缺点

• 复杂度高，运维成本高
• 社区活跃度低于 Thanos/Cortex

✅ 适合已有 M3 生态的公司。

---

八、方案选择建议

需求	推荐方案
简单长期存储 + 全局查询	✅ Thanos（最流行）
多租户、SaaS 平台	✅ Cortex / Mimir
高性能、低成本	✅ VictoriaMetrics
已有 M3 生态	✅ M3DB
Kubernetes 环境	✅ Thanos（Helm 部署）
云环境（AWS/GCP）	✅ Thanos + S3/GCS

---

九、部署架构示例（Thanos + S3）

# prometheus.yml
remote_write:
  - url: "http://thanos-receiver:19291/api/v1/receive"

# thanos-sidecar.yml
args:
  - --tsdb.path=/prometheus
  - --prometheus.url=http://localhost:9090
  - --objstore.config-file=/etc/thanos/s3.yml

# s3.yml（对象存储配置）
type: S3
config:
  bucket: prometheus-data
  endpoint: s3.amazonaws.com
  region: us-east-1
  access_key: XXX
  secret_key: YYY

---

十、最佳实践

实践	说明
✅ 启用压缩和降采样	减少长期存储成本
✅ 定期验证数据可读性	防止对象存储损坏
✅ 备份关键配置	rules.yml, alertmanager.yml
✅ 监控远程写入延迟	prometheus_remote_storage_succeeded_samples_total
✅ 使用 Thanos Querier 统一查询入口	Grafana 指向 Querier

---

十一、总结

Prometheus 本地存储适合短期监控，但长期存储必须依赖外部系统。

三大主流方案：

方案	优势	适用场景
Thanos	全局查询、简单集成、社区强大	大多数生产环境
Cortex / Mimir	多租户、水平扩展	SaaS、大企业
VictoriaMetrics	高性能、低资源	边缘、高吞吐场景

✅ 推荐路径：

1. 先用本地存储（15-90 天）
2. 引入 Thanos 实现长期存储和全局视图
3. Grafana 指向 Thanos Querier

通过合理选择长期存储方案，你可以构建一个无限留存、高可用、可扩展的云原生监控系统，真正实现“历史可查、趋势可析、根因可溯”。