Recommandations pour l’instrumentation d’une application

S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :

Guide connexe : Recommandations pour la conception et la création d’un système de surveillance

Ce guide décrit les recommandations relatives à l’activation de l’observabilité de votre application à l’aide de l’instrumentation. Générez des données de télémétrie significatives qui peuvent être ingérées et intégrées à votre système de surveillance. En utilisant l’instrumentation, vous pouvez collecter des informations sans vous connecter à un serveur de production distant pour effectuer manuellement le suivi ou le débogage. Les données d’instrumentation incluent des métriques et des journaux que vous pouvez utiliser pour évaluer les performances, diagnostiquer les problèmes et prendre des décisions de charge de travail.

Stratégies de conception

Pour optimiser la télémétrie de votre charge de travail, instrumentez votre application pour générer les données suivantes :

• Les journaux sont des enregistrements horodatés d’événements discrets. Il existe trois formes de journaux : texte brut, structuré et binaire.

• Les journaux de suivi distribué vous permettent d’afficher le chemin d’une requête au fur et à mesure qu’elle transite par différents services et composants.

• Les métriques sont des valeurs numériques qui décrivent un aspect d’un système à un moment donné.

Utiliser les journaux structurés et le suivi

Utilisez la journalisation structurée pour intégrer facilement les journaux dans les plateformes de supervision et d’analyse. Instrumentez votre application afin que les niveaux de détail puissent être modifiés. La journalisation détaillée constante peut gaspiller des ressources de stockage, de sorte qu’elle doit être activée et désactivée si nécessaire pour la résolution des problèmes.

Les journaux de trace contiennent des données textuelles ou binaires créées à partir d’un événement de trace, si l’application utilise le suivi d’événements pour Windows (ETW). Les journaux système génèrent du contenu du journal de suivi à partir d’événements dans l’infrastructure, tels que le serveur web. Le contenu du journal textuel est conçu pour être lisible par les humains, mais vous devez vous assurer qu’il est écrit dans un format qu’un système automatisé peut également analyser.

Classez les journaux et utilisez des journaux distincts pour enregistrer la sortie de trace de chaque aspect opérationnel du système. Si vous catégorisez vos journaux, vous pouvez filtrer rapidement les messages de journal au lieu de traiter un seul fichier long. N’écrivez jamais d’informations qui ont des exigences de sécurité différentes, telles que les informations d’audit et le débogage des données, dans le même journal.

Capturer les métriques d’application

Les métriques, ou exemples, sont un nombre d’aspects ou de ressources dans le système à un moment spécifique, avec une ou plusieurs balises ou dimensions associées. Une seule instance d’une métrique n’est pas utile en isolation, les métriques doivent être capturées au fil du temps. Tenez compte des métriques que vous devez enregistrer et de la fréquence à laquelle vous devez procéder. Les données générées trop souvent peuvent imposer une charge importante sur le système, mais la capture de données peu fréquente peut vous amener à manquer les circonstances qui entraînent un événement significatif. La fréquence appropriée pour capturer des données peut varier d’une métrique à l’autre. Par exemple, l’utilisation du processeur sur un serveur peut varier considérablement de la seconde à la seconde, mais l’utilisation élevée devient un problème uniquement s’il est cohérent sur de nombreuses minutes.

Faciliter la corrélation entre les composants

Vous pouvez facilement surveiller des compteurs de performances individuels et au niveau du système, capturer des métriques pour les ressources et obtenir des informations de suivi d’application à partir de différents fichiers journaux. Certaines analyses nécessitent une corrélation des données pendant l’étape d’analyse et de diagnostic dans le pipeline de surveillance. Ces données peuvent prendre plusieurs formes et le processus d’analyse doit être fourni avec des données d’instrumentation suffisantes pour mapper ces différentes formes. Par exemple, au niveau de l’infrastructure d’application, un ID de thread peut identifier une tâche. Dans une application, le même travail peut être associé à l’ID utilisateur de l’utilisateur qui termine cette tâche.

Il est peu probable qu’il s’agit d’une carte 1:1 entre les threads et les requêtes utilisateur, car les opérations asynchrones peuvent réutiliser les mêmes threads pour plusieurs utilisateurs. Pour compliquer davantage les questions, une seule requête peut être corrélée à plusieurs threads au fur et à mesure qu’elle transite par le système. Si possible, associez chaque requête à un ID d’activité unique qui est propagé dans le système dans le contexte de la requête. (La technique utilisée pour générer et inclure des ID d’activité dans les informations de traçage dépend de la technologie utilisée pour la capture des données de suivi).

Toutes les données de surveillance doivent être horodatées de la même façon. Pour des raisons de cohérence, il est nécessaire d’enregistrer toutes les dates et heures en utilisant le temps universel coordonné.

Capturer les données pertinentes

Tenez compte des points suivants lorsque vous décidez des données d’instrumentation que vous devez collecter.

Données lisibles par l’homme

Assurez-vous que les informations capturées par les événements de trace sont à la fois lisibles par l’ordinateur et par l’homme. Adoptez des schémas bien définis pour ces informations afin d’implémenter le traitement automatisé des données de journal entre les systèmes et de fournir une cohérence pour les opérations et le personnel d’ingénierie lisant les journaux.

Incluez les informations environnementales suivantes dans vos données :

• Environnement de déploiement
• Ordinateur de traitement
• Détails du processus
• Pile des appels

Investir dans la traçabilité et la corrélation

Fournissez un contexte suffisant, tel qu’un ID d’activité associé à une instance spécifique d’une demande, afin que le développeur ou l’administrateur puisse déterminer la source de chaque requête.

Le contexte de données peut également inclure des informations utilisées pour mettre en corrélation une activité avec le travail de calcul effectué et les ressources utilisées. Ce travail peut traverser les limites du processus et de l’ordinateur.

Pour le contrôle, le contexte doit inclure directement ou indirectement une référence au client qui a provoqué la demande. Ce contexte fournit de précieuses informations sur l’état de l’application au moment de la capture des données de surveillance.

Capturer toutes les données pertinentes

Enregistrez toutes les requêtes et les emplacements ou régions où elles sont effectuées. Vous pouvez utiliser ces informations pour identifier les points d’accès spécifiques à l’emplacement. Elles peuvent également être utiles pour déterminer s’il convient de repartitionner une application ou les données qu’elle utilise.

Enregistrer et capturer les détails des exceptions avec soin. Les informations de débogage critiques sont souvent perdues en raison d’une mauvaise gestion des exceptions. Capturez tous les détails d’exception levées par l’application, y compris les exceptions internes ou d’autres informations contextuelles, telles que la pile des appels, si possible.

Rechercher la cohérence des données

Les données cohérentes peuvent vous aider à analyser les événements et à les mettre en corrélation avec les demandes utilisateur. Envisagez d’utiliser un package de journalisation complet et configurable pour collecter des informations. Les packages de journalisation peuvent vous aider à éviter la dépendance vis-à-vis des développeurs pour adopter votre approche, car ils implémentent différentes parties du système.

Collectez des données, telles que le volume d’entrée/sortie, le nombre de requêtes et la mémoire, le réseau et l’utilisation du processeur, à partir de compteurs de performances clés. Certains services d’infrastructure fournissent leurs propres compteurs de performances, tels que :

• Nombre de connexions à une base de données.
• Taux de transaction.
• Nombre de transactions qui réussissent ou échouent.

Les applications peuvent également définir leurs propres compteurs de performances.

Prendre en compte les dépendances externes

Journaliser tous les appels de service externe. Les appels externes peuvent être effectués pour :

• Systèmes de base de données.
• Services web.
• Autres services au niveau du système qui font partie de l’infrastructure.

Enregistrez des informations sur la durée de chaque appel et la réussite ou l’échec de l’appel. Si possible, capturer les informations sur toutes les nouvelles tentatives et les échecs pour toutes les erreurs temporaires se produisant.

Garantir la compatibilité du système de télémétrie

Dans de nombreux cas, les informations de l’instrumentation le sont sous la forme d’une série d’événements, puis transmises à un système de télémétrie distinct pour le traitement et l’analyse. Un système de télémétrie est généralement indépendant de toute application ou technologie spécifique.

Les systèmes de télémétrie utilisent des schémas définis pour analyser les informations. Le schéma spécifie un contrat qui définit les champs et types de données que le système de télémétrie peut ingérer. Généralisez le schéma pour permettre l’arrivée de données à partir de différentes plateformes et appareils. Un schéma commun doit inclure des champs pertinents pour tous les événements d’instrumentation, tels que :

• Nom de l’événement.
• Heure de l’événement.
• Adresse IP de l’expéditeur.
• Détails requis pour la corrélation d’événements, notamment :
  • ID d’utilisateur
  • ID de périphérique
  • ID de l’application

N’oubliez pas que de nombreux appareils peuvent déclencher des événements pour la même application, de sorte que le schéma ne doit pas dépendre du type d’appareil. L’application doit prendre en charge la distribution itinérante ou inter-appareils. Le schéma peut également inclure des champs de domaine pertinents pour un scénario particulier commun entre les applications, par exemple :

• Informations sur les exceptions.
• Événements de début et de fin de l’application.
• Réussite ou échec des appels d’API de service web.

Établissez des champs de domaine qui produisent le même ensemble d’événements pour générer un ensemble de rapports et d’analyses communs entre les applications. Vous devrez peut-être configurer un schéma pour contenir des champs personnalisés pour capturer les détails des événements spécifiques à l’application.

OpenTelemetry est une collection neutre par le fournisseur d’API, de sdk et d’autres outils. Vous pouvez utiliser OpenTelemetry pour instrumenter les applications et générer des données de télémétrie significatives de manière cohérente entre les langages. OpenTelemetry est indépendant des outils. Il est donc compatible avec de nombreuses plateformes d’observabilité, notamment les offres open source et commerciale. Microsoft adopte OpenTelemetry comme outil standard pour l’instrumentation.

Optimiser le code d’instrumentation

La liste suivante récapitule les meilleures pratiques pour l’instrumentation d’une application distribuée fonctionnelle dans le cloud :

• Faciliter la lecture et l’analyse des journaux d’activité. Utiliser une journalisation structurée dès que possible.

• Être concis et descriptif dans les messages de journal.

• Identifiez la source du journal.

• Ajoutez des informations d’horodatage à mesure que chaque enregistrement de journal est écrit.

• Utiliser les mêmes fuseau horaire et format pour tous les horodatages.

• Catégorisez les journaux et écrivez des messages à l’emplacement approprié.

• Ne révèlez pas d’informations sensibles sur le système ou les informations personnelles sur les utilisateurs. Nettoyez ces informations avant de les enregistrer, mais conservez les détails pertinents.

• Journaliser toutes les exceptions critiques, mais permettre à l’administrateur d’activer et de désactiver la journalisation si nécessaire pour moins d’exceptions et d’avertissements.

• Capturer et enregistrer toutes les informations de logique de nouvelle tentative. Ces données sont utiles pour surveiller l’intégrité temporaire du système.

• Suivre les appels hors processus, comme les requêtes vers des services web externes ou des bases de données.

• Ne pas associer des messages de journal ayant des exigences de sécurité différentes dans un même fichier journal.

• Vérifiez que tous les appels de journalisation sont des opérations fire-and-forget qui ne bloquent pas la progression des opérations métier. Excluez les événements d’audit de cette règle, car ils sont essentiels pour l’entreprise.

• Assurez-vous que la journalisation est extensible et n’a aucune dépendance directe sur une cible concrète.

• Assurez-vous que toutes les journaux de journalisation ne sont pas fiables et ne déclenchent pas d’erreurs en cascade.

• Traitez l’instrumentation comme un processus itératif continu et examinez régulièrement les journaux d’activité.

Utiliser le profilage d’application

• Implémentez le profilage uniquement si nécessaire, car il peut imposer une surcharge importante sur le système. En utilisant l’instrumentation, le profilage enregistre un événement, tel qu’un appel de méthode, chaque fois qu’il se produit. Toutefois, l’échantillonnage enregistre uniquement les événements sélectionnés.

• Les sélections de profilage peuvent être basées sur le temps, comme une fois toutes les n secondes, ou basées sur une fréquence, comme une fois par requête . Si des événements se produisent fréquemment, le profilage peut entraîner trop de charge sur le système et affecter les performances globales. Dans ce cas, l’approche d’échantillonnage est préférable. Toutefois, si les événements se produisent peu fréquemment, l’échantillonnage risque de les manquer. Dans ce cas, le profilage peut être la meilleure approche.

Facilitation Azure

L’autoinstrumentation est disponible pour de nombreux types d’applications Azure et locales surveillées avec Application Insights. La fonction d’autoinstrumentation configure automatiquement votre application pour fournir des données de télémétrie enrichies à Application Insights et permet d’accéder facilement à des expériences telles que le tableau de bord d’application et la carte d’application. Pour connaître les plateformes d’hébergement prises en charge et les langages de développement, consultez Environnements, langages et fournisseurs de ressources pris en charge.

Liens connexes

• Vue d’ensemble d’Application Insights
• Qu’est-ce que l’autoinstrumentation pour Application Insights ?
• Vue d’ensemble des journaux Azure Monitor
• Vue d’ensemble des métriques Azure Monitor
• Collecte d’événements ETW pour l’analyse des journaux Azure Monitor
• Recommandations pour la conception et la création d’un framework d’observabilité
• Qu’est-ce que le suivi distribué et la corrélation de télémétrie ?

Liens de la communauté

• OpenTelemetry

Liste de contrôle d’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.