Decoding Thanos Architecture: From Query to Compact for Scalable Monitoring

Overview

After optimizing Prometheus for large‑scale scenarios, the next challenge is handling historic or "cold" data that is rarely accessed. Storing such data in cheap object storage and loading it on demand solves this problem, and Thanos offers a comprehensive solution.

Thanos Architecture

The official diagram (shown below) highlights the main components of Thanos, each serving a specific role:

Thanos Query : Implements the Prometheus HTTP API, aggregates data from downstream components, and serves queries to clients such as Grafana, acting like a database middleware.

Thanos Sidecar : Attaches to a Prometheus instance, exposes its data via the Store API, and optionally uploads data to object storage for long‑term retention.

Thanos Store Gateway : Exposes data stored in object storage to Thanos Query.

Thanos Ruler : Evaluates alerting rules and recording rules, computes new metrics, stores results, and makes them available to Query; it also uploads data to object storage.

Thanos Compact : Compresses and down‑samples data in object storage, reducing query load for large time ranges.

Query and Sidecar Design

Directly querying many Prometheus instances is impractical; instead, Thanos Query acts as a central entry point, understanding PromQL and aggregating results from multiple data sources. It uses the internal Store API (gRPC) to fetch data from Sidecars, enabling stateless deployment and dynamic scaling.

Sidecars expose local Prometheus data and can upload it to object storage. Because each Prometheus only holds a subset of the total data, Thanos Query aggregates across all Sidecars, providing a global view and high availability—if one Prometheus fails, its data is still represented after aggregation and deduplication.

Store Gateway

While Query could read directly from object storage, that would burden it with storage‑specific logic. The Store Gateway implements the Store API, exposing object‑storage data to Query. It caches TSDB indexes and minimizes object‑storage requests, enabling efficient long‑term data retrieval.

Ruler

Prometheus rules can generate new metrics and trigger alerts, but in a distributed setup each instance lacks a global view. Thanos Ruler queries the global data via Thanos Query, evaluates rules, stores computed metrics, and exposes them through the Store API, allowing both alerting and further queries on the newly generated data.

Compact

When querying very large time ranges, raw data volume can cause slow responses. Thanos Compact reads data from object storage, compresses it, and creates down‑sampled versions. Queries over long periods can then use these reduced datasets, dramatically speeding up retrieval.

Sidecar Mode vs. Receiver Mode

The original architecture uses Sidecar, but an upcoming component—Thanos Receiver—offers an alternative. Receiver implements Prometheus' remote‑write API, allowing Prometheus instances to push data in real time, centralizing the latest metrics and eliminating the need for many Sidecars. Receiver also uploads data to object storage and supports consistent hashing and clustering to avoid bottlenecks.

Summary

Thanos provides a globally consistent, highly available monitoring stack that extends Prometheus with long‑term storage, query aggregation, rule evaluation, and data compaction. Its modular design—Query, Sidecar/Receiver, Store Gateway, Ruler, and Compact—addresses the limitations of standalone Prometheus deployments and prepares the foundation for large‑scale observability in cloud‑native environments.