La différence entre supervision et observabilité dans les systèmes distribués

La supervision classique repose sur des questions connues à l'avance : le serveur est-il en ligne, le CPU dépasse-t-il 80 %, le disque se remplit-il, le traitement de nuit s'est-il terminé ? Un opérateur choisit un signal, fixe un seuil et déclenche une alerte lorsqu'il est franchi. Pour un petit nombre de serveurs faisant tourner une application monolithique, cela fonctionne bien, car la liste des défaillances possibles est courte et les personnes d'astreinte la connaissent par cœur.

La limite est que chaque contrôle traduit une prédiction. Lorsque la défaillance n'a été prévue par personne, comme une dépendance en aval qui ralentit, une avalanche de tentatives de reconnexion ou un cache techniquement disponible mais qui renvoie des données périmées, les tableaux de bord restent au vert pendant que les clients se plaignent. La supervision reste nécessaire, mais elle ne suffit plus dès que le système dépasse ce qu'une seule personne peut se représenter.

Répartissez la même fonction métier sur une douzaine de services reliés par une file de messages, et trois choses changent. D'abord, une seule requête utilisateur traverse désormais de nombreux processus sur de nombreux hôtes : aucun fichier journal ne raconte à lui seul toute l'histoire. Ensuite, les défaillances deviennent partielles : une région, un locataire ou un chemin de code ralentit alors que l'ensemble paraît sain. Enfin, le système évolue plusieurs fois par jour : la référence de la veille ne s'applique plus.

L'observabilité est la capacité à comprendre l'état interne d'un système à partir des données qu'il émet, sans déployer de nouveau code pour poser une nouvelle question. En pratique, il s'agit de collecter une télémétrie riche et à forte cardinalité (quel client, quel point de terminaison, quelle version, quelle région) et de pouvoir l'analyser à la demande. La question n'est plus de savoir si le système fonctionne, mais quels utilisateurs subissent des lenteurs, depuis quand, et ce qui a changé.

Un objectif de niveau de service (SLO) est une cible portant sur une mesure perçue par l'utilisateur : par exemple, 99,9 % des requêtes de paiement aboutissent en moins de 500 millisecondes, mesuré sur 30 jours. Le pourcentage et la fenêtre sont fixés par l'organisation ; l'essentiel est que le SLO décrit ce que vivent les utilisateurs plutôt que ce que remonte un hôte.

Un SLO définit un budget d'erreur, c'est-à-dire la part de défaillance absorbable sur la fenêtre, et avec lui un autre modèle d'alerte. Au lieu d'alerter lorsque le CPU franchit un seuil, l'équipe alerte lorsque le budget se consomme trop vite pour tenir jusqu'à la fin de la fenêtre (alerte sur le rythme de consommation). Une consommation lente donne lieu à un ticket pour le jour ouvré suivant ; une consommation rapide déclenche l'appel de l'ingénieur d'astreinte. Ce seul changement supprime la plupart des alertes qui se déclenchent sans que personne n'ait à agir.

Les SLO donnent aussi aux équipes techniques et aux métiers un langage commun. Si le budget est sain, l'équipe peut livrer plus vite ; s'il s'épuise, elle investit dans la fiabilité. Un graphique de CPU ne permet pas ce dialogue.

L'échec le plus fréquent des dispositifs de supervision est un excès d'alertes plutôt qu'un manque. Lorsqu'une équipe d'astreinte reçoit des dizaines d'appels par semaine dont la plupart n'exigent aucune action, plus personne ne les lit, et celle qui compte se perd dans le bruit. Chaque alerte doit passer un test simple : quelqu'un doit pouvoir agir immédiatement. Sinon, elle a sa place dans un panneau de tableau de bord ou dans un rapport quotidien, et non dans un appel d'astreinte.

Traitez l'ensemble des alertes comme du code soumis à revue. Chaque alerte a un responsable, un lien vers une procédure d'intervention et une raison d'être ; les alertes qui se déclenchent sans action pendant un mois sont supprimées ou rétrogradées. Mesurez la rotation elle-même : appels par semaine, appels hors heures ouvrées, délai d'accusé de réception. Une astreinte saine est le signe d'un système sain, et une astreinte qui ne l'est pas indique clairement où investir.

Les systèmes distribués ajoutent une exigence : les alertes doivent porter leur contexte. Un appel qui indique « error rate high on payments-api » est un travail d'enquête ; un appel qui renvoie au SLO concerné, au dernier déploiement et au point de terminaison le plus défaillant est une décision à prendre.

Les données d'observabilité ont un coût, et la facture arrive généralement une fois l'habitude prise. Les deux facteurs sont le volume (octets de journaux et de spans par requête, multipliés par le trafic) et la cardinalité (le nombre de combinaisons distinctes d'étiquettes sur une métrique). Une métrique étiquetée par identifiant d'utilisateur ou de requête crée une nouvelle série temporelle pour chaque valeur et sature n'importe quel système de stockage de métriques.

Des réglages par défaut judicieux font déjà beaucoup. Conservez les identifiants à forte cardinalité dans les traces et les journaux structurés plutôt que dans les libellés de métriques. Échantillonnez les traces en conservant chaque erreur et chaque requête lente, ainsi qu’une fraction des requêtes normales. Fixez la durée de conservation par signal : les métriques pendant un an à résolution réduite, les journaux pendant quelques semaines, les traces pendant quelques jours, avec un niveau d’archivage pour tout ce que la conformité exige. Passez en revue chaque mois les principales sources de volume de journaux ; une seule instruction de débogage trop verbeuse sur un chemin critique peut représenter une part importante de la facture.

L’objectif n’est pas de tout collecter, mais de pouvoir répondre rapidement à la prochaine question encore inconnue, à un coût que l’organisation est disposée à supporter dans la durée.