Thanos 是 Prometheus 官方生态中最主流的高可用与长期存储方案，它没有推翻 Prometheus 的架构，而是在其之上做了优雅的扩展。对于一个正在做 Vue 3 中后台工程化改造的团队来说，把前端构建产物、Node 服务、网关和业务接口全部纳入统一监控，Thanos 几乎是绕不开的一环。这篇文章从架构原理讲到落地配置，帮你理解如何在现有工程体系中平稳接入 Thanos。
Thanos 解决了 Prometheus 的哪些痛点
原生 Prometheus 有三个先天限制。第一，它是单机数据库，TSDB 数据保存在本地磁盘，一旦实例挂掉，监控查询直接中断；第二，Prometheus 的 HA 传统上靠两个实例重复抓取同一批目标实现，但查询时需要在外层做去重，Grafana 里经常出现锯齿状的双曲线；第三，本地存储受磁盘容量限制，通常只能保留半个月到一个月的数据，年度级别的容量规划回溯根本做不了。
Thanos 的思路是保留 Prometheus 本体不动，通过一个 Sidecar 容器和 Prometheus 部署在一起，把 TSDB 的 block 周期性上传到对象存储（比如 S3、MinIO、OSS）。这样一来，本地磁盘只是缓存，真正的数据主权在对象存储上，而对象存储本身具备极高的持久性和极低的单位成本。查询侧则由 Thanos Querier 统一接收，它会对多个 Prometheus 实例和对象存储中的历史数据做去重合并，最终呈现给用户一条平滑的曲线。
这套架构的最大好处是侵入性极低。Prometheus 的配置文件、告警规则、Recording Rules 都不需要大改，团队已有的使用习惯可以完整保留，这也是它比 Cortex、VictoriaMetrics 迁移成本更低的原因。
核心组件与部署形态选择
Thanos 的核心组件包括 Sidecar、Querier、Store Gateway、Compactor、Ruler 和 Receive。Sidecar 负责上传 block 并暴露 StoreAPI；Querier 是全局查询入口，通过 gRPC 连接各个数据源；Store Gateway 从对象存储读取历史 block 提供查询；Compactor 负责压实和降采样，把 5 分钟和 1 小时精度的聚合数据生成出来，长期查询才能跑得动；Ruler 提供跨实例统一的规则计算；Receive 则是无查询端拉取场景下的远端写入接收器。
接入方式上有一个关键选择：Sidecar 模式还是 Receive 模式。Sidecar 模式保留了 Prometheus 主动抓取的模型，Prometheus 即使与 Thanos 断连也能独立工作，稳定性更好，是绝大多数场景的推荐方案。Receive 模式则让各个集群把数据通过 remote_write 推到中心，适合抓取目标分布在多个网络分区、中心侧无法主动访问边缘的场景，代价是 Receive 本身成为写入的关键路径，需要额外考虑其高可用和去重。对于 Vue 3 中后台这种通常部署在同一云内网的场景，Sidecar 模式完全够用。
下面是一个 Sidecar 的典型 Kubernetes 配置片段，重点是对象存储的密钥挂载和 prometheus 参数必须开启 TSDB 外部标签：
containers:
- name: thanos-sidecar
image: thanosio/thanos:v0.34.0
args:
- sidecar
- --tsdb.path=/prometheus/data
- --prometheus.url=http://localhost:9090
- --objstore.config-file=/etc/thanos/objstore.yml
volumeMounts:
- name: data
mountPath: /prometheus/data
- name: objstore
mountPath: /etc/thanos
volumes:
- name: objstore
secret:
secretName: thanos-objstore
objstore.yml 里配置 MinIO 或 S3 的 endpoint、bucket 和访问凭证即可。注意 Prometheus 启动参数要加上 --storage.tsdb.min-block-duration=2h 和 --storage.tsdb.max-block-duration=2h，两者保持一致，这是 Thanos 官方要求的写法，能保证 block 边界整齐，避免上传碎片。
查询层整合与前端可视化打通
Querier 部署好后，Grafana 的数据源直接指向 Querier 地址即可。去重靠的是 Prometheus 的 external_labels，给每个实例打上 cluster 和 replica 标签，Querier 查询时开启 --query.replica-label=replica，双实例采集的数据会自动合并成一条。这一点经常被忽略，如果没配 replica 标签，你会看到所有曲线的值都变成两倍。
在 Vue 3 管理后台的工程化场景下，往往还需要把监控面板嵌到自己的系统里。方案通常有两类：一是用 iframe 嵌 Grafana 面板，配置匿名只读访问，集成最快；二是直接通过 Querier 的 HTTP API 查询，用 ECharts 自绘。第二种方式的查询接口示例如下：
async function queryRange(metric: string, start: number, end: number) {
const step = Math.max(15, Math.floor((end - start) / 300));
const url = `http://thanos-querier:9090/api/v1/query_range?query=${encodeURIComponent(metric)}&start=${start}&end=${end}&step=${step}s`;
const res = await fetch(url);
const json = await res.json();
// status 为 success 时解析 data.result 中的矩阵序列
return json.status === 'success' ? json.data.result : [];
}
需要注意的是查询步长的选择。Thanos 查询长期数据时依赖 Compactor 产生的降采样 block，如果查询时间跨度大但 step 设得太小，Store Gateway 会扫描海量原始数据导致超时。一个实用经验是让 step 随时间跨度自适应，比如一年跨度的查询 step 放到 1 小时以上，面板响应能从十几秒降到一秒以内。
前端指标方面，可以借助 prometheus-vlibs 这类库在 Vue 3 应用内埋点，把页面加载耗时、路由切换延迟、接口错误率通过 Pushgateway 或者自建的 metrics 接口暴露出来，最终也汇入同一套 Thanos 体系，实现前后端指标在同一个面板上对照排查。
数据保留策略与常见踩坑
保留策略要在三层协同设置：Prometheus 本地保留 --storage.tsdb.retention.time=48h 左右，只作为故障缓冲；对象存储里由 Compactor 的 --retention.resolution-raw、--retention.resolution-5m、--retention.resolution-1h 分别控制三个精度的保留周期，比如原始数据留 30 天、5 分钟精度留半年、1 小时精度留三年。这样既满足实时排查，又能支撑年度容量分析。
踩坑方面最常见的是对象存储的时钟与权限问题。Sidecar 上传 block 前会做一致性校验，如果 MinIO 集群节点之间时间不同步，会报 block 过期的错误。另外 Compactor 必须以单实例运行，多副本会争抢压实导致数据损坏，部署时记得配上去重的 StatefulSet 或者使用 Thanos Receive Compactor 的高级哈希分片模式。
最后提醒一点，Sidecar 的 --min-time 和 --max-time 参数控制 StoreAPI 暴露的时间窗口，默认配置在某些版本下会导致 Querier 查不到近期数据，升级 Thanos 版本时务必核对这些默认值的变化。整体来说，只要把 external_labels、block 时长、降采样这三件事做对，Thanos 的运行会非常省心，为整个 Vue 3 工程化体系提供一个可以长期信赖的可观测底座。
ThanosPrometheus高可用Vue 3监控修改时间：2026-09-07 12:20:45