introduction à la surveillance : concepts, métriques et alertes

Objectifs

• Comprendre pourquoi la surveillance (“monitoring”) est un pilier essentiel de la culture DevOps.
• Distinguer les trois piliers de l’observabilité : métriques, logs et traces.
• Identifier les types de métriques clés à surveiller pour une application.
• Comprendre le principe d’une alerte efficace et actionnable.

Pourquoi surveiller ?

Le principe DevOps “You Build It, You Run It” implique que les équipes qui construisent une application sont aussi responsables de son bon fonctionnement en production. Mais comment savoir si une application fonctionne bien ? En la surveillant.

Le monitoring n’est pas seulement là pour détecter les pannes. Il permet de :

• Détecter les problèmes proactivement, souvent avant les utilisateurs.
• Comprendre le comportement et la performance de votre application.
• Prendre des décisions basées sur des données (ex: faut-il ajouter des serveurs ?).

Les 3 Piliers de l’Observabilité

L’observabilité est un concept plus large que le monitoring. C’est la capacité de comprendre l’état interne d’un système en se basant sur ses sorties. Elle repose sur trois types de données.

1. Métriques (Metrics) : Des données numériques collectées à intervalles réguliers.

   • Exemple : Utilisation du CPU toutes les 15 secondes, temps de réponse de chaque requête web.
   • Usage : Idéal pour les dashboards, les graphiques de tendance et les alertes.

2. Logs (Journaux) : Un enregistrement d’un événement qui s’est produit à un moment précis.

   • Exemple : [2025-07-12 10:30:05] ERROR: Connection to database failed.
   • Usage : Essentiel pour débugger un problème spécifique.

3. Traces distribuées : Une vue détaillée du parcours complet d’une requête à travers plusieurs services.

   • Exemple : Voir qu’une requête utilisateur a mis 500ms, dont 50ms dans le service web, 200ms dans l’API, et 250ms dans la base de données.
   • Usage : Crucial pour comprendre les goulots d’étranglement dans les architectures microservices.

Quels types de métriques surveiller ?

On peut classer les métriques en trois grandes catégories :

• Métriques Système (Infrastructure) : La santé de vos machines.

  • Utilisation CPU
  • Utilisation de la mémoire (RAM)
  • Espace disque disponible
  • Trafic réseau

• Métriques Applicatives : La performance de votre application.

  • Latence : Le temps de réponse de vos requêtes.
  • Trafic : Le nombre de requêtes par seconde.
  • Erreurs : Le taux d’erreurs (ex: requêtes HTTP 5xx).
  • Saturation : À quel point votre service est proche de sa capacité maximale.

• Métriques Métier (Business) : Ce qui a de la valeur pour l’entreprise.

  • Nombre d’utilisateurs actifs.
  • Nombre d’inscriptions par heure.
  • Chiffre d’affaires.

Les alertes : Agir sur les symptômes

Une alerte est une notification (email, Slack, PagerDuty…) déclenchée lorsqu’une métrique dépasse un seuil critique pendant une durée définie.

Une bonne alerte est une alerte actionnable.

• Alerter sur les symptômes, pas sur les causes : Il est plus important d’être alerté sur ce qui impacte l’utilisateur (ex: “le temps de réponse a explosé”) que sur la cause potentielle (ex: “le CPU est à 90%”). Une latence élevée peut avoir de multiples causes, mais c’est elle qui affecte l’expérience client.
• Éviter la “fatigue d’alerte” : Trop d’alertes non importantes ou non actionnables créent du bruit. Elles finissent par être ignorées, et on risque de manquer la vraie alerte critique. Chaque alerte doit justifier une action ou une investigation.

Bonnes pratiques

• Commencez simple : Ne cherchez pas à tout mesurer dès le premier jour. Commencez par les métriques applicatives clés (latence, erreurs, trafic).
• Automatisez la surveillance : Le monitoring doit être configuré via de l’Infrastructure as Code, comme le reste de votre stack.
• Utilisez des dashboards, mais ne comptez pas sur eux pour détecter les pannes. Un dashboard sert à l’investigation ; la détection est le rôle des alertes.

Exercices

1. Identifier les métriques :

   • Prenez une application web que vous utilisez tous les jours (ex: un site e-commerce, un réseau social).
   • Listez une métrique système, une métrique applicative et une métrique métier qui seraient pertinentes à surveiller pour cette application.

2. Rédiger une alerte :

   • Pour la métrique applicative que vous avez choisie, rédigez une proposition d’alerte. Elle doit spécifier :
     1. La métrique surveillée.
     2. Le seuil (la valeur critique).
     3. La durée avant déclenchement.
     4. Le niveau de criticité (ex: Avertissement, Critique).
   • Exemple : “Déclencher une alerte critique si le taux d’erreurs 5xx sur le service de paiement est supérieur à 1% pendant plus de 5 minutes.”