De la Supervision à l’Observabilité : 4 modes de surveillance à distinguer

Appelée également supervision passive, la supervision technique repose sur la surveillance d’indicateurs techniques a priori simples, isolés et mesurés en temps réel : capacité CPU, mémoire RAM (taux d’utilisation, saturation, seuils d’alerte), disque dur, bande passante, etc. 

Le périmètre couvert concerne principalement les couches basses d’un système comme l’infrastructure physique, les machines virtuelles, les réseaux ou les équipements de stockage.

Avec une vision centrée sur les composants d’un système, la supervision technique suit une approche basée sur le dépassement de seuils prédéfinis. Elle fonctionne donc en réaction à un événement et produit une alerte lorsqu’un seuil est franchi.

Elle permet de cartographier des dépendances entre services, de faire de l’alerting et de produire du reporting. Des outils comme Zabbix, Centreon ou Datadog sont couramment utilisés pour ce type de surveillance.

Cependant cette vision en silo ne permet pas véritablement de corréler des évènements entre eux ou d’identifier la cause à l’origine d’un dépassement de seuil. Ceci sans compter le phénomène de multiplication des faux positifs (alertes non critiques) à gérer et la génération de bruit de données qui en résulte.

Aussi et même s’il est possible d’y intégrer des métriques métiers, la supervision technique ne permet pas de réaliser des analyses comportementales approfondies liées à l’utilisation d’un service ou d’une application métier, ni de faire de la détection proactive ou de la prédiction.

La supervision technique est plutôt adaptée à des infrastructures traditionnelles et relativement stables, où les interdépendances sont limitées (à la différence d’architectures distribuées).

Elle s’avère utile pour de la surveillance de serveurs physiques ou virtuels, la supervision de réseaux (routeurs, bande passante, latence, etc.), la surveillance d’équipement matériel et périphériques ou bien le contrôle des ressources de stockage.

En clair, elle répond bien aux besoins de structures informatiques aux périmètres bien définis, ce qui en fait une une solution pertinente pour les PME. Elle peut aussi être envisagée comme premier niveau de surveillance dans des systèmes plus vastes, en complément d’une supervision applicative et plus loin, d’une stratégie d’observabilité.

La supervision applicative, connue également sous le nom de APM (Application Performance Monitoring) se distingue des approches techniques traditionnelles en plaçant l’expérience utilisateur au cœur de l’analyse.

Il est ainsi possible de surveiller le parcours utilisateur de bout en bout, depuis la saisie d’une requête jusqu’à la réponse affichée à l’écran, en traversant potentiellement plusieurs couches applicatives (front-end, back-end, bases de données, services tiers, etc.).

Là où la supervision technique s’attache à la surveillance d’indicateurs isolés, la supervision applicative mesure ce que perçoit réellement l’utilisateur lors de ses interactions avec une application métier.

Elle permet ainsi d’observer la disponibilité d’une application client, son niveau de performance ou le taux d’erreur renvoyé, les dépendances entre services, et révèle l’écart entre performance technique et performance perçue.

L’Application Performance Monitoring revêt un caractère proactif. En effet, dans ce mode de surveillance, des sondes (ou robots) sont envoyées à travers un système, ses applicatifs et son code, pour simuler des parcours utilisateurs. L’objectif étant de mesurer en continu la disponibilité des applications et la rapidité de réponse émise, indépendamment de l’usage en situation réelle.

On parle alors davantage de supervision active (ou de monitoring) avec l’intention de caractériser si ce que l’on observe marche vraiment du côté des utilisateurs. On vérifie ainsi si ce qui est censé fonctionner, fonctionne bel et bien côté utilisateur.

La supervision applicative emprunte différentes méthodes pour évaluer en temps réel la performance applicative et la performance perçue par les utilisateurs.

Le Continuous Profiling permet d’identifier et de comprendre comment les ressources (CPU et mémoire) sont consommées par un composant, un programme ou une partie de celui-ci. En clair, cette méthode évalue la performance en continu et en temps réel d’une application directement en production.

(La courte vidéo de présentation de l’outil Continuous Profiler de Datadog, permet de comprendre concrètement en quoi consiste le Continus Profiling. Vous pouvez la consulter ici)

Le Real User Monitoring permet la surveillance des activités des visiteurs en situation réelle (dans un environnement de production) et la compréhension des usages de l’application. Elle renvoie ainsi des informations critiques sur l’expérience utilisateur et capture des métriques de performance réelle (temps de chargement, interactions, erreurs, etc.).

Il s’agit de tests automatisés simulant le comportement des utilisateurs sur des parcours prédéfinis. Ils peuvent aider à combler des lacunes au lancement de nouveaux services ou détecter des problèmes avant qu’ils n’affectent les vrais utilisateurs.

C’est une analyse approfondie du code applicatif en production. L’objectif est d’identifier les goulots d’étranglement et localiser précisément les causes de lenteur dans le code source.

Corrélées à ces méthodes, sont rattachés divers indicateurs permettant une analyse complète des performances depuis l’infrastructure jusqu’à l’impact sur la performance commerciale : indice de satisfaction utilisateur (score Apdex), temps total de traitement d’une requête utilisateur (Response Time), pourcentage de requêtes échouées (Error Rate), temps avant réception du premier octet de réponse (TTFB), détail chronologiques d’exécution d’une transaction (Transaction Trace), etc.

Une démarche d’amélioration continue avec le monitoring DevOps

La surveillance continue dans la culture DevOps tient un rôle clé. Elle permet de réintégrer des mesures de performance liées au code qui est produit, ainsi que le retour d’expérience des utilisateurs, dans le processus de développement continue des produits et des services.

Elle tient donc un rôle clé pour maintenir aussi bien les produits développés que les systèmes sous-jacents. On parle alors de monitoring DevOps.

Le monitoring DevOps est orienté infrastructure et agilité

Le monitoring DevOps désigne l’ensemble des pratiques, des outils et des métriques mis en œuvre pour surveiller en continu l’état de l’infrastructure, des services applicatifs et des pipelines de déploiement dans un environnement DevOps.

Il vise à fournir une visibilité temps réel sur la performance, la disponibilité et la fiabilité des systèmes informatiques, dans le but de pouvoir améliorer l’expérience utilisateur, mais aussi réagir rapidement à des incidents. 

Le monitoring DevOps s’appuie ainsi sur la collecte automatique de données (métriques système, logs, erreurs, latence, temps de réponse, taux de succès, etc.) et sur des outils capables de détecter, alerter et visualiser ces données (Prometheus, Grafana, Datadog, etc.).

Champ d’application du monitoring DevOps

Le monitoring DevOps (ou surveillance continue) est utile pour effectuer des tests en production dans lesquels sont reproduits des déploiements, en conditions réelles donc. Le but étant de pouvoir mesurer le comportement et les performances d’une application afin de les valider à l’issue du test.

Comme pour la supervision applicative, le monitoring DevOps recours à des méthodes d’évaluation similaires, pour mesurer la performance applicative et l’expérience utilisateur en situation réelle : le Continuous Profiling et le Real User Monitoring qui mesure l’expérience à partir du navigateur de l’utilisateur, de son appareil mobile ou de son ordinateur de bureau, par exemple.

Dans un pipeline de développement continu (Continuous Delivery), le monitoring DevOps va détecter les inconnues issues du comportement de l’application, les nouvelles anomalies ou tout autre évènement qui ne peut être prévu dans des environnements de pré-production.

En résumé le monitoring DevOps permet : 

On parle également de feedback loop et d’apprentissage continu.

Comparatif monitoring DevOps et supervision applicative

En comparaison avec la supervision applicative qui est plus fonctionnelle, orientée métier et niveau de service, le monitoring DevOps est plus technique, orienté infrastructure et agilité.

Les deux peuvent évidemment coexister, mais ils ne poursuivront pas tout à fait les mêmes objectifs.

L’observabilité vise à comprendre l’état d’un système. C’est une approche exploratoire distincte d’une surveillance prédéfinie, telles que le seraient la supervision technique et la supervision applicative.

En incluant une analyse comportementale du système observé, elle permet de comprendre si les services et les produits délivrés aux utilisateurs sont utilisés tels qu’ils ont été conçus initialement ou pas. Et ceci à travers les contextes d’usage, les réactions et les résultats produits.

L’observabilité tend à une vision globale de la surveillance des systèmes, afin de résoudre des problèmes complexes et prévoir les comportements futurs.

Les architectures modernes (distribuées et structurées en microservices) rendent les interactions systémiques difficiles à prévoir.

Dans ce contexte, l’observabilité aide à naviguer dans cette complexité et à investiguer ces architectures, là où la supervision se limitera à garantir que les performances restent sous contrôle.

Pour mener cette investigation et “poser des questions” non prévues initialement, l’observabilité s’appuie sur 3 types de données :

La capacité de l’observabilité à comprendre l’état interne d’un système repose notamment sur ces analyses et explorations de données.

L’observabilité déploie des capacités techniques avancées qui transforment l’approche traditionnelle de surveillance des systèmes complexes. A la condition bien sûr de pré-requis comme l’existence d’une approche DevOps mature au sein de l’entreprise, l’instrumentation des applications et infrastructures, et la formation des équipes.

La corrélation intelligente constitue le socle de cette évolution. Elle permet la liaison automatique entre logs, métriques et traces pour construire une vision unifiée des incidents. 

Cette corrélation s’appuie sur des algorithmes d’analyse comportementale utilisant le machine learning pour détecter les anomalies et les patterns d’évènement complexes.

Le traçage distribué permet aux développeurs de tracer les requêtes utilisateur au fur et à mesure qu’elles transitent à travers des infrastructures distribuées. Sont ainsi révélés des goulots d’étranglement parfois cachés entre microservices, des dépendances critiques, des erreurs ou bugs applicatifs, ou encore des problèmes de performance.

Aussi, c’est l’intégration du contexte métier qui va venir enrichir l’analyse technique et la quantification de l’impact des incidents sur les performances de l’application et plus loin, le performance économique.