Le système fonctionne. Jusqu’au moment où il s’arrête
Imaginez une boutique en ligne où les clients peuvent parcourir les produits, les ajouter au panier et passer au paiement. Le serveur répond, le site s’ouvre et les indicateurs de base de l’infrastructure n’indiquent aucun problème majeur. En apparence, tout fonctionne correctement.
Pendant ce temps, certains clients ne parviennent pas à finaliser leur commande. Pour certains, le paiement prend plusieurs dizaines de secondes ; pour d’autres, une erreur apparaît. L’équipe technique reçoit des signalements, mais ne sait pas encore si la cause est la passerelle de paiement, la base de données, la dernière mise à jour de l’application ou peut-être un problème de communication entre services.
C’est une situation dans laquelle la supervision classique peut s’avérer insuffisante. Elle peut indiquer que le nombre d’erreurs a augmenté ou que le temps de réponse s’est allongé, mais elle ne fournit pas toujours les informations nécessaires pour retrouver rapidement la cause.
C’est précisément cette lacune que comble l’observability, c’est-à-dire l’observabilité du système. Son objectif n’est pas uniquement de constater que l’application fonctionne mal. Il s’agit de pouvoir analyser son comportement, reconstituer le déroulement des événements et trouver la source du problème, y compris lorsqu’un scénario de panne précis n’avait pas été anticipé auparavant.
Monitoring et observability - objectifs similaires, possibilités différentes
Le monitoring et l’observability sont étroitement liés, mais ne désignent pas la même chose.
Le monitoring consiste à collecter et analyser systématiquement des données sur l’état de l’application et de l’infrastructure. Il permet de suivre des paramètres définis, de détecter les écarts par rapport aux normes établies et de déclencher des alertes lorsqu’une situation nécessite une réaction.
Exemples de questions auxquelles le monitoring répond :
- Le serveur est-il disponible ?
- Quel est le temps de réponse moyen de l’API ?
- Le nombre d’erreurs HTTP 500 dépasse-t-il le seuil défini ?
- Quelle est l’utilisation de la mémoire et du processeur ?
- La file de tâches grossit-elle plus vite que le système ne peut la traiter ?
L’observability va plus loin. Elle permet d’analyser des données provenant de différentes parties du système et de les relier dans un contexte qui aide à comprendre pourquoi un comportement donné s’est produit.
On peut l’exprimer en trois questions :
- Monitoring : Y a-t-il un problème ?
- Diagnostic : Où le problème est-il apparu ?
- Observability : Que s’est-il passé, pourquoi et quel a été l’impact sur le fonctionnement du système ?
L’observabilité ne remplace pas le monitoring. C’est une approche qui exploite le monitoring ainsi que des données télémétriques correctement préparées afin de permettre une analyse plus approfondie du comportement de l’application. OpenTelemetry décrit l’observability comme la capacité à poser au système des questions sur son comportement à partir de signaux tels que les logs, les métriques et les traces distribuées. <Cite ref="turn154932search0"/>
Les trois piliers de l’observability : logs, métriques et tracing
La base de l’observabilité repose sur trois types de données télémétriques : logs, metrics et traces. Chacun montre un aspect différent du fonctionnement de l’application. Ce n’est que leur corrélation qui donne une vision plus large de la situation.
1. Logs - que s’est-il passé dans l’application ?
Les logs sont des enregistrements structurés d’événements générés par l’application, le système d’exploitation, les serveurs, les bases de données et d’autres éléments de l’infrastructure.
Ils peuvent par exemple consigner :
- le début et la fin d’un processus,
- une tentative de connexion d’un utilisateur,
- l’envoi d’une requête à une API externe,
- une erreur de validation des données,
- une transaction échouée,
- une exception levée par l’application,
- un changement d’état de commande.
Un log peut contenir un horodatage, un niveau de gravité, le nom du service, un message, un identifiant de requête et des attributs supplémentaires décrivant l’événement.
Il est utile de distinguer les logs textuels des logs structurés. Un enregistrement textuel peut ressembler à ceci :Erreur lors du traitement de la commande
Un tel message signale l’apparition d’un problème, mais dit peu de choses sur son contexte. Un log structuré peut en revanche contenir des champs distincts, tels que l’identifiant de commande, le nom de l’opération, le code d’erreur, le temps d’exécution et l’identifiant de trace. Ainsi, les données peuvent être filtrées, regroupées et analysées automatiquement.
Bonne pratique : les logs doivent être conçus en vue d’une analyse ultérieure, et pas seulement pour consigner des messages. Il est conseillé d’utiliser une nomenclature cohérente, des niveaux de gravité et des identifiants de corrélation qui permettent de relier des événements provenant de différents composants.
En même temps, la journalisation demande de la mesure. Enregistrer chaque opération de manière exhaustive peut générer d’énormes volumes de données, augmenter les coûts de stockage et compliquer la recherche d’informations pertinentes. Tout aussi important, les logs ne doivent pas révéler de mots de passe, de jetons d’accès, de données de cartes bancaires ni d’autres informations sensibles. Il convient d’appliquer le masquage, le contrôle d’accès, des durées de rétention appropriées et des règles de traitement sécurisé des données.
2. Métriques - comment le système se comporte-t-il dans le temps ?
Les métriques sont des données numériques agrégées décrivant l’état, la performance et le comportement du système sur une période donnée.
Les métriques exemples comprennent :
- le nombre de requêtes traitées par seconde,
- le pourcentage de requêtes terminées par une erreur,
- le temps de réponse de l’API,
- l’utilisation du CPU et de la mémoire,
- le nombre de sessions actives,
- la longueur de la file de tâches,
- le nombre de transactions terminées,
- le temps d’attente pour une connexion à la base de données.
Leur plus grand avantage est de permettre l’observation des tendances. Une erreur isolée peut n’être qu’un incident, mais un temps de réponse qui augmente progressivement, un nombre croissant de transactions échouées ou une file de tâches qui s’allonge peuvent indiquer un problème en cours de développement.
En pratique, les métriques aident à répondre non seulement à la question de savoir si l’application fonctionne, mais aussi si ses performances répondent aux attentes des utilisateurs et aux exigences métier.
Les percentiles du temps de réponse sont particulièrement utiles, par exemple p95 et p99. La moyenne peut masquer une situation où la majorité des utilisateurs obtient une réponse rapide, mais une petite partie subit de très grands ralentissements. Les percentiles montrent combien de temps prennent les requêtes les plus lentes et aident à repérer des problèmes invisibles dans les valeurs moyennes.
Bonne pratique : choisissez des métriques qui ont du sens pour l’utilisateur et pour le processus métier. La simple information sur la charge CPU ne dira pas si le client peut passer une commande. Il vaut donc la peine de surveiller aussi des indicateurs liés aux fonctions clés, comme le taux de réussite des paiements, le délai de traitement des commandes ou la disponibilité des opérations les plus importantes.
3. Tracing - par où la requête est-elle passée ?
Le tracing, en particulier le distributed tracing, c’est-à-dire le traçage distribué, permet de suivre le parcours d’une requête unique à travers différents composants du système.
Dans une application moderne, une action utilisateur peut comporter plusieurs étapes. Un clic sur le bouton « Passer commande » peut déclencher une requête dans le navigateur, qui passe à l’API, puis au service de commandes, à la base de données, au système de stock et à un prestataire de paiement externe.
Si le processus prend du retard, la simple information sur le temps de réponse de l’ensemble de l’API peut ne pas suffire. Le tracing permet de décomposer ce temps en opérations individuelles et de voir quelle étape est responsable du retard.
L’élément de base d’une trace est le span, c’est-à-dire l’enregistrement d’une opération unique. Un span peut contenir l’heure de début et de fin, le nom de l’opération, le statut et des métadonnées. Les spans liés entre eux forment une trace montrant le déroulement de l’ensemble de la requête.
Par exemple :
- L’API reçoit la requête et la transmet plus loin.
- Le service de commandes vérifie les données.
- La base de données enregistre la commande.
- Le service logistique vérifie la disponibilité du produit.
- La passerelle de paiement externe traite la transaction.
- L’application renvoie le résultat à l’utilisateur.
Si l’ensemble du processus dure 8 secondes, le tracing peut montrer que 6,5 secondes ont été prises par la réponse de la passerelle de paiement externe, tandis que les autres opérations se sont déroulées correctement. L’équipe obtient ainsi un point concret pour poursuivre l’analyse, au lieu de commencer le diagnostic à partir de composants choisis au hasard.
Le tracing est particulièrement utile dans les architectures de microservices, les systèmes distribués, les applications basées sur des files d’attente et les solutions intégrant de nombreux services externes. <Cite ref="turn154932search0"/>
Alertes - l’information doit parvenir à la bonne personne
Les données de télémétrie ne sont utiles que si l’on peut agir sur leur base. C’est pourquoi le système d’alerting constitue une partie importante de l’observability.
Une alerte est une notification d’un événement ou d’un état nécessitant une attention. Elle peut être déclenchée lorsqu’un seuil de métrique est dépassé, lorsqu’un certain schéma d’erreurs est détecté ou lorsqu’il est constaté qu’une fonction clé de l’application ne fonctionne pas comme prévu.
Cependant, toute augmentation de charge ne doit pas forcément générer une alarme. Si le système traite régulièrement un trafic important aux heures de pointe, une notification à chaque hausse du nombre de requêtes créera du bruit informationnel. Trop d’alertes conduisent à les ignorer, et par conséquent à manquer un incident réellement important.
Il vaut donc la peine de définir :
- quels événements exigent une réaction immédiate,
- quels problèmes peuvent être analysés en mode de travail standard,
- qui est responsable de chaque type d’alerte,
- quelles informations la notification doit contenir,
- quelles actions doivent être entreprises après sa réception.
Un bon point de départ consiste à définir les alertes en fonction de leur impact sur l’utilisateur et des objectifs de fiabilité, et pas uniquement des paramètres de l’infrastructure. Par exemple, une alerte concernant une hausse du taux de paiements échoués peut avoir une importance métier plus grande qu’une brève augmentation de l’utilisation du CPU.
Une alerte doit mener à une action. Si l’on ne sait pas qui doit la prendre en charge ni ce qu’il faut faire, ce n’est qu’un message de plus dans le système.
Exemple pratique : comment l’observability aide-t-elle à trouver la cause d’une panne ?
Supposons que les utilisateurs d’une application B2B signalent que la génération de rapports prend beaucoup plus de temps que d’habitude. Le monitoring détecte une hausse du temps de réponse et déclenche une alerte.
L’équipe commence l’analyse :
- Les métriques indiquent que le problème concerne principalement les rapports couvrant de grandes plages de données. Les autres fonctions fonctionnent normalement.
- Le tracing montre que le plus grand retard apparaît lors de l’exécution d’une requête vers la base de données.
- Les logs contiennent les détails de la requête, ses paramètres d’exploitation et des informations sur les erreurs, sans révéler de données sensibles.
- La corrélation des données permet de relier une trace précise aux entrées correspondantes dans les logs et aux changements visibles sur les graphiques de métriques.
- L’analyse du changement montre que le problème est apparu après le déploiement d’une nouvelle version du rapport, qui a commencé à exécuter une requête coûteuse.
Grâce à cela, l’équipe n’a pas besoin de vérifier à l’aveugle toute l’infrastructure. Elle peut se concentrer sur une opération précise, comparer le comportement avant et après le déploiement, puis optimiser la requête ou revenir sur le changement.
L’observability n’élimine pas les pannes et ne garantit pas que chaque cause soit trouvée automatiquement. Elle permet toutefois de réduire le champ des recherches, de raccourcir le temps de diagnostic et de fonder les décisions sur des données plutôt que sur des suppositions.
Corrélation des données - la plus grande valeur apparaît ensemble
Les logs, les métriques et le tracing sont utiles séparément, mais leur véritable valeur se révèle lorsqu’on peut les relier entre eux.
Imaginons qu’un tableau de bord affiche une hausse soudaine du temps de réponse. Une métrique indique quand et à quelle échelle le problème est apparu. Une trace montre quelles opérations composaient la requête lente. Les logs permettent de vérifier quels événements se sont produits à une étape précise.
Pour que cela soit possible, le système doit transmettre de manière cohérente le contexte de la requête entre les services. Les identifiants de trace et de span peuvent être utilisés pour relier les entrées de logs aux traces. Il est également utile de conserver des informations cohérentes sur le nom du service, l’environnement, la version de l’application et d’autres attributs décrivant la source des données.
Sans corrélation, l’équipe peut avoir accès à de nombreux tableaux de bord, fichiers et outils, tout en perdant du temps à déterminer manuellement quels événements sont liés entre eux. OpenTelemetry désigne la corrélation des logs, des traces et du contexte des ressources comme un élément important de la construction d’une télémétrie utile. <Cite ref="turn154932search1"/>
OpenTelemetry - une norme commune pour les données de télémétrie
La mise en œuvre de l’observability ne doit pas nécessairement impliquer une dépendance à un seul fournisseur d’outils. L’une des solutions favorisant l’interopérabilité est OpenTelemetry (OTel) - un ensemble ouvert de standards, d’interfaces API, de bibliothèques et d’outils pour l’instrumentation, la génération, la collecte et l’exportation des données de télémétrie.
OpenTelemetry permet à l’application d’émettre des métriques, des logs et des traces selon un modèle cohérent. Les données peuvent ensuite être transmises à un back-end d’observabilité choisi, chargé de leur stockage, de leur recherche, de leur visualisation et de leur analyse.
Un élément important de l’écosystème est l’OpenTelemetry Collector. Il peut recevoir des données provenant de différentes sources, les traiter, les enrichir avec un contexte supplémentaire et les exporter vers les systèmes configurés. Ainsi, l’application n’a pas besoin d’être directement liée à chaque outil utilisé pour l’analyse.
Cette approche est particulièrement utile lorsqu’une entreprise utilise plusieurs technologies, fait évoluer l’architecture de son système ou souhaite conserver la possibilité de changer de fournisseur d’outils. Toutefois, la norme seule ne garantit pas une observabilité complète. Il faut toujours une instrumentation appropriée, une stratégie de collecte de données réfléchie, des tableaux de bord adéquats, des alertes et des procédures de réponse. <Cite ref="turn154932search3"/>
Quand vaut-il la peine de mettre en place l’observability ?
L’observability peut être utile aussi bien dans de grands systèmes distribués que dans des applications plus petites, où une indisponibilité ou un défaut difficile à détecter a des conséquences métier importantes.
Il vaut particulièrement la peine d’envisager cette approche lorsque :
- l'application se compose de nombreux services ou intégrations,
- les problèmes surviennent de manière irrégulière et sont difficiles à reproduire,
- les utilisateurs signalent des erreurs qui n'apparaissent pas dans les tests standard,
- le temps de diagnostic des incidents est trop long,
- les déploiements successifs entraînent des effets difficiles à prévoir,
- l'entreprise fait évoluer le système et a besoin de données pour planifier les performances,
- l'application prend en charge des processus clés de vente, opérationnels ou financiers,
- l'équipe a besoin de mieux comprendre l'impact des services externes sur le fonctionnement de l'ensemble de la solution.
Cela ne signifie toutefois pas que chaque site web a besoin d'un environnement de télémétrie sophistiqué. Dans un service petit et simple, des logs de base, la surveillance de la disponibilité et quelques métriques clés peuvent suffire. Le périmètre de la solution doit correspondre à la complexité de l'application, à l'échelle du trafic, aux exigences de fiabilité ainsi qu'aux coûts des temps d'arrêt potentiels.
Quand l'observabilité peut-elle être un excès de forme sur le fond ?
Le déploiement d'outils avancés sans objectif clairement défini peut engendrer plus de coûts que de bénéfices.
Les erreurs les plus fréquentes comprennent :
- Collecter tout sans plan. L'excès de données augmente les coûts et rend plus difficile la recherche d'informations pertinentes pour le diagnostic.
- Ne pas avoir de questions auxquelles le système doit répondre. Les tableaux de bord peuvent sembler impressionnants, sans pour autant aider à résoudre les vrais problèmes.
- Déclencher des alertes pour chaque écart. Un trop grand nombre de notifications provoque une fatigue d'alerte et augmente le risque de passer à côté d'un incident.
- Absence de responsabilité dans la réaction. Même un problème bien détecté peut durer longtemps si personne ne sait qui doit s'en occuper.
- Absence de protection des données. La télémétrie peut contenir des informations sensibles, des identifiants d'utilisateurs ou des données opérationnelles qui nécessitent un accès restreint et une rétention appropriée.
- Ignorer le coût de l'instrumentation. La collecte de traces et de logs détaillés à grande échelle peut affecter les performances de l'application et générer des coûts importants de stockage et de traitement.
- Considérer l'outil comme une solution prête à l'emploi. Le simple fait d'installer une plateforme ne garantit ni une instrumentation correcte ni un processus de diagnostic efficace.
L'observabilité exige donc non seulement de la technologie, mais aussi des décisions organisationnelles : quelles données sont nécessaires, qui les analyse, comment l'équipe réagit et de quelle manière les enseignements tirés des incidents se traduisent en changements dans le système.
Comment planifier le déploiement de l'observabilité ?
Le plus sûr est de faire évoluer l'observabilité par étapes, en commençant par les processus et fonctions dont la panne a l'impact le plus fort sur les utilisateurs et l'entreprise.
1. Définissez les processus métier clés
Identifiez les opérations les plus importantes, comme la connexion, la passation de commandes, les paiements, la génération de documents ou la synchronisation des données. Ce sont elles qui doivent servir de point de départ pour définir ce que signifie le bon fonctionnement de l'application.
2. Définissez des indicateurs de fiabilité
Choisissez des métriques qui reflètent l'expérience utilisateur, par exemple la disponibilité des fonctions clés, le temps de réponse ou le taux d'opérations réussies. Pour les services importants, on peut définir un SLI (Service Level Indicator), c'est-à-dire un indicateur de niveau de service, ainsi qu'un SLO (Service Level Objective), c'est-à-dire un objectif concernant cet indicateur.
3. Soignez les logs structurés
Uniformisez le format des logs, les niveaux de gravité et les attributs de base. Veillez aux identifiants de corrélation et à une politique de suppression ou de masquage des données confidentielles. Les logs doivent être lisibles pour l'équipe et exploitables par les outils.
4. Ajoutez le tracing dans les parcours critiques
Commencez par les processus qui impliquent plusieurs services, bases de données ou intégrations externes. Suivez le parcours d'une requête à travers le système et veillez à la propagation du contexte entre les composants.
5. Construisez des tableaux de bord autour de questions concrètes
Au lieu de créer un immense panneau unique, préparez des vues répondant aux besoins de différents rôles. L'équipe technique peut avoir besoin d'informations sur les erreurs et les latences, tandis que le responsable produit - de données sur l'efficacité des processus clés et sur l'impact des pannes sur les utilisateurs.
6. Concevez les alertes et les procédures de réaction
Définissez les seuils, les priorités, les personnes responsables et les instructions de traitement. Une alerte doit contenir un contexte qui aide à lancer rapidement le diagnostic, et pas seulement informer du dépassement d'une valeur.
7. Testez l'observabilité
Vérifiez si l'équipe est capable de trouver la cause d'une erreur exemple à partir des données disponibles. On peut réaliser des tests de panne contrôlés dans un environnement de test ou des exercices de réponse aux incidents. Il vaut aussi la peine de vérifier si les alertes se déclenchent lorsqu'elles le doivent.
8. Développez la solution à partir des incidents
Après chaque problème important, il vaut la peine d'examiner quelles informations étaient disponibles, ce qui manquait et comment améliorer l'instrumentation, l'alerting ou les procédures. L'observabilité n'est pas un projet ponctuel, mais un processus d'amélioration de la connaissance du fonctionnement du système.
Coûts et sécurité - deux aspects qu'il ne faut pas négliger
Les données de télémétrie ont un coût. Les coûts peuvent découler de l'instrumentation, du transfert, de l'indexation, du stockage, de la rétention et de l'analyse des données. Dans les systèmes à fort trafic, la collecte de toutes les traces ou de logs très détaillés peut être particulièrement coûteuse.
Il vaut donc la peine d'appliquer une rétention adaptée aux besoins, le filtrage des données, l'échantillonnage des traces (sampling) et différents niveaux de détail selon l'environnement. Par exemple, un système en production peut collecter toutes les données pour les erreurs et certaines opérations critiques, tout en échantillonnant une partie des requêtes réussies afin de limiter le volume.
La protection des données est tout aussi importante. Les logs et les traces peuvent contenir involontairement des données personnelles, des identifiants de session, des fragments de requêtes ou des informations sur la structure de l'infrastructure. Il faut limiter l'accès à la télémétrie, supprimer les données inutiles, masquer les informations confidentielles et contrôler les périodes de conservation. Il convient également de considérer les systèmes d'observabilité comme un élément de l'environnement de production, qui nécessite lui aussi des protections, des sauvegardes et une gestion des droits.
L'observabilité comme outil de gestion, pas seulement de diagnostic
Bien que l'observabilité soit le plus souvent associée au travail des développeurs, des DevOps et des administrateurs, sa valeur dépasse le domaine de l'informatique.
Les données sur le temps de réponse, les erreurs, la disponibilité et l'efficacité des processus peuvent aider l'entreprise à comprendre quels éléments de la technologie soutiennent l'activité et lesquels la limitent. Elles permettent d'identifier les problèmes récurrents, d'évaluer les effets des changements et de planifier le développement sur la base du comportement réel du système.
Si, par exemple, le système de commande ralentit régulièrement à certaines heures, les données de télémétrie peuvent aider à déterminer s'il faut optimiser les requêtes, modifier la manière de traiter les tâches ou étendre l'infrastructure. Plutôt que d'investir dans des ressources supplémentaires sur la base d'une intuition, l'entreprise peut d'abord identifier le véritable goulot d'étranglement.
L’observabilité soutient également l’analyse des effets des déploiements. La comparaison des métriques, des traces et des logs avant et après un changement permet de détecter plus rapidement les régressions et d’évaluer si la mise à jour a produit l’effet attendu.
Il ne faut toutefois pas assimiler l’observabilité à la prise de décision automatique. Les données montrent le comportement du système, mais leur interprétation nécessite de connaître l’architecture, les processus métier et le contexte de l’incident concerné.
Glossaire
- Observability (observabilité) - capacité à comprendre le comportement interne d’un système à partir des données qu’il émet.
- Monitoring - suivi continu de paramètres sélectionnés et détection d’états définis nécessitant une attention particulière.
- Telemetry (télémétrie) - données collectées et transmises depuis les applications et l’infrastructure afin d’analyser leur fonctionnement.
- Logs (journaux) - enregistrements des événements survenant dans l’application ou l’infrastructure.
- Metrics (métriques) - mesures numériques de l’état, des performances ou du comportement du système au fil du temps.
- Tracing - suivi du déroulement des opérations à travers les composants de l’application.
- Distributed tracing - suivi d’une requête unique dans un système composé de nombreux services ou processus.
- Span - enregistrement d’une opération unique faisant partie d’une trace.
- Trace - ensemble de spans liés représentant le déroulement d’une opération.
- Alert - notification d’un état ou d’un événement détecté nécessitant une réaction.
- SLI - indicateur mesurant un aspect précis du fonctionnement d’un service.
- SLO - objectif défini pour un indicateur de fiabilité choisi.
- Sampling - technique consistant à limiter la quantité de données télémétriques collectées en sélectionnant une partie représentative des événements.
- OpenTelemetry - ensemble ouvert de normes et d’outils soutenant l’instrumentation et l’exportation des données télémétriques.
Résumé
Une panne d’application ne commence pas toujours par un serveur indisponible ou un message d’erreur. Parfois, le système fonctionne officiellement, mais une fonction clé devient trop lente, une partie des transactions n’aboutit pas ou l’intégration échoue uniquement dans certaines conditions.
Le monitoring aide à détecter les anomalies. L’observabilité permet de comprendre ce qui les a provoquées et quel a été leur impact sur le fonctionnement de l’application. Les journaux, les métriques, le tracing et des alertes bien conçues forment ensemble une base pour un diagnostic plus efficace, un développement plus réfléchi et une réduction du risque opérationnel.
Il ne s’agit pas de collecter le plus de données possible ni de créer les tableaux de bord les plus complexes. Il s’agit, au moment où un problème survient, de ne pas se demander uniquement : « Le système fonctionne-t-il ? », mais de pouvoir déterminer : « Que s’est-il exactement passé dans le système, pourquoi et que devons-nous faire ensuite ? »
Une application mature n’est pas seulement une application qui fonctionne. C’est aussi une application dont le comportement peut être compris, diagnostiqué et amélioré.
