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
- Ouvrir l’endpoint /metrics de la cible depuis le réseau de Prometheus.
- Vérifier les noms de métriques, labels et valeurs sans forte cardinalité inattendue.
- Contrôler la target dans Status > Targets et le dernier scrape.
- Tester une requête PromQL simple sur la métrique attendue.
- 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.
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 yamlPiè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.