Thanos 0.42.4 介绍与选型指南

Thanos 0.42.4 介绍与选型指南：Prometheus 长期存储与全局视图方案的项目背景、六大组件架构、功能特性、适用限制及与 VictoriaMetrics/Mimir/Cortex 等同类方案量化对比。

ThanosThanos监控2026/10/20

Thanos 0.42.4 介绍与选型指南

目标：全面介绍 Prometheus 长期存储与全局视图方案 Thanos 的项目背景、组件架构、功能特性与选型对比，帮助读者判断是否引入 Thanos 以及与同类方案如何取舍。本文数据均来自官方渠道联网溯源（查询日期 2026-10-20）。

一、环境信息

本文为认知篇，仅联网溯源，未做本地实测。溯源渠道与查询日期如下：

二、软件概述

2.1 项目定位

Thanos（以漫威角色"灭霸"命名）是一套基于对象存储构建的、高可用 Prometheus 长期存储与全局查询方案。它通过在多个 Prometheus 实例之上叠加一组无状态/有状态组件，解决原生 Prometheus 的三大痛点：

  • 本地 TSDB 存储受单机磁盘容量限制，历史数据只能保留数天到数周；
  • 多个独立 Prometheus 实例（分片/多副本）数据割裂，无法一站式查询；
  • 原生方案缺乏跨实例去重、统一告警评估与长期数据降采样能力。

2.2 项目背景与治理

  • 项目 2018 年由 Improbable 发起，采用 Apache-2.0 许可证；
  • 2019 年 7 月 14 日被 CNCF 接受（来源：CNCF TOC projects.md，查询日期 2026-10-20），目前为 CNCF 孵化（Incubating）项目；
  • 开发语言 Go（无 JVM 依赖，单二进制交付），架构上深度复用 Prometheus 组件库（promql、tsdb、scrape 等均直接 import 官方包）。

2.3 版本与社区活跃度（实查数据）

维度数据来源
最新稳定版v0.42.4（2026-07-30 发布）GitHub releases.atom，查询日期 2026-10-20
版本节奏平均 1~2 个月一个 minor 版本，patch 跟进及时同上
GitHub Stars约 14kshields.io 徽章，查询日期 2026-10-20
构建工具链Go 1.26.5v0.42.4 二进制版本信息
CNCF 治理2019-07-14 进入 CNCFCNCF TOC 台账

💡 说明：Thanos 采用多组件单二进制发布，同一个 thanos 可执行文件通过子命令（sidecar/query/store/compact/rule/receive/query-frontend）扮演不同角色，升级时全组件统一换版本即可。

三、核心架构

3.1 总体设计：Prometheus 不动，外挂一套侧车体系

Thanos 的核心设计哲学是不修改 Prometheus 本身：每个 Prometheus 实例旁边部署一个 Sidecar，通过共享本地 TSDB 目录读取数据块、通过 Prometheus HTTP API 读取实时数据，再把历史数据块归档到对象存储（S3/GCS/Azure/OSS/COS/Swift/本地文件系统均支持）。查询侧由 Query 组件聚合所有数据源并按 external label 去重。

数据流可以概括为：

Prometheus(带 external_labels) → Sidecar → 对象存储(Bucket)
                                              ↓ Store Gateway（提供历史块查询）
告警/记录规则 → Ruler → Query（PromQL 全局查询、去重）
实时查询    → Query → Sidecar（近实时）
降采样/压缩 → Compactor（对 Bucket 里的块做降采样与保留清理）
流式接入    → Receive（远程写入无状态收数）→ 自有 TSDB → 上传 Bucket
查询缓存    → Query Frontend（缓存/拆分查询）

3.2 六大组件职责表

组件角色是否有状态关键端口（默认）一句话职责
Sidecar代理否gRPC 10901 / HTTP 10902连接本机 Prometheus：上传 TSDB 块到对象存储、代理近实时查询、热加载配置
Query查询聚合否gRPC 10904 / HTTP 10902实现 StoreAPI 聚合，提供完整 PromQL 与 Web UI，跨数据源去重
Store Gateway历史块网关是（本地索引缓存）gRPC 10901 / HTTP 10902只读挂载对象存储中的历史块，按需拉取 chunk，支持索引缓存与筛选
Compactor压实/降采样是HTTP 10902对桶内块做水平压实、5m/1h 降采样与保留期清理（单桶单实例）
Ruler规则评估是gRPC 10902 / HTTP 10902对全局视图执行告警/记录规则，把结果落成块上传对象存储
Receive远程写入是HTTP 10902 / 远程写 19291接收 Prometheus remote_write，经 hashring 分片写入自有 TSDB 并上传
Query Frontend查询网关否HTTP 10902查询结果缓存、按时间拆分与并发下推，加速大范围查询

💡 技术拓展：Thanos 的"数据源发现"有多种服务发现机制可选——

机制原理适用场景
静态配置（--endpoint / endpoint 配置文件）Query 直接写死各 StoreAPI 地址组件少、拓扑稳定的环境
DNS 服务发现目标写 DNS 名，周期解析 A 记录K8s Headless Service / 内网 DNS
StoreAPI 文件 SD（store.sd-files）监视 JSON 文件变化动态加减端点与配置管理系统联动

本文部署实践中采用静态 endpoint 配置文件方式，简单直观、无需额外设施。

3.3 数据存储模型：一切皆块（Block）

Thanos 把"长期存储"问题收敛为"管理一组不可变 TSDB 块"：

  • Prometheus 每 2 小时（默认）产出一个块，Sidecar 上传后即不可变；
  • 每个块带 meta.json（来源、压缩级别、外部标签、时间范围）；
  • Compactor 按水位把小块压实成更大块，并生成 5m/1h 降采样块；
  • 查询时按块 meta 与时间范围做裁剪，只拉需要的 chunk。

💡 技术拓展：监控长期存储的对象存储选型对比——

类型代表特点适用场景
公有云对象存储S3/GCS/OSS/COS/Azure无限容量、高持久化生产首选
自建对象存储MinIO/Ceph RGW兼容 S3 协议、自主可控私有化环境
本地文件系统FILESYSTEM零依赖、共享目录即可实验与小型部署

本文各部署篇实测采用 FILESYSTEM 后端打通全链路，生产环境建议替换为 S3 兼容后端。

四、功能特性

  • 全局查询视图：Query 聚合 Sidecar/Store Gateway/Receive/Ruler/下级 Query 等全部 StoreAPI 端点，一个 PromQL 查所有环境；
  • 副本去重：基于 external label（如 replica=A/B）与可插拔去重函数（penalty 等）对多副本数据自动去重；
  • 无限历史：数据落在对象存储，保留期只受桶策略约束，本地 TSDB 可缩到数小时；
  • 自动降采样：Compactor 自动产出 5m/1h 分辨率数据，大时间跨度查询自动命中低分辨率块；
  • 全局告警：Ruler 可挂接全局规则，评估结果支持推送 Alertmanager 并落块存储；
  • 水平扩展接入：Receive 以 hashring 分片接收 remote_write，支持多副本与租户；
  • 查询加速：Query Frontend 提供查询结果缓存与时间拆分；Store Gateway 提供索引缓存（in-memory/memcached）；
  • 运维工具链：thanos tools bucket 子命令提供桶校验/巡检/重写/复制/清理等日常运维能力，tools rules-check 提供规则文件校验；
  • 兼容性：完整兼容 PromQL 与 Prometheus HTTP API（查询接口可无缝对接 Grafana），支持 Prometheus 2.x/3.x 作为数据源。

五、快速开始（官方路径）

Thanos 官方《Getting Started》推荐的最快路径是使用仓库内置的 Compose 示例（监控栈一键拉起 Prometheus + Thanos 全组件 + Grafana），命令形态如下（来源：官方文档 https://thanos.io/tip/thanos/getting-started.md/ ，查询日期 2026-10-20）：

git clone https://github.com/thanos-io/thanos.git
cd thanos/tutorials/getting-started
docker compose up -d

💡 说明：该示例依赖 Docker Compose。若希望以二进制 + systemd 方式在 Ubuntu 服务器上从零部署 Thanos 全组件，请直接阅读本专栏《Thanos 0.42.4 部署指南》与《Ubuntu 22.04 安装 Thanos 0.42.4 指南》；Thanos 依赖的 Prometheus 服务端安装可参考《Ubuntu 24.04 安装 Prometheus 3.x》（点击跳转）。

六、适用场景与限制

6.1 适合引入 Thanos 的场景

  • Prometheus 集群数量多（多机房/多业务线/多套 K8s），需要统一查询入口；
  • 监控数据要求保留 3 个月以上，且不能接受采样丢失（需要降采样分层）；
  • 需要跨副本高可用查询与自动去重；
  • 希望告警规则独立于数据源生命周期（Ruler + 对象存储）。

6.2 限制与代价

  • 组件数量多，引入后至少新增 4~6 个服务，运维复杂度显著上升；
  • Compactor 对同一个桶必须单实例运行（并发压实会造成数据重叠冲突）；
  • Sidecar 与 Prometheus 必须同机部署（共享 TSDB 目录），限制了弹性调度；
  • 对象存储 API 调用量与查询延迟直接相关，需要配好 Store Gateway 缓存；
  • 版本升级需全组件同步（官方建议同集群内组件版本保持一致）。

七、同类选型对比

Prometheus 长期存储/全局视图方案的主流候选如下（社区数据查询日期 2026-10-20）：

方案形态存储引擎全局视图多副本去重降采样运维复杂度社区活跃度
Thanos外挂多组件复用 Prometheus TSDB 块 + 对象存储✅ Query 聚合✅ external label✅ 5m/1h中高CNCF 孵化，~14k stars
VictoriaMetrics单进程集群版自研 LSM（vmstorage）✅ 原生✅ 原生✅ 自动低（组件少）~14k stars
Grafana Mimir微服务（可单二进制）自研块 + 对象存储✅ 原生✅ 原生✅ 原生中高~4k+ stars
Cortex微服务（Mimir 上游）自研块 + 对象存储✅ 原生✅ 原生✅ 原生高维护趋缓，重心转 Mimir
M3微服务自研（M3DB）✅✅✅高活跃度下降
Graphite传统三件套Whisper 文件⚠️ 聚合需 cluster❌⚠️ 轮询归档中老牌，迭代缓慢
InfluxDB单机/集群TSM/IOx⚠️ 需联邦❌✅低~中商业主导

量化维度说明：Stars 数据取自 shields.io 徽章（查询日期 2026-10-20）；"运维复杂度"按部署组件数与状态组件占比综合评估；Mimir 数据取自其官方仓库。

选型建议：

  • 已有大量原生 Prometheus、希望"渐进式"获得长期存储与全局查询 → Thanos（不改 Prometheus、可按需启用组件，与现有生态零迁移成本）；
  • 希望一套组件解决所有问题、追求更低资源开销与更简单运维 → VictoriaMetrics（vmagent/vminsert/vmselect/vmstorage，部署组件比 Thanos 少）；
  • 大规模多租户 SaaS 化监控、需要严格隔离 → Grafana Mimir；
  • 历史遗留 Whisper 体系且无迁移动力 → Graphite 维持现状；
  • 已深度投入 InfluxDB 生态 → InfluxDB 继续使用，新监控体系不建议。

💡 提示：Thanos 与 VictoriaMetrics 并非互斥——不少团队用 vmagent 抓取 + VictoriaMetrics 存储，同时保留 Thanos 管理既有 Prometheus 集群，按业务分域选型。

八、参考链接