Surveillance et observabilité : quelle est la différence ?

La surveillance collecte et analyse les données système, généralement des métriques de séries chronologiques telles que l'utilisation du processeur ou de la mémoire, pour détecter des problèmes connus et alerter une équipe lorsqu'un seuil est franchi. L'observabilité va plus loin : elle combine métriques, journaux et traces afin qu'une équipe puisse enquêter sur des problèmes qu'elle n'avait jamais prévus, y compris ceux pour lesquels aucune alerte n'a jamais été configurée.

La plupart des organisations qui exploitent des systèmes distribués ou natifs du cloud ont besoin des deux. La supervision répond à la question : “ Le système fonctionne-t-il dans les limites prévues ? ” L'observabilité répond à : “ Pourquoi le système se comporte-t-il ainsi et qu'est-ce qui a changé ? ” 

La surveillance détecte les anomalies connues ; l'observabilité fournit le contexte nécessaire pour enquêter sur des causes qui n'avaient pas été anticipées.

Dans cet article, nous aborderons :

• Ce qui sépare la surveillance de l'observabilité, et où la frontière devient floue avec la télémétrie et l'APM
• Les trois piliers de l'observabilité et comment ils fonctionnent ensemble lors d'un incident
• Quand la surveillance seule suffit et quand l'observabilité devient nécessaire
• Comment passer de la surveillance à l'observabilité sans multiplier les outils
• Où la surveillance et l'observabilité s'intègrent dans les flux de travail DevOps et SRE

Qu'est-ce que le monitoring ?

Supervision est le processus continu de collecte et d'analyse des données provenant des systèmes informatiques pour détecter les problèmes de performance ou les pannes et alerter à leur sujet, en utilisant généralement des seuils prédéfinis sur des métriques connues.

La plupart des outils de surveillance suivent des données de séries chronologiques telles que l'utilisation du processeur, la consommation de mémoire, les E/S disque et le temps de réponse. Lorsqu'une métrique dépasse un seuil défini, l'outil déclenche une alerte. Le seul rôle de cette alerte est d'informer quelqu'un qu'un nombre est sorti de sa plage attendue.

Cela rend la surveillance réactive. Les alertes se déclenchent après qu'un seuil a été franchi, souvent après que les utilisateurs sont déjà touchés. De plus, la surveillance ne détecte que ce pour quoi une équipe a pensé à configurer une alerte. Tout le reste passe entre les mailles du filet.

Par exemple, une alerte CPU à 92% indique à un ingénieur qu’un serveur est soumis à une charge importante. Elle ne précise pas la cause : un pic de trafic, une fuite de mémoire ou une tâche cron bloquée pourraient tous présenter les mêmes symptômes. Il faut tout de même que quelqu’un passe au crible d’autres outils pour en déterminer la cause.

Les principales caractéristiques de la surveillance comprennent :

• Réactif par nature : Les alertes se déclenchent généralement après que les utilisateurs ont déjà ressenti l'impact.
• Basé sur des seuils : Les notifications se déclenchent lorsqu'un indicateur dépasse une limite prédéfinie, par exemple lorsque l'utilisation de la mémoire dépasse 85%.
• Suivi continu : Les données sont collectées régulièrement ou en temps réel pour offrir une visibilité continue sur les performances du système.
• Conçu pour les problèmes connus : La surveillance détecte les modes de défaillance qu'une équipe a prédits et pour lesquels elle a configuré des alertes.

Qu'est-ce que l'observabilité ?

Observabilité est la capacité de déduire ce qui se passe à l'intérieur d'un système à partir de ses sorties externes, y compris métriques, journaux, traces et autres données de télémétrie. Elle prend en charge les investigations ouvertes, bien qu'une instrumentation incomplète ou une télémétrie incohérente limite encore ce qu'une équipe peut déterminer.

Le terme observabilité vient de la théorie du contrôle, où il décrit dans quelle mesure l'état interne d'un système peut être inféré à partir de ses sorties externes. Dans les systèmes logiciels, ces sorties comprennent des métriques, des journaux, des traces et d'autres données de télémétrie.

En informatique, l'observabilité applique cette même idée aux logiciels. Au lieu de s'en remettre uniquement à des alertes prédéfinies, elle met en corrélation les métriques, les journaux et les traces afin qu'une équipe puisse enquêter sur des problèmes auxquels personne n'avait pensé à se préparer. 

Par exemple, dans une architecture de microservices, une seule requête de paiement lente peut traverser une douzaine de services avant d'aboutir. Si les temps de réponse augmentent, les outils d'observabilité peuvent tracer cette requête de bout en bout et montrer exactement quel service a provoqué le ralentissement, même si la cause réelle est une dépendance située à plusieurs niveaux du point où le ralentissement est apparu en premier.

Principales caractéristiques de l'observabilité :

• Conçu pour l'inconnu : Cela aide les équipes à déboguer des pannes pour lesquelles aucune alerte n'avait été configurée, car les données étaient déjà collectées d'une manière qui permet des investigations ouvertes.
• Trois types de données, un seul contexte : Les métriques, les journaux et les traces sont corrélés entre eux au lieu d'exister dans des outils séparés.
• Explique la cause : La corrélation, et souvent l'apprentissage automatique, aide à relier un ralentissement dans un service à sa véritable cause racine amont.

Surveillance vs Observabilité : Principales différences

Voici une comparaison côte à côte des deux.

Surveillance vs Observabilité vs Télémétrie vs APM

La télémétrie est constituée des données qu'un système émet sur son fonctionnement. La surveillance et l'APM (Application Performance Monitoring) utilisent ces données pour détecter et mesurer les performances. L'observabilité les utilise pour expliquer le comportement du système et en trouver les causes profondes.

• Télémétrie comprend les métriques, les journaux et les traces qui décrivent le comportement de l'infrastructure et des applications en temps réel. 
• Supervision utilise la télémétrie pour suivre l'état du système, identifier les problèmes connus et déclencher des alertes lorsque des seuils prédéfinis sont dépassés.
• APM (surveillance des performances des applications) se concentre spécifiquement sur les performances au niveau des applications : transactions, latence, taux d'erreur, dépendances des services et expérience utilisateur au sein d'une application distribuée.
• Observabilité analyse la télémétrie corrélée à travers l'infrastructure, les services et les applications pour expliquer le comportement du système et identifier les causes profondes.

Voici une comparaison rapide : 

APM contre observabilité

L'APM se concentre principalement sur les performances des applications, notamment les transactions, l'exécution du code, les erreurs, la latence et les dépendances des services. L'observabilité relie ces données aux métriques d'infrastructure, aux journaux et aux traces, afin qu'une équipe puisse avoir une vue d'ensemble plutôt que de voir seulement l'application de manière isolée. 

Voici la comparaison rapide :

Là où la surveillance traditionnelle montre ses limites

La surveillance traditionnelle est efficace pour identifier des conditions connues et signaler qu'un dysfonctionnement est possible. Elle indique rarement pourquoi. Dans les environnements distribués, cet écart ralentit tout.

À mesure que les systèmes deviennent plus complexes et que les services dépendent les uns des autres de multiples façons, les seuils fixes ne peuvent pas expliquer ce qui a réellement causé une panne. Un ingénieur finit par chercher des indices dans plusieurs outils au lieu de travailler à partir d'une vue d'ensemble claire.

C'est là que les limites ont tendance à apparaître :

• Biais de la condition connue : Les règles de surveillance ne détectent que les problèmes qu'une équipe a anticipés et pour lesquels elle a configuré des alertes. Tout ce qui sort de cette liste passe inaperçu jusqu'à ce qu'un utilisateur le signale.
• Signaux cloisonnés : Les métriques expliquent rarement une panne multiservice à elles seules. Un ingénieur doit corréler manuellement les journaux, les traces et les données d'infrastructure sur différents outils, souvent au milieu d'un incident.
• Alerte à la fatigue: Des seuils statiques mal réglés génèrent des alertes bruyantes et des faux positifs, ce qui incite les ingénieurs d'astreinte à commencer à ignorer les pages.
• Complexité distribuée : Dans un environnement de microservices, le symptôme apparaît dans un service tandis que la cause racine réside dans une dépendance située plusieurs couches en amont ou en aval.
• Lacunes dans les environnements à fort taux de rotation : Les groupes de mise à l'échelle automatique, les conteneurs éphémères et les charges de travail sans serveur peuvent être créés et disparaître plus rapidement que les configurations de surveillance statiques ne peuvent les suivre, créant ainsi des angles morts de courte durée.
• La prolifération des outils : Les différentes équipes utilisent souvent des outils distincts pour les métriques, les journaux, les traces et la surveillance des applications, ce qui ralentit toute investigation qui dépasse les frontières des équipes.

Voici comment l'observabilité répond à ces limites :

Quand la surveillance suffit et quand vous avez besoin d'observabilité

Si un système est simple et que ses modes de défaillance sont bien connus, la surveillance suffit souvent à elle seule. À mesure que les systèmes deviennent plus distribués et plus dynamiques, l'observabilité peut fournir le contexte supplémentaire nécessaire pour analyser les problèmes, en identifier les causes profondes et réduire le temps de résolution.

La plupart des organisations ne choisissent pas l'un ou l'autre. Elles déploient la surveillance pour la détection et ajoutent l'observabilité à mesure que les incidents deviennent plus difficiles à expliquer, à reproduire ou à prévenir en utilisant de simples seuils.

La surveillance peut suffire lorsque :

• Le système est de petite taille ou bien compris, avec des modes de défaillance prévisibles.
• La plupart des incidents correspondent à des problèmes connus, et les alertes identifient systématiquement la cause réelle du problème.
• Les ingénieurs peuvent retracer un problème sans corréler les données entre les services.
• L'infrastructure change rarement et reste stable entre les versions.

L'observabilité devient nécessaire lorsque :

• L'environnement comprend des microservices, des architectures distribuées ou une infrastructure hybride et multicloud.
• Les incidents sont intermittents, difficiles à reproduire ou s'étendent sur plusieurs services.
• La fatigue des alertes fait qu'il est plus difficile pour l'équipe de distinguer le signal du bruit.
• Les déploiements ont lieu fréquemment grâce à CI/CD, et les problèmes doivent être rattachés à un changement ou à une version spécifique.

Matrice de décision rapide

Voici un tableau qui montre quand la surveillance seule peut suffire et quand l'observabilité devient importante. 

Comment la surveillance et l'observabilité fonctionnent ensemble

La surveillance établit la référence et l'observabilité fournit le contexte nécessaire pour agir en conséquence :

La surveillance établit les bases : Supervision Les outils suivent des indicateurs connus tels que l'utilisation du processeur, la consommation de mémoire, les taux d'erreur et le temps de réponse. Lorsqu'un seuil défini est franchi, une alerte se déclenche. Cette alerte est le premier signal qu'un élément nécessite une attention particulière.

L'observabilité ajoute du contexte : Une fois qu'une alerte se déclenche, les plateformes d'observabilité utilisent les journaux, les traces et la corrélation entre les sources de données pour en expliquer la raison. Si la surveillance signale des temps de réponse élevés sur un service spécifique, le traçage peut révéler quelle dépendance en aval en est réellement responsable, qu'il s'agisse d'un goulet d'étranglement dans la base de données, d'une congestion réseau ou d'une API tierce défaillante.

Ce type de corrélation importe le plus sur les problèmes multi-services. Lorsqu'une plateforme de commerce électronique observe un pic d'échecs de paiement, la surveillance signale le taux d'erreur, mais l'observabilité permet à l'équipe de corréler ce pic avec un déploiement récent ou un changement de configuration, réduisant souvent l'investigation à une seule version en quelques minutes au lieu d'heures.

L'apprentissage automatique ajoute une autre couche ici. 

À elle seule, la surveillance ne permet pas de faire la différence entre un pic de CPU temporaire dû à un traitement par lots planifié et une augmentation soutenue qui signale un réel problème. Les plateformes d'observabilité dotées de la détection d'anomalies apprennent ce qui est normal pour un service donné et éliminent le premier tout en signalant le second, ce qui réduit le nombre d'alertes qui s'avèrent fausses.

Là où la supervision et l'observabilité se rejoignent

La surveillance et l'observabilité partagent le même objectif et les mêmes données sous-jacentes. Toutes deux visent à maintenir les systèmes fiables, performants et disponibles pour les utilisateurs ; la différence réside dans la manière dont la télémétrie partagée est utilisée.

Les métriques, les journaux et les traces alimentent à la fois les alertes de surveillance et les investigations d'observabilité. La surveillance utilise ces données pour détecter et alerter. L'observabilité les utilise pour expliquer et prévenir. 

La plupart des plateformes modernes utilisent les deux ensemble : la surveillance gère la détection, et l'observabilité prend en charge l'investigation approfondie, l'analyse des causes profondes et l'optimisation à long terme qui s'ensuivent.

Surveillance et observabilité dans les flux de travail DevOps et SRE

Dans les pratiques DevOps et SRE (Site Reliability Engineering), la surveillance et l'observabilité s'intègrent directement au cycle de vie du déploiement. 

• La surveillance suit les indicateurs clés de santé après chaque version. 
• L'observabilité permet à l'ingénieur d'astreinte de remonter d'un incident jusqu'au déploiement, au commit ou au changement de configuration spécifique qui l'a causé.

Prenons un exemple hypothétique. 

Une version « canary » passe avec succès le test de taux d'erreur et est déployée sur le trafic 100%. Deux heures plus tard, un segment de clientèle signale un chargement lent des pages, mais aucun indicateur n'a jamais dépassé le seuil fixé, car la régression n'affecte qu'un seul segment de base de données dans le cadre d'un seul modèle de requête. 

Le traçage montrerait le routage des requêtes concernées à travers cette partition, et les journaux de la partition afficheraient une requête passée de 40 ms à 900 ms après un changement de schéma lors de la même version. 

La surveillance seule n'aurait pas détecté cela, car personne n'avait configuré d'alerte pour cette requête spécifique.

Les équipes SRE utilisent également l'observabilité pour gérer les budgets d'erreur, c'est-à-dire le niveau d'indisponibilité acceptable qu'un service peut consommer avant que les livraisons ne soient ralenties au profit de la stabilité. Tracer quels incidents ont consommé ce budget, et pourquoi, transforme cette revue en une liste concrète de causes profondes plutôt qu'en un exercice de devinettes.

Cette même télémétrie alimente également les flux de travail de sécurité. Les équipes de sécurité intègrent de plus en plus les journaux et les traces dans des outils SIEM (gestion des informations et des événements de sécurité) pour corréler une anomalie de performance, telle qu'un pic de latence, avec un événement de sécurité potentiel, tel qu'une augmentation inhabituelle des échecs d'authentification.

Comment passer de la surveillance à l'observabilité

Pour passer de la surveillance à l'observabilité complète, suivez cette séquence d'étapes délibérées, chacune s'appuyant sur la précédente :

1. Commencez par une base de surveillance solide

Mettez en place une surveillance centralisée dans tous les environnements, sur site, dans le cloud et hybrides, couvrant les métriques principales telles que le processeur, la mémoire, le disque et la latence réseau. Dans les environnements hybrides, cela implique de choisir un outil qui gère à la fois les actifs virtuels et physiques sans angle mort.

Note: Prenez le temps d'ajuster les seuils d'alerte et d'éliminer les faux positifs connus avant d'ajouter l'observabilité. Une base de surveillance bruyante devient simplement une base d'observabilité bruyante avec des étapes supplémentaires.

2. Ajouter l'agrégation de journaux pour une visibilité granulaire

Choisissez un outil d'agrégation de journaux qui gère des volumes élevés, prend en charge l'indexation en temps réel et permet des requêtes flexibles sur des journaux structurés et non structurés.

Note: Tout journaliser, tout le temps, avec un niveau de détail maximal devient coûteux et difficile à rechercher rapidement. De nombreuses équipes utilisent des niveaux de journalisation dynamiques, n'augmentant les détails que lorsqu'un problème est suspecté, puis réduisant une fois que le système se stabilise.

3. Ajouter le traçage pour relier les points

Adoptez un framework de traçage compatible avec votre architecture existante, tel qu'OpenTelemetry, et commencez par les parcours utilisateur qui comptent le plus pour l'entreprise, comme les tunnels d'achat ou les appels API clés, avant d'étendre la couverture.

4. Couche de détection des anomalies

Les seuils statiques manquent les dégradations progressives et génèrent du bruit sur les variations normales. La détection d'anomalies, qui fait souvent partie d'un AIOps (Intelligence artificielle pour les opérations informatiques) couche de plateforme, apprend ce qui est normal pour un service donné et signale plutôt les véritables écarts. 

Calibrez-le d'abord par rapport aux données historiques pour que le modèle comprenne vos modèles de trafic réels, y compris la saisonnalité, avant de lui faire confiance pour prioriser les alertes de manière autonome.

5. Créer une interface unifiée

Passer d'un tableau de bord à un autre lors d'un incident fait perdre un temps précieux à l'équipe. Une vue unifiée qui combine les données de surveillance et d'observabilité, personnalisée selon les rôles (accès aux traces approfondies pour les ingénieurs, résumé de l'état de santé pour la direction), permet à tout le monde de travailler sur la même base.

6. Automatiser la réponse aux incidents

Configurez des flux de travail qui se déclenchent lorsque des outils détectent une anomalie significative et acheminent les incidents vers les systèmes de collaboration et de gestion des incidents existants de l'équipe. 

Acheminez les incidents liés au réseau, aux applications et aux bases de données vers les équipes les mieux équipées pour les gérer afin de réduire les délais lors des transferts.

7. Boucler la boucle du retour d'information

L'observabilité peut révéler des schémas de défaillance qui n'étaient pas surveillés auparavant. Réinjectez ces schémas dans la surveillance.

Si un modèle de journal spécifique précède de manière fiable une fuite de mémoire, convertissez ce modèle en alerte de surveillance afin que les occurrences ultérieures soient détectées plus tôt et nécessitent moins d'investigation manuelle.

8. Lier l'effort aux résultats commerciaux

Suivre TMTR (temps moyen de résolution), la fréquence des incidents et disponibilité, et reliez ces chiffres au coût des temps d'arrêt pour l'entreprise. 

Si l'observabilité a évité une panne, chiffrez ce qu'aurait coûté cette panne par heure d'indisponibilité. C'est ce qui permet de maintenir le financement de l'investissement après la première année.

Ce qu'il faut rechercher dans les outils de surveillance et d'observabilité

Choisissez une plateforme qui correspond à l'architecture que vous exploitez aujourd'hui, qui évolue avec ce que vous gérerez l'année prochaine et qui aide l'équipe à passer de la détection à la résolution sans ajouter un nouvel outil pour chaque nouveau type de données.

Utilisez cette liste de contrôle pour évaluer vos options : 

Architecture et couverture

• Prend en en charge l'ensemble de la pile d'infrastructure : fournisseurs cloud, sur site et hybride
• Natif visibilité sur Kubernetes et environnements conteneurisés
• Couverture pour les services de base, les bases de données et les dépendances tierces
• Corrèle la télémétrie avec Pipelines CI/CD et les événements de déploiement

Corrélation de données et contexte

• Corréle les métriques, les journaux et les traces dans une vue unifiée
• Lie la télémétrie aux déploiements, aux modifications de configuration et aux incidents passés
• Fournit des cartes de services ou une visualisation des dépendances

Qualité des alertes et réduction du bruit

• Établissement d'une base de référence dynamique ou détection d'anomalies, et non pas seulement des seuils statiques
• Routage intelligent des alertes et escalade
• Dédoublonnage et suppression pour réduire les pages redondantes
• Priorisation claire basée sur l'impact et la gravité, et pas seulement sur les seuils techniques

Évolutivité et gestion des coûts

• Traite des volumes élevés de télémétrie sans baisse de performance
• Prend en charge l'échantillonnage et la rétention de données par paliers
• Tarification transparente et prévisible à mesure que le volume de données augmente

Normes ouvertes et flexibilité

• Prend en charge OpenTelemetry ou des normes ouvertes similaires
• Permet une instrumentation flexible entre les services
• Réduit la dépendance vis-à-vis d'un fournisseur grâce à des intégrations et des API ouvertes

Visibilité basée sur les rôles

• Analyse approfondie des traces et des journaux pour les ingénieurs qui déboguent un incident
• Tableaux de bord de haut niveau et vues de la santé des services pour la direction
• Vues personnalisables par équipe ou par fonction

Si votre équipe bascule encore entre la supervision d'infrastructure, Splunk pour la recherche de logs, des tableaux de bord Grafana et des outils applicatifs distincts lors des incidents, il est peut-être temps de réduire cette fragmentation.

Unifiez la surveillance et l'observabilité avec LogicMonitor

LogicMonitor rassemble la santé des infrastructures, le contexte applicatif et les données d'observabilité dans une vue opérationnelle unifiée, permettant ainsi aux équipes de passer de la détection au diagnostic sans avoir à rassembler manuellement des preuves provenant de systèmes déconnectés.

Évaluez votre flux de travail actuel en matière d'incidents : identifiez les métriques que les ingénieurs doivent collecter, les outils qu'ils doivent ouvrir et les transferts qui retardent la résolution. 

Déterminez ensuite si LogicMonitor peut consolider ces flux de travail, améliorer la visibilité sur les dépendances et donner à chaque équipe le niveau de contexte dont elle a besoin.