必须引入Thanos构建分布式数据归档架构：Sidecar上传TSDB块至对象存储，Store Gateway暴露历史数据查询接口，Query统一聚合去重，Compactor降采样压缩清理，MinIO/S3为底座，支持Docker/Helm/二进制等多部署模式。
要让 Prometheus 支持长期存储，必须引入 Thanos 构建分布式数据归档架构。它不替换 Prometheus，而是通过对象存储解耦数据生命周期与计算节点，实现无限扩展、跨集群聚合和低成本保留。
核心组件分工明确
Thanos 不是单体服务，而是由多个松耦合组件协同工作：
- Sidecar：紧贴每个 Prometheus 实例运行，定时将已完成的 TSDB 数据块（block）上传至对象存储，不影响主进程查询性能
- Store Gateway：从对象存储中加载历史块，暴露 StoreAPI，使老数据可被 PromQL 查询
- Query：统一查询入口，自动聚合本地 Sidecar + 远程 Store Gateway 的数据，并自动去重（如多副本 Prometheus 的相同指标）
- Compactor：定期合并小块、降采样（例如把 1m 粒度压缩为 5m/1h）、清理过期数据，降低存储成本与查询延迟
对象存储选型与配置要点
对象存储是 Thanos 长期存储的底座，MinIO 是最常用的自建方案，S3/GCS/Azure 适用于云环境。关键配置项包括：
- 使用
--objstore.config-file指向 YAML 文件，明确定义bucket、endpoint、认证凭据 - 内网部署 MinIO 时，务必设
insecure: true跳过 TLS 验证（否则连接失败） - 避免硬编码密钥，生产环境推荐用 IAM 角色或 Kubernetes Secret 注入凭证
- Bucket 名称需提前创建，且对所有 Thanos 组件保持一致
部署方式按场景选择
没有“最佳”，只有“最合适”：
- Docker Compose（测试/边缘）：适合快速验证，MinIO + Prometheus + Thanos 各组件容器化，5 分钟拉起全套
- 原生二进制 + systemd（合规/精简环境）：无 Docker 依赖，用专用系统用户管理服务，日志、资源、权限更可控
-
Helm Chart（K8s 生产）：集成 kube-prometheus-stack，通过
values.yaml启用 thanos.sidecar 和 thanosQuery，自动注入配置与 Service -
Remote Write（替代 Sidecar）：当 Prometheus 无法部署 Sidecar（如托管服务），改用
remote_write推送至 Thanos Receiver
关键配置不能漏
哪怕组件跑起来，缺了这些配置也查不到长期数据：
- Prometheus 必须启用
--web.enable-lifecycle，方便 Sidecar 触发 reload - 建议设置
--storage.tsdb.max-block-duration=2h，让块更小、上传更及时 - 所有 Prometheus 实例需配置唯一
external_labels（如{cluster="prod-us-east"}），否则 Query 无法区分来源 - Compactor 需单独部署并持续运行，否则对象存储中堆积的原始块不会被压缩或清理
