Observabilité : métriques, logs, traces, SLI et SLO

Objectif

Comprendre ce que l'on mesure quand on « supervise » une application, distinguer les trois grands signaux (métriques, journaux, traces) et savoir fixer un objectif de service chiffré, avec son budget d'erreur. C'est la base de toute la formation.

L'essentiel

• La supervision répond à « est-ce que ça marche ? » ; l'observabilité permet de répondre à « pourquoi ça ne marche pas ? » sans ajouter de code à chaud.
• Trois signaux se complètent : les métriques (des nombres dans le temps), les journaux (des événements en texte), les traces (le parcours d'une requête à travers plusieurs services).
• Un SLI (Service Level Indicator) est une mesure de la qualité vue par l'utilisateur : part des requêtes réussies, part des requêtes servies en moins de 300 ms…
• Un SLO (Service Level Objective) est la cible de ce SLI sur une fenêtre de temps : « 99,9 % des paiements réussis sur 30 jours ».
• Le budget d'erreur = 100 % − SLO. Tant qu'il en reste, l'équipe peut livrer ; quand il est épuisé, on privilégie la fiabilité.
• On alerte sur les symptômes que subit l'utilisateur (erreurs, lenteur), pas sur chaque cause possible (CPU à 80 %).

Supervision ou observabilité ?

Prenons une boutique en ligne de Casablanca qui vend des produits d'artisanat. Un vendredi soir, des clients se plaignent : « le paiement tourne dans le vide ».

• Avec une supervision classique, vous avez un voyant vert ou rouge par serveur : le serveur web répond au ping, la base de données tourne. Tout est vert… et pourtant les clients ne paient pas.
• Avec de l'observabilité, vous voyez que le taux d'erreurs de l'API /api/paiement est passé de 0,05 % à 4 % à 21 h 12, que les journaux montrent des « timeout » vers la passerelle de paiement, et qu'une trace d'une requête lente montre 9 secondes passées dans l'appel au prestataire bancaire.

L'observabilité ne remplace pas la supervision : elle l'enrichit. Le mot vient de l'automatique : un système est observable si l'on peut déduire son état interne à partir de ce qu'il émet.

Les trois signaux

Le parcours habituel d'un diagnostic : une métrique déclenche l'alerte, un tableau de bord situe le problème dans le temps, les journaux et les traces donnent le détail.

Les métriques

Une métrique est une série temporelle : un nom, des étiquettes (labels) et des valeurs successives. Prometheus, l'outil central de cette formation, distingue quatre types :

# Compteur (counter) : ne fait que monter (ou repart à zéro au redémarrage)
http_requests_total{route="/api/paiement", status="200"}   184532

# Jauge (gauge) : monte et descend
node_memory_MemAvailable_bytes{instance="srv-web-rabat:9100"}   2147483648

# Histogramme (histogram) : des compteurs par tranche de durée (« bucket »)
http_request_duration_seconds_bucket{le="0.3"}   181020
http_request_duration_seconds_bucket{le="+Inf"}  184532

# Résumé (summary) : des quantiles calculés côté application
rpc_duration_seconds{quantile="0.95"}   0.41

Les métriques sont peu coûteuses : qu'il y ait 10 ou 10 000 requêtes par seconde, un compteur occupe la même place. C'est pour cela qu'on les garde longtemps et qu'on alerte dessus.

Attention aux étiquettes : chaque combinaison de valeurs crée une nouvelle série. Une étiquette client_id avec 200 000 clients crée 200 000 séries : c'est l'erreur dite de cardinalité qui fait exploser la mémoire du serveur de métriques.

Les journaux

Les journaux racontent les événements un par un. Ils sont indispensables pour comprendre un cas précis (« pourquoi la commande 88412 a échoué ? »). Bonnes pratiques :

{"ts":"2026-10-18T21:12:04Z","niveau":"error","service":"paiement","commande":88412,"msg":"timeout passerelle","duree_ms":9001}

• un format structuré (JSON) plutôt que du texte libre : on peut filtrer par champ ;
• un niveau (debug, info, warn, error) ;
• jamais de numéro de carte, de mot de passe ni de CIN en clair dans un journal (loi 09-08 sur les données personnelles au Maroc).

Les traces

Une trace suit une requête à travers tous les services. Chaque étape est un span avec un début, une durée et un identifiant de trace partagé. Le standard ouvert actuel est OpenTelemetry (bibliothèques, protocole OTLP), avec des outils comme Jaeger ou Tempo pour stocker et afficher les traces. Prometheus, lui, ne stocke pas de traces : il s'occupe des métriques.

Les méthodes pour choisir quoi mesurer

Deux grilles simples évitent de tout mesurer au hasard :

• RED pour un service qui reçoit des requêtes : Rate (débit), Errors (erreurs), Duration (durée).
• USE pour une ressource (CPU, disque, réseau) : Utilization (taux d'occupation), Saturation (file d'attente), Errors.

Les « quatre signaux d'or » popularisés par Google reprennent la même idée : latence, trafic, erreurs, saturation.

Service « paiement » (RED)            Serveur srv-bdd-casa (USE)
  débit   : requêtes/s                 CPU     : % occupé, file d'exécution
  erreurs : % de réponses 5xx          disque  : % plein, temps d'attente E/S
  durée   : 95e centile en ms          réseau  : débit, paquets perdus

SLI, SLO, SLA

Trois sigles qu'on confond souvent :

Le SLA est toujours moins exigeant que le SLO : le SLO sert d'alarme interne avant de rompre le contrat.

Un bon SLI se calcule comme un ratio d'événements bons sur événements totaux :

SLI disponibilité = requêtes réussies / requêtes totales
SLI latence       = requêtes servies en moins de 300 ms / requêtes totales

Le budget d'erreur

Si le SLO est de 99,9 % sur 30 jours, vous avez le droit à 0,1 % d'échec :

30 jours × 24 h × 60 min = 43 200 minutes
43 200 × 0,001           = 43,2 minutes d'indisponibilité tolérée par mois

Même calcul en requêtes : sur 2 millions de paiements par mois,
2 000 000 × 0,001 = 2 000 requêtes en échec tolérées.

Chaque « 9 » supplémentaire coûte très cher (redondance, astreinte, tests). Une école en ligne de Fès n'a pas besoin du même SLO qu'une banque. Choisissez un objectif que vos utilisateurs remarquent vraiment.

Le budget d'erreur devient un outil de décision : il en reste ? On livre la nouvelle version. Il est épuisé ? On gèle les nouveautés et on corrige la fiabilité.

Écrire ses SLO noir sur blanc

Un SLO qui n'existe que dans la tête d'une personne ne sert à rien. Rangez-les dans le dépôt Git de l'équipe, dans un format simple :

# slo/paiement.yml
service: paiement
sli: requêtes /api/paiement sans réponse 5xx / requêtes totales
objectif: 99.9          # en pourcentage
fenetre: 30d            # 30 jours glissants
responsable: equipe-paiement
revue: trimestrielle    # on rediscute l'objectif tous les trois mois

Calculer un SLI à la main

Avant d'avoir Prometheus, un simple journal d'accès suffit pour mesurer. Avec un journal au format combiné de nginx, le code de statut est le 9e champ :

# Nombre total de requêtes
wc -l < /var/log/nginx/access.log

# Nombre de réponses 5xx (erreurs côté serveur)
awk '$9 ~ /^5/ {n++} END {print n+0}' /var/log/nginx/access.log

# Disponibilité en pourcentage
awk '{t++} $9 !~ /^5/ {ok++} END {printf "%.2f %%\n", ok*100/t}' /var/log/nginx/access.log

Pourquoi seulement les 5xx ? Une erreur 404 ou 401 est en général la faute du client (mauvaise adresse, mauvais mot de passe) : elle ne doit pas consommer le budget d'erreur du service. À l'inverse, une 503 signifie que vous n'avez pas pu répondre.

Dans les leçons suivantes, Prometheus fera ce calcul en continu :

sum(rate(http_requests_total{status!~"5.."}[30d])) / sum(rate(http_requests_total[30d]))

Où se place chaque outil

  Applications et serveurs
  │  métriques (/metrics)      journaux               traces (OTLP)
  ▼                            ▼                      ▼
  Prometheus  ──règles──▶ Alertmanager ──▶ e-mail, chat, astreinte
  │                            Loki / Elasticsearch   Jaeger / Tempo
  └──────────────┬─────────────┴──────────────────────┘
                 ▼
              Grafana (tableaux de bord, exploration)

Prometheus convient très bien aux séries purement numériques et reste utilisable pendant une panne, car chaque serveur est autonome. Il ne convient pas quand il faut une exactitude à 100 %, par exemple pour facturer chaque requête : utilisez alors une base de données ou les journaux.

Pièges fréquents

• Alerter sur tout : 200 alertes par jour, personne ne les lit. Alertez sur les symptômes (erreurs, lenteur ressenties par l'utilisateur) et gardez les causes (CPU, mémoire) pour les tableaux de bord.
• Un SLO à 100 % : impossible à tenir, il interdit toute mise à jour. Même les grands fournisseurs de cloud visent moins.
• Compter les 4xx comme des pannes : une vague de mauvais mots de passe ferait croire à une panne du service.
• Des étiquettes à forte cardinalité (identifiant de client, adresse IP, numéro de commande) dans les métriques : mettez-les dans les journaux, pas dans les étiquettes.

Lab

Vous êtes l'ingénieur d'exploitation d'une boutique en ligne. Le journal /root/obs/acces.log contient 1 000 appels à l'API de paiement. Vous allez :

1. décrire l'objectif du service dans un petit fichier YAML ;
2. calculer le budget d'erreur correspondant, en minutes ;
3. compter les réponses 5xx du journal avec awk ;
4. décider si l'objectif est respecté sur cet échantillon.

Quiz

1. Citez les trois signaux de l'observabilité et une question à laquelle chacun répond.
2. Quelle est la différence entre un SLO et un SLA ? Lequel est le plus exigeant ?
3. Un service a un SLO de 99,5 % sur 30 jours. Combien de minutes d'indisponibilité sont tolérées ?
4. Pourquoi ne faut-il pas mettre l'identifiant du client dans une étiquette de métrique ?
5. Faut-il déclencher une alerte quand le CPU d'un serveur dépasse 80 % ? Justifiez.

Sources de référence : documentation Prometheus (Apache 2.0). Texte original MasterLinux.