Skip to main content
This lesson covers the essentials of Thanos: what it is, why you’d use it with Prometheus, and the core components to understand for reliable long‑term metric storage and unified querying.
For the exam you do not need to memorize Thanos’s entire internals. Focus on its purpose—providing long‑term storage and a single query layer for multiple Prometheus instances—and the main benefits summarized below.
Why use Thanos with Prometheus?
  • Single pane of glass: Query metrics from many Prometheus instances through one Thanos Query endpoint instead of logging into each Prometheus server.
  • High‑availability deduplication: When you run Prometheus in HA (multiple Prometheus servers scraping the same targets), Thanos can deduplicate duplicate series so dashboards and alerts reflect a single logical view.
  • Cost‑effective long‑term storage: Thanos uploads Prometheus TSDB blocks to object stores (AWS S3, Azure Blob Storage, GCS) so local disk usage on each Prometheus server doesn’t grow without bound.
Key terminology and components Architecture overview
  • Thanos Sidecar: Deployed with each Prometheus server. Uploads local blocks to long‑term object storage and exposes the instance’s recent data to Thanos Query.
  • Thanos Store: Loads historical blocks from object storage (S3, GCS, Azure Blob) and serves those blocks to Thanos Query.
  • Thanos Query: The PromQL‑aware query frontend that merges results from sidecars (recent data) and stores (historical data), deduplicates series, and returns unified results to clients such as Grafana.
Typical query flow: a user issues a PromQL query to Thanos Query, which fans out the query to relevant sidecars for recent data and to the Thanos Store for historical blocks, then merges and deduplicates results before returning them.
The image depicts a diagram of Thanos architecture, showing the interaction between Prometheus servers, Thanos Sidecars, a central storage bucket, Thanos Store, Thanos Query, and a Grafana client.
Prometheus TSDB blocks, compaction, and Thanos Prometheus writes TSDB blocks (commonly every 2 hours). Prometheus also performs block compaction to merge small blocks into larger ones for better query efficiency. However, compaction rewrites, merges, or deletes blocks while the Thanos Sidecar is concurrently uploading them, which can cause transient upload races or failures. To keep block layouts stable for Thanos uploads, many deployments disable Prometheus automatic compaction by setting the minimum and maximum block duration to the same value. For example:
Setting both flags to the same duration (here, 2h) prevents Prometheus from running compaction and keeps block boundaries stable while Thanos uploads blocks to object storage.
Disabling compaction reduces Prometheus’s on‑disk optimizations and can affect local query performance or disk usage patterns. Test this configuration in staging and monitor resource use before applying in production.
Best practices and exam focus
  • Focus on what Thanos does and the benefits it adds to Prometheus: unified querying, deduplication for HA, and long‑term storage in object stores.
  • Know the roles of Sidecar, Store, and Query as the main Thanos building blocks.
  • Understand why you might disable Prometheus compaction when integrating with Thanos and be aware of the operational tradeoffs.
References Summary
  • Thanos provides a global view across multiple Prometheus servers, deduplicates HA series, and enables durable, cost‑effective long‑term storage by backing Prometheus blocks up to object stores.
  • For exam purposes, prioritize understanding Thanos’s purpose and the core components rather than its full internal architecture.
The image shows a "Prometheus Compaction" interface with a "Enable Compaction" button and three 2-hour blocks. A Prometheus logo is visible on the left.

Watch Video