Mimir - Stockage de métriques Prometheus scalable
Prometheus est un excellent serveur de métriques, mais il a été pensé pour une seule instance. Quand vous voulez de la rétention longue, de la haute disponibilité et du multi-tenant, vous arrivez vite à un mur. Mimir répond à ce problème en gardant le même format de données et le même langage de requête, mais avec un backend scalable. Sur France Nuage, Mimir est managé : vous n'avez rien à déployer, vos métriques y arrivent automatiquement, et Grafana est déjà branché dessus.
Pourquoi Mimir ?
Mimir est un fork communautaire de Cortex maintenu par Grafana Labs. Il offre tout ce que Prometheus fait, mais à une autre échelle.
- Long terme : rétention bien au-delà de ce qu'une instance Prometheus unique peut stocker, sans dégradation des performances
- Multi-tenant : isolation stricte entre tenants via le header
X-Scope-OrgID, parfait pour séparer les environnements ou les équipes - Haute disponibilité : déduplication automatique des échantillons écrits par plusieurs instances Prometheus/Alloy
- PromQL : exactement le même langage de requête que Prometheus, vos dashboards et vos alertes marchent sans rien changer
- Compatible Prometheus : Mimir parle le protocole
remote_writede Prometheus, donc n'importe quel scraper Prometheus (Alloy, Agent, Prometheus lui-même) peut y écrire
Comparatif
| Critère | Mimir (France Nuage) | Prometheus seul | Thanos | VictoriaMetrics | Datadog |
|---|---|---|---|---|---|
| Langage de requête | PromQL | PromQL | PromQL | MetricsQL (≈PromQL) | Propriétaire |
| Multi-tenant | Oui, natif | Non | Oui, sidecar | Oui, via cluster | Oui, payant |
| Rétention longue | Oui (S3) | Limitée au disque | Oui (S3) | Oui | Oui |
| Haute disponibilité | Oui, déduplication | Non | Oui, replicas | Oui | Oui |
| Open source | Oui (AGPLv3) | Oui (Apache 2.0) | Oui (Apache 2.0) | Oui (Apache 2.0) | Non |
| Hébergement souverain | Oui (France) | Selon vous | Selon vous | Selon vous | Non (USA) |
| Coût | Inclus dans la stack | Gratuit + ops | Gratuit + ops | Gratuit + ops | Par host/métrique |
| Coût ops | Zéro | Le vôtre | Le vôtre | Le vôtre | Zéro |
Concrètement
Si vous avez un seul petit service, Prometheus seul suffit. Dès que vous avez plusieurs environnements, plusieurs équipes, ou que vous voulez garder un an d'historique, Mimir vous enlève une tonne de complexité. Thanos et VictoriaMetrics répondent au même besoin, mais il faut les opérer. Chez France Nuage, l'opérationnel est déjà fait.
Côté Datadog, la facturation grimpe avec le nombre de hosts et de métriques custom. Avec Mimir, vous poussez ce que vous voulez dans la limite de cardinalité de votre tenant — pas de calcul à la fin du mois.
Multi-tenant par namespace
Sur France Nuage, un tenant Mimir = un namespace Kubernetes. Quand Alloy scrape un pod dans le namespace mon-app, il écrit dans Mimir avec X-Scope-OrgID: mon-app. Résultat :
- Vos métriques sont isolées des autres équipes par défaut, sans rien configurer
- Votre instance Grafana France Nuage est pré-branchée sur votre tenant, vous n'avez pas à gérer le header côté lecture
- Si vous avez plusieurs environnements (
staging,production), créez deux namespaces et vous obtenez deux tenants séparés gratuitement
Portabilité
- PromQL : le standard de l'industrie. Vos requêtes et vos dashboards sont portables vers n'importe quel backend Prometheus-compatible
- Protocole
remote_writestandard : si demain vous voulez écrire dans un autre backend, il suffit de changer l'URL - Format de métriques Prometheus natif : aucun lock-in sur le format des données
- Licence AGPLv3 : le code reste ouvert, Mimir ne peut pas basculer en propriétaire
Mimir vs auto-hébergement
Vous pourriez déployer Mimir vous-même. Voilà ce que ça implique concrètement :
| Aspect | Auto-hébergement | France Nuage |
|---|---|---|
| Object storage | À provisionner (S3, MinIO) | Inclus |
| Distributeur/Ingester/Querier | À déployer | Déployés |
| Scaling horizontal | À votre charge | Géré |
| Déduplication HA | À configurer | Active |
| Rétention long terme | À paramétrer | 1 an inclus |
| Limites de cardinalité | À définir | Pré-configurées |
| Sauvegardes | À configurer | Automatiques |
| Supervision de Mimir | À votre charge | Incluse |
| Mises à jour sécurité | À surveiller | Appliquées |
Démarrage rapide
1. Rien à déployer
Mimir est déjà en place sur chaque cluster Kubernetes France Nuage. Vous n'avez pas de chart Helm à installer, pas de CRD à créer.
2. Ajouter les annotations sur vos pods
Alloy scrute le cluster en permanence et scrape chaque pod qui porte ces annotations :
metadata:
annotations:
prometheus.io/scrape: "true"
prometheus.io/port: "9090"
prometheus.io/path: "/metrics"
Pour un tutoriel pas à pas avec un exemple Node.js, lisez Exposer les métriques Prometheus de vos pods Kubernetes vers Mimir.
3. Interroger depuis Grafana
Ouvrez votre instance Grafana France Nuage. La datasource Mimir est déjà configurée et liée à votre tenant. Allez dans Explore, sélectionnez Mimir, et tapez une requête PromQL :
sum(rate(http_requests_total[5m])) by (status)
Aller plus loin
Écrire des requêtes PromQL
Mimir parle PromQL exactement comme Prometheus. Tous les exemples de la communauté Prometheus fonctionnent tels quels. Quelques requêtes utiles pour démarrer :
# Taux d'erreurs 5xx sur 5 minutes
sum(rate(http_requests_total{status=~"5.."}[5m]))
# P95 de latence par endpoint
histogram_quantile(0.95,
sum(rate(http_request_duration_seconds_bucket[5m])) by (le, endpoint)
)
# Pods qui ont redémarré dans la dernière heure
increase(kube_pod_container_status_restarts_total[1h]) > 0
Alerting
Mimir intègre un composant de règles qui évalue vos règles d'alerte en continu et les pousse vers Alertmanager. Chez France Nuage, Alertmanager est pré-configuré — vous n'avez qu'à créer vos règles via l'interface Grafana (Alerting > Alert rules) ou à les versionner dans Git pour les appliquer ensuite.
Métriques Kubernetes prêtes à l'emploi
Alloy collecte automatiquement les métriques de kube-state-metrics, node-exporter et cAdvisor sur chaque cluster. Vous pouvez immédiatement interroger :
# Consommation CPU par pod
sum(rate(container_cpu_usage_seconds_total{namespace="mon-app"}[5m])) by (pod)
# Mémoire utilisée par pod
container_memory_working_set_bytes{namespace="mon-app"} / 1024 / 1024
Bonnes pratiques
- Cardinalité maîtrisée : évitez les labels à valeurs infinies (
user_id,request_id,trace_id). Chaque combinaison unique crée une nouvelle série et consomme de la mémoire - Conventions de nommage Prometheus : suffixes
_totalpour les counters,_secondspour les durées,_bytespour les tailles - Labels cohérents : un
appet unenvsur toutes vos métriques pour que vos requêtes restent simples - Un namespace par environnement :
stagingetproductiondans deux namespaces séparés donnent deux tenants Mimir isolés - Dashboards versionnés : exportez vos dashboards Grafana en JSON et commitez-les dans Git