Du monitoring à l'observabilité

L’Observabilité est un terme actuellement très galvaudé par la presse spécialisée et aussi les éditeurs de solutions qui ont adopté ce terme comme mot clé à la mode, tout en créant une confusion avec le monitoring. Il est cependant important de considérer les deux domaines comme liés mais certainement très différents.

Par définition, l’observabilité est une propriété d’un Système d’Information (SI) tout comme son aptitude à l’extensibilité, à la sécurité, à la résilience, etc. Un système est observable quand sa conception ou son instrumentation le rend en capacité d’être mesuré et testé à tous les stades de son cycle de vie.

Il est important de comprendre que l’observabilité s’étend bien au-delà du concept de monitoring. C’est plus une démarche globale qui change sérieusement les concepts habituels du monitoring historiquement déployé. En effet, le monitoring historique avait plutôt une démarche de contrôle des ressources et parfois de services basiques très orientés système. L’observabilité va se concentrer sur la notion de service.

Le monitoring : chronique d’une mort annoncée ?

Le monitoring, supervision en français, est un ensemble de tests qui sont déroulés régulièrement afin de détecter des dysfonctionnements soit en évaluant l’état d’un composant ou en évaluant une métrique en fonction de seuils considérés comme critiques ou non. Ce monitoring existe maintenant depuis plus de 30 ans pour tenter d’évaluer l’ensemble des équipements d’infrastructure (Réseau avec les débuts du SNMP dans les années 1980, serveurs, etc.) et des services essentiels (réponse à un service IP, existence d’un processus, état de la mémoire, charge CPU, etc.).

Les outils répondant à ces besoins sont légion, et ils ont beaucoup évolué depuis ces dernières décennies. S’ils sont nombreux et qu’ils embarquent sans cesse de nouvelles fonctionnalités les différenciant, il n’en reste pas moins que leur implémentation repose sur le même principe de contrôle/test de chacun des constituants d’un système pour tenter d’identifier une défaillance. C’est donc à la charge des ingénieurs experts de chacun des systèmes d’élaborer une stratégie de monitoring la plus exhaustive possible pour tenter d’anticiper au mieux les dysfonctionnements probables de ce système. Mais il est souvent très difficile d’anticiper toutes les causes de défaillances d’un système et de l’ensemble des composants qui le constituent.

En effet, les solutions de monitoring ne savent pas détecter de façon autonome un comportement anormal selon des critères qui n’auraient pas été identifiés et déclarés. En d’autres termes, tout composant élémentaire d’un système qui ne serait pas testé est une panne potentielle qui ne sera pas détectée et qui pourrait avoir un impact sur une chaine de service.

L’évolution des infrastructures ces dernières années avec l’avènement de la virtualisation, du cloud public et/ou privé, les réseaux étendus vers des architectures de plus en plus dynamiques, définies par logiciel, remet sérieusement en cause le monitoring tel que nous avions l’habitude de le déployer. En effet, les architectures deviennent polymorphes voire éphémères ; Leur topologie et/ou le nombre de leurs composants varie en fonction du temps, l’ensemble piloté par des ordonnanceurs qui les adaptent en fonction d’événements extérieurs. Ce changement de paradigme a un impact majeur sur les outils de monitoring car comment tester les composants d’une architecture qui varient à la volée au fil du temps ?

La mise en œuvre du monitoring était en général une préoccupation des équipes de RUN, en charge de l’exploitation des infrastructures (applicatives, serveurs et réseau). Les équipes en charge du développement avaient historiquement une vision du monitoring s’arrêtant le plus souvent aux tests fonctionnels unitaires avant de lâcher leur code aux équipes de production. La démarche de monitoring n’était pas intégrée lors de la construction d’un projet et le monitoring était mis en œuvre au dernier moment par des équipes qui le plus souvent n’avaient pas toute l’expertise ni les moyens financiers pour identifier tous les composants et leur impact dans la chaine de service.

Le monitoring se réduisait le plus souvent à la consommation des ressources système et au contrôle de quelques services identifiés comme essentiels. L’augmentation de la complexité des infrastructures rend cette démarche de plus en plus compliquée et de plus, si la démarche vise l’exhaustivité des composants elle devient quasiment impossible même avec les nouveaux outils de gestion des configurations dynamiques et de service discovery. L’anticipation de l’ensemble des scénarii de pannes potentielles et leur mise sous vérification est trop lourd et ambitieux pour être réalisable.

Alors comment s’assurer du bon fonctionnement des services dont les enjeux business sont de plus en plus critiques, les métiers étant de plus en plus exigeants vis-à-vis de leur DSI ? C’est probablement une des raisons qui explique l’émergence de l’observabilité.

Observabilité : le début d’une nouvelle ère

Comme indiqué en introduction, l’observabilité est une propriété d’un SI tout comme son aptitude à l’extensibilité, à la sécurité, à la résilience, etc. La finalité de l’observabilité, tout comme le monitoring, est de s’assurer que le système fournit le service attendu en termes de disponibilité et de performance pour les utilisateurs. L’observabilité doit, lorsque le service est défaillant, aussi permettre de procéder à des investigations efficaces pour identifier la root-cause le plus rapidement possible, afin de le rétablir ; Le fameux MTTR (Mean Time To Restore) derrière lequel tout le monde court. Cette approche est orientée plutôt « service délivré » (L’Expérience Utilisateur – l’UX) et part du principe que plutôt qu’observer les infrastructures techniques, c’est en observant le service délivré que l’on peut rendre compte de sa disponibilité et de sa performance.

Le principe de l’observabilité est d’avoir accès à une grande quantité d’informations depuis l’ensemble des composants du SI permettant alors d’évaluer si le comportement est « normal », c’est-à-dire répondant aux exigences de service et sinon, au travers de ces informations, disposer des éléments contextuels permettant une investigation en temps réel afin d’en comprendre la cause.

Il est d’usage de déclarer que l’observabilité repose sur trois piliers : Les Logs, les Métriques et les Traces.

Les Logs

Les logs, diminutif de logging ou encore journaux d’événements existent depuis très longtemps. Nous les connaissons sous forme de fichiers texte classique, plus ou moins structurés, présentant de façon chronologique des événements qui interviennent sur un SI. Un logiciel ou un processus est à la source d’un fichier de log.

Bien souvent, pour comprendre un phénomène, il faut consulter plusieurs fichiers de logs dans une fourchette de temps commune. Le nombre de lignes dans un fichier de log est directement proportionnel à l’activité (nombre d’utilisateurs, nombre de transactions, etc.) et à un niveau de détail (granularité des actions appelé Sévérité) qui y sont consignées. Les logs ont d’abord été analysé à la main grâce à des fonctions comme ‘grep, sed ou awk’ bien connues des administrateurs système Unix/linux, permettant de rechercher des motifs avec des expressions régulières sur des fichiers volumineux.

L’analyse de ces fichiers se fait aussi à l’aide d’outils à intervalles réguliers pour générer des statistiques (connexions à un site web grâce à des outils comme Webalizer sur des fichiers de log du serveur Apache). Sur un fichier d’une telle nature, comme bien d’autres fichiers de logs, on peut y retrouver des informations très sensibles (Adresse IP, date/heure, Url, etc.). Ces fichiers sont utiles aussi pour la sécurité des systèmes.

Un serveur va générer beaucoup de fichiers de logs avec beaucoup de lignes dans chaque fichier et proportionnellement à son volume d’activité. Mais cela ne s’applique pas qu’à la partie système. Les middlewares, les bases de données et les applications elles-mêmes génèrent des logs. Une très grande quantité de données peut être générée sur l’ensemble d’un SI (plusieurs To de données par jour). N’oublions pas que les équipements réseau (switch, routeurs…), de sécurité (Firewall…), d’infrastructure (Load-Balancer, Proxy…) génèrent eux aussi des logs précieux. Cette grande quantité de données génère des coûts matériels et humains pour être exploités.

Afin d’être exploitables, il est important de mettre en place des outils spécialisés pour les collecter et de mettre en œuvre une véritable politique de gestions de logs en prenant soin de sélectionner les données utiles à collecter, à stocker avec leur durée de rétention, de garantir leur confidentialité, contrôler la qualité des informations collectées, parfois les enrichir pour les exploiter en les analysant. La contextualisation des informations de log collectées est la partie la plus sensible pour en obtenir une bonne exploitation.

Le système historique de log n’est pas optimal dans un contexte des SI de nos jours avec la complexité des architectures. Il est primordial de consolider ces logs tout en les sérialisant en un format standard (Json) qui structure l’information afin d’en faciliter le traitement dans un outil spécialisé qui embarquera des fonctions de filtrage et d’indexation pour permet des recherches efficaces.

Mais l’utilisation des logs ne se limite pas à procéder à des recherches post-incident. Le Machine-Learning peut être un bon compagnon pour automatiser la détection des anomalies. Des outils comme Elastic sont capables de modéliser automatiquement le comportement des données collectées et de détecter en temps réel des anomalies.

Les métriques

Les métriques sont des valeurs numériques indexées sur l’échelle du temps. Le monitoring en collecte depuis toujours (CPU, RAM Débit, volume, espace) et sont de deux natures : Les compteurs qui cumulent au fil du temps (ex. Nombre de paquets transmis) ou des indicateurs qui varient au fil du temps (ex. % CPU consommée).

Les métriques étaient la plupart du temps d’origine système, collectées par les outils traditionnels de monitoring mais dans le contexte d’observabilité, ces métriques deviennent d’origine applicatives. On y retrouve alors des volumes de transactions, des nombres d’erreurs, des temps de réponse entre des composants logiciels, sur des requêtes SQL, ou des requêtes API.

Des indicateurs de performance sur des actes métiers s’ajoutent à l’ensemble de ces métriques techniques comme un nombre de transactions, un nombre de commandes ou de paniers validés. Ces métriques sont des séries numériques chronologiques faciles à stocker pour des technologies de bigdata et sur lesquelles il est aisé d’introduire du Machine Learning afin de détecter des anomalies, des tendances et de générer du forecast. Sur de longues périodes de conservation, ces données peuvent être compressées en agrégats moins granulaires.

Les traces (distribuées)

Les architectures applicatives ont évolué vers des architectures distribuées sur des architectures de plus en plus complexes, souvent hybrides avec une partie hébergée dans le Cloud et une autre hébergée dans des datacenters.

Le traçage capture principalement les relations entre les services invoqués et la structure des échanges transitant via le système (traitement synchrone ou asynchrone, relations enfant ou élément résultant).

Les traces sont utiles pour représenter les cheminements de bout en bout des appels individuels et la décomposition des temps passés à chaque étape. Ces appels donnent un aperçu détaillé de la multitude des parcours clients via un système distribué. Cela donne la possibilité aux ingénieurs de comprendre ces parcours, de trouver les goulets d’étranglement et d’identifier les erreurs afin qu’elles puissent être corrigées et optimisées. Ces trois sources d’information sont à combiner et à doser dans leur granularité en fonction du contexte si on veut les exploiter efficacement.

L’observabilité en remplacement du monitoring ?

L’observabilité est parfois décrite comme un « monitoring 2.0 ». Donc, celle-ci va-t-elle remplacer le monitoring des ressources système et bas niveau ? Non, elle va l’englober car les ressources d’infrastructure système ou réseau ont toujours un intérêt d’être supervisées, pour comprendre des dysfonctionnements ou anticiper des dégradations. Mais c’est le système d’alerting et surtout l’origine de ces alertes qui change. Le focus est désormais mis sur les services plutôt que sur les composants du système d’information.

C’est bien là que réside le changement de paradigme. Le monitoring historique n’est pas mort, mais il va désormais alimenter le concept d’observabilité comme une source d’information parmi les autres. L’observabilité remet surtout en cause l’état d’esprit de la surveillance du SI en termes de niveau de service et finalement, le service fourni aux utilisateurs. Aujourd’hui, on parle de « Site Reliability Engineering », de SLI, SLO et de SLA.

Cette nouvelle démarche s’accompagne aussi souvent par la mesure de l’expérience utilisateur (UX), car c’est bien là l’objectif final. En effet, c’est l’UX qui est le juge de paix du service délivré. Que ce soit pour les utilisateurs internes ou externes à l’entreprise, l’enjeux est de fournir le bon niveau de service face aux exigences du business.

Pour implémenter le concept d’observabilité que ce soit sur une application ou plus globalement une chaine de service, il faut identifier l’ensemble des indicateurs permettant de rendre compte de son activité. Une méthode est proposée dans l’article « The First Four Things You Measure » (Instrumentation: The First Four Things You Measure - Honeycomb).

L'idée est de pouvoir identifier rapidement les composants qui sont affectés et/ou responsables de dégradations. La démarche va consister par identifier : Les événements externes déclencheurs (les demandes ou entrants) et les indicateurs liés : Nombre de requêtes par intervalle de temps, les requêtes servies, le type de réponse, le nombre d’erreurs, le temps mis pour commencer à répondre (réparti entre Ok et Erreur) et éventuellement le nombre de requêtes en cours de réponse et leur âge.

Cela va permettre déjà de qualifier la qualité des réponses en mode nominal et de constater des dégradations sur le service et de connaître sa situation en matière de qualité de service. Les appels de votre service (évènements sortants auquel le service fait appel) vers une base de données, un appel RPC ou à une API et les indicateurs liés : Nombre d’appels par intervalle de temps, le type de réponse (Ok ou Erreur), la durée d’attente des réponses (répartie entre Ok et Erreur), et là aussi éventuellement le nombre de requêtes en cours de réponse et leur âge pour factualiser le nombre d’appels en attente.

Ceci permet d’identifier si un problème se situe dans votre service ou dans une de ses dépendances. Cette notion de dépendance est valable quelle que soit la nature des services invoqués que se soient des appels à base de données, API, organisés ou une nébuleuse de micro-services. En agissant de façon itérative, on arrive ainsi à créer l’Observabilité d’une chaîne de service et pas seulement au niveau applicatif, mais sur toutes les couches de la chaine de service en passant par le réseau, la sécurité et le device ou poste utilisateur.

Bien entendu, l’état de l’art veut que des indicateurs métiers soient intégrés dans cette chaine d’Observabilité comme des indicateurs autour du panier et de la transformation en acte d’achat pour un site de e-commerce, une demande de devis ou une simulation tarifaire pour un assureur, …

Comme vous l’avez compris, cette démarche « Observabilité » génère de très grands volumes de données et donc requiert l’automatisation du traitement de ces données afin d’assister l’humain face à cette avalanche d’informations qu’il n’est plus en mesure d’interpréter.

Donc, c’est là que l’Intelligence Artificielle au travers essentiellement du Machine Learning prend toute sa valeur. On parle alors d’AIOps (Artificial Intelligence Operations Systems). L’AIOps a pour objectif de mieux identifier les dégradations de services, automatiser les tâches routinières de la production et lancer des actions de remédiation automatique.

Quelques définitions :

Le SRE (Site Reliability Engineering) est une nouvelle approche de l’exploitation informatique. Les ingénieurs SRE utilisent des logiciels (à vocation d’observabilité) pour gérer la production, résoudre les incidents et mettre en œuvre une politique d’amélioration continue de la performance avec une stratégie d’automatisation des tâches pour résoudre les problèmes et gérer l’ensemble des composantes d’une chaine de production. Ce concept d'ingénierie de la fiabilité des sites provient des ingénieurs de Google, et de Ben Treynor Sloss en particulier. La normalisation et l’automatisation sont deux des composantes importantes du modèle SRE. Le SRE permet de décider quelles nouvelles fonctions lancer et selon quel calendrier, sur la base de contrats de niveau de service qui définissent la fiabilité requise du système en fonction d'indicateurs de niveau de service (SLI) et d'objectifs de niveau de service (SLO).

Un SLI (Service Level Indicator) mesure des aspects spécifiques des niveaux de service fournis. Les SLI clés comprennent la latence des requêtes, la disponibilité, le taux d'erreur et le débit du système. Un SLO est basé sur la valeur ou la plage de valeurs visée pour un niveau de service déterminé par le SLI.

Un SLO (Service Level Objective) pour la fiabilité requise du système est alors fixé en fonction d'une période d'indisponibilité jugée acceptable. Cette période d'indisponibilité est appelée budget d'erreur. Il s'agit du seuil maximal admissible d'erreurs et d'interruptions. Un SLA (Service Level Agreement) est un contrat qui engage un prestataire à un client, sur la base de SLO et de pénalités en cas de non-respect.

Conclusion

Le monitoring était historiquement une affaire d’administrateurs système ou réseau avec une orientation très technique et bas niveau sur l’équipement ou les ressources.

L’Observabilité est orientée sur les services. Le focus est mis sur la performance et la disponibilité de chaque service sous-jacent composant le service délivré à l’utilisateur final.

L’Observabilité est donc un changement de paradigme profond du monitoring et représente un ensemble de moyens destinés à faciliter l’observation d’un système informatique.

L’Observabilité va avoir une vision dans le temps de l’évolution du comportement des composantes d’un système. Le but est de générer des éléments d’analyse à partir de sources de données brutes. L’objectif d’une « plateforme d’observabilité » sera donc d’organiser ces données pour les rendre exploitables via une centralisation et une normalisation pour rendre l’information accessible rapidement.

La démarche de Tenedis est de permettre l’implémentation de solutions adaptées au contexte de nos clients. Dans un prochain article, nous partagerons notre vision sur la démarche d’implémentation de l’Observabilité de bout en bout d’une chaine de service.