Grafana Mimir stockage métriques Prometheus : le dépôt grafana/mimir héberge un logiciel écrit en Go, qui sert de stockage longue durée, multi-locataire et scalable pour les métriques Prometheus. Son README le présente comme « un stockage longue durée scalable pour Prometheus ». Il est publié sous licence GNU AGPL v3 (AGPL-3.0-only), ce qui compte avant de l’embarquer dans un produit.
Le problème est classique. Un seul Prometheus conserve ses données en local, sur une période limitée, et ne donne pas de vue globale quand vous en exploitez dix. Mimir reçoit les échantillons de tous vos Prometheus, les range dans un stockage objet et répond aux requêtes PromQL. Comment est-il construit, comment le démarrer, et comment le surveiller lui-même ?
Précision d’honnêteté : span.observer n’a pas installé ni lancé Mimir. Les commandes viennent du README, du dossier docs/ du dépôt et des pages grafana.com/docs/mimir, lus le 7 novembre 2026. Les captures reproduisent des fichiers et une image du dépôt. Le nombre d’étoiles affiché sur la page du dépôt était d’environ 5,3 k ce jour-là, sans valeur exacte relue à l’API GitHub, qui était inaccessible.
Grafana Mimir stockage métriques Prometheus : ce que dit le dépôt
- Licence : le fichier LICENSE contient le texte de la GNU Affero General Public License version 3. Selon
LICENSING.md, seulsvendor/etoperations/relèvent de licences amont, dont le texte est fourni. Le préambule de l’AGPL la décrit comme conçue pour les logiciels serveur : faites relire votre usage par un juriste. - Version : le fichier
VERSIONet la dernière section publiée du CHANGELOG indiquent 3.2.4. La date de cette version n’a pas pu être relue : nous ne la citons pas. La section « main / unreleased » liste de nombreux changements, dont des retraits d’options, marqués[CHANGE]. - Revendications du projet : le README affirme que des tests internes montrent une capacité jusqu’à un milliard de séries actives. C’est une affirmation du projet, que nous n’avons pas mesurée.
- Stockage objet : selon la documentation, les blocs vont vers Amazon S3, Google Cloud Storage, Azure Storage, OpenStack Swift, ou le système de fichiers local (nœud unique seulement).
Architecture à composants et multi-tenance
Mimir se compose de microservices appelés composants : distributor, ingester, query-frontend, querier, store-gateway, compactor, ruler, alertmanager, entre autres. Le code de tous les composants est compilé dans un seul binaire, et le paramètre -target choisit le rôle. Deux modes existent : monolithique (-target=all, tout dans un processus) et microservices, recommandé en production.
Depuis la version 3.0, deux architectures coexistent. L’architecture « ingest storage », préférée par la documentation, passe par Kafka pour séparer lecture et écriture. L’architecture classique utilise des ingesters avec journal d’écriture local.
Le format de stockage reprend celui de Prometheus TSDB : chaque locataire a ses propres blocs, de deux heures par défaut. Chaque requête HTTP porte l’identifiant du locataire dans l’en-tête X-Scope-OrgID. Mimir ne fait pas l’authentification : un proxy inverse doit l’assurer et injecter l’en-tête.
Installer Mimir pas à pas, selon la documentation
Étape 1 : récupérer Mimir
docker pull grafana/mimir:latest
# ou un binaire local (Linux amd64)
curl -fLo mimir https://github.com/grafana/mimir/releases/latest/download/mimir-linux-amd64
chmod +x mimirÉtape 2 : écrire la configuration de démonstration
Le guide « Get started » donne un fichier demo.yaml en mode monolithique avec stockage sur disque local. Son en-tête précise de ne pas l’utiliser en production. La première capture le reproduit, avec la configuration Prometheus de la même page.
Étape 3 : démarrer et brancher Prometheus
./mimir --config.file=./demo.yamlMimir écoute sur le port 9009. Ajoutez ensuite à Prometheus le bloc remote_write de la capture, puis redémarrez-le. Avec Grafana Alloy, le composant prometheus.remote_write envoie vers la même adresse. Le guide note aussi que Mimir peut envoyer des statistiques d’usage anonymes, avec une procédure de désactivation dans la documentation.
Étape 4 : interroger en PromQL
Dans Grafana, ajoutez une source de données Prometheus avec l’URL http://localhost:9009/prometheus (binaire local). Sans Grafana, la table de l’API HTTP donne l’endpoint de requête instantanée GET,POST <prometheus-http-prefix>/api/v1/query. La commande ci-dessous en est déduite : nous ne l’avons pas exécutée.
curl -G http://localhost:9009/prometheus/api/v1/query \
--data-urlencode 'query=up'
# avec multitenancy_enabled: true, ajoutez
# -H 'X-Scope-OrgID: tenant-1'Pour vérifier que cela fonctionne, la page se termine ainsi : interrogez les métriques dans Grafana Explore et créez un panneau avec la nouvelle source. Une série up du job prometheus devrait apparaître.
OpenTelemetry : ingestion OTLP
Mimir accepte aussi OTLP sur HTTP : le point d’entrée est POST /otlp/v1/metrics. La page sur le Collector recommande OTLP plutôt que remote write. Elle donne l’exporteur otlphttp avec l’adresse http://<mimir-endpoint>/otlp, ou prometheusremotewrite vers /api/v1/push. La capture suivante reproduit l’exemple avec authentification de base, et la rétention par locataire.
Trois points de la page de format méritent attention. Les points des noms sont convertis en _. Les attributs de ressource vont dans la série target_info, sauf job et instance déduits de service.name et service.instance.id. Les histogrammes exponentiels OpenTelemetry sont refusés par défaut tant que les histogrammes natifs ne sont pas activés. Pour le contexte, voyez les composants du Collector contrib et OpenTelemetry face à Prometheus.
Limites et points ouverts
- Complexité : le mode microservices multiplie les composants, et l’architecture ingest storage ajoute Kafka. Le mode monolithique convient pour démarrer, mais la documentation le déconseille à grande échelle.
- Disques : la documentation déconseille NFS, EFS et les systèmes de fichiers réseau pour les composants qui écrivent en local, et recommande des SSD (risque de plantages ou de corruption silencieuse).
- Rétention : par défaut, rien n’est supprimé. Réglez
compactor_blocks_retention_period. La suppression par série n’est pas prise en charge. - Sécurité : pas d’authentification intégrée, donc un proxy inverse est obligatoire.
- Évolution rapide : le CHANGELOG « unreleased » retire des options et en renomme d’autres. Lisez les notes avant chaque mise à jour.
- Licence : l’AGPL impose des obligations si vous modifiez le logiciel et le proposez en service réseau.
Observer Mimir lui-même
Mimir expose ses métriques Prometheus sur /metrics. Le dépôt fournit un « mixin » : dans operations/mimir-mixin-compiled/, 27 fichiers de tableaux de bord JSON, rules.yaml (règles d’enregistrement) et alerts.yaml (127 entrées alert: au 7 novembre 2026, un même nom pouvant apparaître à plusieurs niveaux de gravité). Parmi eux : MimirIngesterUnhealthy, MimirRequestErrors et MimirRequestLatency. Chaque alerte porte une runbook_url.
La capture ci-dessous montre le tableau « Mimir / Overview » publié dans la documentation du dépôt : état du cluster, écritures, lectures, règles et stockage objet. Les noms de cluster et de namespace qu’on y voit sont ceux de l’exemple.
Pour l’installer, importez les JSON dans Grafana et chargez les règles et alertes dans Prometheus, ou lancez make build-mixin après avoir adapté operations/mimir-mixin/config.libsonnet. Les tableaux exigent les étiquettes cluster, namespace, job, pod et instance sur les métriques collectées. En mode monolithique, job vaut <namespace>/mimir. L’intervalle de collecte doit rester à 1 minute ou moins pour les règles précompilées.
Comme Mimir est le maillon de stockage, surveillez d’abord le taux d’erreurs et la latence d’écriture, puis la santé de l’anneau et du stockage objet : un échec d’écriture signifie des trous dans vos SLI. Les règles d’enregistrement se nomment avec méthode : voyez les recording rules Prometheus. Gardez un œil sur la cardinalité, expliquée dans la cardinalité des métriques Kubernetes.
Et Dynatrace ?
Mimir ne documente aucune intégration Dynatrace, et nous n’en inventons pas. Pour l’ingestion de métriques Prometheus côté Dynatrace, lisez Prometheus et Dynatrace sur Kubernetes : la configuration relève de la documentation Dynatrace correspondante.
Bonnes pratiques
- Commencez en mode monolithique sur un poste de test, jamais avec
demo.yamlen production. - Placez un proxy inverse authentifié devant Mimir et laissez-le fixer
X-Scope-OrgID. - Fixez la rétention dès le départ, par locataire si besoin.
- Installez le mixin avant la mise en production, avec les bonnes étiquettes.
- Déployez Mimir par GitOps, comme dans Argo CD pour Kubernetes, et notez les versions.
Questions fréquentes
Mimir remplace-t-il Prometheus ?
Non. Prometheus collecte les métriques, et Mimir les stocke à long terme et répond aux requêtes. Prometheus (ou Grafana Alloy) envoie vers Mimir par remote write, et le Collector OpenTelemetry par OTLP.
Faut-il Kubernetes pour utiliser Mimir ?
Non pour démarrer : un binaire ou un conteneur Docker suffisent en mode monolithique. La documentation prévoit aussi un chart Helm, et les tableaux de bord supposent Kubernetes sauf si vous réglez deployment_type: 'baremetal' avant de les compiler.
Comment séparer les équipes dans Mimir ?
Par locataire : chaque équipe utilise son identifiant dans X-Scope-OrgID, avec ses propres limites et sa propre rétention. L’option -tenant-federation.enabled=true permet d’interroger plusieurs locataires, séparés par |.
Conclusion
Grafana Mimir répond à un besoin précis : garder longtemps les métriques de nombreux Prometheus, avec une vue globale et une séparation par locataire. Il demande plus d’exploitation qu’un Prometheus seul et une licence AGPL relue, mais il fournit ses tableaux de bord et ses alertes. Essayez le mode monolithique sur un poste de test avant de décider.
span.observer est un blog indépendant de la communauté, non affilié à Grafana Labs ni à Dynatrace LLC. Les marques citées appartiennent à leurs propriétaires. Les outils évoluent vite : vérifiez les commandes et options dans leur documentation officielle.
