Les trois piliers de l’observabilité : logs, indicateurs et traces

Bon nombre de structures et d’organes de gouvernance s’appuient sur trois piliers pour assurer la réussite. Les pratiques de responsabilité sociétale des entreprises mettent l’accent sur la durabilité environnementale, sociale et financière pour orienter les pratiques commerciales. 

Les entreprises qui souhaitent opérer une transformation numérique s’appuient souvent sur trois piliers : les personnes, les processus et la technologie, pour les guider à travers cette transition. Ce cadre encourage les décideurs à se concentrer sur la rétention de talents techniques créatifs et collaboratifs (les personnes), à utiliser des pratiques rigoureuses et structurées de gestion des données et de la sécurité (les processus), et à s’appuyer sur des outils avancés et des plateformes pour stimuler le progrès (la technologie). 

Et les trois piliers sur lesquels repose Scrum, un ensemble de cadres et de principes permettant la gestion agile de projets, sont la transparence, l’inspection et l’adaptation. Dans chacun de ces cas, les piliers sont distincts et essentiels, mais incomplets. Chacun possède ses propres marges de manœuvre et priorités, mais leur véritable puissance réside dans la manière dont ils interagissent et collaborent pour soutenir des objectifs plus larges. L’observabilité n’échappe pas à cette règle.

Dans un contexte informatique, l’observabilité utilise trois piliers de données télémétriques (indicateurs, journaux et traces) pour faciliter la visualisation et la compréhension de vastes réseaux informatiques. Elle permet aux développeurs de comprendre l’état interne d’un système à partir de ses sorties externes. Lorsqu’un réseau est observable, le personnel informatique peut identifier la cause racine d’un problème de performance en examinant les données qu’il produit, sans aucun test ou codage supplémentaire.

Les solutions d’observabilité utilisent les données brutes produites par un système pour effectuer des analyses, offrant aux équipes la visibilité de bout en bout sur le réseau et les informations exploitables dont elles ont besoin pour un dépannage et un débogage efficaces.

Les architectures observables aident les équipes d’ingénierie et les administrateurs réseau à gérer la complexité des réseaux informatiques modernes. Aujourd’hui, cela signifie souvent maintenir d’immenses réseaux informatiques hautement dynamiques, incluant des configurations cloud hybrides et multicloud, ainsi qu’une multitude d’applications cloud natives, de microservices et de conteneurs Kubernetes.

Les outils d’observabilité, tels que la solution open source OpenTelemetry, offrent aux entreprises une vue complète et contextualisée de la santé de leurs systèmes. La visibilité complète des conteneurs aide les équipes à identifier les anomalies dans les données et les goulets d’étranglement en matière de performance avant qu’ils n’affectent les utilisateurs finaux. Ainsi, l’observabilité peut aider les entreprises à minimiser les temps d’arrêt réseau et à maintenir la fiabilité des services dans une variété de cas d’utilisation.

Cependant, quelle que soit la complexité du réseau, l’observabilité dépend des « événements » du système et de ses trois principaux piliers. Les piliers permettent aux plateformes d’observabilité de collecter et d’analyser les données provenant des applications front-end, des services back-end, des pipelines CI/CD et des pipelines de données en continu exécutés sur les systèmes distribués.

L’observabilité exige une collecte méticuleuse des données auprès de chaque composant du réseau afin de déterminer le « quoi », « où » et « pourquoi » des événements système, ainsi que la manière dont les événements peuvent affecter la performance de l’architecture. Les événements constituent donc la base de la surveillance et de la télémétrie.

Les événements sont des circonstances distinctes qui se produisent à des moments précis sur le réseau et génèrent généralement des données utiles pour les journaux, les indicateurs et les traces. Ils font donc partie intégrante de l’observabilité, au même titre que les trois piliers. Ces événements s’inscrivent dans un contexte plus large.

Lorsqu’un client, par exemple, demande des ressources à un serveur d’entreprise, il dirige sa requête vers le bon point de terminaison API en utilisant l’URL correspondante. Le serveur reçoit la requête, vérifie les identifiants d’authentification (comme une clé API) et les permissions du client, et, si tout est valide, traite la requête conformément aux spécifications de l’API (par exemple, en s’assurant que la réponse est correctement formatée). Le serveur renvoie ensuite une réponse au client avec les données demandées.

Les événements déclenchent des actions distinctes à des moments précis. Les outils d’observabilité s’appuient donc sur eux pour lancer les processus de suivi, d’analyse et de corrélation qui aident les équipes DevOps à visualiser leur environnement informatique et à optimiser leur réseau.

Les indicateurs fournissent des informations quantitatives sur la performance du système en mesurant divers paramètres du réseau. Ils aident les équipes à comprendre le « quoi » des problèmes liés au système. Les types d’indicateurs sont les suivants :

• Indicateurs de l’hôte : utilisation de la mémoire, du disque et du processeur
• Indicateurs de performance réseau : temps de fonctionnement, latence, débit
• Indicateurs applicatifs : temps de réponse, taux de requêtes et d’erreurs
• Indicateurs du pool de serveurs : total des instances, nombre d’instances en cours d’exécution
• Indicateurs de dépendances externes : disponibilité, état du service

Certains indicateurs courants, tels que l’utilisation de la mémoire et la latence, sont intuitivement liés à la santé du système. Cependant, bien d’autres métriques et indicateurs clés de performance (KPI) peuvent révéler des problèmes sous-jacents dans le système. Par exemple, l’épuisement des handles du système d’exploitation peut ralentir considérablement un système et nécessite souvent un redémarrage pour restaurer son fonctionnement normal.

Les indicateurs sont souvent agrégés afin d’offrir une vue synthétique via des tableaux de bord et autres visualisations (comme les graphiques de séries temporelles), permettant aux développeurs d’évaluer rapidement l’état général du système, d’analyser les tendances et de réagir aux problèmes réseau. Ils orientent également les décisions liées au dimensionnement et à l’allocation des ressources, ce qui rend les indicateurs essentiels pour une planification efficace des capacités et une bonne gestion de la charge.

Il est crucial que les équipes sélectionnent avec soin les indicateurs à suivre et les analysent en continu, car certains peuvent leur permettre d’anticiper des problèmes avant qu’ils ne surviennent.

Les équipes peuvent définir des seuils pour les indicateurs qui, une fois franchis, déclenchent des alertes afin d’avertir le personnel informatique d’un problème actuel ou imminent. Les indicateurs permettent aussi aux outils d’observabilité de détecter des problèmes, comme une fuite de handles système, qui s’accumulent lentement au fil du temps, bien avant qu’ils n’affectent l’expérience utilisateur.

Cependant, les indicateurs offrent souvent un contexte limité et nécessitent donc en général d’être corrélés avec des logs et des traces pour que les développeurs puissent comprendre pleinement les événements du système. Les indicateurs à haute résolution génèrent également d’importants volumes de données, difficiles à stocker et à gérer efficacement. C’est pourquoi l’observabilité requiert souvent des solutions de stockage de haute qualité et à long terme, capables de gérer les données d’indicateurs et d’en garantir la disponibilité pour les analyses.

Les journaux sont des enregistrements exhaustifs et immuables des événements discrets qui se produisent au sein d’un système. Ils aident les équipes à comprendre le « pourquoi » des problèmes liés au système.

Les fichiers journaux contiennent des informations détaillées sur le comportement du système et les processus applicatifs, notamment :

• Horodatage des événements
• ID de transaction
• Adresses IP et identifiants utilisateurs
• Détails des événements et des processus
• Messages d’erreur
• Tentatives de connexion
• Changements de configuration

Les journaux d’événements peuvent être binaires, non structurés (par exemple, en texte brut) ou structurés (par exemple, au format JSON). Tous les fichiers journaux sont utiles dans le bon contexte, mais les approches de connexion structurées structurent le texte et les métadonnées au fur et à mesure qu’ils sont générés, ce qui facilite l’analyse.

Les fonctionnalités de journalisation présentes dans les outils d’observabilité agrègent les fichiers journaux des systèmes d’exploitation, des périphériques réseau, des applications internes et tierces et des appareils IdO (Internet des objets) pour aider les équipes de développement à diagnostiquer les erreurs et à comprendre les défaillances du système. En cas d’erreur, de violation de sécurité ou de problème de conformité, les journaux fournissent les informations nécessaires pour retracer la cause racine et comprendre ce qui n’a pas fonctionné.

Les logs offrent de précieuses informations sur les événements et incidents du système, mais à eux seuls, ils ne dressent qu’un tableau incomplet. Comme pour les indicateurs, les outils d’observabilité doivent analyser et corréler les logs avec les indicateurs et les traces pour en maximiser la valeur. Et, tout comme les indicateurs, les logs augmentent significativement le volume de données, si bien que les entreprises doivent souvent investir dans des outils sophistiqués de gestion des journaux pour faire face à cette charge.

En outre, l’enregistrement complet des événements peut dissimuler des informations importantes sous des données moins pertinentes. Ce « bruit » complique l’identification des problèmes pour le personnel informatique. C’est pourquoi les solutions d’observabilité modernes s’appuient sur des workflows d’automatisation pilotés par l’IA et le machine learning (ML) pour affiner les pratiques d’alerte et distinguer les alertes critiques du bruit.

Les traces, qui combinent certains aspects des indicateurs et des logs, permettent de cartographier les données à travers les différents composants réseau pour visualiser le workflow d’une requête. Elles représentent le parcours complet d’une requête à travers le réseau, capturant le chemin emprunté et la durée de vie de chaque composant impliqué dans le traitement de cette requête. En résumé, le traçage aide les ingénieurs en fiabilité des sites (SRE) et les équipes de développement logiciel à comprendre le « où » et le « comment » des événements et des problèmes système.

Les données de suivi peuvent inclure :

• La durée des événements et des opérations réseau
• Le flux des paquets de données dans l’architecture
• L'ordre dans lequel les requêtes traversent les services réseau
• La cause racine des erreurs système

Le traçage, à savoir le traçage réparti, est utile dans les architectures de microservices, où les requêtes peuvent traverser plusieurs services géographiquement dispersés avant d’atteindre leur destination. Il fournit des informations sur les dépendances et les interactions entre les différents composants et services, et peut aider les équipes informatiques à comprendre combien de temps il faut aux utilisateurs pour effectuer des actions spécifiques.

Les fonctionnalités de traçage des outils d’observabilité sont essentielles pour analyser la latence. Cela permet aux ingénieurs d’identifier les composants problématiques et les services peu performants, susceptibles de créer des goulets d’étranglement côté utilisateur.

Ils facilitent les processus de débogage en illustrant les flux requête-réponse et les relations de causalité entre les éléments du réseau. Lors de l’analyse des causes racines, les traces aident les équipes à identifier la source des problèmes de réseau dans les workflows complexes pour accélérer et optimiser la résolution.

Contrairement aux indicateurs et aux journaux, les traces peuvent fournir des informations contextuelles pour enrichir l’analyse. Cependant, le traçage ne peut à lui seul révéler les tendances ni les schémas présents dans les données. La mise en place de traces distribuées nécessite également une instrumentation des déploiements de services, ce qui peut rendre le processus particulièrement complexe et chronophage. Et s’il n’est pas géré correctement, le traçage et la puissance de calcul qu’il exige peuvent augmenter la latence de l’environnement.

Associer ces trois piliers permet aux équipes de développement et d’exploitation d’obtenir une vision globale, ainsi qu’une compréhension granulaire du comportement complexe des systèmes. Les indicateurs sont utilisés pour alerter les équipes en cas de problème, tandis que les traces indiquent leur chemin d’exécution, et les journaux fournissent le contexte nécessaire pour les résoudre.

Ensemble, ils permettent d’accélérer l’identification et la résolution des problèmes, offrant aux équipes des outils complémentaires pour gérer les problèmes, optimiser la performance et favoriser la Full Stack Observability.

Les indicateurs, les logs et les traces sont largement reconnus comme les trois piliers fondamentaux de l’observabilité, mais cela n’exclut pas l’existence d’autres composantes essentielles. Certains avancent que le contexte, la corrélation et les alertes constituent également des piliers de l’observabilité.

En effet, le contexte enrichit les indicateurs, les journaux et les traces en fournissant des informations supplémentaires sur l’environnement réseau (topologie, rôles des appareils et dépendances des applications, par exemple). Sans contexte, les données d’observabilité ne sont pas exploitables.

La corrélation relie les indicateurs, les journaux, les traces et les informations contextuelles pour présenter une vue cohérente des événements à travers les différentes couches de la pile. Et sans alerte, les outils d’observabilité ne seraient pas en mesure d’envoyer des notifications prompt en cas de problème.

Cependant, le profilage émerge comme une autre fonctionnalité clé de l’observabilité.

Le profilage, également appelé « profilage continu », consiste à exécuter une application et à recueillir en permanence des données détaillées sur l’état d'exécution du code. Par exemple, les profils peuvent indiquer si les unités d’exécution Java sont en cours d’exécution (RUNNING) ou en attente (WAIT). Si une application présente des fuites de mémoire, les profils permettent d’identifier la partie du code qui consomme trop de ressources.

Le profil est donc une radiographie du fonctionnement interne de chaque composant du système.

Le profilage permet d’identifier les problèmes de bas niveau, comme ceux qui affectent individuellement les fonctions ou les blocs de code. Il aide les équipes informatiques à identifier les chemins de code occupés, à localiser et à supprimer les chemins inutilisés et à prioriser les chemins critiques pour les événements et interactions futurs.

Bien que les profils ne fassent pas partie des trois piliers, les capacités de profilage ont beaucoup évolué. Des projets tels que l’extended Berkeley Packet Filter (eBPF) pour le noyau Linux ont rationalisé le développement d’outils de profilage, simplifiant considérablement les processus pour les équipes de développement.

Les équipes de développement utilisent les profils de traçage, d’échantillonnage et d’instrumentation pour obtenir une vue plus approfondie et plus granulaire du code des applications. En outre, lorsqu’il est utilisé parallèlement à d’autres piliers de l’observabilité, le profilage peut fournir des informations en temps réel sur la performance des applications, accélérer le cycle de développement logiciel et aider les entreprises à optimiser leur stratégie DevOps.