Qu'est-ce qu'une « bonne » télémétrie ?

D'après mon expérience en tant qu'architecte d'observabilité qui accompagne les équipes dans l'adoption des bonnes pratiques, l'une des questions les plus fréquentes que l'on me pose est : « Qu'est-ce qu'une bonne télémétrie, exactement ? ». Et franchement, la réponse n'est pas toujours simple.

Nous savons tous que les données télémétriques sont essentielles pour comprendre les performances de nos applications en temps réel, mais définir ce qu'est un « bon » résultat peut s'avérer complexe. La notion de « bon » peut être définie à plusieurs niveaux, de l’évolutivité de la production de données au sein de vos applications, à la capacité de votre télémétrie à décrire votre système et votre logique métier, en passant par la fiabilité du transport de ces données vers votre plateforme d’observabilité. La notion de « bon » dépend aussi beaucoup du système, de l'équipe et de l'organisation qui l'utilisent. Ce qui fonctionne pour une petite start-up peut ne pas fonctionner pour une grande entreprise, et un système axé sur le traitement des données en temps réel aura des besoins différents d'un système gérant des tâches par lots.

Cependant, je suis persuadé que si l'on ne mesure pas quelque chose, on ne peut pas l'améliorer, et ce principe s'applique également à l'observabilité. Après tout, l'observabilité n'est pas une action, comme peut l'être le monitoring ; l'observabilité est une qualité inhérente à un système, comme la sécurité ou la fiabilité. Si nous voulons sérieusement améliorer la façon dont nous observons nos systèmes, nous devons établir des mesures standardisées et convenues qui nous indiquent si nous allons dans la bonne direction.

C’est pourquoi je suis ravi d’annoncer un nouveau projet dans le monde de l’observabilité : Instrumentation Score. Cette norme ouverte vise à mesurer l'adéquation de la configuration des applications pour l'observabilité. C'est un travail d'équipe, qui comprend à la base des ingénieurs de New Relic, Ollygarden, Splunk et Dash0, pour n'en citer que quelques-uns, et je suis très impatient de contribuer à son développement initial.

L'outil adapté à la tâche

Entrons tout de suite dans le vif du sujet et voyons pourquoi cela est important. Vous avez souvent entendu dire qu'il vous fallait plusieurs signaux — traces, métriques, logs/événements et profils — pour obtenir une vue complète de votre système. OpenTelemetry vous aide à les générer de manière standard sans fournisseur associé, que vous soyez un utilisateur final ou un propriétaire de bibliothèques open source — un sujet que nous avons abordé récemment à KubeCon + CloudNativeCon, dans notre session OpenTelemetry in Five Minutes. Mais comment savoir quand utiliser chacun de ces signaux ? Et comment savoir si vous le faites dans le but prévu ?

Pour illustrer cela, menons une petite expérience de pensée, illustrée dans l'image ci-dessous. Imaginons qu'un internaute visite votre site web et rencontre des difficultés au moment du paiement. Cela se traduit par une augmentation du nombre d'événements « checkout failed » émis par les navigateurs de vos utilisateurs. Il peut s'agir d'événements distincts, mais vous pouvez utiliser un attribut « session.id » commun permettant de corréler ces événements aux traces distribuées générées au cours de la même session utilisateur. Ces traces vous permettent de suivre les requêtes individuelles à travers le système, jusqu'à vos services backend, chacun étant représenté ci-dessous par des couleurs différentes. Vous pouvez ainsi mieux comprendre comment et où les échecs se produisent, identifier les anomalies dans toutes les requêtes et, enfin, trouver la cause profonde de ces erreurs.

Il est aussi possible qu'en même temps une équipe exploitant l'un de ces services backend ait reçu une alerte concernant une régression (potentiellement) associée. Mais cette fois-ci, au lieu de partir du point de vue de l'utilisateur final, l'équipe part d'une métrique standard de haut niveau qui lui indique le nombre de réponses « 5xx » dans son service. Grâce aux concepts d'OpenTelemetry comme les points de données modèles appelés « exemplars », elle peut trouver des traces individuelles enregistrées en même temps que la création des métriques d'erreur. Grâce à ce contexte, l'équipe peut rapidement comprendre l'impact sur ses utilisateurs finaux et identifier la dépendance problématique qui est à l'origine de la défaillance de son service. Tout fait partie d'une même description globale du système, et chaque ingénieur impliqué dans son dépannage la comprend.

Le même contexte de trace peut également être utilisé pour enrichir les logs générés dans le cadre de transactions individuelles, ou les profils qui nous permettent d'approfondir les problèmes qui ne peuvent être identifiés qu'en examinant le stack d'appels au sein d'une réplique donnée. Nous obtenons alors différents niveaux de granularité, mais toujours dans le même contexte holistique.

Enfin, l'utilisation de conventions sémantiques standards pour l'ensemble de ces signaux permet aux plateformes d'observabilité, comme New Relic, de comprendre les relations et la causalité entre les différentes mesures. Par exemple, il est possible que toutes les requêtes ayant échoué fassent partie du même pod Kubernetes, et qu'elles indiquent peut-être une contention de mémoire dans une réplique particulière comme cause profonde potentielle.

Je ne suis pas expert en IA, mais je sais une chose : plus le contexte est précis, meilleurs sont les insights. Si tous ces signaux partagent le même contexte et le même ensemble de conventions sémantiques, une plateforme d'observabilité capable de les corréler tous avec une seule requête nous permet de répondre à des questions comme « Quel est le taux d'utilisation de la mémoire dans les répliques du service qui a traité les requêtes pour les paiements qui ont échoué ? ». Ou ce qui serait encore mieux, on pourrait ne pas poser la question et laisser l'IA s'en occuper !

En définitive, l'objectif de l'observabilité est de comprendre ce qui satisfait nos utilisateurs et rend nos systèmes efficaces pour offrir une expérience de qualité, et pour cela, nous avons besoin de données de qualité. Ces données doivent décrire le système de manière à nous permettre de répondre aux questions par des preuves, et non par intuition, en nous appuyant sur la corrélation et non sur le fait que ce qui s'est produit auparavant peut se reproduire.

Toutes les données ne se valent pas

Voilà le problème ! Toutes les données ne se valent pas. Les données d'observabilité ont des exigences différentes de celles des données d'audit ou d'autres types d'analyse. Par exemple, nous pouvons privilégier l'originalité à l'exécution. Nous savons également que la majorité des transactions qui transitent par nos systèmes ne sont pas vraiment intéressantes. Elles se terminent sans problème dans un délai normal. Faut-il donc transporter et stocker des informations de débogage pour chacune d'elles, au cas où il y aurait une défaillance ? Dans la plupart des cas, non. Nous devons nous concentrer sur la collecte des données pertinentes pour le dépannage et le monitoring des performances, et rien de plus. Notre planète vous en sera reconnaissante.

Même au cœur de la télémétrie, chaque signal possède intrinsèquement des niveaux de fiabilité différents, ce qui le rend adapté à divers usages. Par exemple, les flux de données métriques produisent des signaux prévisibles et très fiables. Une métrique qui agrège le nombre de requêtes par point de terminaison sous forme de compteur générera à peu près la même quantité de données, que le service traite dix ou un million de requêtes par seconde. Cela permet aux clients implémentant des protocoles comme OTLP de réaliser la mise en mémoire tampon et de réessayer les exportations de métriques pendant une durée plus longue qu'ils ne le peuvent avec les traces ou les logs, car cela générerait un enregistrement par requête observée. Les métriques deviennent ainsi très utiles pour l'analyse des tendances à long terme et pour les alertes, car elles fournissent des vues très agrégées. Cependant, elles ne sont pas idéales pour d'autres cas comme le débogage ou la compréhension des anomalies, car elles manquent intrinsèquement de contexte.

Par contre, de par sa grande précision, le tracing est idéal pour comprendre en profondeur le système et ses interdépendances. Il est essentiel de bien comprendre un système distribué. Cependant, en raison des volumes de données plus importants, la mise en mémoire tampon, les nouvelles tentatives et la sortie du trafic peuvent devenir excessivement coûteuses si l'on doit mettre en œuvre le même niveau de fiabilité que pour les métriques. Heureusement, le contexte nous aide aussi ici, ce qui nous permet d'utiliser des techniques d'échantillonnage intelligentes pour ne stocker que ce qui compte, puis de le corréler à d'autres signaux.

C’est là qu’intervient Instrumentation Score, pour fournir plus d’informations sur la façon dont tous ces signaux s’articulent et mesurer si la télémétrie résultante décrit bien notre système de manière holistique. C'est un moyen d'estimer à quel point notre télémétrie répond aux besoins spécifiques d'observabilité, et de le faire de manière efficace et efficiente, en évitant les factures élevées ou les surprises opérationnelles.

La voie vers la maturité de l'observabilité

Je sais ce que vous pensez : « N'est-ce pas à cela que servent les conventions sémantiques d'OpenTelemetry ? » Et vous avez raison ! Les conventions sémantiques définissent ce à quoi ressemble une bonne télémétrie du point de vue du producteur. Les outils OpenTelemetry comme Weaver nous permettent de mesurer la conformité à ces schémas, et même de les étendre à nos propres cas d'utilisation. Cependant, Instrumentation Score va plus loin, ou plutôt plus large. Il s'agit d'une vision de plus haut niveau qui prend en compte la qualité de la télémétrie au point d'utilisation. Nous ne nous contentons pas d'examiner la qualité de la télémétrie produite à la source, mais aussi sa capacité à nous aider à comprendre et à améliorer nos systèmes au sein d'un environnement spécifique, composé des applications observées et de la plateforme d'observabilité utilisée.

Pour terminer, abordons la maturité de l'observabilité. Nous avons mentionné que l'observabilité est une qualité spécifique d'un système observé, qui nous permet d'obtenir des résultats de l’entreprise. Cependant, on ne passe pas de zéro à héros du jour au lendemain, il est donc important de comprendre les actions les plus importantes que nous pouvons entreprendre pour améliorer progressivement notre position.

Si un expert en observabilité envoyait à une équipe moyenne une longue liste de toutes les actions qu'elle peut entreprendre pour améliorer son observabilité, elle serait probablement submergée de conseils sans en comprendre l'impact. Elle fermerait cette liste et ne la rouvrirait jamais. C’est là qu'Instrumentation Score — et les scorecards qui peuvent être développés dessus — est essentiel. En attribuant différents niveaux d'impact à chaque règle, ainsi que des scores pondérés, il est possible de construire des modèles de maturité et de promouvoir l'adoption des bonnes pratiques au sein d'une organisation, ce qui permet ainsi aux équipes de prioriser les actions les plus importantes afin d'améliorer l'observabilité de leurs systèmes. Et puis, qui n'apprécie pas un peu de gamification pour optimiser son excellence opérationnelle ?

Rejoignez-nous !

Alors, qu'en pensez-vous ? J'aimerais beaucoup connaître votre avis sur ce concept. Entamons une discussion sur la manière de rendre l'observabilité plus efficace pour tous. Instrumentation Score n'en est qu'à ses débuts, car nous essayons encore de saisir certains des aspects les plus importants à mesurer, et comment les mesurer, comme vous pouvez le constater dans les discussions en cours sur https://github.com/instrumentation-score/spec. Rejoignez-nous et aidez-nous à façonner l'avenir de l'observabilité avec de meilleures données !