Modèles d’observabilité

Conseil

Ce contenu est un extrait du livre électronique, Cloud Native .NET apps for Azure (Architecture d’applications .NET natives cloud pour Azure), disponible dans la documentation .NET ou au format PDF à télécharger gratuitement pour le lire hors connexion.

Télécharger le PDF

À l’instar des modèles qui ont été développés pour faciliter la présentation du code dans les applications, des modèles ont été développés pour faire fonctionner les applications de manière fiable. Trois modèles utiles pour maintenir les applications ont émergé : journalisation, surveillance et alertes.

Quand utiliser la journalisation

Que nous faisions attention ou non, les applications se comportent presque toujours de manière inattendue en production. Lorsque les utilisateurs signalent des problèmes avec une application, il est utile de pouvoir voir ce qui s’est passé dans l’application lorsque le problème s’est produit. L’un des moyens les plus sollicités et les plus concrets de capturer des informations sur ce qu’une application fait quand elle s’exécute consiste à lui faire écrire ce qu’elle fait. Ce processus est appelé journalisation. Chaque fois que des défaillances ou des problèmes arrivent en production, l’objectif doit être de reproduire les conditions dans lesquelles les défaillances sont survenues, dans un environnement de non-production. Une bonne journalisation en place fournit une feuille de route que suivent les développeurs pour dupliquer les problèmes dans un environnement qui peut être testé et expérimenté.

Difficultés lors de la journalisation avec des applications natives cloud

Dans les applications traditionnelles, les fichiers journaux sont généralement stockés sur l’ordinateur local. En fait, dans les systèmes d’exploitation comme Unix, une structure de dossiers est définie pour contenir tous les journaux, généralement sous /var/log.

Figure 7-1. Journalisation sur un fichier dans une application monolithique.

La journalisation sur un fichier plat sur un seul ordinateur perd largement de son utilité dans un environnement cloud. Les applications produisant des journaux peuvent ne pas avoir accès au disque local ou le disque local peut être extrêmement temporaire, car les conteneurs passent d’un ordinateur physique à un autre. Même un simple scale-up d’applications monolithiques sur plusieurs nœuds peut compliquer la localisation du fichier journal basé sur fichiers approprié.

Figure 7-2. Journalisation sur fichiers dans une application monolithique mise à l’échelle.

Les applications natives cloud développées avec une architecture de microservices présentent également des difficultés pour les journaliseurs basés sur fichiers. Les demandes utilisateur peuvent désormais s’étendre à plusieurs services exécutés sur différents ordinateurs et inclure des fonctions serverless sans accès à aucun système de fichiers local. Il serait très difficile de mettre en corrélation les journaux d’un utilisateur ou d’une session sur ces nombreux services et ordinateurs.

Figure 7-3. Journalisation sur des fichiers locaux dans une application de microservices.

Enfin, le nombre d’utilisateurs dans certaines applications natives cloud est élevé. Imaginez que chaque utilisateur génère une centaine de lignes de messages de journal lorsqu’il se connecte à une application. Dans un contexte d’isolement, c’est gérable, mais multiplié par plus de 100 000 utilisateurs et le volume des journaux devient suffisamment grand pour que des outils spécialisés deviennent nécessaires pour prendre en charge l’utilisation efficace des journaux.

Journalisation dans les applications natives cloud

Chaque langage de programmation dispose d’outils permettant d’écrire des journaux, et généralement la surcharge pour l’écriture de ces journaux est faible. La plupart des bibliothèques de journalisation fournissent différents types de journalisation de criticités, qui peuvent être réglées au moment de l’exécution. Par exemple, la bibliothèque Serilog est une bibliothèque de journalisation structurée connue pour .NET qui fournit les niveaux de journalisation suivants :

• Commentaires
• Débogage
• Information
• Avertissement
• Error
• Erreur irrécupérable

Ces différents niveaux de journal fournissent une précision dans la journalisation. Lorsque l’application fonctionne correctement en production, elle peut être configurée pour journaliser uniquement les messages importants. Lorsque l’application se comporte mal, le niveau de journal peut être augmenté afin que des journaux plus détaillés soient collectés. Cela crée un équilibre entre les performances et la facilité de débogage.

Les hautes performances des outils de journalisation et la possibilité de régler le niveau de détail doivent encourager les développeurs à journaliser fréquemment. Beaucoup favorisent un modèle de journalisation de l’entrée et de la sortie de chaque méthode. Cette approche peut sembler excessive, mais il est peu fréquent que les développeurs souhaitent moins de journalisation. En fait, il n’est pas rare d’effectuer des déploiements dans le seul but d’ajouter une journalisation autour d’une méthode problématique. Mieux vaut choisir trop de journalisation que pas assez. Certains outils peuvent être utilisés pour fournir automatiquement ce type de journalisation.

En raison des difficultés liées à l’utilisation de journaux basés sur fichiers dans les applications natives cloud, il est préférable d’utiliser des journaux centralisés. Les journaux sont collectés par les applications et envoyés à une application de journalisation centrale qui indexe et stocke les journaux. Cette classe de système peut ingérer des dizaines de gigaoctets de journaux tous les jours.

Il est également utile de suivre certaines pratiques standard lors de la création d’une journalisation qui englobe de nombreux services. Par exemple, la génération d’un ID de corrélation au début d’une longue interaction, puis la journalisation dans chaque message lié à cette interaction facilitent la recherche de tous les messages associés. Il suffit de trouver un seul message et d’extraire l’ID de corrélation pour trouver tous les messages associés. Un autre exemple consiste à s’assurer que le format du journal est le même pour chaque service, quels que soient le langage ou la bibliothèque de journalisation utilisés. Cette standardisation facilite beaucoup la lecture des journaux. La figure 7-4 montre comment une architecture de microservices peut tirer parti de la journalisation centralisée dans le cadre de son workflow.

Figure 7-4. Des journaux de sources diverses sont ingérés dans un magasin de journaux centralisé.

Difficultés avec la détection de problèmes potentiels d’intégrité des applications et leur résolution

Certaines applications ne sont pas critiques. Peut-être qu’elles sont juste utilisées en interne et que quand un problème se produit, l’utilisateur peut contacter l’équipe responsable et l’application peut être redémarrée. Toutefois, les clients ont souvent de plus grandes attentes pour les applications qu’ils consomment. Vous devez savoir quand des problèmes se produisent avec votre application avant les utilisateurs, ou avant que les utilisateurs ne vous en avertissent. Sinon, vous risquez de découvrir qu’il y a un problème lorsque vous verrez un déluge de posts de médias sociaux ridiculisant votre application ou même votre organisation.

Certains scénarios que vous devriez peut-être prendre en compte sont les suivants :

• Un service de votre application n’arrête pas de planter et de redémarrer, ce qui entraîne des réponses lentes intermittentes.
• À certains moments de la journée, le temps de réponse de votre application est lent.
• Après un déploiement récent, la charge sur la base de données a triplé.

Implémentée correctement, la surveillance peut vous informer des conditions qui aboutiront à des problèmes, ce qui vous permet de résoudre les conditions sous-jacentes avant qu’elles n’impactent les utilisateurs de manière significative.

Surveillance des applications natives cloud

Certains systèmes de journalisation centralisée endossent un rôle supplémentaire pour collecter la télémétrie en dehors des journaux purs. Ils peuvent collecter des métriques, telles que le temps d’exécution d’une requête de base de données, le temps de réponse moyen d’un serveur web, et même les moyennes de charge du processeur et la pression de la mémoire, comme l’indique le système d’exploitation. Conjointement avec les journaux, ces systèmes peuvent fournir une vue globale de l’intégrité des nœuds dans le système et de l’application dans son ensemble.

Les fonctionnalités de collecte des métriques des outils de surveillance peuvent également être alimentées manuellement à partir de l’application. Les flux d’activité qui ont un intérêt particulier, comme l’inscription de nouveaux utilisateurs ou la prise de commandes, peuvent être instrumentés de sorte qu’ils incrémentent un compteur dans le système de surveillance central. Cet aspect permet aux outils de surveillance de surveiller non seulement l’intégrité de l’application, mais aussi l’intégrité de l’activité.

Des requêtes peuvent être créées dans les outils d’agrégation de journaux pour rechercher certaines statistiques ou certains modèles, qui peuvent ensuite être affichés sous forme graphique, sur des tableaux de bord personnalisés. Fréquemment, les équipes investissent dans de grands écrans fixés au mur qui font défiler les statistiques liées à une application. De cette façon, il est simple de voir les problèmes quand ils se produisent.

Les outils de supervision natifs cloud fournissent la télémétrie en temps réel et des insights sur les applications, que ce soit des applications monolithiques monoprocessus ou des architectures de microservice distribuées. Ils comprennent des outils qui permettent la collecte de données à partir de l’application, ainsi que des outils qui permettent d’interroger et d’afficher des informations sur l’intégrité de l’application.

Difficultés avec la réaction aux problèmes critiques dans les applications natives cloud

Si vous avez besoin de réagir aux problèmes liés à votre application, vous avez besoin d’un moyen d’alerter le personnel approprié. Il s’agit du troisième modèle d’observabilité d’application native cloud et il dépend de la journalisation et de la surveillance. Votre application doit avoir une journalisation en place pour pouvoir diagnostiquer les problèmes et, dans certains cas, se servir des outils de surveillance. Elle a besoin de la surveillance pour agréger les métriques d’application et les données d’intégrité à un seul endroit. Une fois cette opération établie, des règles peuvent être créées qui déclenchent des alertes lorsque certaines métriques tombent en dehors des niveaux acceptables.

En règle générale, les alertes sont placées au-dessus de la surveillance afin que certaines conditions déclenchent les alertes appropriées pour avertir les membres de l’équipe des problèmes urgents. Voici quelques scénarios qui peuvent demander des alertes :

• L’un des services de votre application ne répond pas après 1 minute de temps d’arrêt.
• Votre application retourne des réponses HTTP infructueuses à plus de 1 % des requêtes.
• Le temps de réponse moyen de votre application pour les points de terminaison clés dépasse 2 000 ms.

Alertes dans les applications natives cloud

Vous pouvez créer des requêtes sur les outils de surveillance pour rechercher des conditions de défaillance connues. Par exemple, des requêtes peuvent rechercher dans les journaux entrants des indications du code d’état HTTP 500, qui signale un problème sur un serveur web. Dès qu’une de ces conditions est détectée, un e-mail ou un SMS peut être envoyé au propriétaire du service d’origine qui peut commencer à investiguer.

En règle générale, une seule erreur 500 n’est pas suffisante pour déterminer qu’un problème s’est produit. Cela peut signifier qu’un utilisateur a mal tapé son mot de passe ou entré certaines données mal formées. Des requêtes d’alerte peuvent être créées pour être déclenchées uniquement lorsqu’un nombre moyen de 500 erreurs est détecté.

L’un des modèles d’alerte les plus préjudiciables consiste à déclencher trop d’alertes pour que des humains enquêtent. Les propriétaires de services deviennent rapidement indifférents aux erreurs qu’ils ont déjà regardées et qu’ils ont jugées bénignes. Quand de vraies erreurs se produisent, elles sont perdues dans la masse de centaines de faux positifs. La fable de l’enfant qui criait au loup est fréquemment racontée aux enfants pour les avertir de ce danger. Il est important de s’assurer que les alertes qui se déclenchent indiquent un réel problème.

PrécédentSuivant