Stratégie d’observabilité : comment anticiper, diagnostiquer et optimiser vos systèmes IT

Pourquoi déployer une stratégie d’observabilité en entreprise ?
Dans un contexte marqué par le DevOps, les architectures en micro services et la migration vers le Cloud, l’observabilité informatique devient une brique incontournable de l’IT moderne.
Pour cause, les systèmes informatiques tendent de plus en plus vers des modèles distribués, dynamiques et complexes, où leur performance et leur niveau de disponibilité sont devenus critiques. La vision d’une infrastructure, de ses applications et de ses services doit être globale et en temps réel.
Une stratégie d’observabilité répond à ses enjeux. Elle vise à détecter des anomalies, anticiper des interruptions de services ou assurer la fiabilité des systèmes et applicatifs, dans des environnements hautement technologiques et évoluant rapidement.
L’observabilité est un processus d’optimisation continu permettant, entre autres, d’améliorer significativement l’expérience utilisateur (ou client) d’une application métier. Mais c’est aussi un levier d’innovation et donc un avantage compétitif accessible aux entreprises évoluant dans des secteurs fortement concurrentiels.
Toutefois, le lancement d’un projet d’observabilité nécessite des protocoles et des expertises solides pour garantir que les moyens déployés (matériels et humains) apportent des bénéfices mesurables à l’activité de l’entreprise.
Préparer le terrain en identifiant les besoins et les contraintes
La mise en œuvre d’une stratégie d’observabilité repose sur un cadrage clair des besoins, des objectifs et du contexte de l’entreprise. Cette étape doit permettre d’aligner les objectifs d’un projet d’observabilité avec les priorités métiers.
Identifier les besoins et spécificités de l’entreprise
L’observabilité devient pertinente dès lors qu’elle assure une couverture complète des enjeux métiers de l’organisation. Mais elle doit aussi prendre en compte une réalité technique, guidée par des choix technologiques et une infrastructure IT propres à chaque entreprise.
- Systèmes on-premise, hybrides ou full cloud
- Virtualisation ou conteneurisation (Docker, Kubernetes)
- Applications monolithiques ou microservices
Ainsi, une stratégie d’observabilité vise à questionner les composants d’un système informatique, ayant notamment un fort impact business. Elle doit être étroitement liée à la compréhension et l’analyse des applications métiers, aux indicateurs de performances et aux contraintes d’activité de l’entreprise.
Exemples :
Quels sont les services ou applications critiques, pour le fonctionnement de l’entreprise ? Quels sont les seuils d’acceptabilité en termes de temps de réponse, de taux d’erreur, de taux de disponibilité d’un service ou d’une API ?
Identifier les parties prenantes
La mise en place d’un projet d’observabilité va également impliquer de multiples équipes. Chaque métier ayant des besoins spécifiques (accès à des données sensibles, reporting et alertes personnalisées, visualisation de données avancée, etc.), l’intégration de toutes les parties prenantes dès la phase stratégique, aura une incidence sur l’adoption globale du projet.
C’est pourquoi la cartographie des équipes IT en charge des infrastructures, du DevOps, de la sécurité, ainsi que l’implication des responsables, des chefs de projet et des chefs de produits, est ici déterminante. Nous aborderons plus bas, quelques notions liées à la création d’une culture d’observabilité, au sein de l’entreprise.
Auditer l’existant et se conformer à la sécurité
Un état des lieux des outils informatiques déjà intégrés et du niveau d’expertise des équipes sera indispensable pour poser les bases d’une stratégie d’observabilité cohérente et évolutive.
- État sur la collecte de logs, métriques ou traces
- Outils de collecte, de traitement et de monitoring déjà en place
- Présence de silos de données entre équipes ou entre systèmes
- Niveau de maturité des équipes sur ces sujets
L’observabilité impliquant la collecte et le traitement de données sensibles, il faudra également considérer lors de l’audit différents aspects du volet “sécurité”. Il s’agira par exemple de vérifier que les données transitant au travers différentes applications (ou services) soient chiffrées et stockées de manière sécurisée. Les authentifications et accès devront être contrôlés et tracés. Plus globalement, le projet d’observabilité devra respecter le RGPD et les politiques internes en matière de sécurité et de gestion de données.
Aussi, pour évaluer la réussite d’un tel projet il peut être intéressant de l’adosser à une méthodologie visant à déterminer des objectifs et des indicateurs mesurables facilement. La méthodologie SMART (Spécifiques, Mesurables, Atteignables, Réalistes, Temporellement définis) en est une parmi d’autres. Exemples d’objectifs SMART :
- Centraliser 100 % des logs applicatifs dans un outil unique
- Améliorer le taux de disponibilité de X applications critiques de 99,90 % à 99,95 %, à horizon 6 mois
- Réduire le temps nécessaire à résoudre un incident (MTTR : Mean Time to Resolution) de 15 % à horizon 6 mois
Le choix des outils dans un projet d’observabilité
La réussite d’une stratégie d’observabilité repose également sur le choix d’outils pouvant répondre aux objectifs fixés, aux besoins métiers et aux contraintes budgétaires. Deux approches sont envisageables : les plateformes “tout-en-un” et les solutions spécifiques.
Plateformes ou outils dédiés ?
Des acteurs comme Splunk (partenaire d’adista), Grafana, Datadog ou New Relic proposent des solutions d’observabilité unifiée.
Elles centralisent très bien de hauts volumes de logs, de métriques et de traces sur une seule plateforme. Elles offrent une visualisation temps réel des données, une détection proactive des anomalies et une corrélation intelligente des données. En ce sens, elles peuvent convenir à des entreprises en recherche d’efficacité grâce à de l’alerting avancé par exemple, ou en recherche de simplicité grâce à des tableaux de bord intuitifs.
À l’opposé, une démarche plus modulaire consiste à combiner des outils dédiés comme :
- Prometheus : spécialisé dans la collecte de métriques.
- Loki : un système de gestion de log développé par Grafana fonctionnant comme Prometheus mais pour les logs (centralisation, indexation, consultation des journaux d’activités).
- Jaeger : spécialisée dans le traçage distribué.
- Tempo : un outil permettant de suivre le parcours complet d’une requête ou d’une transaction dans un système distribué, développé également par Grafana.
- Elasticsearch : solution particulièrement puissante pour ses fonctions de recherche et de visualisation en temps réel.
Cette approche convient pour des environnements complexes ou fortement hybrides. Elle permet en effet de répondre spécifiquement à un projet d’observabilité, avec une maîtrise des coûts plus ajustée par exemple.
Note : Elasticsearch proposant une approche de licencing pouvant être complexe à gérer, une alternative comme OpenSearch (un fork maintenu par la communauté et supervisé par Amazon), peut être envisagé.
Instrumentation et norme open source OpenTelemetry
Dans une stratégie d’observabilité basée sur des solutions spécifiques, il est également pertinent d’instrumenter les systèmes et les applications, et de se tourner vers des solutions compatibles avec la norme open source OpenTelemetry (dont l’un des principaux contributeurs est SignalFX, racheté en 2019 par Splunk).
En substance, l’instrumentation consiste à intégrer des agents ou des bibliothèques qui collectent les données nécessaires à l’observabilité, sur les applications, les conteneurs ou les infrastructures.
Ainsi, OpenTelemetry capture des informations spécifiques sur un environnement d’exécution, un framework, une application ou une infrastructure cloud, de façon agnostique et durable. Elle facilite donc l’instrumentation des applications, l’interopérabilité entre outils et ainsi la mise en œuvre d’une stratégie d’observabilité.
Autres critères de sélection à considérer
Dans un domaine aussi technique que l’observabilité, il faut pouvoir évaluer la compatibilité d’une solution avec l’infrastructure existante, avant de l’intégrer à sa stratégie.
Si par exemple les applications de l’infrastructure fonctionnent sur un modèle d’architecture distribuées (avec des solutions d’orchestration de conteneurs comme Kubernetes) ou bien sur un modèle d’architecture monolithique (à savoir sur des machines physiques ou virtuelles), les solutions retenues ne seront pas nécessairement les même.
La scalabilité des outils pour accompagner l’évolution d’un projet d’observabilité avec la croissance des infrastructures, est aussi à considérer. Les niveaux de sécurité et de conformité des solutions, également.
Aussi, les coûts d’exploitation des solutions (stockage, maintenance, licences) qui viendront s’ajouter aux coûts globaux de l’infrastructure, devront être évalués.
La collecte des données : le socle fondamental d’une stratégie d’observabilité
La réussite d’une stratégie d’observabilité informatique repose en très grande partie sur la collecte des données de télémétrie : logs, métriques et traces. Ces trois piliers de l’observabilité permettent de comprendre en profondeur l’état des systèmes.
Automatiser l’ingestion de données
Pour éviter le risque de confusion face au haut volume d’informations générées, il est nécessaire de mettre en place des agents ou des collecteurs de données.
Ces outils assurent une ingestion automatisée des logs et des métriques, et facilitent ainsi la détection d’anomalies. Une plateforme d’observabilité unifiée permet en l’occurrence d’agréger, de corréler et de visualiser les données produites au sein de l’infrastructure.
Structurer et hiérarchiser l’information
Toutes les données n’auront pas la même valeur en fonction des besoins et des analyses qui y seront liées.
Il convient donc de prioriser les données critiques, des données non critiques, essentielles à la compréhension globale du système.
Les logs de sécurité, les métriques de performance applicative ou les traces liées à l’exécution d’une fonction feront partie des données critiques. Cependant, parmis les données non critiques, d’autres informations essentielles doivent être capturées, comme par exemple :
- Les données de démarrage et d’arrêt des services, qui permettent de repérer des comportements anormaux ou une instabilité sous-jacente (logs indiquant le redémarrage fréquent d’un micro-service, déploiement non planifié)
- Les données liées aux quotas et à l’usage des ressources, essentielles pour optimiser l’allocation de ressources avant que la situation ne devienne critique (limites CPU ou mémoire atteintes dans un cluster)
- Les données de latence entre deux services, permettant de détecter des temps de réponse dégradés pouvant nuire à l’expérience utilisateur ou à la fluidité des traitements backend.
- Les données d’authentification comme les logs d’accès utilisateur permettant de suivre les habitudes d’usage, de détecter des accès hors horaires ou atypiques, et de créer des modèles comportementaux.
Ainsi, la structuration et la normalisation des données doit apporter une lecture claire et exploitable sur des points pertinents, afin de se concentrer ensuite sur les aspects les plus stratégiques d’un système, sans diluer les efforts.
Piloter l’observabilité avec intelligence
L’accumulation d’une quantité massive de données provenant de différentes sources peut générer du bruit et rendre difficile l’identification des véritables problèmes. De plus, les logs, métriques et traces en provenance de divers systèmes et plateformes, ajoutent de la complexité à la corrélation des événements.
Alertes et visualisation de données
Une contrainte fréquente en observabilité concerne le bruit de données lié à une surcharge excessive d’alertes, ainsi que la difficulté d’interprétation et de corrélation des évènements qui en résulte. La conséquence directe est alors l’émission de faux positifs répétés (une alerte déclenchée à tort, un incident n’existant pas réellement).
Elle implique une sur-mobilisation des parties prenantes et une dégradation de la réactivité des équipes à moyen termes. C’est ce que l’on pourrait appeler en observabilité, la fatigue d’alerte.
Pour pallier ces effets, la surveillance et la configuration d’alertes pertinentes est obligatoire. Elles doivent s’appuyer sur des seuils de déclenchement clairs et des indicateurs de performance avec une visée très opérationnelle, entre autres.
La mise en place de tableaux de bord partagés, proposant des visualisations de données avancées et temps réel, va aider à la visibilité et à la compréhension des interactions se produisant dans un système. Ce qui est particulièrement vrai avec des environnements complexes comme les microservices, les API ou les infrastructures cloud.
Modèles comportementaux et alerting prédictif
L’intégration de modèles comportementaux à la surveillance de données est une voie pour mettre en place de l’alerting prédictif, permettant ainsi d’aller plus loin dans l’élimination du bruit de données.
Grâce au machine learning, l’alerting prédictif rend possible des stratégies de détection proactive, du scoring d’anomalies, des alertes anticipées et de l’analyse de tendance.
On peut ainsi prévenir plus efficacement une baisse de vigilance au sein des équipes et éviter le risque d’ignorer un incident qui dégraderait le succès d’une stratégie d’observabilité.
Corrélation des données aux contextes métiers
Pour s’assurer qu’une stratégie d’observabilité produise de la valeur directement exploitable par l’entreprise, il faut nécessairement l’aligner avec les objectifs métiers.
Ici, c’est donc la corrélation de données contextuelles (comportement utilisateur, impact direct côté client) avec les données de télémétrie (logs, métriques, traces) qui permettra de tirer une analyse, un enseignement.
Ainsi, le configuration d’alertes contextualisées, capable de révéler des anomalies avérées et vérifiables dans un système, doit permettre de mesurer concrètement l’impact d’incidents techniques. Qu’ils concernent une typologie d’utilisateurs, l’usage qui est attendu d’une fonctionnalité applicative, le parcours d’évènements au sein de microservices ou l’identification de goulots d’étranglement potentiels.
Dans ce cadre, l’alerting prédictif offre un nouvel éclairage pour améliorer la fiabilité de différents éléments d’un système. En voici quelques exemples.
- Cluster de conteneurs : anticiper une saturation mémoire grâce à la détection d’une sur-consommation
- Application : assurer la disponibilité constante d’un portail client face à un trafic variable
- Microservice : identifier un goulot d’étranglement dans un service de paiement d’une architecture e-commerce
- Fonctionnalité : détecter une anomalie récurrente sur un module de recherche après chaque mise à jour
- Framework : surveiller les performances d’un framework frontend lors du rendu côté client
- Pipeline CI/CD : corréler des échecs de déploiement à des versions spécifiques d’un environnement de staging
- API Gateway : analyser le taux d’erreurs suite à une montée en charge des appels API dans une architecture distribuée
- Volumétrie de logs : repérer une anomalie dans le volume de logs générés par un service
- Timeout réseau entre deux services distribués : corréler une hausse du temps de réponse à une surcharge réseau, sur un réseau privé cloud
Créer une culture d’observabilité dans l’entreprise
L’observabilité nécessite un changement de mentalité au sein de l’organisation et l’instauration d’une culture à part entière autour des processus et outils clés. Pour fonctionner, elle doit rompre les barrières entre les équipes IT, à savoir le développement, l’opérationnel et les branches métiers.
Un axe de réussite est donc de faciliter l’adoption d’une stratégie d’observabilité auprès des membres de l’entreprise, dès sa conception. Il faut promouvoir en interne la montée en compétences, l’amélioration continue et la connaissance autour de l’observabilité pour que l’organisation dans son ensemble perçoive la valeur et les bénéfices potentiels.
La formation des équipes IT à l’utilisation des outils d’observabilité y sera stratégique : lecture des métriques, interprétation et gestion des alertes, exploitation des tableaux de bord, prise de décision, etc. C’est pourquoi les outils retenus doivent être simples d’utilisation, avec des interfaces conviviales, accessibles et adaptées à différents profils (techniques et non techniques).
Un modèle de services partagés peut aider à centraliser les outils, les méthodologies et les meilleures pratiques en matière d’observabilité. Cela permet une approche unifiée et cohérente à travers l’organisation, facilitant la collaboration inter-équipes.
Sur la même idée, un centre d’excellence sur l’observabilité avec un rôle visant à cartographier les processus et les outils, de la définition des standards au choix d’une librairie commune de solutions d’observabilité, peut accompagner la stratégie d’observabilité de l’entreprise dans sa recherche de performance et de résultats.