En général, l'observabilité est le degré de compréhension de l'état ou de la condition interne d'un système complexe à partir de la connaissance seule de ses résultats externes. Plus un système est observable, plus il est possible de remonter rapidement et précisément d'un problème de performance identifié à sa cause première, sans test ou codage supplémentaire.

En informatique et dans le domaine du cloud computing, l'observabilité fait également référence aux outils et pratiques logiciels qui permettent d'agréger, de corréler et d'analyser un flux régulier de données de performances à partir d'une application distribuée et du matériel et du réseau sur lesquels elle fonctionne, afin de de surveiller, d'identifier et de déboguer plus efficacement l'application pour répondre aux attentes d'expérience client, aux accords sur les niveaux de service (SLA) et aux autres exigences opérationnelles.

Sujet relativement nouveau dans le domaine de la technologie de l'information, l'observabilité fait souvent l'objet d'une publicité surmédiatisée ou est considérée, à tort, comme l'équivalent de la surveillance des systèmes, de la surveillance des performances des applications (APM) et de la gestion des performances du réseau (NPM). En fait, l'observabilité est une évolution naturelle des méthodes de collecte de données APM et NPM qui répond mieux à la nature toujours plus rapide, distribuée et dynamique des déploiements d'applications cloud natives. L'observabilité ne remplace pas la surveillance ; elle l'améliore, ainsi que la surveillance APM et NPM.

Le terme « observabilité » vient de la théorie du contrôle, un domaine d'ingénierie centré sur l'automatisation du contrôle d'un système dynamique (par exemple, le flux d'eau dans un tuyau ou la vitesse d'une automobile dans les pentes et les montées) en fonction des retours d'un système.

Depuis une vingtaine d'années, les équipes informatiques s'appuient principalement sur APM pour surveiller et identifier et résoudre les problèmes liés aux applications. La surveillance APM échantillonne et agrège régulièrement des données d'application et de système, appelées télémétrie, dont on sait qu'elles sont liées à des problèmes de performances des applications. Elle analyse la télémétrie par rapport à des indicateurs clés de performance (KPI) et rassemble les résultats dans un tableau de bord pour signaler aux équipes chargées des opérations et du support les états anormaux qui doivent être traités pour résoudre ou prévenir les problèmes.

La surveillance APM est suffisamment efficace pour surveiller et résoudre les problèmes liés aux applications monolithiques ou les applications distribuées traditionnelles, où le nouveau code est publié régulièrement et où les flux et les dépendances entre les composants de l'application, les serveurs et les ressources connexes sont identifiés ou faciles à retracer.

Mais les organisations actuelles adoptent rapidement des pratiques de développement modernes (développement agile, intégration continue et déploiement continu (CI/CD), DevOps, langages de programmation multiples) et des technologies cloud natives, telles que les microservices, les conteneurs Docker, Kubernetes et les fonctions sans serveur. En conséquence, elles mettent plus de services sur le marché plus rapidement que jamais. Mais au cours de ce processus, elles déploient de nouveaux composants d'application si souvent, dans tant d'endroits, dans tant de langages différents et pour des périodes si variables (quelques secondes ou quelques fractions de seconde, dans le cas des fonctions sans serveur) que l'échantillonnage de données APM toutes les minutes ne peut pas suivre le rythme.

Ce qu'il faut, c'est une télémétrie de meilleure qualité, et beaucoup plus étendue, qui puisse être utilisée pour créer un enregistrement très précis, très contextuel et entièrement corrélé de chaque demande ou transaction de l'utilisateur de l'application. Entrez dans l'observabilité.

Les plateformes d'observabilité découvrent et collectent en continu des données de télémétrie sur les performances en s'intégrant à l'instrumentation existante incorporée dans les composants d'application et d'infrastructure et en fournissant des outils permettant d'ajouter des instruments à ces composants.

L'observabilité couvre quatre principaux types de télémétrie :

• Journaux. Les journaux sont des rapports granulaires, horodatés, complets et non modifiables des événements d'une application. Ils peuvent être utilisés, notamment, pour créer un enregistrement très précis, milliseconde par milliseconde, de chaque événement, avec le contexte environnant, que les développeurs peuvent « se repasser » pour identifier et résoudre des problèmes et effectuer des opérations de débogage.
• Mesures. Les mesures (appelées parfois mesures de série temporelle) sont des mesures fondamentales de l'état des applications et des systèmes sur une période donnée, telles que la capacité de mémoire ou de traitement utilisée par une application sur une période de cinq minutes, ou le temps d'attente d'une application lors d'un pic d'utilisation.
• Traces. Les traces enregistrent le « parcours » de bout en bout de chaque demande utilisateur, de l'interface utilisateur ou de l'application mobile jusqu'à l'utilisateur, en passant par l'ensemble de l'architecture distribuée.
• Les dépendances (également appelées cartes de dépendances) indiquent comment chaque composant d'application est dépendant d'autres composants, applications et ressources informatiques.

Après avoir collecté cette télémétrie, la plateforme la corrèle en temps réel pour fournir aux équipes DevOps, aux équipes d'ingénierie de fiabilité des sites (SRE) et au personnel informatique des informations complètes et contextuelles sur l'élément, l'emplacement et la raison liés à un événement susceptible d'indiquer un problème de performances d'application, de le générer ou d'être utilisé pour le résoudre. 

De nombreuses plateformes d'observabilité découvrent automatiquement de nouvelles sources de télémétrie à mesure qu'elles apparaissent dans le système (par exemple, un nouvel appel d'API à une autre application logicielle). Et comme elles traitent beaucoup plus de données qu'une solution APM standard, de nombreuses plateformes intègrent des fonctionnalités AIOps (intelligence artificielle pour les opérations) qui écartent les signaux (indications de problèmes réels) du bruit (données sans rapport avec les problèmes).

Le principal avantage de l'observabilité est que, toutes choses étant égales par ailleurs, un système plus observable est plus facile à comprendre (en général et dans les moindres détails), plus facile à contrôler, plus facile et plus sûr à mettre à jour avec un nouveau code, et plus facile à réparer qu'un système moins observable. Plus précisément, l'observabilité soutient directement les objectifs Agile/DevOps/SRE de fournir plus rapidement des logiciels de meilleure qualité en permettant à une organisation de :

• Découvrir et traiter les « inconnus inconnus », les problèmes dont vous ne connaissez pas l'existence. L'une des principales limites des outils de surveillance est qu'ils ne surveillent que les « inconnus connus », des conditions exceptionnelles que vous savez déjà surveiller. L'observabilité permet de découvrir des états que vous n'auriez jamais pu connaître ou que vous n'auriez jamais pensé à rechercher, puis de suivre leur relation avec des problèmes de performance spécifiques et de fournir le contexte qui permet d'identifier les causes premières, afin d'accélérer la résolution des problèmes.
• Détecter et résoudre les problèmes dès le début du développement. L'observabilité intègre la surveillance dans les premières phases du processus de développement des logiciels. Les équipes DevOps peuvent identifier et résoudre les problèmes dans un nouveau code avant qu'ils n'affectent l'expérience client ou les SLA.
• Adapter l'observabilité automatiquement. Par exemple, vous pouvez spécifier l'instrumentation et l'agrégation de données dans le cadre de la configuration d'une grappe Kubernetes et commencer à collecter des données de télémétrie, de son démarrage jusqu'à son arrêt.
• Mettre en œuvre la résolution automatisée et une infrastructure d'application à réparation spontanées. Combiner l'observabilité avec les fonctionnalités de machine learning et d'automatisation AIOps, afin de prévoir les problèmes en fonction des sorties système et les résoudre sans intervention de la gestion.