C'est quoi l'observabilité ? Logs, métriques et traces
Résumé
C'est quoi l'observabilité ? C'est la capacité à comprendre ce que fait un système, et pourquoi, à partir des données qu'il émet : logs (événements), métriques (nombres dans le temps) et traces (le parcours d'une requête). Le monitoring signale les problèmes prévus ; l'observabilité aide à enquêter sur ceux qui ne l'étaient pas. Ce guide explique la différence en langage de tableur, avec des formules Sheets et Excel pour les taux d'erreur et les centiles.
C'est quoi l'observabilité ? C'est la capacité à comprendre ce que fait un système, et pourquoi, uniquement à partir des données qu'il émet : les logs, les métriques et les traces. Le monitoring vous dit que quelque chose a cassé. L'observabilité vous permet de poser la question suivante : où, pour qui, et depuis quand. Si vous vivez dans les tableurs, vous faites déjà une petite version de ce travail chaque fois que vous remontez un chiffre bizarre jusqu'à la ligne source qui l'a produit.
La version d'une minute pour ceux qui vivent dans les tableurs
Imaginez une feuille de chiffre d'affaires mensuel dont le total semble faux. Un tableau de bord qui affiche « le total est faux » fait du monitoring. Pouvoir filtrer par région, par jour et par produit, puis trouver l'import qui a doublé 400 lignes, c'est de l'observabilité.
Les équipes logicielles se heurtent au même mur avec des systèmes en production. Une page de paiement ralentit. Une alerte se déclenche. Il faut alors trouver quel service, quel segment de clients et quel déploiement en sont la cause. Les données qui rendent cela possible s'appellent la télémétrie, et la capacité à s'en servir est ce que l'on désigne par observabilité.
Monitoring ou observabilité : problèmes connus contre surprises
Le monitoring surveille ce que vous avez décidé de surveiller à l'avance. Un CPU au-dessus de 90 %, un taux d'erreur au-dessus de 2 %, une page qui ne répond plus. Vous écrivez la règle, et l'outil se met à crier quand elle est enfreinte.
L'observabilité sert aux problèmes pour lesquels vous n'avez écrit aucune règle. Le projet OpenTelemetry la décrit comme une façon de comprendre un système de l'extérieur, sans connaître son fonctionnement interne, ce qui aide face aux « inconnues inconnues ».
Inutile d'opposer les deux. Le monitoring est votre détecteur de fumée, l'observabilité est le plan de l'étage et les images de caméra que vous consultez après coup. Vous avez besoin des deux.
Logs, métriques et traces : les trois ingrédients bruts
Presque toutes les explications aboutissent aux mêmes trois signaux. Voici chacun d'eux en termes de tableur.
Les logs sont des messages horodatés qui décrivent des événements individuels. Dans un tableur, c'est une ligne par événement : heure, utilisateur, action, résultat. Ils contiennent le plus de détails et prennent le plus de place.
Les métriques sont des nombres agrégés dans le temps, comme le taux d'erreur, le nombre de requêtes par minute ou la mémoire utilisée. Dans un tableur, c'est votre onglet de synthèse. Elles coûtent peu à stocker et se tracent vite, mais elles ne vous disent pas quelle requête précise a échoué.
Les traces suivent une requête unique à travers plusieurs services, avec le temps passé à chaque étape. Dans un tableur, imaginez un numéro de commande que vous suivez sur cinq onglets, en notant combien de temps elle est restée dans chacun d'eux.
La formule courte : les métriques vous disent que quelque chose ne va pas, les traces disent à peu près où, et les logs donnent le détail. Voilà ce que ça donne dans une vraie cellule, en une minute.
Vous avez 5 000 lignes de logs dans un fichier : un exemple concret dans Sheets
Imaginons que vous ayez exporté 5 000 lignes d'un journal d'application dans Google Sheets. La colonne A contient l'horodatage, la colonne B le nom du service, la colonne C le code de statut et la colonne D le temps de réponse en millisecondes. Les formules fonctionnent dans Excel et dans Sheets, sauf mention contraire. Les noms de fonctions sont donnés en français, et les séparateurs suivent les réglages français (point-virgule et virgule décimale). Si votre version ou votre réglage diffère, adaptez-les sans changer la logique.
D'abord, le taux d'erreur, une métrique classique :
=NB.SI(C2:C5001; ">=500") / NBVAL(C2:C5001)La plage est C2:C5001, c'est-à-dire les codes de statut.
Le critère
">=500"compte chaque erreur serveur.Diviser par
NBVALdonne la part de toutes les requêtes. Mettez la cellule au format pourcentage.
C'est du monitoring : un chiffre, un seuil. Passons maintenant à la partie observabilité. Quel service en est responsable ?
=REQUETE(A1:D5001; "select B, count(C) where C >= 500 group by B order by count(C) desc"; 1)Cette formule ne fonctionne que dans Sheets, car REQUETE n'a pas d'équivalent dans Excel. Ses arguments :
La plage est A1:D5001, en-têtes compris.
Le texte est une petite requête proche du SQL : compter les erreurs par service, du plus grand au plus petit.
Le dernier
1indique qu'il y a une seule ligne d'en-tête.
Dans Excel 365, on obtient le même résultat avec une autre recette :
=LET(s; FILTRE(B2:B5001; C2:C5001>=500); u; UNIQUE(s); EMPILERH(u; NB.SI(s; u)))Cette formule demande Excel 365 ou Excel 2021, car FILTRE, UNIQUE et EMPILERH n'existent pas dans Excel 2016. Les versions plus anciennes s'en sortent mieux avec un tableau croisé dynamique.
Pour les requêtes lentes, le 95e centile est plus honnête que la moyenne :
=CENTILE(D2:D5001; 0,95)Si le temps de réponse moyen est de 180 ms mais que le 95e centile atteint 2 400 ms, une personne sur vingt passe une très mauvaise journée. Les moyennes masquent cela, et c'est justement le piège que les outils d'observabilité vous aident à éviter.
Biscuit l'a déjà cherchée pour vous, si la formule est la partie que vous oubliez. Formula.dog transforme une description en langage courant en une formule de ce genre.
Où l'observabilité apparaît dans une journée de travail normale
Vous n'avez pas besoin de faire tourner des serveurs pour la croiser. Une responsable support qui demande « pourquoi les tickets ont doublé mardi ? » la pratique. Un analyste financier qui remonte un écart jusqu'à une seule facture fournisseur aussi, tout comme la personne des opérations qui découvre qu'un import nocturne a silencieusement ignoré un fichier.
Dans le logiciel, ces questions deviennent plus pointues, parce que les systèmes sont distribués. Un clic sur un bouton peut toucher une passerelle d'API, un service d'authentification, une base de données et un prestataire de paiement. Quand cela échoue, le message d'erreur que vous voyez est rarement l'endroit où le problème a commencé. Une trace montre toute la chaîne, avec le maillon lent ou cassé mis en évidence, pour que personne n'ait à deviner.
Trois termes reviennent sans cesse, les voici en langage clair :
L'instrumentation consiste à ajouter le code qui émet la télémétrie. Imaginez l'ajout d'une colonne d'horodatage et d'identifiant à un rapport qui n'en avait jamais eu.
La cardinalité est le nombre de valeurs distinctes que peut prendre un champ. La région a une faible cardinalité, l'identifiant utilisateur une cardinalité très élevée. Les champs à forte cardinalité répondent aux questions les plus fines, et ils coûtent le plus cher à conserver.
Le SLO (objectif de niveau de service) est une cible que l'on se fixe, par exemple « 99,5 % des paiements se terminent en moins de deux secondes ». Il transforme une inquiétude floue en un chiffre que l'on peut suivre.
Pourquoi une pile de tableaux de bord n'est pas de l'observabilité
Voici l'avis qui agace les éditeurs : avoir les trois signaux ne veut pas dire que vous avez de l'observabilité. Si les métriques sont dans un outil, les logs dans un autre et les traces dans un troisième, quelqu'un doit les aligner à la main à deux heures du matin. C'est l'équivalent de trois classeurs sans colonne d'identifiant commune.
Le test est simple : quand quelque chose d'inattendu casse, pouvez-vous poser une nouvelle question à vos données sans déployer de nouveau code ? Si la réponse est « il faudrait ajouter des logs et redéployer », vous avez du monitoring déguisé en observabilité.
Deux choses font la différence en pratique :
Du contexte sur chaque événement. Chaque ligne de log porte un identifiant de requête, un nom de service et une version, pour pouvoir grouper et filtrer plus tard. C'est la colonne d'identifiant que vous auriez aimé trouver dans chaque export.
Des détails conservés assez longtemps. Les données à forte cardinalité, comme les identifiants d'utilisateurs ou les numéros de commande, sont là où se cachent les réponses. Ce sont aussi elles qui font grimper la facture.
Les outils que les équipes utilisent vraiment, et ce qu'ils vous coûtent
Inutile d'acheter quoi que ce soit pour comprendre l'idée, mais le marché mérite d'être connu.
OpenTelemetry est le standard ouvert pour produire la télémétrie, pas un endroit où la stocker ou la consulter. Vous instrumentez une fois, puis vous envoyez les données où vous voulez.
Grafana Cloud est bâti autour des standards ouverts, avec un palier gratuit de 10 000 séries de métriques actives et 50 GB chacun de logs, de traces et de profils par mois. Vous pouvez aussi héberger vous-même la pile open source, au prix d'assembler Prometheus, Loki et Tempo par vos propres moyens.
Datadog est l'option clé en main : vous installez l'agent, vous obtenez des tableaux de bord fonctionnels en quelques minutes, et l'infrastructure, l'APM et les logs sont au même endroit. Le piège, c'est la facturation. Le tarif par hôte (environ 15 $ par hôte et par mois pour la seule infrastructure), auquel s'ajoutent des frais séparés pour les logs et les métriques personnalisées, peut grimper vite au-delà d'environ 50 hôtes. Et il n'existe pas de palier gratuit permanent.
New Relic se situe entre les deux sur le prix : 100 GB de données ingérées gratuites par mois, puis 0,40 $ par GB, avec un utilisateur plateforme complet inclus.
Ça vaut le coup si vous avez une petite équipe plateforme et aucune envie de faire tourner une infrastructure dédiée à votre infrastructure. Passez votre chemin si vous avez deux serveurs et un seul développeur. Un bon format de logs et les formules ci-dessus vous mèneront étonnamment loin.
Que faire lundi si vous n'êtes pas ingénieur
Vous ne toucherez peut-être jamais à une trace. Mais la réflexion sur l'observabilité se transpose très bien à quiconque rapporte des chiffres pour vivre.
Ajoutez un identifiant à chaque export. Une colonne sur laquelle vous pouvez faire une jointure vaut mieux que n'importe quelle formule astucieuse.
Gardez les lignes brutes. Ne collez pas des valeurs par-dessus l'onglet de détail. Les synthèses sont vos métriques, les lignes brutes sont vos logs.
Notez ce que « normal » veut dire. Un seuil que vous n'avez jamais défini ne peut pas se déclencher.
Posez la troisième question. « Le chiffre d'affaires baisse », c'est l'alerte. « Baisse où ? », c'est la métrique. « Baisse à cause de quelles lignes ? », c'est l'observabilité.
Faites cela, et le prochain total bizarre de votre feuille prendra dix minutes à expliquer, au lieu d'un après-midi. Bon garçon, le tableur.
Réponses rapides aux questions que les gens tapent vraiment
Les réponses aux questions les plus fréquentes figurent dans la FAQ ci-dessous. Si vous ne retenez qu'une chose : l'observabilité n'est pas un produit que l'on achète. C'est la capacité des données émises par votre système à répondre à des questions que vous n'avez pas prévues.