Aller au contenu principal

Les outils et l'art de l'alerte

Résumé : l'écosystème de l'observabilité s'organise autour de Prometheus pour les métriques, de Grafana pour la visualisation, et d'OpenTelemetry comme standard d'instrumentation. Cette leçon compare les outils open source et commerciaux, puis traite le sujet le plus négligé du domaine : concevoir des alertes que les gens ne finissent pas par ignorer.

1. Le paysage des outils​

Les deux noms à retenir absolument : Prometheus (les métriques, standard de fait) et OpenTelemetry (l'instrumentation, standard émergent devenu incontournable). Ces deux mots apparaissent dans la quasi-totalité des offres d'emploi mentionnant l'observabilité.

2. Prometheus — le standard des métriques​

Pourquoi Prometheus a gagné dans le monde Kubernetes : sa découverte automatique. Dans un cluster où les pods apparaissent et disparaissent en permanence, un système qui exige de déclarer manuellement chaque cible est ingérable. Prometheus interroge l'API de Kubernetes et découvre seul ce qu'il doit surveiller. C'est ce qui a fait la différence.

3. La pile Grafana — l'approche unifiée​

L'idée de conception de Loki mérite d'être comprise : contrairement à Elasticsearch qui indexe tout le contenu de chaque log, Loki n'indexe que les étiquettes (service, environnement, niveau) et stocke le texte compressé sans index. Conséquence : un coût de stockage nettement inférieur, au prix d'une recherche plein texte moins rapide. Pour la majorité des usages — « montre-moi les logs du service paiement, niveau erreur, entre 14h et 15h » — c'est parfaitement adapté.

4. OpenTelemetry — le standard à connaître​

C'est le conseil le plus durablement utile de cette leçon. L'instrumentation est la partie la plus coûteuse à refaire de toute votre observabilité — elle est répartie dans tout votre code. En choisissant OpenTelemetry, vous rendez ce travail réutilisable quel que soit l'outil que vous choisirez dans trois ans.

5. Open source ou solution commerciale​

Un avertissement utile sur les solutions commerciales : leur facturation est souvent basée sur le volume de données ingérées. Une application un peu trop bavarde en logs peut faire tripler votre facture d'un mois sur l'autre, sans que rien ne vous prévienne. Configurez des limites de volume et des alertes de budget, exactement comme pour le cloud.

6. La fatigue d'alerte — le vrai problème​

La phrase à retenir : « trop d'alertes équivaut à aucune alerte ». Une équipe qui reçoit quarante notifications par jour est aveugle, exactement comme une équipe qui n'en reçoit aucune — avec en plus l'épuisement.

7. Les règles d'une alerte utile​

La règle 5 est celle qui transforme le plus l'expérience d'astreinte. Être réveillé à 3 h du matin par une alerte accompagnée d'un lien vers « Procédure : saturation du pool de connexions » détaillant cinq vérifications concrètes est radicalement différent de recevoir un message laconique « erreur service commandes ». C'est souvent la différence entre dix minutes et deux heures de résolution.

8. À quoi ressemble une bonne alerte​

Voici deux formulations pour le même incident.

Ce que la bonne alerte apporte, point par point : elle nomme l'impact métier (180 paiements échoués, pas un pourcentage abstrait), donne le contexte (le budget consommé), indique l'urgence (taux de consommation), fournit les outils (tableau de bord, procédure), et suggère une piste (un déploiement récent). La personne réveillée peut agir immédiatement.

La ligne sur le déploiement récent est particulièrement précieuse : dans une majorité d'incidents, la cause est un changement récent. Corréler automatiquement les alertes avec les déploiements fait gagner un temps considérable.

9. Les tableaux de bord — quelques principes​

Le principe 3 est le plus souvent négligé. Un graphique affichant « latence : 340 ms » ne renseigne sur rien sans référence. Est-ce normal ? Est-ce deux fois plus lent qu'hier ? Affichez toujours soit le seuil de SLO, soit la même période de la semaine précédente. Sans référence, un graphique est décoratif.

Retenir en 30 secondes​

  • Prometheus = standard des métriques, modèle de collecte active et découverte automatique (d'où son succès sur Kubernetes).
  • Grafana = standard incontesté de la visualisation. Loki (logs, économique), Tempo (traces), Pyroscope (profils).
  • Loki n'indexe que les étiquettes, pas le contenu — d'où son faible coût comparé à Elasticsearch.
  • OpenTelemetry = le standard d'instrumentation. Instrumentez une fois, changez d'outil librement.
  • Open source ou commercial : petite équipe sans expert → commercial. Kubernetes avec compétences → Prometheus. Grande échelle → auto-hébergé, plus économique.
  • Attention aux factures commerciales : elles suivent le volume de logs. Posez des limites.
  • Fatigue d'alerte : « trop d'alertes équivaut à aucune alerte ».
  • Règle numéro un : toute alerte doit exiger une action humaine immédiate. Sinon c'est un tableau de bord.
  • Chaque alerte doit pointer vers une procédure écrite (runbook). C'est le levier le plus puissant sur le temps de résolution.
  • Marquez les déploiements sur vos graphiques — la cause d'un incident est le plus souvent un changement récent.

Suivant : Cas d'usage réels + FAQ 14 questions →