Un backend métriques est la brique qui stocke et indexe vos séries temporelles. Prometheus gère la plupart des cas. Passez à Mimir ou VictoriaMetrics quand vous atteignez ses limites : multi-cluster, rétention longue, haute disponibilité native.
Modèle mental : où se place le backend ?
Section intitulée « Modèle mental : où se place le backend ? »Une stack métriques se découpe en 5 briques. Le backend TSDB est la brique #3 :
| # | Brique | Rôle | Exemples |
|---|---|---|---|
| 1 | Sources | Émettent les métriques | Apps, exporters, kubelet |
| 2 | Collecte | Récupère et transmet | Prometheus (pull), OTel Collector (push) |
| 3 | Backend TSDB | Stocke + indexe | Prometheus, Mimir, VictoriaMetrics |
| 4 | Query | Interroge les données | PromQL, query frontend |
| 5 | Alerting | Évalue règles + notifie | Alertmanager |
Quand changer de backend ?
Section intitulée « Quand changer de backend ? »| Symptôme | Cause probable | Solution |
|---|---|---|
| Prometheus OOM fréquents | Trop de séries ou cardinalité | VictoriaMetrics (meilleure compression) |
| Compactions douloureuses | Volume + rétention | Object storage (Mimir ou VM) |
| Rétention > 30 jours requise | Disque local insuffisant | Mimir ou VictoriaMetrics + S3 |
| Multi-cluster à agréger | Pas de vue globale | Mimir (multi-tenant) ou Thanos |
| Besoin HA native | Prometheus = SPOF | Mimir ou VictoriaMetrics cluster |
Matrice de décision
Section intitulée « Matrice de décision »| Critère | Prometheus | Mimir | VictoriaMetrics |
|---|---|---|---|
| Cas d'usage | Mono-cluster | Multi-cluster, multi-tenant | Haute perf, migration facile |
| Complexité ops | Simple | Élevée (microservices) | Modérée |
| Scaling | Vertical uniquement | Horizontal natif | Vertical + cluster |
| Rétention longue | Disque local (limité) | Object storage (S3, GCS) | Object storage |
| HA native | Non (fédération/Thanos) | Oui | Oui (cluster mode) |
| Coût opérationnel | Faible | Élevé | Modéré |
| Licence | Apache 2.0 | AGPL (attention intégration) | Apache 2.0 |
| Compression | ~1.3 bytes/sample | ~1.0 bytes/sample | ~0.7 bytes/sample |
Anti-patterns à éviter
Section intitulée « Anti-patterns à éviter »| Anti-pattern | Pourquoi c'est un problème | Solution |
|---|---|---|
| Labels dynamiques (user_id, request_id) | Explosion de cardinalité → OOM | Utiliser des métriques summary/histogram |
| Rétention longue sur disque local | Compactions lentes, risque de perte | Object storage ou remote_write |
| Un Prometheus isolé par cluster | Pas de vue globale, silos | Fédération, Thanos ou Mimir |
| Scrape interval < 15s sans raison | Volume x2 ou x4 | Garder 15-30s sauf besoins spécifiques |
Backends TSDB
Section intitulée « Backends TSDB » Prometheus TSDB de référence : pull model, PromQL, stockage local
Guides associés
Section intitulée « Guides associés » Métriques (fondamentaux) Types de métriques, conventions de nommage, labels
Alertmanager Routage, grouping et notifications d'alertes
Observabilité Kubernetes Métriques cluster avec kube-state-metrics et node-exporter
À retenir
Section intitulée « À retenir »- Backend TSDB = stockage + indexation des séries temporelles
- Prometheus : excellent pour mono-cluster, mono-tenant, rétention courte
- Mimir/VictoriaMetrics : pour multi-cluster, HA native, rétention longue
- Alertmanager n'est pas un backend, c'est la brique alerting/notification
- Évitez les labels à haute cardinalité : c'est la cause #1 des problèmes de performance