Les trois piliers et leurs limites
Distinguer métriques, journaux et traces, et comprendre pourquoi leur addition ne fait pas automatiquement de l'observabilité.
À retenir
- Les métriques, logs et traces répondent à des questions différentes et complémentaires.
- La corrélation (trace_id partagé) est indispensable, sinon les trois piliers restent cloisonnés.
- La cardinalité non maîtrisée des labels de métriques est une cause fréquente d'incident.
- L'instrumentation doit être revue comme du code avant sa mise en production.
Supervision, monitoring, observabilité : trois mots, trois réalités
La supervision classique répond à une question fermée : « le service est-il up ou down ? ». L'observabilité répond à une question ouverte : « pourquoi ce comportement inattendu se produit-il, alors que je n'avais pas prévu de le mesurer à l'avance ? ». C'est cette capacité à interroger un système a posteriori, sans avoir instrumenté le cas précis, qui distingue les deux approches.
Les trois piliers
| Pilier | Ce qu'il capture | Cas d'usage typique |
|---|---|---|
| Métriques | Séries temporelles agrégées (compteurs, jauges, histogrammes) | Tableaux de bord, alerting, tendances |
| Journaux (logs) | Événements discrets horodatés, structurés ou non | Investigation fine, audit, contexte métier |
| Traces | Chemin d'une requête à travers plusieurs services | Latence distribuée, dépendances, goulots d'étranglement |
Point clé
aucun pilier seul ne suffit. Une métrique dit *qu'*il y a un problème de latence P99 ; une trace dit où dans la chaîne d'appels ; un log dit pourquoi (exception, timeout, payload invalide).
La limite du « avoir les trois piliers »
Empiler Prometheus, Loki et Jaeger ne rend pas un système observable si les identifiants de corrélation (trace ID, request ID) ne sont pas propagés d'un pilier à l'autre. Le Google SRE Book insiste sur le fait que la supervision doit rester simple et orientée symptômes : trop de collecte sans corrélation produit du volume, pas de la compréhension.
# Exemple : propagation d'un trace_id dans un log structuré
level: error
service: checkout-api
trace_id: 7f3a1c9e0b2d4f11
message: "payment gateway timeout after 3000ms"
upstream: payment-gateway
retry_count: 2
Attention
collecter des logs non structurés (texte libre) rend la corrélation avec les métriques et traces quasiment impossible à grande échelle. Le format structuré (JSON) avec des champs constants (trace_id, service, env) est un prérequis, pas une option.
Cardinalité : le piège classique des métriques
Ajouter un label à haute cardinalité (ex. user_id, request_id) sur une métrique Prometheus peut multiplier par des milliers le nombre de séries temporelles stockées, jusqu'à saturer le serveur de métriques. La règle empirique : les labels doivent avoir un nombre de valeurs possibles borné et connu à l'avance (statut HTTP, méthode, route, environnement).
Sur le terrain
un cas fréquent en astreinte est la panne du serveur Prometheus lui-même après le déploiement d'une nouvelle version d'un service qui expose un label endpoint non normalisé (contenant des identifiants variables) au lieu d'une route template (/users/:id).
Tests et revue avant mise en production
Toute nouvelle instrumentation doit être revue comme du code : vérifier qu'aucun label à cardinalité illimitée n'est introduit, que les niveaux de log (debug, info, warn, error) sont cohérents, et que le coût de stockage additionnel est estimé avant déploiement.
Astuce
avant d'ajouter un nouveau label métrique en production, testez-le d'abord sur un environnement de préproduction avec un scraping de courte durée pour mesurer l'impact réel sur le nombre de séries actives.