Observabilité : ce que nous instrumentons, et ce que nous ignorons

La première fois qu’on met en place de l’observabilité, on a tendance à tout instrumenter. Trois mois plus tard, personne ne regarde les tableaux de bord et les alertes partent dans un canal que tout le monde a mis en sourdine.

Le problème n’est pas le manque de données. C’est qu’on ne sait pas quoi en faire.

Les quatre signaux qui portent l’essentiel

Le taux d’erreur. La proportion de requêtes qui échouent. C’est le signal le plus direct : si elle monte, quelque chose est cassé, et c’est visible avant que les utilisateurs n’appellent.

Le temps de réponse. Pas la moyenne — elle ment. La moyenne d’un service dont 95 % des requêtes répondent en 100 ms et 5 % en 20 secondes reste bonne, alors qu’un utilisateur sur vingt vit une expérience inacceptable. Il faut regarder les percentiles élevés, ceux qui décrivent les cas les plus lents.

La saturation. Mémoire, processeur, connexions à la base, espace disque. Ce signal est le seul qui anticipe : il monte avant que le taux d’erreur ne bouge, et permet d’agir avant la panne.

Le trafic. Utile surtout comme dénominateur — cinq erreurs sur dix requêtes et cinq erreurs sur cent mille ne racontent pas la même histoire. Une chute brutale du trafic est par ailleurs un excellent détecteur de panne silencieuse.

Les indicateurs métier, souvent plus parlants

C’est l’ajout qui a le plus changé notre façon de surveiller.

Une application peut afficher un taux d’erreur nul, des temps de réponse excellents, et ne plus rien produire d’utile. Un service tiers qui répond « OK » sans traiter, une file bloquée, une tâche planifiée qui ne s’exécute plus : rien de tout cela n’apparaît dans les signaux techniques.

Nous suivons donc, sur chaque application, deux ou trois compteurs métier : commandes créées par heure, paiements aboutis, dossiers validés. Et nous alertons sur leur absence.

« Zéro paiement depuis quarante minutes en pleine journée » est l’alerte la plus utile que nous ayons mise en place. Elle a détecté des pannes qu’aucune métrique technique ne voyait.

Ce que nous n’instrumentons pas

Tout ce qui n’entraîne aucune action. Une métrique qu’on regarde sans jamais rien décider est un coût de collecte et de bruit visuel. Le test : à quelle question cette courbe répond-elle, et qu’est-ce que je fais si elle bouge ?

Le détail de chaque fonction. Les traces fines sont précieuses en investigation, coûteuses en permanence. Nous les activons à la demande sur un incident, plutôt que de tout enregistrer en continu.

Les journaux verbeux. Un système qui écrit une ligne à chaque étape produit un volume dans lequel on ne retrouve plus rien le jour où c’est nécessaire. Nous écrivons peu, mais structuré et corrélable — chaque ligne porte un identifiant de requête qui permet de reconstituer un parcours.

Les alertes : moins, mais qui réveillent

C’est le sujet où j’ai le plus changé d’avis.

Une alerte doit satisfaire trois conditions : quelque chose est réellement cassé, quelqu’un peut agir, et il faut agir maintenant. Si l’une manque, ce n’est pas une alerte — c’est une information, qui a sa place dans un rapport quotidien.

Trois alertes qui réveillent valent mieux que trente que personne ne lit. La fatigue d’alerte est le vrai risque : au bout de deux semaines de faux positifs, l’équipe acquitte sans regarder, et l’alerte réelle passe inaperçue.

Nous accompagnons chaque alerte d’une phrase : que vérifier d’abord, où regarder, qui prévenir. Une alerte sans procédure oblige la personne réveillée à réfléchir de zéro, à trois heures du matin.

Photo : Tim Sullivan — licence CC0.

La conservation

Un point pratique souvent réglé par défaut, et mal.

Les journaux détaillés servent quelques jours — le temps d’investiguer un incident. Les métriques agrégées servent des mois : c’est ce qui permet de dire « les temps de réponse se dégradent depuis six semaines », donc d’agir avant la panne.

Conserver les journaux détaillés pendant un an coûte cher et n’apporte rien. Perdre les métriques agrégées au bout de deux semaines empêche de voir les dérives lentes, qui sont précisément celles qu’on peut anticiper.

Photo : Tim Sullivan — licence CC0.

Ce qui rend une trace exploitable

Un journal volumineux et inutilisable est très courant. Trois règles font la différence entre une trace qu’on lit et une trace qu’on subit.

Un identifiant de corrélation unique par requête, transmis d’un composant à l’autre et présent sur chaque ligne. Sans lui, reconstituer le parcours d’une requête dans quatre services relève de l’archéologie. Avec lui, c’est une recherche.

Des messages structurés plutôt que des phrases. Une ligne composée de champs nommés — durée, identifiant client, code de retour — se filtre et s’agrège. Une phrase libre ne se lit qu’à l’œil, une par une.

Aucune donnée personnelle. Les journaux se copient, se transmettent au support, se conservent des mois. Ils sont l’endroit où les données sensibles fuient le plus discrètement. Les identifiants techniques suffisent presque toujours à mener une enquête.

Le coût, et comment le tenir

L’observabilité facturée au volume produit régulièrement de mauvaises surprises : un composant trop bavard mis en service un vendredi, et la facture du mois double.

Deux garde-fous que j’applique systématiquement.

L’échantillonnage sur ce qui est nominal. Conserver toutes les requêtes en erreur ou lentes, et une fraction seulement des requêtes rapides et réussies. On perd très peu d’information utile et on divise le volume par dix.

Une durée de conservation différenciée. Quelques jours de détail complet, quelques mois d’agrégats. Les questions qu’on se pose à trois mois portent sur des tendances, jamais sur une requête particulière.

Un dernier point qui compte plus qu’il n’y paraît : une alerte sur le volume lui-même. C’est ce qui permet de découvrir qu’un composant est devenu bavard avant de le découvrir sur la facture.

Le tableau de bord d’astreinte

Une page, affichable en dix secondes sur un téléphone, qui répond à une seule question : est-ce que ça marche, et pour qui ?

Ce qu’elle contient : le taux d’erreur et le temps de réponse sur les parcours critiques, la profondeur des files d’attente, l’état des dépendances externes, et le résultat du dernier déploiement. Rien d’autre.

Ce qu’elle ne contient pas : les mesures système. La charge processeur d’une machine n’intéresse personne à trois heures du matin — ce qui compte est de savoir si les utilisateurs sont bloqués et depuis quand. Les mesures système servent au diagnostic, une fois le problème constaté, et elles ont leur propre page.

Par où commencer

Sur une application qui n’a rien : les quatre signaux de base, un compteur métier, et deux alertes — l’application ne répond plus, et le compteur métier est à zéro alors qu’il ne devrait pas.

Cela prend deux jours, couvre l’immense majorité des incidents réels, et donne immédiatement quelque chose qu’on n’avait pas : savoir que ça casse avant que le client n’appelle.

Le reste s’ajoutera au fil des incidents. Chaque panne apprend quel signal aurait permis de la voir venir — et c’est une bien meilleure source de priorités qu’une liste théorique.