Grafana Mimir Prometheus metrics storage: the grafana/mimir repository holds a Go project that acts as long-term, multi-tenant, scalable storage for Prometheus metrics. Its README describes it as scalable long-term storage for Prometheus. It is released under the GNU AGPL v3 (AGPL-3.0-only), which matters before you embed it in a product.

The problem is a familiar one. A single Prometheus keeps its data locally, for a limited period, and gives no global view once you run ten of them. Mimir receives the samples from all your Prometheus servers, stores them in object storage and answers PromQL queries. How is it built, how do you start it, and how do you monitor it?

A note on honesty: span.observer has not installed or run Mimir. The commands come from the README, from the repository’s docs/ folder and from the grafana.com/docs/mimir pages, read on 7 November 2026. The screenshots reproduce files and one image from the repository. The star count shown on the repository page was about 5.3k that day, with no exact value re-read from the GitHub API, which was not reachable.

Grafana Mimir Prometheus metrics storage: what the repository says

  • Licence: the LICENSE file holds the GNU Affero General Public License version 3. According to LICENSING.md, only vendor/ and operations/ fall under upstream licences, whose text is shipped. The AGPL preamble describes it as designed for network server software: have a lawyer review your use.
  • Version: the VERSION file and the latest published CHANGELOG section both say 3.2.4. We could not re-read the release date, so we do not quote it. The « main / unreleased » section lists many changes, including removed options, marked [CHANGE].
  • Project claims: the README states that internal testing shows up to 1 billion active series. That is the project’s claim, and we have not measured it.
  • Object storage: according to the documentation, blocks go to Amazon S3, Google Cloud Storage, Azure Storage, OpenStack Swift, or the local filesystem (single node only).

Component architecture and multi-tenancy

Mimir is made of microservices called components: distributor, ingester, query-frontend, querier, store-gateway, compactor, ruler and alertmanager, among others. The code of every component compiles into a single binary, and the -target parameter picks its role. Two modes exist: monolithic (-target=all, everything in one process) and microservices, which is recommended for production.

Since version 3.0, two architectures coexist. The « ingest storage » architecture, preferred by the documentation, uses Kafka to decouple reads from writes. The classic architecture uses ingesters with a local write-ahead log.

The storage format follows Prometheus TSDB: each tenant has its own blocks, two hours long by default. Every HTTP request carries the tenant ID in the X-Scope-OrgID header. Mimir does not authenticate callers: a reverse proxy must do it and inject the header.

Installing Mimir step by step, as documented

Step 1: get Mimir 

docker pull grafana/mimir:latest # or a local binary (Linux amd64) curl -fLo mimir https://github.com/grafana/mimir/releases/latest/download/mimir-linux-amd64 chmod +x mimir

Step 2: write the demo configuration

The « Get started » guide gives a demo.yaml file for monolithic mode with local disk storage. Its header says not to use it in production. The first screenshot reproduces it, together with the Prometheus configuration from the same page.

The demo.yaml file from the grafana/mimir repository (multitenancy\_enabled false, filesystem storage, memberlist rings, port 9009) and a prometheus.yml with remote\_write to http://localhost:9009/api/v1/push

Step 3: start Mimir and connect Prometheus 

./mimir --config.file=./demo.yaml

Mimir listens on port 9009. Then add the remote_write block from the screenshot to Prometheus and restart it. With Grafana Alloy, the prometheus.remote_write component sends to the same address. The guide also notes that Mimir can report anonymous usage statistics, and the documentation explains how to opt out.

Step 4: query with PromQL

In Grafana, add a Prometheus data source with the URL http://localhost:9009/prometheus (local binary). Without Grafana, the HTTP API table gives the instant query endpoint as GET,POST <prometheus-http-prefix>/api/v1/query. The command below is derived from it: we have not run it.

curl -G http://localhost:9009/prometheus/api/v1/query \ --data-urlencode 'query=up' # with multitenancy_enabled: true, add # -H 'X-Scope-OrgID: tenant-1'

To check that it works, the guide ends as follows: query the metrics in Grafana Explore and build a panel on the new data source. An up series for the prometheus job should appear.

OpenTelemetry: OTLP ingestion

Mimir also accepts OTLP over HTTP: the entry point is POST /otlp/v1/metrics. The Collector page recommends OTLP over remote write. It gives the otlphttp exporter with the address http://<mimir-endpoint>/otlp, or prometheusremotewrite towards /api/v1/push. The next screenshot reproduces the example with basic authentication, plus per-tenant retention.

Example from the Mimir documentation: an OpenTelemetry Collector with a basicauth extension and an otlphttp exporter pointing to /otlp, then compactor\_blocks\_retention\_period overrides for tenant1 and tenant3

Three points from the format page deserve attention. Dots in names are converted to _. Resource attributes go into the target_info series, except job and instance, which come from service.name and service.instance.id. OpenTelemetry exponential histograms are rejected by default until native histograms are enabled. For context, see the Collector contrib components and OpenTelemetry versus Prometheus.

Limits and open points

  • Complexity: microservices mode multiplies components, and the ingest storage architecture adds Kafka. Monolithic mode suits a first try, but the documentation advises against it at large scale.
  • Disks: the documentation advises against NFS, EFS and network filesystems for components that write locally, and recommends SSDs (risk of crashes or silent corruption).
  • Retention: by default, nothing is deleted. Set compactor_blocks_retention_period. Per-series deletion is not supported.
  • Security: there is no built-in authentication, so a reverse proxy is mandatory.
  • Fast change: the « unreleased » CHANGELOG removes some options and renames others. Read the notes before each upgrade.
  • Licence: the AGPL imposes obligations if you modify the software and offer it as a network service.

Observing Mimir itself

Mimir exposes its Prometheus metrics on /metrics. The repository ships a « mixin »: in operations/mimir-mixin-compiled/, 27 JSON dashboard files, rules.yaml (recording rules) and alerts.yaml (127 alert: entries on 7 November 2026, since one name can appear at several severity levels). Among them: MimirIngesterUnhealthy, MimirRequestErrors and MimirRequestLatency. Every alert carries a runbook_url.

The screenshot below shows the « Mimir / Overview » dashboard published in the repository’s documentation: cluster health, writes, reads, rules and object storage. The cluster and namespace names visible in it come from the example.

The Grafana Mimir / Overview dashboard from the repository documentation: Status panel, firing alerts, write and read requests per second, latencies, rule evaluations

Source : github.com

To install it, import the JSON files into Grafana and load the rules and alerts into Prometheus, or run make build-mixin after adapting operations/mimir-mixin/config.libsonnet. The dashboards require the labels cluster, namespace, job, pod and instance on the collected metrics. In monolithic mode, job is <namespace>/mimir. The scrape interval must stay at 1 minute or less for the precompiled rules.

Since Mimir is the storage link, watch the error rate and write latency first, then the health of the ring and of object storage: a failed write means gaps in your SLIs. Name recording rules methodically: see Prometheus recording rules. Keep an eye on cardinality, covered in Kubernetes metrics cardinality.

What about Dynatrace?

Mimir documents no Dynatrace integration, and we do not invent one. For Prometheus metrics ingestion on the Dynatrace side, read Prometheus and Dynatrace on Kubernetes: the setup belongs to the matching Dynatrace documentation.

Best practices

  • Start in monolithic mode on a test machine, and never use demo.yaml in production.
  • Put an authenticating reverse proxy in front of Mimir and let it set X-Scope-OrgID.
  • Set retention from the start, per tenant if needed.
  • Install the mixin before going live, with the right labels.
  • Deploy Mimir through GitOps, as in Argo CD for Kubernetes, and record the versions.

Frequently asked questions

Does Mimir replace Prometheus?

No. Prometheus collects the metrics, and Mimir stores them long term and answers queries. Prometheus (or Grafana Alloy) sends to Mimir by remote write, and the OpenTelemetry Collector by OTLP.

Do you need Kubernetes to use Mimir?

Not to get started: a binary or a Docker container is enough in monolithic mode. The documentation also covers a Helm chart, and the dashboards assume Kubernetes unless you set deployment_type: 'baremetal' before compiling them.

How do you separate teams in Mimir?

By tenant: each team uses its own ID in X-Scope-OrgID, with its own limits and retention. The -tenant-federation.enabled=true option allows querying several tenants, separated by |.

Conclusion

Grafana Mimir answers a precise need: keeping the metrics of many Prometheus servers for a long time, with a global view and per-tenant separation. It takes more operating effort than a single Prometheus and an AGPL review, but it ships its own dashboards and alerts. Try monolithic mode on a test machine before you decide.

span.observer is an independent community blog, not affiliated with Grafana Labs or Dynatrace LLC. Trademarks belong to their owners. Tools change quickly: check commands and options in their official documentation.

Originally published on span.observer. French version: https://span.observer/fr/grafana-mimir-stockage-metriques-prometheus/.