Guide

Comment lire et vérifier des métriques Prometheus

Vérifier qu’une cible expose des métriques cohérentes et que Prometheus les collecte sans erreur.

⌚ Environ 2 min de lecture
Voir mes favoris

Vérifier qu’une cible expose des métriques cohérentes et que Prometheus les collecte sans erreur.

Avant de commencer

Travaillez sur une copie ou un test contrôlé lorsque l’action peut affecter la production. Conservez les horodatages, captures et l’ancienne configuration afin de comparer le résultat.

Étapes

  1. Ouvrir l’endpoint /metrics de la cible depuis le réseau de Prometheus.
  2. Vérifier les noms de métriques, labels et valeurs sans forte cardinalité inattendue.
  3. Contrôler la target dans Status > Targets et le dernier scrape.
  4. Tester une requête PromQL simple sur la métrique attendue.
  5. Comparer scrape duration, erreurs et timestamps avant d’ajuster les alertes.

Validation

Rejouez le test initial après la modification et confirmez que le service attendu fonctionne sans créer de nouvelle régression. Documentez l’état final.

Complément technique

Kubernetes / Prometheus : état du workload et observabilité doivent rester corrélés

Repères techniques

  • CrashLoopBackOff est un backoff de redémarrage : la cause réelle se trouve dans exit code, events, logs --previous, probes ou limites de ressources.
  • Prometheus scrape une cible ; UP=1 prouve le scrape, pas que chaque métrique est sémantiquement correcte.
  • Une forte cardinalité de labels peut augmenter fortement mémoire et stockage sans augmenter la valeur des métriques.

Kubernetes

Pour CrashLoop, lire les logs de l’instance précédente avant qu’ils disparaissent ; pour Prometheus, vérifier Target puis requête simple.

kubectl describe pod <pod>
kubectl logs <pod> --previous
kubectl get pod <pod> -o yaml

Pièges spécifiques

  • Supprimer le Pod en boucle ne corrige pas la configuration du Deployment/StatefulSet.
  • Ajouter un label contenant un ID utilisateur/requête crée souvent une cardinalité explosive.

Comment valider

  • Le Pod reste Ready sans nouveaux restarts et les probes reflètent la santé réelle.
  • La cible Prometheus est UP et la requête attendue retourne des séries stables avec cardinalité maîtrisée.

Preuves et vérifications

CrashLoopBackOff est un backoff de redémarrage : la cause réelle se trouve dans exit code, events, logs --previous, probes ou limites de ressources. Prometheus scrape une cible ; UP=1 prouve le scrape, pas que chaque métrique est sémantiquement correcte.

Contrôle de résultat

Le Pod reste Ready sans nouveaux restarts et les probes reflètent la santé réelle. La cible Prometheus est UP et la requête attendue retourne des séries stables avec cardinalité maîtrisée.

Point d’attention

Supprimer le Pod en boucle ne corrige pas la configuration du Deployment/StatefulSet. Une forte cardinalité de labels peut augmenter fortement mémoire et stockage sans augmenter la valeur des métriques.

Concepts liés

Référence primaire : Prometheus Documentation — PromQL.

♡ 0