Thanos

概述 Prometheus 是云原生监控领域的事实标准，但它在长期数据存储和全局查询方面存在明显短板：本地存储默认只保留 15 天数据，单实例无法跨集群聚合查询，高可用方案也相对复杂。Thanos 作为 CNCF 孵化项目，通过将 Prometheus 数据上传到对象存储（如 S3、GCS、MinIO）实现了无限容量的长期存储，并通过分布式查询组件提供跨集群的全局视图。 将深入剖析 Thanos 的架构设计，并结合生产环境实战经验，详细讲解各组件的配置、部署和运维要点。 Thanos 解决了什么问题 在引入 Thanos 之前，我们首先需要理解 Prometheus 原生存储的局限性： 维度 Prometheus 原生 Thanos 增强 数据保留 默认 15 天，受本地磁盘限制 理论无限，依赖对象存储容量 高可用 需要 Thanos Sidecar 或 remote_write 双写 Sidecar + Query 天然支持 全局查询 联邦方案，有限且易丢数据 Query 组件聚合所有 Store API 降采样 不支持 Compactor 自动降采样，优化长周期查询 历史数据查询 超出保留期即丢失 可查询数月甚至数年前数据 跨集群视图 需要额外联邦配置 原生支持多集群统一查询 核心思路是：不改 Prometheus 本身，通过 Sidecar 旁路将数据上传到对象存储，再通过 Query 组件统一查询。这种设计保持了 Prometheus 的简单性，同时获得了企业级存储和查询能力。 核心架构与组件 整体架构 Thanos 的架构围绕"Sidecar 上传、Store 读取、Query 聚合"三个核心环节展开：...

概述 Prometheus 默认是单节点架构，这在生产环境中是一个危险的隐患。一个 Prometheus 实例挂掉意味着整个监控体系失明——你无法在故障期间看到任何指标，告警也会因为规则不评估而完全失效。当数据量增长到单机存储和处理能力的极限时，还会面临写入超时、查询缓慢、磁盘爆满等问题。 本文系统性地分析 Prometheus 高可用和水平扩展方案，从最简单的双副本到 Thanos、Mimir、VictoriaMetrics、Cortex 等远程存储方案，帮助你根据实际场景做出正确的技术选型。 参考来源：Prometheus 官方文档 — HA、Thanos 官方文档 一、单点问题分析 1.1 单点 Prometheus 的风险 ┌──────────────┐ ┌───────────────┐ ┌──────────┐ │ Exporters │ ──→ │ Prometheus │ ──→ │ Grafana │ │ (targets) │ │ (单节点) │ │ Alertmgr│ └──────────────┘ └───────────────┘ └──────────┘ │ ┌──────┴──────┐ │ 本地 TSDB │ │ (15-30 天) │ └─────────────┘ 这个架构的脆弱点： 风险点 影响 发生概率 Prometheus 进程崩溃 监控完全中断，告警失效 中 宿主机宕机 同上，且可能丢失最近数据 中 磁盘故障 历史数据丢失 低-中 磁盘空间耗尽 写入失败，数据丢失 中-高 单机内存/CPU 不足 写入延迟、查询超时 高（数据量增长后） 网络分区 部分 target 无法采集 中 1....