Thanos

thanos.io ↗

Adds a global query view, high availability, and long-term storage to Prometheus deployments.

SI Score
75/100
Pricing
Open Source AI reading, not confirmed
Free plan
Not confirmed
Sign-up required
Not confirmed

Ask SI about Thanos

Answers use saved listing facts and recorded sources.
Homepage screenshot
Screenshot of the Thanos homepage

What it does

Thanos is a set of deployable components that extends existing Prometheus servers rather than replacing their scrapers. Its query layer can combine metrics from several Prometheus installations, while object storage can retain historical data beyond local disk. Operators can add these capabilities gradually, then use Prometheus-compatible query clients such as Grafana against the shared view. It is aimed at teams that already operate Prometheus and need to federate or retain more of its metrics.

Extend a Prometheus setup in pieces

Thanos is most useful when there is already a Prometheus installation to build on. The getting-started documentation lists Prometheus 2.2.1 or newer with persistent disk as dependencies; object storage is optional. A common deployment pairs Thanos Sidecar with Prometheus, stores historical blocks in an object store, and connects Thanos Query to the available Store API endpoints. That gives a team with separate regional Prometheus servers a shared query endpoint without turning the individual servers into one large instance.

The Query component presents a Prometheus-compatible API, so existing query tooling can read across connected stores. Other components handle distinct jobs: Compactor down-samples and compacts historical blocks, while Sidecar connects Prometheus data to the Thanos Store API. Thanos can therefore support both a broader view of current metrics and longer retention, but it is infrastructure to deploy and operate rather than a managed dashboard service.

Plan for the distributed parts

The documentation explicitly advises against using a one-node arrangement for production. Object storage also needs its own capacity, access policy, and cost planning. Teams should introduce only the components they need and decide how to operate the storage and query path; a small Prometheus setup may not need Thanos at all. The project is open source under Apache 2.0. The examples here describe documented architecture, not a deployment performed for this listing.

Strengths

  • Can merge Prometheus metrics from multiple servers and high-availability pairs behind a shared query view.
  • Object-store integration extends historical retention, with downsampling and compaction for older blocks.
  • Prometheus-compatible querying lets existing metrics clients continue to work against Thanos Query.

Watch out for

  • Requires an existing Prometheus deployment and persistent storage; long-term storage adds an object-store dependency when enabled.
  • The maintainers do not recommend a single-node Thanos setup for production, so a reliable deployment involves operating distributed components.

Best for

  • SRE teams querying metrics across multiple Prometheus clusters
  • Operators extending Prometheus retention with object storage
  • Organizations consolidating Prometheus high-availability pairs without changing query clients

Sources