1. The limits of Prometheus alone #
Why a distributed metrics store.
One server, one disk #
Available in: ✓ OSS ✓ Enterprise ✓ Cloud Mimir open source, Enterprise Metrics and Grafana Cloud Metrics
Prometheus is excellent for collecting and alerting, but it was designed as a standalone server: its data lives on its local disk, its capacity is bounded by a single machine and each instance only sees what it collects.
| Need | Prometheus alone | With Mimir |
|---|---|---|
| Retention of several years | Expensive local disk, no downsampling | Cheap object storage, per-tenant retention |
| High availability | Two replicas with slightly different data | HA deduplication at ingestion, ×3 replication |
| Global view | One instance = one scope | All sources in a single PromQL API |
| Several teams | One instance per team | Native multi-tenancy with per-tenant limits |
| Hundreds of millions of series | Impossible on one node | Horizontal scalability of each component |
Mimir in one sentence #
Grafana Mimir is a distributed, Prometheus-compatible time series database: it receives metrics via remote_write (or OTLP), stores them as TSDB blocks in object storage and serves them through the Prometheus HTTP API. Grafana queries it like a regular Prometheus data source.
Good to know: Mimir was born in 2022 as a fork of Cortex by Grafana Labs, under the AGPLv3 license. It keeps its architecture (hash ring, ingesters, store-gateway) with many optimizations: partitioned compactor, faster query engine, and an ingestion path decoupled by Kafka in recent versions.
2. The components #
Each component has a single role and scales separately.
Overview #
| Component | Path | Role |
|---|---|---|
| distributor | write | Validates samples, applies limits, deduplicates HA pairs and distributes series to the ingesters |
| ingester | write / read | Keeps recent data in memory (WAL on disk), produces 2h blocks and uploads them |
| query-frontend | read | Splits long queries, caches results, queues requests |
| query-scheduler | read | Shared queue between query-frontends and queriers (optional) |
| querier | read | Evaluates PromQL by querying ingesters (recent) and store-gateways (history) |
| store-gateway | read | Exposes blocks from object storage, with index-headers and caches |
| compactor | background | Merges and deduplicates blocks, applies retention, maintains the bucket index |
| ruler | background | Evaluates recording and alerting rules per tenant |
| alertmanager | background | Multi-tenant Alertmanager, configured through the API |
The hash ring #
Components that share a load (distributors, ingesters, store-gateways, compactors, rulers) coordinate through a hash ring. Each instance owns tokens in it; the hash of a series (tenant + labels) designates the responsible ingesters. The ring is stored in memberlist (gossip, the default), Consul or etcd.
Good practice: Keep memberlist: it needs no external dependency. Just open the gossip port (7946 by default) between the Mimir pods.
3. Deployment modes #
A single binary, several ways to run it.
Monolithic or microservices #
All components are in the same binary. The -target parameter chooses what a process runs.
| Mode | Startup | For whom |
|---|---|---|
| Monolithic | -target=all (default) | Tests, small installations, labs; several identical replicas can be run |
| Microservices | -target=distributor, -target=ingester... | Production: each component scales according to its load (Helm chart mimir-distributed) |
# Monolithique : tous les composants dans un processus
mimir -config.file=/etc/mimir.yaml -target=all
# Un seul composant
mimir -config.file=/etc/mimir.yaml -target=ingesterGood to know: Recent versions of Mimir offer the « ingest storage » architecture: distributors write to Kafka (or a compatible equivalent) and ingesters consume this log. Reads and writes are thus decoupled: a burst of queries no longer slows down ingestion. The block storage principle remains the same; it is the one described in this course.
Ports and endpoints to know #
| Endpoint | Usage |
|---|---|
/api/v1/push | Receiving Prometheus remote_write |
/otlp/v1/metrics | Receiving OTLP (OpenTelemetry) |
/prometheus/api/v1/query | Prometheus-compatible query API (Grafana datasource URL: http://mimir:8080/prometheus) |
/prometheus/config/v1/rules | Ruler API |
/alertmanager | Alertmanager interface and API |
/ready, /metrics, /config | Health, internal metrics, effective configuration |
/ingester/ring, /distributor/ha_tracker | Status pages for the ring and the HA tracker |
