Dans le DevOps moderne, l’observabilité et la surveillance sont deux termes qui reviennent souvent et qui sont parfois utilisés de façon interchangeable. Dans de nombreux cas, ces concepts peuvent paraître similaires et, de fait, la ligne de séparation entre les deux est floue. Cependant, il existe des différences claires.
La surveillance fait référence au travail réalisé par les équipes d’ingénierie ou d’exploitation pour surveiller et comprendre l’état actuel de leurs systèmes. Cette opération, qui dépend de la collecte d’indicateurs prédéfinis, est presque aussi ancienne que l’informatique elle-même.
L’observabilité est en revanche un concept beaucoup plus récent. Bien qu’elle soit plus difficile à définir, elle vise un objectif clair. Ce n’est donc pas qu’un terme DevOps vide de sens.
Dans cet article, nous nous pencherons sur la signification de ces deux termes et la relation entre eux. Nous examinerons aussi plus en détail certains des outils disponibles pour les implémenter.
Commençons par définir plus précisément la surveillance.
Qu’est-ce que la surveillance ?
La finalité de la surveillance est de promouvoir une communication efficace. En informatique moderne, la surveillance indique aux équipes DevOps ou d’ingénierie de fiabilité du site (SRE, Site Reliability Engineering) si un système observable fonctionne correctement.
Avant d’implémenter un processus de surveillance, vous devez définir les indicateurs que vous souhaitez suivre. À partir de là, vous pouvez collecter ces indicateurs prédéfinis (et, potentiellement, des logs) sur les systèmes surveillés pertinents. Ensuite, vous devez regrouper les données, déterminer et mettre en lumière les tendances, puis signaler les perturbations, les problèmes ou autres erreurs.
Quels problèmes vos outils de surveillance peuvent-ils signaler ? Les possibilités sont multiples, mais voici quelques exemples :
- Latence du réseau
- Lenteur de réponse des applications
- Baisse des performances d’E/S
- Échec des opérations de base de données
Les applications web modernes utilisent deux types de surveillance : la surveillance synthétique et la surveillance des utilisateurs réels (RUM, Real User Monitoring). La surveillance synthétique est généralement utilisée pour surveiller les tendances à court terme, tandis que la RUM est plus adaptée aux tendances à long terme. La surveillance synthétique s’appuie sur des outils d’automatisation pour évaluer le fonctionnement d’un système. Par exemple, elle utilise des valeurs échantillons pour déterminer si une application web fonctionne comme prévu. La RUM implique d’enregistrer les interactions réelles de l’utilisateur avec l’application, et d’établir si cette dernière fonctionne comme prévu.
La surveillance n’est pas une pratique nouvelle ni un concept inédit. Elle a toujours fait partie du paysage informatique moderne, remontant aussi loin que les origines des PC. Ainsi, Norton Disk Doctor, l’un des premiers exemples d’outil de surveillance, analysait le disque dur des PC et signalait les problèmes.
Dans les environnements DevOps d’aujourd’hui, les équipes SRE utilisent une fonction de surveillance pour contrôler l’état général de serveurs, de réseaux et d’espaces de stockage spécifiques. La surveillance fonctionne comme un sous-ensemble des objectifs d’observabilité globaux d’un environnement.
Qu’est-ce que l’observabilité ?
Selon Wikipédia, « l’observabilité est la mesure dans laquelle l’état interne d’un système peut être déduit de la connaissance de ses sorties externes ».
On peut comparer cette notion à un patient qui reçoit des soins médicaux de routine lors d’une longue maladie. Du point de vue de l’informatique, l’objectif de l’observabilité est d’analyser les sorties externes — c’est-à-dire, dans notre analogie, les symptômes — qui montrent comment le système interne fonctionne. L’observabilité examine les effets, puis les met en corrélation avec une cause spécifique.
Pourquoi l’observabilité est-elle devenue un concept aussi prisé dans l’univers informatique ? Depuis 2005, la popularité du cloud computing — et l’utilisation d’applications distribuées — a explosé. L’époque où il suffisait de surveiller un seul cluster de VM est révolue. Dans le monde informatique moderne, une application peut être déployée sur plusieurs clouds, à l’aide de conteneurs et de microservices. Ces services peuvent être à la fois distribués et multiniveaux.
C’est la principale différence entre la surveillance simple et l’observabilité. Un environnement multiniveau nécessite de disposer d’une vue globale de l’infrastructure — et seule l’observabilité permet de l’obtenir.
L’objectif de l’observabilité est de fournir une vue complète de l’infrastructure, ce qui va au-delà de ce que la surveillance d’un système spécifique peut offrir. L’observabilité aide à déterminer avec beaucoup plus de certitude la cause première d’un problème, en particulier dans les systèmes distribués complexes.
Les sorties externes d’un système observable sont notamment des indicateurs, des événements, des traces et des logs. Voici quelques exemples de la façon dont les ingénieurs DevOps peuvent bénéficier de l’observabilité :
- Détection des anomalies de sécurité
- Analyse du coût des ressources cloud
- Analyse des traces d’appel pour déterminer comment des valeurs d’entrée spécifiques affectent les défaillances du programme
- Identification des pics saisonniers de la charge système et mise en corrélation de ces informations avec un répartiteur de charge inefficace
La plupart des plateformes d’observabilité offrent les informations détaillées dont les utilisateurs ont besoin pour identifier facilement la cause première d’un problème. Certaines peuvent même suggérer des solutions pour résoudre le problème. D’autres vont plus loin encore en appliquant les mesures correctives elles-mêmes.
Pourquoi l’observabilité et la surveillance semblent-elles similaires ?
Comment expliquer cette confusion entre observabilité et surveillance ? Tout d’abord, ces termes sont similaires et les deux ont des objectifs finaux semblables. Ensuite, les deux visent à améliorer la fiabilité du système et à identifier la cause d’un problème afin d’améliorer les performances globales.
En outre, les deux s’appuient sur les mêmes données. Que vous souhaitiez créer un système observable ou surveillé, vous devez d’abord capturer les sorties appropriées. Cela nécessite d’installer des collecteurs et des agents, voire d’instrumenter le code d’application.
Par ailleurs, ces deux tâches peuvent coexister. Comme mentionné précédemment, la surveillance est un sous-ensemble de l’observabilité. En fait, de nombreuses plateformes d’observabilité intègrent des outils de surveillance dans leur interface. Cela signifie que vous n’avez pas besoin de posséder deux jeux d’outils distincts pour assurer la surveillance et l’observation — tout est inclus.
Différence entre observabilité et surveillance
Malgré leurs nombreux points communs, l’observabilité et la surveillance présentent également plusieurs différences majeures. Tout d’abord, la surveillance est essentiellement une fonction opérationnelle. Elle examine les performances internes d’un système et signale les problèmes. En revanche, elle ne permet pas de révéler les différents facteurs à l’origine d’un problème. Elle peut uniquement alerter l’équipe DevOps de l’existence de ce problème.
Par exemple, une fonction de surveillance peut avertir votre équipe SRE qu’un serveur ne répond pas. Elle peut fournir des données sur la mémoire du système, les performances réseau et les indicateurs du processeur, mais pas sur ce qui a provoqué les pics. Une plateforme d’observabilité va plus loin : elle examine les logs du serveur, les traces, les événements et les indicateurs, puis met les données en corrélation, ce qui peut permettre de déterminer le processus d’échappement responsable d’un pic dans l’utilisation du processeur. La plateforme d’observabilité génère ensuite un rapport sur ce processus.
La surveillance vous dit que quelque chose ne va pas. L’observabilité utilise les données collectées pour vous dire ce qui ne va pas et pourquoi.
Si la surveillance collecte des indicateurs, les équipes DevOps doivent toujours analyser les informations, les mettre en corrélation avec le problème et localiser l’erreur, et ce manuellement. L’observabilité automatise quant à elle ces tâches fastidieuses, de sorte que l’équipe peut repérer et résoudre les problèmes beaucoup plus facilement.
L’observabilité intègre des fonctions avancées comme la mise en corrélation des données (parfois à l’aide de l’intelligence artificielle pour l’indication contextuelle), le traçage distribué et la détection avancée des anomalies.
Une autre différence notable est que l’observabilité peut révéler les « inconnues ignorées », c’est-à-dire des problèmes dont l’équipe DevOps n’a peut-être même pas conscience. De son côté, la surveillance est davantage axée sur la découverte de l’état d’un système.
Comment l’observabilité et la surveillance peuvent fonctionner ensemble
Si ces deux fonctions sont différentes et servent chacune leurs propres objectifs, il ne s’agit pas de choisir entre l’une ou l’autre. Elles peuvent — et doivent — coexister, en se complétant l’une l’autre pour offrir une expérience de résolution des problèmes plus performante.
La surveillance peut détecter et signaler des problèmes mineurs connus. Elle peut révéler ces problèmes au moyen d’alertes, en apportant aux équipes SRE les informations de base dont elles ont besoin pour les résoudre avant qu’ils ne deviennent plus graves.
La surveillance aide également à valider les modifications planifiées d’un système. Imaginons un scénario où un serveur arrive à court d’espace disque. La surveillance peut l’indiquer, après quoi l’équipe DevOps pourra implémenter les modifications prévues (comme ajouter de l’espace disque), ce qui mettra fin aux alertes du système de surveillance. Dans ce cas, la correction peut être considérée comme terminée sans enclencher une observation plus complexe.
Imaginons toutefois que le même problème se répète sans que la cause première soit clairement identifiée. Cette situation peut nécessiter une observation et un niveau d’analyse plus approfondi, ce qui va au-delà des capacités de la surveillance. Un outil d’observabilité, en revanche, peut identifier une ou plusieurs causes premières. Une fois cette étape effectuée, les ingénieurs DevOps peuvent reconfigurer l’outil de surveillance afin qu’il collecte d’autres indicateurs, envoie des alertes supplémentaires ou même ignore des conditions d’alarme spécifiques.
L’observabilité est idéale pour aider à effectuer des opérations telles que la planification des capacités, l’optimisation des coûts, l’application et le développement de correctifs et les mises à niveau. Si la surveillance n’est pas capable de réaliser ces tâches, elle peut en revanche confirmer que les actions entreprises ont eu une issue favorable.
Journalisez toutes vos données et répondez à toutes les questions – gratuitement
Falcon LogScale Community Edition (anciennement Humio) offre une plateforme moderne et gratuite de gestion des logs pour le cloud. Exploitez l’ingestion des données de streaming pour bénéficier d’une visibilité instantanée sur les systèmes distribués, de même que détecter et résoudre les incidents.
Falcon LogScale Community Edition, disponible instantanément et gratuitement, inclut les fonctionnalités suivantes :
- Ingestion de jusqu’à 16 Go de données par jour
- Durée de rétention de 7 jours
- Aucune carte de crédit n’est requise
- Accès continu sans période d’essai
- Journalisation sans index, alertes en temps réel et tableaux de bord en direct
- Accès à notre place de marché et à nos packages, y compris aux guides de création de nouveaux packages
- Formation et collaboration avec une communauté active
