1. Les limites de Prometheus seul #
Pourquoi un stockage de métriques distribué.
Un serveur, un disque #
Prometheus est excellent pour collecter et alerter, mais il a été conçu comme un serveur autonome : ses données vivent sur son disque local, sa capacité est bornée par une seule machine et chaque instance ne voit que ce qu'elle collecte.
| Besoin | Prometheus seul | Avec Mimir |
|---|---|---|
| Rétention de plusieurs années | Disque local coûteux, pas de downsampling | Stockage objet bon marché, rétention par tenant |
| Haute disponibilité | Deux réplicas aux données légèrement différentes | Déduplication HA à l'ingestion, réplication ×3 |
| Vue globale | Une instance = un périmètre | Toutes les sources dans une seule API PromQL |
| Plusieurs équipes | Une instance par équipe | Multi-tenant natif avec limites par tenant |
| Centaines de millions de séries | Impossible sur un nœud | Scalabilité horizontale de chaque composant |
Mimir en une phrase #
Grafana Mimir est une base de données de séries temporelles distribuée, compatible Prometheus : elle reçoit les métriques par remote_write (ou OTLP), les stocke en blocs TSDB dans un stockage objet et les sert via l'API HTTP de Prometheus. Grafana l'interroge comme une source de données Prometheus classique.
À savoir : Mimir est né en 2022 d'un fork de Cortex par Grafana Labs, sous licence AGPLv3. Il en reprend l'architecture (hash ring, ingesters, store-gateway) avec de nombreuses optimisations : compacteur partitionné, moteur de requêtes plus rapide, chemin d'ingestion découplé par Kafka dans les versions récentes.
2. Les composants #
Chaque composant a un rôle unique et se met à l'échelle séparément.
Vue d'ensemble #
| Composant | Chemin | Rôle |
|---|---|---|
| distributor | écriture | Valide les échantillons, applique les limites, déduplique les paires HA et répartit les séries vers les ingesters |
| ingester | écriture / lecture | Garde les données récentes en mémoire (WAL sur disque), produit des blocs de 2 h et les téléverse |
| query-frontend | lecture | Découpe les requêtes longues, met en cache les résultats, met en file d'attente |
| query-scheduler | lecture | File d'attente partagée entre query-frontends et queriers (facultatif) |
| querier | lecture | Évalue PromQL en interrogeant ingesters (récent) et store-gateways (historique) |
| store-gateway | lecture | Expose les blocs du stockage objet, avec index-headers et caches |
| compactor | fond | Fusionne et déduplique les blocs, applique la rétention, maintient le bucket index |
| ruler | fond | Évalue les règles d'enregistrement et d'alerte par tenant |
| alertmanager | fond | Alertmanager multi-tenant, configuré par API |
Le hash ring #
Les composants qui partagent une charge (distributors, ingesters, store-gateways, compactors, rulers) se coordonnent via un hash ring. Chaque instance y possède des jetons ; le hachage d'une série (tenant + labels) désigne les ingesters responsables. Le ring est stocké dans memberlist (gossip, par défaut), Consul ou etcd.
Bonne Pratique : Gardez memberlist : il ne demande aucune dépendance externe. Ouvrez simplement le port de gossip (7946 par défaut) entre les pods Mimir.
3. Modes de déploiement #
Un seul binaire, plusieurs façons de le lancer.
Monolithique ou microservices #
Tous les composants sont dans le même binaire. Le paramètre -target choisit ce que lance un processus.
| Mode | Lancement | Pour qui |
|---|---|---|
| Monolithique | -target=all (défaut) | Tests, petites installations, TP ; on peut lancer plusieurs réplicas identiques |
| Microservices | -target=distributor, -target=ingester... | Production : chaque composant se met à l'échelle selon sa charge (chart Helm 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=ingesterÀ savoir : Les versions récentes de Mimir proposent l'architecture « ingest storage » : les distributors écrivent dans Kafka (ou un équivalent compatible) et les ingesters consomment ce journal. Lecture et écriture sont ainsi découplées : une rafale de requêtes ne ralentit plus l'ingestion. Le principe du stockage en blocs reste identique, c'est celui que décrit cette formation.
Les ports et points d'entrée à connaître #
| Point d'entrée | Usage |
|---|---|
/api/v1/push | Réception remote_write Prometheus |
/otlp/v1/metrics | Réception OTLP (OpenTelemetry) |
/prometheus/api/v1/query | API de requête compatible Prometheus (URL de la datasource Grafana : http://mimir:8080/prometheus) |
/prometheus/config/v1/rules | API du ruler |
/alertmanager | Interface et API de l'Alertmanager |
/ready, /metrics, /config | Santé, métriques internes, configuration effective |
/ingester/ring, /distributor/ha_tracker | Pages d'état du ring et du suivi HA |
