Grafana with Thanos or Grafana Mimir for long-term metrics

Grafana with Thanos or Grafana Mimir for long-term Prometheus metrics: what the integration does

A team running several single Prometheus servers loses history when local retention expires, and it cannot show clusters side by side in one place. Grafana solves the display side of this without changing how it is configured for a single server: it uses the core Prometheus data source, pointed at a Prometheus-compatible query API served by either Thanos or Grafana Mimir. The Grafana Prometheus data source documentation names both projects as examples of systems that implement the Prometheus querying API, so the dashboards, PromQL queries and alert rules your teams already use carry over.

The two projects take different shapes. Thanos is a set of components added on top of existing Prometheus servers. Its sidecar uploads Prometheus blocks to object storage, its Query component fans out across servers and merges results, and its Store, Compact and Receive components handle historical reads, downsampling and push-based ingest. Grafana Mimir is a multi-tenant, horizontally scalable store that Prometheus writes into through remote write, and it runs either as a single binary in monolithic mode or as separate components. Both are open source, Thanos under Apache-2.0 and Mimir under AGPL-3.0-only, so the choice turns on operating model, licensing review and the skills your team already has, not on whether the software is free to run.

Before choosing, confirm three things with your platform team: how many Prometheus servers will feed the store, whether those servers already run in high availability pairs, and which object storage your organization permits. Each answer changes the component count and the cost of running the system. Confirm also which Grafana version you run, because Grafana 13 removed SigV4 and Azure AD authentication from the core Prometheus data source, which matters if your store sits behind AWS-managed endpoints.

What you need before connecting Grafana to Thanos or Mimir

Grafana with Thanos or Mimir depends on several components that must be in place before the data source can be pointed at them. Each card below covers one prerequisite, what it means for the connection, and what to confirm in your own environment before work starts.

Prometheus v2.2.1 or later

Thanos requires one or more Prometheus installations at version 2.2.1 or later, and each Prometheus needs persistent disk for its local TSDB. If you use the Thanos sidecar, confirm that Prometheus min and max block duration can be set to equal values so local compaction is disabled before uploads. Check the Prometheus version on every cluster you plan to include, since a global view is only as consistent as its oldest server. Mimir receives data through remote write, so the same Prometheus versions also need remote write configured.

Object storage for long-term blocks

Both Thanos and Mimir keep long-term data in object storage, so you need a bucket and credentials before deploying either component. Thanos treats object storage as its only optional dependency, while Mimir supports Amazon S3, Google Cloud Storage, Microsoft Azure Storage, OpenStack Swift and a local filesystem that works only on a single node. Confirm the bucket location against your data residency rules, the retention you expect, and who holds the access keys. Each Thanos bucket also needs a single compactor running against it.

Grafana 13 or a checked earlier line

Grafana 13 removed SigV4 (AWS) and Azure AD authentication from the core Prometheus data source, so an AWS-hosted Prometheus-compatible endpoint needs the separate Amazon Managed Service for Prometheus plugin. If you run an earlier Grafana line, confirm that its Prometheus data source accepts the query endpoint you plan to use and that the version is still receiving patches. Check the upgrade guidance before moving an existing instance, because minor releases are supported for a limited period.

Production database for Grafana

Grafana stores its configuration in SQLite by default, and the installation docs say SQLite does not scale for production. Plan MySQL 8.0 or later or PostgreSQL 12 or later for any instance that must be highly available or shared by several teams. Ask your database team who will back up the database, how it will be restored, and whether the instance can reach it from every Grafana node. This database is separate from the Thanos or Mimir bucket and holds dashboards, users and data source settings.

Tenant header or reverse proxy

Mimir requires a tenant ID header on every HTTP request and leaves authentication and authorization to an external reverse proxy, so you must decide how Grafana will send the tenant header and how users reach their tenants. Thanos Receive identifies tenants with the THANOS-TENANT header by default. Confirm which team owns the proxy, how it authenticates Grafana, and whether per-team dashboards will depend on a fixed tenant per data source. Mimir does not enforce this on its own, so the proxy is part of the access model.

Network paths and confirmations

Grafana, the query components, the object storage endpoint and each Prometheus must reach one another over the ports your design uses, and TLS requirements should be agreed before deployment. Confirm firewall rules, DNS names, certificate authorities and whether traffic crosses a boundary such as a DMZ. Several items in this list, including the storage region, the database engine and the tenant model, depend on your own environment and should be verified with the teams that own them before a scope is written.

How to configure the Grafana Prometheus data source for Thanos or Mimir

This sequence takes a team from an existing Prometheus estate to a Grafana Prometheus data source that answers queries from long-term storage, so dashboards show history beyond what local Prometheus retains. Each step ends with a check that the previous step produced what the next one needs.

Choose the backend and ingest path
Decide whether Thanos or Grafana Mimir fits your estate before anything is deployed. Thanos extends existing Prometheus servers through a sidecar that uploads blocks to object storage, or through Thanos Receive when Prometheus pushes by remote write. Mimir receives remote write from Prometheus and stores each tenant's series in object storage. Write down the object storage target, the tenant model and who operates the components. The step is done when the team has a signed-off decision record that names the backend, the ingest path and the storage bucket or service. Confirm details against the current Thanos and Mimir documentation for your version.
Deploy the write or sidecar path
The platform team deploys the chosen path in the environment you control. For Thanos with a sidecar, each Prometheus server runs the sidecar next to it, and the Prometheus min and max block duration must be set to equal values so local compaction does not corrupt uploaded blocks. For Thanos Receive or Mimir, configure Prometheus remote write to the distributor or receive endpoint and make sure each request carries the expected tenant identifier. The step is done when each Prometheus target shows successful remote write or sidecar uploads in its own status and the first blocks appear in object storage.
Confirm the Prometheus-compatible query endpoint
Identify the URL that will serve PromQL. For Thanos, this is the Query component, and the Query Frontend can sit in front of it. For Mimir, this is the query frontend. Test the endpoint directly with an HTTP client, using the Prometheus query API path and, for Mimir, the tenant ID header on every request. Note whether an external reverse proxy handles authentication, because Mimir leaves authentication and authorization to that proxy. The step is done when a plain query for a recent metric returns a valid JSON response from the endpoint outside Grafana.
Add the Prometheus data source in Grafana
A Grafana administrator adds a Prometheus data source under the connections settings and sets the URL to the query endpoint confirmed in the previous step. If the backend requires a tenant header, add it as a custom HTTP header in the data source configuration rather than in individual dashboards. Use the Prometheus type in Grafana 13 for Thanos and Mimir, and do not expect SigV4 or Azure AD options on that type in Grafana 13. Save the data source and select Test. The step is done when Grafana reports a successful connection and the built-in Explore view returns series for a known metric.
Verify history beyond local retention
Pick a metric and a time range that is older than the local Prometheus retention window, which defaults to 15 days unless your configuration changed it. Run the query in Explore against the new data source and compare it with the same query against a single Prometheus server if that server still holds the data. Look for continuous lines with no gaps across the boundary where local data ends. The step is done when a query over the older range returns samples from long-term storage. If nothing returns, check that the compactor, store gateway or Mimir store-gateway components have loaded the uploaded blocks.
Check duplicates from high availability pairs
If Prometheus runs as an HA pair or multiple replicas feed the same backend, confirm the query layer deduplicates the series before the team builds dashboards on top. Thanos Query can deduplicate replica series through configured replica labels, and the team should confirm the equivalent behavior in Mimir for its ingest design. Compare a rate or count over a short window with the expected value from one replica. The step is done when the query result shows one series per logical target and the team has recorded which replica labels or settings the deduplication depends on.
Document the configuration as code
Store the data source definition, the tenant header reference and the endpoint address in version control so the configuration can be reviewed and rebuilt. Grafana provisioning loads data sources from YAML files at startup, and the team can keep secrets for the header value in the secrets mechanism of its deployment rather than in the file. Record which Grafana version, backend version and object storage bucket the configuration targets. The step is done when a fresh Grafana instance built from the repository shows the same data source and passes the same test query.

Thanos or Mimir: how to choose the backend for your estate

If you already run Prometheus servers that scrape their own targets, the lowest-change path is usually to keep them and add Thanos components beside them. The Thanos Sidecar runs next to each Prometheus, implements the Thanos Store API on top of the Prometheus remote-read API, and can upload TSDB blocks to object storage as Prometheus produces them every 2 hours. Thanos Query then fans out across sidecars and stores, giving Grafana one global query endpoint.

Ingest model: Prometheus keeps scraping and alerting as before, so your existing scrape configuration and service discovery do not move.
Compaction: when the sidecar uploads blocks, Prometheus minimum and maximum block duration must be set to equal values to disable local compaction, which the Thanos sidecar docs say otherwise can corrupt uploaded data.
Tenancy: there is no built-in tenant model. Isolation comes from how you separate Prometheus servers and query paths, so confirm this matches your access requirements.
Historical data: the Thanos compactor, which must run as a singleton against each bucket, downsamples raw data older than 40 hours to 5-minute resolution and 5-minute data older than 10 days to 1-hour resolution.
Operational load: you run the sidecars, Query, Store and Compact components alongside each Prometheus fleet, and Thanos is built to run as a distributed system rather than on a single node.

Before committing, check your Prometheus version against the minimum the Thanos getting started guide lists and confirm that each server has persistent disk and a bucket policy your security team accepts.

Mapping Prometheus labels, tenants and data sources to Grafana

This table compares how Grafana's Prometheus data source connects to Thanos Query, Thanos Receive and Grafana Mimir, including where tenant identity comes from and which Prometheus features carry over. Read each row as a setting to confirm in your own environment before you build dashboards on top of it. The main takeaway is that tenant handling differs by backend, so the tenant design must be settled before data source configuration starts.

Mapping item	Thanos (Query or Receive)	Grafana Mimir
Data source URL	Point at Thanos Query or Query Frontend, not at individual Prometheus servers	Point at the Mimir query frontend Prometheus-compatible API endpoint
Tenant identifier	Receive identifies tenants by the THANOS-TENANT header by default	Every HTTP request must carry a tenant ID header
Authentication	Set up at the proxy or gateway layer you place in front of the components	Left to an external reverse proxy, so authorization must be designed there
Global label scope	Query merges series from connected stores; confirm which external labels identify each cluster	Each tenant's series are stored separately, so cross-tenant views need explicit query design
Exemplars	Confirm Grafana exemplar support against your Thanos version and store path	Confirm exemplar storage and query behavior in the Mimir version you run
Recording rules	Run rules through Thanos Ruler or Prometheus, then query the output series in Grafana	Confirm where rule evaluation runs and which tenant owns the resulting series
Deduplication labels	Prometheus HA replica labels must be set so Query can merge pairs correctly	Confirm how replica labels are handled on ingest for each tenant
Vendor behavior check	Review the Grafana Prometheus data source docs and Thanos component docs for your versions	Review the Grafana Prometheus data source docs and Mimir docs for your versions

How retention and global views change in practice

A single Prometheus server keeps local data for 15 days by default, and that setting is the baseline you are moving away from. Once Thanos or Mimir takes over long-term storage, retention becomes a set of decisions across tiers rather than one number. With Thanos, raw blocks uploaded by the sidecar or Receive sit in object storage, and the Thanos compactor downsamples raw data older than 40 hours to 5-minute resolution and 5-minute data older than 10 days to 1-hour resolution. Those thresholds decide how much detail an investigation from last month can still show, so confirm that a 5-minute or 1-hour view is acceptable for each alert, capacity report and audit question before you set retention per bucket. The compactor must also run as a singleton against each object storage bucket, so plan one compactor per bucket and make its restart behavior part of your runbook.

Global views depend on deduplication. Prometheus HA pairs scrape the same targets, and the Thanos Query layer deduplicates and merges those series so a dashboard does not show doubled values or gaps. The result is only as clean as your external labels, so check that every replica and cluster carries labels that identify its origin and that the same series does not collide across clusters. Mimir takes a different route: it stores each tenant's series in its own Prometheus TSDB in object storage, so the tenant boundary, not a label convention, separates one team's data from another's. In practice, decide whether each business unit gets its own tenant, how Grafana data source settings map to tenant IDs, and which authentication proxy enforces them, since Mimir requires a tenant ID header on every request and leaves access control to that proxy.

Validate retention against your written policy before cutover, not after. Ask your compliance owner which metrics must survive, for how long, and at what resolution, then confirm each rule against the configured compaction thresholds, object storage lifecycle rules and per-tenant limits. Test a restore or query of data at the oldest age you promise, because a retention setting that deletes data early is hard to notice until an auditor asks. Record the Prometheus local retention you keep for short-term queries, the object storage retention for long-term data and the owner of each. Where your requirements are unclear, treat the answer as an open decision, not a default.

Securing the Grafana to Thanos or Mimir connection

Grafana, Thanos or Mimir, and the object storage behind them each trust something different. Mimir pushes authentication out to a reverse proxy, Thanos inherits the security model of the Prometheus servers it sits beside, and Grafana's own settings decide who reaches the data at all. Work through these items as one design before the first dashboard goes live.

Authentication sits outside Mimir

Mimir requires a tenant ID header on every HTTP request and does not authenticate callers itself. Whatever sits in front of it has to verify identity, decide which tenants a user may read or write, and strip or set the tenant header so clients cannot pick someone else's tenant. Confirm which proxy or gateway your team will run, who owns its configuration, and how it is tested against a cross-tenant query before go-live.

The tenant header trust boundary

In a multi-tenant design, the tenant header is the only thing separating one team's series from another's. Any component that accepts traffic without checking the caller can be used to forge that header, so the boundary has to be enforced at the edge and not inside the dashboard. Decide where Grafana's data source header is set, make sure Grafana users cannot edit it, and check that the Thanos receive path follows the same rule with its own tenant header default.

Grafana hardening for the data source path

The Grafana security hardening guidance covers secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, and domain verification against DNS rebinding. Require authentication on the metrics endpoint so Grafana's own internal metrics are not readable anonymously. Each setting is a configuration key in the Grafana server config, so record the values in version control and review them after every upgrade.

Prometheus security model assumptions

Prometheus assumes its operators control the network, and its security model does not add authentication to the query API or the scrape endpoints. When Grafana queries a Prometheus server through Thanos Query, or Prometheus pushes through Thanos Receive or Mimir, every hop inherits that assumption. Read the Prometheus security model, then decide which hops need mutual TLS, network policy or a proxy that adds authentication, and document who may reach each port.

Object storage access credentials

Thanos sidecars and compactors, and Mimir ingesters, store and compact, need credentials for the bucket that holds the long-term data. Use separate identities per component where the storage platform allows it, grant only the read and write actions each one needs, and avoid long-lived static keys copied into multiple config files. Ask your storage provider which roles are required for the compactor and store gateway, and confirm that deletion is limited to the owners who run retention.

Common failures when Grafana reads from Thanos or Mimir

This table lists the failures teams most often hit when Grafana queries Thanos or Mimir, with the cause and the documented fix for each. Read it before go-live and again when a dashboard shows empty, duplicated or missing data. The main takeaway is that most failures trace to configuration of the storage and query path rather than to Grafana itself.

Failure	Cause	Fix
Empty results from Mimir	Requests reach Mimir without the tenant ID header, which Mimir requires on every HTTP request	Set the tenant header in the Prometheus data source custom HTTP headers, and confirm the auth proxy passes it through
Duplicate series on panels	Two Prometheus HA replicas both send the same series and nothing merges them at query time	Enable deduplication in Thanos Query using the replica label that distinguishes each Prometheus instance
Corrupted uploaded blocks	Prometheus min and max block duration differ, so local compaction rewrites blocks the Thanos sidecar already uploaded	Set min and max block duration to equal values when the sidecar uploads blocks, as the Thanos sidecar docs require
Overlapping or failed compaction	More than one Thanos compactor runs against the same object storage bucket	Run exactly one compactor per bucket and confirm no second deployment, cron job or replica targets it
Broken queries after Grafana 13	The core Prometheus data source dropped SigV4 authentication, so AWS-hosted backends fail to authenticate	Install the dedicated Amazon Managed Service for Prometheus plugin and move the data source to it before or after upgrading
Gaps during outages on a single node	Thanos is built as a distributed system and is not recommended for production on a single node	Deploy the components as a distributed set with redundancy, and confirm the design against the Thanos getting started guidance

Questions buyers ask before connecting Grafana to Thanos or Mimir

What drives the cost of running Thanos or Mimir behind Grafana?

The cost comes from four places: the infrastructure that runs the components, the object storage that holds long-term blocks, the Prometheus servers that produce the data, and the people who build and operate the stack. Prometheus is licensed under Apache-2.0 and has no paid enterprise edition, so there is no license line item for it. Thanos is Apache-2.0 licensed, while Grafana Mimir is distributed under AGPL-3.0-only, which matters for how you distribute modified code, not for what you pay to run it. Object storage and compute recur every month and grow with series count, retention and query load. The build work is largely one-time. Ask any partner to split the quote into one-time implementation work and recurring run costs, and to state which infrastructure and storage sizing assumptions the figures rest on.

How long does a Grafana with Thanos or Mimir project take?

Duration depends on scope rather than on a fixed template. The main variables are how many Prometheus servers or clusters feed the platform, whether you are starting fresh or migrating existing Prometheus data, how many tenants need isolation, and whether the target runs on Kubernetes, virtual machines or bare metal. A single Thanos sidecar pattern on one existing Prometheus fleet is a smaller change than a multi-tenant Mimir deployment with ingest storage and migrated history. Ask for a written scope with named deliverables and milestones before any date is agreed. DeployOpen plans most engagements as fixed scope, with scope, deliverables and timelines agreed in writing before work starts.

What does our team need to provide before the work starts?

Expect to provide access and decisions, not just time. The usual inputs are: an inventory of Prometheus servers, their scrape targets and their retention settings; the cloud accounts, data centers or air-gapped networks where the stack will run; an object storage bucket or equivalent with access credentials; a Kubernetes cluster or virtual machines if those are the target; identity and tenant mapping for teams that will share the platform; and a named owner who can approve design choices. Your team should also confirm the current Prometheus version and the Grafana version in use, since those affect the integration path. Agree who approves changes to production Prometheus configuration, because some Thanos setups require specific Prometheus block settings.

Can our own platform team build and run this without a partner?

Yes, if your team has the skills and capacity to own a distributed system. Thanos and Mimir are both designed to run as distributed systems, and the Thanos getting started guide says it is not recommended for production on a single node. Your team needs working knowledge of Prometheus, object storage, Kubernetes or virtual machine operations, certificates and tenant-aware authentication. Mimir requires a tenant ID header on every request and leaves authentication and authorization to an external reverse proxy, so someone must build and maintain that layer. A partner can shorten the first deployment and document it, while your team keeps the operating knowledge. Decide before starting who will be on call for storage, compaction and query performance.

When should we choose Thanos instead of Grafana Mimir?

Choose Thanos when you want to keep your existing Prometheus servers and add a global query view, long-term storage in object storage and high availability around them. The Thanos sidecar works alongside Prometheus, and the components can be added on top of existing deployments. Choose Mimir when you need a horizontally scalable, multi-tenant backend that receives data through remote write, with isolation between independent teams or business units. Mimir's README cites internal testing up to 1 billion active time series. Consider your operating model too: Mimir's preferred ingest storage uses Kafka from version 3.0, which is another system to run. Both are valid, and the decision should rest on tenancy needs, scale, existing Prometheus fleet and the team's operating capacity.

Does Grafana need to change when we move to Thanos or Mimir?

The Prometheus data source in Grafana works with any project that implements the Prometheus querying API, and the Grafana docs name both Thanos and Grafana Mimir. In most setups you point the existing Prometheus data source at the query endpoint of the new backend. Check the Grafana version before you do this. In Grafana 13 the core Prometheus data source no longer supports SigV4 (AWS) or Azure AD authentication. If your Thanos or Mimir endpoint sits behind AWS SigV4 or Azure AD, you must install the dedicated Amazon Managed Service for Prometheus plugin or another supported authentication path. Confirm this during design, because the change affects how Grafana connects to the endpoint.

What breaks most often after a Thanos or Mimir rollout?

The most common problems are operational rather than visual. Several are documented: Prometheus must have min and max block duration set to equal values when the Thanos sidecar uploads blocks, or local compaction can corrupt uploaded data. The Thanos compactor must run as a singleton against each object storage bucket. Thanos and Mimir both depend on object storage performance and cost, so unplanned growth in series or retention shows up as a bill and a query slowdown. Mimir ingest and query paths depend on tenant headers being set correctly. Teams also forget that Prometheus local storage is not clustered or replicated, so the long-term store must be planned as the system of record. Ask any partner for a verification plan covering compaction, downsampling, query tests and restore tests.

Does DeployOpen handle the security and compliance side of this stack?

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which covers the Thanos or Mimir stack, its object storage integration and the Grafana connection. Security work can include access design for tenant headers, authentication in front of the reverse proxy, and security testing of the deployed environment. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask for the security scope in writing so you know which controls are built, which are tested, and which are your responsibility.

How DeployOpen scopes and delivers the Grafana long-term metrics integration

DeployOpen plans and builds the Grafana side of a long-term Prometheus metrics setup inside infrastructure you control, from the choice between Thanos and Grafana Mimir through to documented operations. Each engagement starts from a written scope that names the clusters, data sources, retention rules and object storage involved.

How we scope

We record which Prometheus servers, clusters and tenants the Grafana data source must query, and which teams own each one.
We compare Thanos and Grafana Mimir against your retention, tenancy and object storage requirements, and document the choice for your review.
We confirm whether any AWS SigV4 or Azure AD authentication is needed, since Grafana 13 moved AWS support into a separate plugin.

How we build

We configure the Prometheus data source against the chosen query API, including exemplars and recording rules where your teams use them.
We set up object storage, compaction and downsampling jobs, and confirm the compactor runs as a single instance per bucket.
We test global queries, deduplication of HA Prometheus pairs and query behavior for each tenant before the build is accepted.

How we hand over

We deliver the data source, dashboard and storage configuration as provisioning files so the setup can be reviewed and rebuilt.
We document the architecture, retention settings, tenant mapping, access boundaries and the runbook for routine and failure cases.
We walk your platform and security teams through the handover so they can run upgrades, storage checks and restores on their own.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and quotes follow from that scope.
Ongoing support, upgrades for Grafana, Thanos or Mimir, and continuous testing are available as a retainer.
Before any retainer starts, we confirm current release lines and support windows with the vendors, since these change over time.

Grafana with Thanos or Grafana Mimir for long-term Prometheus metrics