Thanos是围绕Prometheus构建的大规模监控扩展方案，它解决了原生Prometheus在长期存储、全局视图和高可用三个维度上的短板。原生Prometheus单机存储受本地磁盘限制，一旦实例宕机，历史数据就面临丢失风险；同时多个Prometheus实例之间数据彼此隔离，无法做跨集群的全局聚合查询。Thanos通过引入对象存储作为统一的数据底座，配合一组松耦合的组件，把Prometheus的监控能力扩展到PB级别。本文将从核心架构、数据接入模式、查询去重机制以及生产部署实践几个方面，详细拆解这套方案。
Thanos核心组件与整体架构
Thanos的架构设计遵循"拥抱Prometheus"的理念，不重写采集层，而是在Prometheus外围叠加扩展组件。整套体系由Sidecar、Store Gateway、Compactor、Query、Query Frontend、Receiver和Ruler等组件构成，每个组件只做一件事，通过对象存储桶解耦数据的生产与消费。
Sidecar以容器形式与Prometheus运行在同一Pod中，它做了两件关键的事：一是读取Prometheus的数据目录，把TSDB块（block）上传到对象存储，实现数据的异地长期保存；二是暴露一个StoreAPI的gRPC端点，让Query组件可以直接查询该Prometheus近期的内存数据。StoreAPI是Thanos的精髓所在，所有数据源（Sidecar、Store Gateway、Receiver）都实现这套统一接口，Query因此可以用同一套协议访问任意位置的数据。
Store Gateway负责从对象存储中读取历史数据块并对外提供查询服务，Compactor则负责对存储桶中的块做降采样和压缩，将2小时的小块合并成更大的块，同时生成5分钟和1小时两种降采样数据，大幅降低长周期查询的扫描量。Query作为查询入口，对所有StoreAPI端点做扇出查询、结果归并和去重。Ruler承担告警规则和记录规则的集中评估，可以独立于Prometheus运行，实现告警链路的统一管理。
两种数据接入模式：Sidecar上传与Receiver接收
Sidecar模式是最经典的接入方式，Prometheus在本地写满一个2小时的block后，Sidecar将其上传到对象存储。这种方式实现简单，Prometheus完全无感知，数据写入路径短。但它的缺点也很明显：数据上传存在最多2小时的延迟，且如果Prometheus在block未完成时崩溃，这部分数据就丢了。适合对数据完整性要求中等、架构追求简洁的场景。
Receiver模式则改变了数据流向，Prometheus配置remote_write将数据实时推送给Receiver，Receiver写入本地TSDB后再上传对象存储。数据延迟降到秒级，且支持多副本写入，配合外部的负载均衡可以实现Prometheus无本地状态运行。代价是Receiver成为关键路径，必须保证其高可用，通常部署2到3个实例并开启哈希环复制：
receive:
replication-factor: 3
tsdb:
path: /var/thanos/receive
hashrings:
- hashring: default
endpoints:
- thanos-receive-0.receive:10901
- thanos-receive-1.receive:10901
- thanos-receive-2.receive:10901两种模式的选择标准很清晰：如果Prometheus集群规模不大、可以接受小时级的数据上传延迟，优先选Sidecar，运维负担小；如果是大规模多租户场景，或者需要让Prometheus完全无状态以便弹性伸缩，则Receiver模式更合适。两者也可以混合使用，不同集群按需选择。
查询去重与副本机制
高可用部署时，同一个监控目标通常会被两个Prometheus实例同时抓取，查询时如果不做处理，所有序列的值都会翻倍。Thanos Query的去重基于序列标签集加副本标签实现，默认副本标签为replica，只需在两个Prometheus的配置中添加不同的external_labels，Query就能识别出哪些数据是重复的：
global:
external_labels:
cluster: prod
replica: A去重算法并非简单取任意一份，而是按时间点选取最新采集的那份样本，保证在其中一个实例短暂离线时数据仍然连续。需要注意的是，去重会带来一定的CPU开销，查询数据量巨大时可以在Query Frontend层配合缓存来缓解，将重复查询的结果按时间分片缓存到Redis或内存中。
另一个容易被忽视的点是StoreAPI端点的路由收敛。Query会周期性访问每个数据源的元数据接口，如果Sidecar数量达到数百个，元信息同步的开销会显著上升。可以通过给Sidecar的StoreAPI打上标签，查询时按cluster标签过滤端点，减少不必要的扇出。对于已经上传到对象存储的历史数据，Store Gateway支持按时间和标签做块级预过滤，能有效降低跨存储查询的延迟。
生产部署实践与容量规划
对象存储是整个体系的基石，Thanos支持S3、GCS、Azure Blob以及兼容S3协议的MinIO、阿里云OSS等。生产环境建议使用对象存储的多版本或软删除机制做兜底防护，并单独规划Compactor的运行权限。Compactor必须是单实例运行，多实例同时压缩同一个桶会导致数据损坏，这是Thanos运维中最重要的红线之一，通常用单独的锁机制或调度器保证其唯一性。
资源规划方面，Store Gateway的内存消耗与块索引的缓存大小正相关，大集群建议给出16GB以上内存并启用索引缓存；Query的CPU主要消耗在结果归并和去重上，可以按每千个StoreAPI端点预留2到4核估算；对象存储的出口流量费用在降采样未启用时可能非常可观，务必配置Compactor的降采样规则，对保留期超过一个月的数据启用5分钟降采样，超过半年的启用1小时降采样，可以把存储和查询成本降低一个数量级。
thanos query \ --grpc-address=0.0.0.0:10901 \ --http-address=0.0.0.0:9090 \ --query.replica-label=replica \ --store=dnssrv+_grpc._tcp.thanos-sidecar.monitoring.svc \ --store=dnssrv+_grpc._tcp.thanos-store.monitoring.svc
故障排查时，重点观察Query的/metrics中store_gaia系列指标（不同版本命名略有差异）以及各StoreAPI的响应耗时直方图。常见问题包括Prometheus时间与Query节点偏差过大导致查询窗口错位、Sidecar上传因对象存储凭证失效而静默失败、Compactor因桶中出现重叠块而拒绝工作等。建议为每个组件配置独立的指标监控和告警，把对象存储上传延迟、块压缩成功率纳入核心告警项，确保这套大规模监控体系自身也处于被监控之中。
ThanosPrometheus监控架构修改时间：2026-09-11 14:26:51