Bonnes pratiques Grafana Mimir : architecture, limites, coûts et exploitation

1. Architecture #

Les choix structurants.

Principes #

Disponible dans : ✓ OSS ✓ Enterprise ✓ Cloud Mimir open source, Enterprise Metrics et Grafana Cloud Metrics

• Mode microservices via le chart Helm en production ; monolithique pour les tests.
• Réplication par zone activée pour les ingesters et les store-gateways.
• Trois buckets (blocs, règles, alertmanager), versionnés ou protégés contre la suppression.
• Memberlist pour les rings, Consul ou etcd uniquement pour le HA tracker.
• Un gateway authentifiant devant Mimir : jamais d'accès direct avec un X-Scope-OrgID libre.

2. Limites et cardinalité #

Le principal poste de coût.

Réglages #

• Des limites explicites par tenant dans la configuration d'exécution, revues chaque trimestre.
• Une alerte quand un tenant dépasse 80 % de max_global_series_per_user.
• mimirtool analyze régulièrement pour supprimer les métriques jamais lues.
• Pas d'identifiants uniques (user_id, request_id, URL complètes) dans les labels.
• Des règles d'enregistrement pour les requêtes lourdes des dashboards.

Bonne Pratique : Une série active coûte de la mémoire dans trois ingesters. Diviser la cardinalité par deux divise presque par deux le coût du chemin d'écriture.

3. Exploitation #

Ce qu'il faut surveiller.

Alertes essentielles #

Montées de version #

• Lire les notes de version (paramètres dépréciés, changements de valeurs par défaut).
• Mettre à jour une zone d'ingesters à la fois.
• Tester d'abord sur un cluster de préproduction avec un trafic dupliqué (remote_write vers deux Mimir).

Schéma de référence et vérification rapide #

Check-list avant la mise en production.

Check-list #

1. Rétention définie par tenant
2. Caches memcached déployés et surveillés
3. HA tracker actif pour les paires Prometheus
4. Dashboards et alertes du mixin installés
5. Règles versionnées et synchronisées par mimirtool
6. Procédure de restauration du bucket testée