Skip to main content
This article explains the core purpose of Thanos, how it complements Prometheus, and the high-level architecture you need to understand to use it effectively for long-term metrics storage and global querying.
Focus on Thanos’s purpose: providing a single, scalable query layer, deduplication for HA Prometheus setups, and long-term storage by shipping Prometheus TSDB blocks to object storage. You do not need to memorize every architectural detail—understanding these roles is enough to design and operate a Thanos-enabled monitoring stack.
What Thanos provides (high level):
  • A single “pane of glass” to query metrics across multiple Prometheus servers.
  • Deduplication for high-availability setups where multiple Prometheus instances scrape the same targets.
  • Cost-effective long-term storage by uploading Prometheus TSDB blocks to object stores such as Amazon S3 or Azure Blob Storage, preventing unbounded growth of Prometheus local disks.
If you operate three Prometheus servers, Thanos lets you query all three from a single endpoint without logging into each server. In HA deployments where redundant Prometheus servers scrape the same targets, Thanos deduplicates overlapping samples so queries return a single, correct result. Thanos also moves older TSDB blocks into object storage, offloading long-term retention to cheaper, scalable storage backends. Architecture overview
  • Thanos sidecar: Runs alongside each Prometheus instance (same host or pod). It exposes Prometheus data over gRPC and uploads TSDB blocks to the configured object storage.
  • Thanos Store (store gateway): Reads TSDB blocks from the object store and makes historical data available for queries.
  • Thanos Query: The query layer that federates queries across Prometheus sidecars (for recent/live data) and Thanos Store components (for historical data), merges results, and applies deduplication when needed.
A diagram titled "Thanos Architecture" showing Prometheus instances with Thanos sidecars sending data to object storage, and Thanos Store and Query components feeding a Grafana/client.
Thanos components at a glance How queries flow:
  • A user issues a PromQL query to Thanos Query.
  • Thanos Query contacts Prometheus sidecars to retrieve recent/real-time samples.
  • It also queries Thanos Store components to fetch historical data stored in the object store.
  • Thanos Query merges the results, applies deduplication when necessary, and returns the final response to the client (for example, Grafana).
Disabling local compaction for Prometheus Prometheus writes TSDB blocks and, by default, performs local compaction (merging smaller blocks into larger ones). When using Thanos, you should disable Prometheus’s internal compaction so that Thanos can manage block lifecycles consistently in object storage. Achieve this by setting the minimum and maximum block durations to the same value. Example Prometheus flags to disable compaction (set both to a 2-hour duration):
Set both --storage.tsdb.min-block-duration and --storage.tsdb.max-block-duration to the same value to effectively prevent Prometheus from compacting blocks. Let Thanos components handle compaction and retention to avoid inconsistencies in object storage.
A dashboard screen titled "Prometheus Compaction" showing a green "Enable Compaction" button, three blue tiles each labeled "2 hr", and a Prometheus flame logo on the left. The layout appears to configure compaction intervals.
Summary Thanos provides:
  • A unified query layer across multiple Prometheus servers.
  • Deduplication for HA Prometheus setups.
  • Long-term, cost-effective storage by uploading Prometheus TSDB blocks to object stores.
Focus on these benefits when planning Thanos adoption rather than memorizing every implementation detail. Understanding the sidecar → store → query roles and disabling Prometheus compaction are the key operational takeaways. Links and references

Watch Video