Grafana Mimir is a horizontally scalable, highly available, multi-tenant Prometheus-as-a-service system.
Let’s see Mimir in action. Imagine you’ve got a Kubernetes cluster and Prometheus is scraping metrics from your applications. Normally, Prometheus stores these metrics locally, but that’s not sustainable for long-term storage and analysis. Mimir steps in here.
First, you’ll need to set up Mimir itself. This usually involves deploying Mimir components like the distributor, ingester, querier, and ruler. For a basic setup on Kubernetes, you might use the Grafana Mimir Helm chart.
# values.yaml for Grafana Mimir Helm chart (simplified)
distributed:
enabled: true
ingester:
enabled: true
querier:
enabled: true
Once Mimir is running, you need to configure your Prometheus instances to send their metrics to Mimir instead of (or in addition to) their local storage. This is done via the remote_write and remote_read configurations in your Prometheus prometheus.yml.
# prometheus.yml
scrape_configs:
- job_name: 'my-app'
static_configs:
- targets: ['localhost:9090']
remote_write:
- url: "http://mimir-distributor.mimir.svc.cluster.local:8080/api/v1/push"
remote_read:
- url: "http://mimir-querier.mimir.svc.cluster.local:8080/api/v1/read"
Here, mimir-distributor.mimir.svc.cluster.local is the Kubernetes service name for your Mimir distributor, and mimir-querier.mimir.svc.cluster.local is for the querier. The /api/v1/push endpoint is where Prometheus sends its metrics, and /api/v1/read is where Prometheus (or Grafana) queries for metrics.
Now, the magic happens. Your Prometheus instances will stream metrics directly to Mimir. Mimir then handles the long-term storage, sharding, and querying of these metrics across its distributed architecture.
The real power emerges when you connect Grafana to Mimir. In Grafana, you add Mimir as a Prometheus data source, pointing it to the Mimir querier’s URL.
// Grafana Data Source configuration (simplified)
{
"name": "Mimir",
"type": "prometheus",
"url": "http://mimir-querier.mimir.svc.cluster.local:8080",
"access": "proxy"
}
With this setup, you can now build dashboards in Grafana that query metrics stored in Mimir. These queries will be incredibly fast, even for data that’s months or years old, because Mimir’s architecture is designed for efficient retrieval from its distributed object storage backend (like S3, GCS, or MinIO).
What problem does Mimir solve? It decouples metric storage from the Prometheus server itself. This means you don’t have to worry about Prometheus running out of local disk space, experiencing performance degradation with large datasets, or managing complex HA setups for Prometheus storage. Mimir provides a scalable, resilient, and cost-effective solution for long-term metric retention.
Internally, Mimir uses a microservices architecture. The distributor receives data from Prometheus, splits it into chunks, and sends it to the ingester. The ingester writes these chunks to object storage. The querier is responsible for retrieving data from object storage when Grafana or Prometheus requests it, often querying multiple ingesters or directly from object storage. The ruler evaluates alerting and recording rules.
The most surprising thing about Mimir’s architecture is its reliance on object storage for all persistent data. Unlike traditional Prometheus, which has its own block-based storage, Mimir offloads all durable storage to external object storage. This might seem like a performance bottleneck, but Mimir’s clever chunking, compression, and indexing strategies, combined with its distributed query engine, make it incredibly performant for both writes and reads, even at petabyte scale. It also means that Mimir components themselves are largely stateless, simplifying scaling and resilience.
One common misconception is that Mimir is just "Prometheus with a bigger disk." It’s much more. Mimir’s internal data model and query execution are fundamentally different, optimized for distributed access and long-term retention. It doesn’t just store blocks; it stores highly optimized, compressed chunks of time-series data that can be accessed in parallel by multiple queriers.
The next step you’ll likely want to explore is Mimir’s multi-tenancy capabilities, allowing you to isolate different teams or applications’ metrics within a single Mimir cluster.