Meilleures pratiques pour la surveillance et les diagnostics

Les applications et services distribués qui s’exécutent dans le cloud sont des éléments complexes de logiciels qui comprennent de nombreuses parties mobiles. Dans un environnement de production, il est important de suivre la façon dont les clients utilisent votre système, de suivre l’utilisation des ressources et de surveiller l’intégrité et les performances de votre système. Vous pouvez utiliser ces informations pour détecter et corriger les problèmes et détecter les problèmes potentiels avant qu’ils ne se produisent.

Scénarios de supervision et de diagnostic

Vous pouvez utiliser la supervision pour obtenir des informations sur le fonctionnement d’un système. La surveillance est un élément essentiel de la maintenance des objectifs de qualité de service (QoS). Collectez les données de surveillance pour les scénarios courants suivants :

• Assurez-vous que le système reste sain.

• Suivez la disponibilité du système et de ses composants.

• Conservez les performances pour vous assurer que le débit du système ne se dégrade pas de manière inattendue à mesure que le volume de travail augmente.

• Garantir que le système répond aux contrats de niveau de service (SLA).

• Protégez la confidentialité et la sécurité du système, des utilisateurs et de leurs données.

• Effectuez le suivi des opérations d’audit ou de réglementation.

• Surveillez l’utilisation quotidienne du système et résolvez les tendances susceptibles d’entraîner des problèmes.

• Suivez les problèmes qui se produisent, du rapport initial à l’analyse des causes possibles, de la correction, des mises à jour logicielles et du déploiement.

• Assurez le suivi des opérations et déboguez les versions logicielles.

Les sections suivantes décrivent ces scénarios plus en détail.

Surveillance de la santé

Un système sain s’exécute et peut traiter les demandes. Utilisez la surveillance de l’état de santé pour générer un instantané de l’état de santé actuel du système afin de pouvoir vérifier que tous les composants fonctionnent comme prévu.

Configurer des alertes

Le système doit déclencher une alerte en quelques secondes si une partie n’est pas saine. Les alertes peuvent indiquer l’état du système au moyen d’indicateurs de type feu tricolore :

• Rouge pour un état défectueux (le système s’est arrêté)
• Jaune pour un état partiellement opérationnel (le système fonctionne avec des fonctionnalités réduites)
• Vert pour la santé

Un système complet de surveillance de l’intégrité vous indique l’état d’intégrité de chaque sous-système et composant afin de pouvoir déterminer les parties qui fonctionnent normalement et quelles parties rencontrent des problèmes.

Collecter des données de santé

Les sources suivantes peuvent générer les données brutes nécessaires à la surveillance de l’état :

• Tracez l’exécution des demandes utilisateur. Vous pouvez utiliser ces informations pour déterminer les requêtes qui réussissent ou échouent et mesurer le temps nécessaire à chaque requête.

• Surveillez les utilisateurs synthétiques. Ce processus simule les actions effectuées par un utilisateur et suit une série prédéfinie d’étapes. Capturez les résultats de chaque étape.

• Consignez les exceptions, les erreurs et les avertissements. Vous pouvez capturer ces informations à partir d’instructions de trace incorporées dans le code de l’application et à partir des journaux d’événements des services référencés par le système.

• Surveillez l’état des services non Microsoft utilisés par le système. Vous devrez peut-être récupérer et traiter les données de santé fournies par ces services.

• Surveiller les points de terminaison.

• Collectez les informations de performances ambiantes, telles que l’utilisation du processeur en arrière-plan ou les opérations d’entrée/sortie (E/S), y compris l’activité réseau.

Analyser les données de santé

L’objectif principal de la surveillance de l'état de santé est d’indiquer rapidement si le système fonctionne. L’analyse à chaud des données immédiates peut déclencher une alerte si un composant critique n’est pas sain.

Un système plus avancé peut inclure un élément prédictif qui effectue une analyse à froid sur les charges de travail récentes et actuelles. Une analyse à froid peut identifier les tendances et déterminer si le système est susceptible de rester sain ou a besoin de ressources supplémentaires. Basez cet élément prédictif sur les métriques de performances critiques suivantes :

• Taux de requêtes dirigées vers chaque service ou sous-système
• Temps de réponse de ces demandes
• Volume de données entrantes et sortantes de chaque service

Si la valeur d’une métrique dépasse un seuil défini, le système peut déclencher une alerte pour effectuer un scale-up. Vous pouvez également ajouter des ressources, redémarrer des services défaillants ou limiter les demandes de priorité inférieure pour maintenir l’intégrité du système.

Surveillance de la disponibilité

Dans un système sain, tous les composants et sous-systèmes sont disponibles. La surveillance de la disponibilité est étroitement liée à la surveillance de l'état. La surveillance de l’état offre une vue immédiate de l’état actuel du système. La surveillance de la disponibilité suit la disponibilité du système et de ses composants pour générer des statistiques sur le temps d’activité.

Dans de nombreux systèmes, certains composants, tels que les bases de données, sont configurés avec une redondance intégrée pour permettre un basculement rapide si une panne ou une perte de connectivité grave se produit. Rassemblez autant d’informations que possible sur ces défaillances afin d’en déterminer la cause et de prendre des mesures correctives pour éviter qu’elles ne se reproduisent.

Les données requises pour suivre la disponibilité peuvent dépendre de plusieurs facteurs de niveau inférieur qui peuvent être spécifiques à l’application, au système et à l’environnement. Un système de surveillance efficace capture les données de disponibilité qui correspondent à ces facteurs de bas niveau, puis les agrège pour fournir une image globale du système. Par exemple, dans un système de commerce électronique, la fonctionnalité métier qui permet à un client de passer des commandes peut dépendre du référentiel qui stocke les détails de la commande et du système de paiement qui gère les transactions monétaires. La disponibilité de la fonctionnalité de placement de commande dépend de la disponibilité du référentiel et du sous-système de paiement.

La solution de supervision de la disponibilité fournit des vues actuelles et historiques de l’état de disponibilité de chaque sous-système. Il vous avertit rapidement quand un ou plusieurs services échouent ou lorsque les utilisateurs ne peuvent pas se connecter aux services. Utilisez ces informations pour identifier les tendances susceptibles de provoquer l’échec des sous-systèmes. Par exemple, vous pouvez utiliser des données de disponibilité pour détecter les services qui échouent pendant les heures de traitement maximales.

Collecter des données de disponibilité

Surveillez les utilisateurs synthétiques, consignez les exceptions, les défaillances et les avertissements, et surveillez les points de terminaison pour générer les données brutes nécessaires à la surveillance de la disponibilité. L’application peut exposer un ou plusieurs points de terminaison de santé, chacun testant l’accès à une zone fonctionnelle du système. Le système de surveillance suit une planification définie pour effectuer un test ping sur chaque point de terminaison et collecter les résultats, tels que la réussite ou l’échec.

Enregistrez tous les délais d’expiration, les échecs de connectivité réseau et les nouvelles tentatives de connexion, et horodatagez toutes les données.

Analyser les données de disponibilité

Agréger et mettre en corrélation les données pour prendre en charge les types d’analyse suivants :

• Disponibilité immédiate du système et des sous-systèmes.

• Taux de défaillance de disponibilité du système et de ses sous-systèmes. Mettre en corrélation les défaillances avec des activités spécifiques pour comprendre les causes de l’échec du système.

• Vue historique des taux d’échecs sur une période spécifiée et la charge sur le système, telles que le nombre de demandes utilisateur, lorsqu’une défaillance se produit.

• Raisons de l’indisponibilité du système ou des sous-systèmes. Ces raisons incluent le service qui n’est pas en cours d’exécution, la perte de connectivité, les délais d’expiration ou les réponses de code d’erreur.

Vous pouvez calculer le pourcentage de disponibilité d’un service sur une période donnée à l’aide de la formule suivante :

%Availability =  ((Total Time – Total Downtime) / Total Time ) * 100

Utilisez cette formule pour le suivi des SLA. La définition du temps d’arrêt dépend du service. Par exemple, le service de génération Azure DevOps définit le temps d’arrêt comme période, en minutes cumulées totales, pendant lesquelles le service de build n’est pas disponible. Le service est considéré comme indisponible pendant une minute si toutes les requêtes HTTP continues pendant cette minute entraînent un code d’erreur ou ne retournent pas de réponse.

analyse des performances.

À mesure que le volume d’utilisateurs augmente, la taille des jeux de données auxquels les utilisateurs accèdent augmente et la possibilité de défaillance d’un ou plusieurs composants devient plus probable. La dégradation des performances se produit souvent avant l’échec du composant. Si vous pouvez détecter la dégradation, vous pouvez prendre des mesures proactives pour éviter les défaillances.

Les performances du système dépendent de plusieurs facteurs. Vous mesurez généralement chaque facteur par le biais d’indicateurs de performance clés (KPI), tels que le nombre de transactions de base de données par seconde ou le volume de requêtes réseau correctement serviceées dans un délai spécifié. Certains de ces indicateurs de performance clés peuvent être disponibles en tant que mesures de performances spécifiques, tandis que d’autres indicateurs de performance clés peuvent être dérivés d’une combinaison de métriques.

Conditions requises pour l’analyse des performances

Pour évaluer les performances du système, vous avez généralement besoin des informations suivantes :

• Taux de réponse pour les demandes utilisateur
• Nombre de demandes utilisateur simultanées
• Volume du trafic réseau
• Taux auxquels le système termine les transactions commerciales
• Temps de traitement moyen pour les demandes

Utilisez des outils qui peuvent vous aider à identifier les corrélations suivantes :

• Nombre d’utilisateurs simultanés par rapport aux temps de latence des requêtes, ou combien de temps il faut pour démarrer le traitement d’une demande après l’envoi de l’utilisateur

• Nombre d’utilisateurs simultanés par rapport au temps de réponse moyen, ou combien de temps il faut pour effectuer une demande après le traitement

• Volume de requêtes par rapport au nombre d’erreurs de traitement

En plus de ces informations fonctionnelles de haut niveau, obtenez une vue détaillée des performances de chaque composant du système. Les compteurs de performances de bas niveau fournissent généralement ces données. Ils suivent les informations suivantes :

• Utilisation de la mémoire
• Nombre de threads
• Temps de traitement du processeur
• Longueur de la file d’attente de requête
• Taux et erreurs d’E/S de disque ou réseau
• Nombre d’octets écrits ou lus
• Indicateurs d’intergiciel, tels que la longueur de la file d’attente

Toutes les visualisations doivent vous permettre de spécifier une période. Les données affichées peuvent être un instantané de la situation actuelle ou une vue historique des performances. Le système doit déclencher des alertes en fonction de toute mesure de performances pour toute valeur spécifiée pendant tout intervalle de temps spécifié.

Collecter des données de performances

Rassemblez des données de performances élevées, telles que le débit, le nombre d’utilisateurs simultanés, le nombre de transactions commerciales et les taux d’erreur, en surveillant la progression des demandes des utilisateurs. Incorporer des instructions de suivi et des informations de minutage à des points clés dans le code de l’application. Capturez toutes les erreurs, exceptions et avertissements avec des données suffisantes et mettez-les en corrélation avec les demandes qui les ont provoquées.

Si possible, capturez les données de performances pour tous les systèmes externes utilisés par l’application. Ces systèmes externes peuvent fournir leurs propres compteurs de performances ou d’autres fonctionnalités pour demander des données de performances. Si cette méthode n’est pas possible, enregistrez des informations telles que l’heure de début et l’heure de fin de chaque requête à un système externe et l’état de réussite, d’échec ou d’avertissement de l’opération.

Les données de performances de bas niveau pour les composants individuels d’un système peuvent être disponibles via des fonctionnalités et des services tels que Windows compteurs de performances collectés par l’agent Azure Monitor.

Analyser les données de performances

La plupart des analyses agrègent les données de performances par type de demande utilisateur ou par le sous-système ou le service auquel chaque requête est envoyée. Un exemple de demande d’utilisateur consiste à ajouter un élément à un panier d’achat ou au processus de paiement dans un système de commerce électronique.

Une autre exigence courante consiste à synthétiser les données de performances en centiles. Par exemple, vous pouvez déterminer les temps de réponse pour 99% de requêtes, 95% de demandes et 70% de demandes. Vous pouvez définir des objectifs de SLA ou d’autres objectifs pour chaque percentile. Signaler des résultats en cours en quasi-temps réel pour aider à détecter immédiatement les problèmes. Agréger les résultats au fil du temps à des fins statistiques.

Les problèmes de latence peuvent également affecter les performances. Pour identifier rapidement la cause des goulots d’étranglement, évaluez la latence de chaque étape effectuée par chaque requête. Les données de performances doivent fournir un moyen de mettre en corrélation les métriques de performances pour chaque étape afin de les associer à une requête spécifique.

Selon vos besoins en matière de visualisation, il peut être utile de générer et de stocker un cube de données qui contient des vues des données brutes. Ce cube de données peut autoriser les requêtes complexes, non planifiées et l’analyse des informations de performances.

Surveillance de la sécurité

Tous les systèmes commerciaux qui incluent des données sensibles doivent implémenter une structure de sécurité. La sensibilité des données détermine généralement la complexité du mécanisme de sécurité. Dans un système qui exige que les utilisateurs soient authentifiés, enregistrez les informations suivantes :

• Toutes les tentatives de connexion et qu’elles échouent ou réussissent

• Toutes les opérations effectuées par un utilisateur authentifié et les détails de toutes les ressources auxquelles ils accèdent

• Lorsqu’un utilisateur termine une session et se déconnecte

La surveillance peut aider à détecter les attaques sur le système. Par exemple, plusieurs tentatives de connexion ayant échoué peuvent indiquer une attaque par force brute. Une augmentation inattendue des requêtes peut être le résultat d’une attaque DDoS. Préparez-vous à surveiller toutes les demandes adressées à toutes les ressources, quelle que soit leur source. Un système qui a une vulnérabilité de connexion peut exposer accidentellement des ressources sans demander à un utilisateur de se connecter.

Conditions requises pour la surveillance de la sécurité

Les données que la surveillance de sécurité recueille peuvent vous aider à :

• Détecter les tentatives d’intrusion par une entité non authentifiée.

• Identifiez les tentatives effectuées par les entités pour effectuer des opérations sur les données auxquelles elles n’ont pas accès.

• Déterminez si un utilisateur non authentifié ou un utilisateur authentifié malveillant tente d’attaquer le système.

Pour prendre en charge ces tâches, le système doit envoyer des alertes si :

• Un compte effectue des tentatives de connexion ayant échoué répétées au cours d’une période spécifiée.

• Un compte authentifié tente à plusieurs reprises d’accéder à une ressource interdite pendant une période spécifiée.

• Un grand nombre de requêtes non authentifiées ou non autorisées se produisent pendant une période spécifiée.

Configurez des alertes pour inclure l’adresse hôte de la source pour chaque requête. Si des violations de sécurité se produisent régulièrement à partir d’une plage d’adresses spécifique, vous pouvez bloquer ces hôtes.

Une partie clé de la maintenance de la sécurité d’un système est la possibilité de détecter rapidement les actions qui s’écartent du modèle habituel. Vous pouvez afficher des informations telles que le nombre de demandes de connexion ayant échoué ou réussies visuellement pour vous aider à détecter les pics d’activité à des moments inhabituels. Vous pouvez également utiliser ces informations pour configurer la mise à l’échelle automatique basée sur le temps. Par exemple, si de nombreux utilisateurs se connectent régulièrement à un moment spécifique, vous pouvez démarrer des services d’authentification supplémentaires pour gérer le volume de travail. Arrêtez ces services une fois le pic passé.

Collecter des données de sécurité

La sécurité est un aspect englobant de la plupart des systèmes distribués et la surveillance génère des données pertinentes à plusieurs points dans tout le système. Adoptez une approche SIEM (Security Information and Event Management) pour collecter des informations résultant des événements déclenchés par l’application, l’équipement réseau, les serveurs, les pare-feu, les logiciels antivirus et d’autres éléments de prévention des intrusions.

La surveillance de la sécurité peut incorporer des données à partir d’outils en dehors de votre application. Ces outils incluent des utilitaires qui identifient les activités d’analyse des ports par des agences externes et des filtres réseau qui détectent les tentatives d’accès non authentifié à votre application et à vos données. Dans certains cas, les outils de déploiement CI/CD (Intégration continue et livraison continue) constituent une partie importante du cycle de vie de l’application. Ces outils doivent également marquer un comportement anormal.

Analyser les données de sécurité

Une fonctionnalité clé de la surveillance de la sécurité est qu’elle collecte des données à partir de nombreuses sources. Les différents formats et niveaux de détail nécessitent souvent une analyse complexe pour compiler les données dans un thread cohérent d’informations. Vous pouvez détecter les échecs de connexion ou les tentatives répétées d’accès non autorisé aux ressources, mais le traitement automatisé complexe des données de sécurité peut ne pas être réalisable. Dans ce scénario, vous devez horodatager les données et les écrire dans un référentiel sécurisé sous sa forme d’origine pour l’analyse manuelle d’experts.

Surveillance du SLA

Les systèmes commerciaux qui prennent en charge le paiement des clients prennent des engagements sur les performances du système sous la forme de contrats SLA. Les contrats SLA indiquent que le système peut gérer un volume de travail défini dans un délai convenu et sans perdre les informations critiques. Le suivi des SLA garantit que le système respecte des SLA mesurables.

Les métriques suivantes définissent les contrats SLA :

• Disponibilité globale du système. Par exemple, une organisation peut s'engager à ce que le système soit disponible 99,9% du temps. Ce pourcentage équivaut à pas plus de neuf heures de temps d’arrêt par an, soit environ 10 minutes par semaine.

• Débit opérationnel. Cet aspect est souvent exprimé par un ou plusieurs seuils de capacité, par exemple sous la forme d’un engagement selon lequel le système peut prendre en charge jusqu’à 100 000 demandes simultanées d’utilisateurs ou gérer 10 000 transactions métier simultanées.

• Temps de réponse opérationnel. Le système peut également avoir besoin de traiter les demandes à un débit défini. Par exemple, 99% de toutes les transactions commerciales doivent se terminer dans les 2 secondes, et aucune transaction unique ne prend plus de 10 secondes.

Conditions requises pour la surveillance du contrat SLA

Vous devez être en mesure de déterminer rapidement si le système répond à un contrat SLA. S’il ne respecte pas le SLA, vous devez évaluer les facteurs sous-jacents afin d’identifier la cause des performances insuffisantes.

Vous pouvez représenter visuellement les indicateurs de haut niveau suivants :

• Le pourcentage de disponibilité du service

• Débit de l’application, mesuré en termes de transactions ou d’opérations réussies par seconde

• Nombre de demandes d’application réussies ou défaillantes

• Nombre d’erreurs d’application et système, d’exceptions et d’avertissements

Vérifiez que vous pouvez filtrer tous ces indicateurs en fonction d’une période spécifiée.

Votre application cloud comprend probablement plusieurs sous-systèmes et composants. Vous devez être en mesure de sélectionner un indicateur de haut niveau, comme le temps de fonctionnement global du système, et déterminer quels éléments sous-jacents affectent son état d’intégrité.

À des fins d’alerte, le système doit déclencher un événement si l’un des indicateurs de haut niveau dépasse un seuil spécifié. Rendre les détails de niveau inférieur disponibles pour le système d’alerte en tant que données contextuelles.

Collecter des données SLA

Effectuez les actions suivantes pour capturer les données brutes requises pour la surveillance du contrat SLA :

• Effectuez une surveillance des points de terminaison.
• Consignez les exceptions, les erreurs et les avertissements.
• Tracez l’exécution des demandes utilisateur.
• Surveillez la disponibilité des non-services Microsoft que le système utilise.
• Utilisez des métriques et des compteurs de performances.

Toutes les données doivent être chronométrées et horodatées.

Analyser les données du contrat SLA

Agréger les données sla pour générer une image des performances globales du système. Vous devez également être en mesure d’explorer les données agrégées pour évaluer les sous-systèmes sous-jacents. Par exemple, vous devez être en mesure d’effectuer les tâches suivantes :

• Calculez le nombre total de requêtes utilisateur pendant une période spécifiée et déterminez le taux de réussite et d’échec de ces demandes.

• Combinez les temps de réponse des demandes utilisateur pour générer une vue globale des temps de réponse système.

• Analysez la progression des demandes utilisateur pour décomposer le temps de réponse global dans les temps de réponse des éléments de travail individuels dans la demande.

• Déterminez la disponibilité globale du système sous la forme d’un pourcentage de temps d’activité pendant une période spécifique.

• Analysez le pourcentage de disponibilité des composants et services individuels dans le système. Vous devrez peut-être analyser les journaux d'activité générés par des services autres que Microsoft.

Les systèmes commerciaux doivent communiquer des données de performance réelles au regard des SLA sur une période spécifiée. Vous pouvez utiliser ces informations pour calculer des crédits ou d’autres formes de remboursements pour les clients si vous ne répondez pas aux contrats SLA pendant cette période. Vous pouvez calculer la disponibilité d’un service à l’aide de la technique décrite dans Analyser les données de disponibilité.

À des fins internes, une organisation peut également suivre le nombre et la nature des incidents qui provoquent l’échec des services. Découvrez comment résoudre ces problèmes rapidement ou les éliminer afin de réduire les temps d’arrêt et de répondre aux contrats SLA.

Auditing

En fonction de la nature de l’application, les réglementations légales peuvent spécifier des exigences pour l’audit des opérations des utilisateurs et l’enregistrement de tous les accès aux données. L’audit peut fournir des preuves qui relient les clients à des demandes spécifiques. La non-répudiation est un facteur important dans les systèmes d’entreprise électroniques pour aider à maintenir la confiance entre un client et l’organisation responsable de l’application ou du service.

Conditions requises pour l’audit

Vous devez être en mesure de suivre la séquence d’opérations métier effectuées par les utilisateurs afin de pouvoir reconstruire les actions des utilisateurs. Ce dossier peut être nécessaire à des fins de documentation ou dans le cadre d’une enquête judiciaire.

Les informations d’audit sont très sensibles. Il inclut probablement des données qui identifient les utilisateurs système et les tâches qu’ils effectuent. Pour cette raison, les informations d’audit sont probablement disponibles uniquement pour les analystes approuvés, plutôt que dans le cadre d’un système interactif. L’analyste génère une plage de rapports comme les exemples suivants :

• Rapports qui répertorient toutes les activités des utilisateurs pendant une période spécifiée

• Rapports qui détaillent la chronologie de l’activité pour un seul utilisateur

• Rapports qui répertorient la séquence d’opérations effectuées sur une ou plusieurs ressources

Collecter des données d’audit

Les principales sources d’informations pour l’audit sont les suivantes :

• Système de sécurité qui gère l’authentification utilisateur.
• Des journaux de trace qui enregistrent l’activité des utilisateurs.
• Journaux de sécurité qui effectuent le suivi de toutes les demandes réseau identifiables et non identifiables.

Les exigences réglementaires peuvent déterminer le format des données d’audit et la façon dont vous les stockez. Si les réglementations vous obligent à enregistrer les données dans son format d’origine, il se peut que vous ne puissiez pas nettoyer les données. Par conséquent, l’accès au référentiel qui le stocke doit être étroitement protégé pour empêcher la falsification.

Analyser les données d’audit

Vous devez pouvoir accéder aux données brutes dans son intégralité et dans sa forme d’origine. Outre la nécessité de générer des rapports d’audit courants, les outils d’analyse de ces données sont probablement spécialisés et conservés en externe au système.

Surveillance de l’utilisation

La surveillance de l’utilisation suit la façon dont les clients utilisent les fonctionnalités et les composants d’une application. Vous pouvez utiliser les données pour :

• Identifiez les fonctionnalités populaires et les points d’accès potentiels dans le système. Les éléments à trafic élevé peuvent tirer parti du partitionnement fonctionnel ou de la réplication pour répartir la charge plus uniformément. Vous pouvez également utiliser ces informations pour déterminer quelles fonctionnalités sont rarement utilisées et sont des candidats possibles à la mise hors service ou au remplacement dans une version ultérieure du système.

• Obtenez des informations sur les événements opérationnels du système en cours d’utilisation normale. Par exemple, dans un site de commerce électronique, vous pouvez enregistrer des informations statistiques sur le nombre de transactions et le volume de clients responsables d’eux. Vous pouvez utiliser ces informations pour la planification de la capacité à mesure que le nombre de clients augmente.

• Détectez la satisfaction des utilisateurs avec les performances et les fonctionnalités du système. Par exemple, si de nombreux clients d’un système de commerce électronique abandonnent régulièrement leurs paniers d’achat, il peut y avoir un problème avec la fonctionnalité de paiement.

• Générez des informations de facturation. Une application commerciale ou un service multilocataire peut facturer aux clients les ressources qu’ils utilisent.

• Appliquer des quotas. Si un utilisateur d’un système mutualisé dépasse le quota souscrit de temps de traitement ou d’utilisation des ressources au cours d’une période donnée, vous pouvez restreindre son accès ou brider le traitement.

• Détecter les problèmes de voisin bruyant. Pour faciliter l’examen des erreurs ou les décisions de produit, déterminez si le trafic est réparti uniformément ou si un petit ensemble d’utilisateurs génère la plupart du trafic. Si un seul utilisateur génère un trafic significatif, la fonctionnalité peut avoir besoin d’un réglage des performances. Vous pouvez également décider d’imposer des quotas supplémentaires pour réduire le trafic.

Conditions requises pour la surveillance de l’utilisation

Pour évaluer l’utilisation du système, vous avez généralement besoin des informations suivantes :

• Nombre de requêtes que chaque sous-système traite et dirige vers chaque ressource

• Travail effectué par chaque utilisateur

• Volume de stockage de données occupé par chaque utilisateur

• Ressources auxquelles chaque utilisateur accède

Vous devez également être en mesure de générer des graphiques. Les exemples courants incluent des graphiques d’utilisateurs qui consomment la plupart des ressources et les ressources les plus fréquemment consultées ou les fonctionnalités système.

Collecter les données d’utilisation

Vous pouvez effectuer un suivi d’utilisation de haut niveau en notant les heures de début et de fin de chaque requête et la nature de chaque requête, telles que la lecture ou l’écriture. Pour capturer ces informations, effectuez les tâches suivantes :

• Tracez l’activité de l’utilisateur.
• Capturez des compteurs de performances qui mesurent l’utilisation de chaque ressource.
• Surveillez la consommation des ressources de chaque utilisateur.

À des fins de contrôle, vous devez également identifier les utilisateurs qui effectuent les opérations et les ressources utilisées par ces opérations. Assurez-vous que les informations que vous collectez sont suffisamment détaillées pour prendre en charge la facturation précise.

Suivi des problèmes

Les clients et d’autres utilisateurs peuvent signaler des problèmes si des événements ou comportements inattendus se produisent dans le système. Le suivi des problèmes gère ces problèmes, associe des problèmes à des efforts pour les résoudre et informe les clients des résolutions.

Conditions requises pour le suivi des problèmes

Pour suivre les problèmes, utilisez un système distinct qui vous permet d’enregistrer et de signaler les détails des problèmes que les utilisateurs signalent. Ces détails incluent les tâches tentées, les symptômes du problème, la séquence d’événements et les messages d’erreur ou d’avertissement.

Collecter des données de suivi des problèmes

La source de données initiale pour les données de suivi des problèmes est l’utilisateur qui signale le problème. Cet utilisateur peut être en mesure de fournir les détails suivants :

• Un vidage sur incident, si l’application inclut un composant qui s’exécute sur le Bureau de l’utilisateur.

• Capture instantanée d’écran

• Date et heure auxquelles l’erreur s’est produite et d’autres informations environnementales, telles que l’emplacement de l’utilisateur

Utilisez ces informations pour vous aider à déboguer le système et à construire un backlog pour les futures versions logicielles.

Analyser les données de suivi des problèmes

Différents utilisateurs peuvent signaler le même problème, et le système de suivi des problèmes doit associer des rapports communs.

Enregistrez l’avancement du débogage pour chaque rapport. Lorsque vous résolvez le problème, informez le client de la solution.

Si un utilisateur signale un problème qui a une solution connue dans le système de suivi des problèmes, vous pouvez informer l’utilisateur de la solution immédiatement.

Opérations de traçage et débogage des versions logicielles

Lorsqu’un utilisateur signale un problème, il n’est généralement conscient que de l’effet immédiat qu’il a sur ses opérations. L’utilisateur peut uniquement signaler les résultats de sa propre expérience. Ces expériences sont généralement un symptôme visible d’un ou plusieurs problèmes fondamentaux. Dans de nombreux cas, un analyste doit analyser la chronologie des opérations sous-jacentes pour établir la cause racine du problème. Ce processus est appelé analyse de la cause racine (RCA).

Exigences pour le suivi et le débogage

Pour tracer des événements inattendus et d’autres problèmes, les données de surveillance doivent fournir suffisamment d’informations pour permettre à un analyste de trouver l’origine du problème et de reconstruire la séquence d’événements. Ensuite, un développeur peut apporter des modifications pour empêcher le problème de se reproduire.

Recueillir les données de traçage et de débogage

Pour résoudre les problèmes, tracez toutes les méthodes et leurs paramètres appelés dans le cadre d’une opération. Créez ensuite une arborescence qui représente le flux logique via le système lorsqu’un client effectue une requête spécifique. Capturez et consignez des exceptions et des avertissements que le système génère à la suite de ce flux.

Pour prendre en charge le débogage, le système fournit des hooks que vous pouvez utiliser pour capturer des informations d’état à des points essentiels du système. Ou le système peut fournir des informations détaillées détaillées au fur et à mesure que les opérations sélectionnées progressent. La capture de données à ce niveau de détail peut augmenter la charge sur le système et doit être un processus temporaire. Utilisez ce processus lorsque des événements inhabituels et difficiles à répliquer se produisent ou lorsqu’une nouvelle version nécessite une surveillance minutieuse pour s’assurer que les éléments fonctionnent comme prévu.

Pipeline de surveillance et de diagnostic

La surveillance d’un système distribué à grande échelle constitue une difficulté importante. Vous ne devez pas nécessairement prendre en compte chacun des scénarios décrits dans les sections précédentes en isolation. Les données de surveillance et de diagnostic requises pour chaque situation se chevauchent, mais vous devrez peut-être traiter et présenter ces données de différentes manières. Pour ces raisons, prenez une vue holistique de la surveillance et des diagnostics.

Vous pouvez imaginer l’ensemble du processus de surveillance et de diagnostic en tant que pipeline qui comprend les étapes indiquées dans le diagramme suivant.

Le diagramme montre comment les données de surveillance et de diagnostic proviennent de différentes sources. Les phases d’instrumentation et de collecte vous aident à identifier les données dont vous avez besoin pour capturer, où et comment la capturer, et comment mettre en forme les données afin de pouvoir les analyser facilement. L’étape d’analyse et de diagnostic prend les données brutes et les utilise pour générer des informations significatives que vous pouvez utiliser pour déterminer l’état du système. Vous pouvez utiliser ces informations pour déterminer les actions possibles à entreprendre, puis alimenter les résultats dans les phases d’instrumentation et de collecte. La phase de visualisation et d’alerte présente une vue consommable de l’état du système. Il peut afficher des informations en quasi temps réel à l’aide d’une série de tableaux de bord. Il peut générer des rapports, des graphiques et des graphiques pour fournir une vue historique des données qui peuvent vous aider à identifier les tendances à long terme. Si des informations indiquent qu’un indicateur de performance clé est susceptible de dépasser les limites acceptables, cette étape peut également déclencher une alerte. Dans certains cas, une alerte peut également déclencher un processus automatisé qui tente d’effectuer des actions correctives, telles que la mise à l’échelle automatique.

Ces étapes forment un processus de flux continu dans lequel les étapes s’exécutent en parallèle. Dans l’idéal, toutes les phases doivent être configurables dynamiquement. À certains moments, en particulier lorsqu’un système vient d’être déployé ou rencontre des problèmes, vous devrez peut-être collecter plus fréquemment des données étendues. À d’autres moments, vous pouvez continuer à capturer des informations essentielles de haut niveau pour vérifier que le système fonctionne correctement.

Traitez l’ensemble du processus de surveillance comme une solution dynamique et continue qui a besoin d’un réglage précis et d’améliorations en fonction des commentaires. Par exemple, vous pouvez commencer par mesurer de nombreux facteurs pour déterminer l’intégrité du système et affiner votre analyse au fil du temps pour ignorer les mesures qui ne sont pas pertinentes.

Sources de données de surveillance et de diagnostic

Les informations que le processus de surveillance utilise peuvent provenir de plusieurs sources. Au niveau de l’application, les informations proviennent des journaux de suivi que vous incorporez dans le code système. Les développeurs doivent suivre une approche standard pour suivre le flux de contrôle par le biais de leur code. Par exemple, une entrée à une méthode peut émettre un message de trace qui spécifie le nom de la méthode, l’heure actuelle, la valeur de chaque paramètre et d’autres informations pertinentes. Vous pouvez également enregistrer les heures d’entrée et de sortie.

Consignez toutes les exceptions et avertissements, puis assurez-vous de conserver une trace complète des exceptions et avertissements imbriqués. Capturez des informations qui identifient l’utilisateur qui exécute le code et les informations de corrélation d’activité pour suivre les demandes au fur et à mesure qu’ils passent par le système. Consignez les tentatives d’accès à toutes les ressources, telles que les files d’attente de messages, les bases de données, les fichiers et les autres services dont elles dépendent. Vous pouvez utiliser ces informations à des fins de contrôle et d’audit.

De nombreuses applications utilisent des bibliothèques et des frameworks pour effectuer des tâches courantes telles que l’accès à un magasin de données ou la communication sur un réseau. Vous pouvez peut-être configurer ces infrastructures pour fournir leurs propres messages de suivi et informations de diagnostic brutes, telles que les taux de transaction et les réussites et les échecs de transmission des données.

Le système d’exploitation sur lequel l’application s’exécute peut être une source d’informations de bas niveau, à l’échelle du système, telles que les compteurs de performances qui indiquent les taux d’E/S, l’utilisation de la mémoire et l’utilisation du processeur. Il peut également signaler des erreurs de système d’exploitation, telles que l’échec de l’ouverture d’un fichier correctement.

Tenez également compte de l’infrastructure et des composants sous-jacents sur lesquels votre système s’exécute. Les machines virtuelles, les réseaux virtuels et les services de stockage peuvent toutes être des sources de compteurs de performances importants au niveau de l’infrastructure et d’autres données de diagnostic.

Si votre application utilise d’autres services externes, tels qu’un serveur web ou un système de gestion de base de données (SGBD), ces services peuvent publier leurs propres informations de trace, journaux et compteurs de performances. Par exemple, les vues de gestion dynamique (DMV) dans SQL Server permettent de suivre les opérations effectuées sur une base de données SQL Server. Application Insights trace les journaux d’activité pour l’enregistrement des demandes adressées à Azure App Service.

Lorsque vous modifiez les composants système et déployez de nouvelles versions, il est important que vous puissiez attribuer des problèmes, des événements et des métriques à chaque version. Associez ces informations au pipeline de mise en production pour vous permettre de suivre et de résoudre rapidement les problèmes liés à une version spécifique d’un composant.

Utilisez les stratégies suivantes pour collecter les données de surveillance et de diagnostic :

• La surveillance des applications et des systèmes utilise des sources internes au sein de l’application, des infrastructures d’application, du système d’exploitation et de l’infrastructure. Le code de l’application peut générer ses propres données de surveillance à des points notables pendant le cycle de vie d’une demande cliente. L’application peut inclure des instructions de suivi que vous pouvez activer et désactiver si nécessaire. Vous pouvez également injecter des diagnostics dynamiquement à l’aide d’une infrastructure de diagnostics. Ces frameworks fournissent généralement des plug-ins qui s’attachent à différents points d’instrumentation dans votre code et capturent les données de trace à ces points.

  Votre code ou l’infrastructure sous-jacente peut également déclencher des événements à des points critiques. Les agents de surveillance configurés pour écouter ces événements peuvent enregistrer les informations d’événement.

• La surveillance des utilisateurs réels enregistre les interactions entre un utilisateur et l’application et observe le flux de chaque demande et réponse. Utilisez ces informations pour mesurer l’utilisation par chaque utilisateur et déterminer si les utilisateurs reçoivent une qoS appropriée, notamment les temps de réponse rapides, la faible latence et les erreurs minimales. Vous pouvez utiliser les données pour identifier les zones où des défaillances se produisent le plus souvent. Vous pouvez également utiliser les données pour identifier les zones où le système ralentit en raison de points d’accès dans l’application ou d’autres goulots d’étranglement. Si vous implémentez cette approche avec soin, vous pourrez peut-être reconstruire les flux des utilisateurs via l’application à des fins de débogage et de test.

  Important

  Traitez les données capturées par la surveillance des utilisateurs réels comme très sensibles, car elles peuvent inclure des documents confidentiels. Si vous enregistrez des données capturées, stockez-les en toute sécurité. Si vous souhaitez utiliser les données à des fins de supervision ou de débogage des performances, supprimez d’abord toutes les données personnelles.

• La surveillance des utilisateurs synthétiques vous oblige à écrire votre propre client de test qui simule un utilisateur et effectue une série d’opérations configurable mais standard. Vous pouvez suivre les performances du client de test pour déterminer l’état du système. Vous pouvez également utiliser plusieurs instances du client de test dans le cadre d’une opération de test de charge pour établir la façon dont le système répond sous contrainte et la sortie de surveillance générée par ces conditions.

  Note

  Vous pouvez implémenter la surveillance des utilisateurs réels et synthétiques en incluant du code qui trace et times l’exécution des appels de méthode et d’autres parties critiques d’une application.

• Le profilage vous permet de surveiller et d’améliorer les performances des applications. Contrairement à la surveillance des utilisateurs réels et à la surveillance des utilisateurs synthétiques, qui fonctionnent au niveau fonctionnel, le profilage capture les informations de niveau inférieur à mesure que l’application s’exécute. Implémentez le profilage en échantillonnant régulièrement l’état d’exécution d’une application ou en déterminant quel élément de code l’application s’exécute à un moment spécifique. Vous pouvez également utiliser l’instrumentation qui insère des sondes dans le code à des moments importants, comme le début et la fin d’un appel de méthode. Les sondes enregistrent les méthodes appelées, à quel moment et combien de temps chaque appel prend. Vous pouvez ensuite analyser ces données pour déterminer quelles parties de l’application peuvent entraîner des problèmes de performances.

• La surveillance des points de terminaison utilise un ou plusieurs points de terminaison de diagnostic que l’application expose spécifiquement pour activer la surveillance. Un point de terminaison fournit un chemin d’accès au code d’application et peut retourner des informations sur l’intégrité du système. Différents points de terminaison peuvent se concentrer sur différents aspects de la fonctionnalité. Vous pouvez écrire votre propre client de diagnostic qui envoie des demandes périodiques à ces points de terminaison et assimilent les réponses. Pour plus d'informations, consultez le schéma de surveillance des terminaux de santé.

• Les vidages d’erreurs utilisateur s’appuient sur l’application pour fournir un moyen de collecter un instantané de l’état de l’application s’il ne peut pas récupérer. Les utilisateurs doivent également partager volontairement cet instantané. Vous ne pouvez pas garantir qu’un vidage mémoire des erreurs soit généré, mais vous pouvez utiliser les données de bas niveau qu’il fournit pour déterminer la cause première des erreurs. Ce scénario est courant si les erreurs se produisent rarement ou si des erreurs se produisent uniquement dans une fonctionnalité d’application rarement utilisée.

Pour une couverture maximale, vous devez utiliser une combinaison de ces techniques.

Instrumenter une application

L’instrumentation est une partie essentielle du processus de surveillance. Vous devez capturer des données qui vous aident à prendre des décisions significatives sur les performances et l’intégrité de votre système. Utilisez l’instrumentation pour collecter suffisamment d’informations pour évaluer les performances, diagnostiquer les problèmes et prendre des décisions sans vous connecter à un serveur de production distant pour tracer et déboguer manuellement. Les données d’instrumentation comprennent généralement des métriques et des informations écrites dans les journaux de suivi.

Un journal de trace peut contenir des données textuelles que l’application écrit ou des données binaires qu’un événement de trace crée, si l’application utilise le suivi d’événements pour Windows (ETW). Les journaux système qui enregistrent des événements provenant de certains composants de l’infrastructure, comme un serveur Web, peuvent également générer du contenu de journaux de traçage. Les messages de journal textuels sont souvent lisibles par l’homme, mais écrivent-les dans un format où un système automatisé peut également analyser facilement.

Catégorisez aussi les logs. N’écrivez pas toutes les données de trace dans un seul journal. Utilisez des journaux distincts pour enregistrer la sortie de trace à partir de différents aspects opérationnels du système. Vous pouvez ensuite filtrer rapidement les messages de journal en lisant le journal approprié plutôt que de traiter un seul fichier long. N’écrivez jamais dans le même fichier journal des informations soumises à des exigences de sécurité différentes, comme les informations d’audit et les données de débogage.

Les métriques sont généralement une mesure ou un nombre d’aspects ou de ressources dans le système à un moment spécifique, avec une ou plusieurs balises ou dimensions associées, également appelées exemples. Une seule instance d’une métrique n’est pas utile en isolation. Au lieu de cela, capturez les métriques au fil du temps. Prenez en compte les métriques à enregistrer et à quelle fréquence. La génération de données pour les métriques peut trop souvent charger trop sur le système. Mais ne pas capturer suffisamment de données peut vous amener à manquer les circonstances qui mènent à un événement significatif. Les considérations varient d’une métrique à l’autre. Par exemple, l’utilisation du processeur sur un serveur peut varier de la seconde à la seconde, mais l’utilisation élevée devient une préoccupation uniquement si elle persiste pendant plusieurs minutes.

Informations sur la corrélation des données

Vous pouvez facilement surveiller des compteurs de performances individuels 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. Toutefois, certaines formes de surveillance nécessitent l’étape d’analyse et de diagnostic dans le pipeline de surveillance pour mettre en corrélation les données récupérées à partir de plusieurs sources. Ces données brutes peuvent prendre plusieurs formes et le processus d’analyse doit avoir suffisamment de données d’instrumentation 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 effectue cette tâche.

Un mappage un-à-un n’existe probablement pas entre les threads et les demandes utilisateur, car les opérations asynchrones peuvent réutiliser les mêmes threads pour effectuer des opérations pour plusieurs utilisateurs. Plusieurs threads peuvent également gérer une requête unique en tant que flux d’exécution via le système. Si possible, associez chaque requête à un ID d’activité unique propagé par le biais du système dans le cadre du contexte de la requête. La technique de génération et d’inclusion d’ID d’activité dans les informations de trace dépend de la technologie que vous utilisez pour capturer les données de trace.

Horodatez toutes les données de surveillance de la même manière. Pour assurer la cohérence, enregistrez toutes les dates et toutes les heures à l’aide de l’heure UTC. Cette méthode vous permet de suivre plus facilement les séquences d’événements.

Informations à inclure dans les données d’instrumentation

Tenez compte des points suivants lorsque vous décidez des données d’instrumentation à collecter :

• Assurez-vous que les informations capturées par les événements de trace sont lisibles par l’ordinateur et lisibles par l’homme. Adoptez des schémas bien définis pour ces informations afin de faciliter le traitement automatisé des données de journal sur les systèmes et de fournir une cohérence aux opérations et au personnel d’ingénierie qui lisent les journaux. Incluez des informations environnementales, telles que l’environnement de déploiement, l’ordinateur sur lequel le processus s’exécute, les détails du processus et la pile des appels.

• Activez le profilage uniquement si nécessaire, car il peut ajouter une surcharge importante au système. Le profilage à l’aide d’enregistrements d’instrumentation enregistre un événement, tel qu’un appel de méthode, chaque fois qu’il se produit, tandis que l’échantillonnage enregistre uniquement les événements sélectionnés. La sélection peut être basée sur le temps, une fois toutes les n secondes ou basée sur la fréquence, une fois toutes les n requêtes. Si des événements se produisent fréquemment, le profilage par instrumentation peut entraîner trop de charge et affecter les performances globales. Dans ce cas, l’approche d’échantillonnage est préférable. Toutefois, si la fréquence des événements est faible, l’échantillonnage peut les manquer. Dans ce cas, l’instrumentation peut être la meilleure approche.

• Fournissez un contexte suffisant afin qu’un développeur ou un administrateur puisse déterminer la source de chaque requête. Ce contexte peut inclure un ID d’activité qui identifie une instance spécifique d’une demande ou d’informations qui met 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 comptage, le contexte doit également inclure, directement ou indirectement via d’autres informations corrélées, une référence au client qui soumet la demande. Ce contexte fournit des informations précieuses sur l’état de l’application lorsque vous capturez des données de surveillance.

• Enregistrez toutes les requêtes, ainsi que les emplacements ou régions à partir desquels ces demandes sont effectuées. Ces informations peuvent vous aider à déterminer si des points d’accès spécifiques à l’emplacement existent. Il peut également vous aider à déterminer s’il faut repartitionner une application ou les données qu’elle utilise.

• Enregistrez et capturez attentivement les détails des exceptions. Souvent, les informations de débogage critiques sont perdues en raison d’une mauvaise gestion des exceptions. Capturez les détails complets des exceptions levées par l’application, y compris les exceptions internes et d’autres informations de contexte. Incluez la pile des appels si possible.

• Soyez cohérent dans les données que les différents éléments de votre application capturent. La cohérence peut 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, plutôt que de dépendre des développeurs pour qu'ils adoptent la même approche lorsqu'ils implémentent différentes parties du système. Collectez des données à partir de compteurs de performances clés, comme le volume d’E/S, l’utilisation du réseau, le nombre de requêtes, l’utilisation de la mémoire et l’utilisation du processeur. Certains services d’infrastructure peuvent fournir leurs propres compteurs de performances, tels que le nombre de connexions à une base de données, le taux auquel le système effectue des transactions et le nombre de transactions qui réussissent ou échouent. Les applications peuvent également définir leurs propres compteurs de performances spécifiques.

• Journalisez tous les appels effectués vers des services externes, tels que des systèmes de base de données, des services web ou d’autres services au niveau du système qui font partie de l’infrastructure. Enregistrez des informations sur le temps nécessaire à chaque appel et indiquez si l’appel réussit ou échoue. Si possible, capturez des informations sur toutes les tentatives de nouvelle tentative et les échecs pour toutes les erreurs temporaires qui se produisent.

Garantir la compatibilité avec les systèmes de télémétrie

Dans de nombreux cas, les informations produites par l’instrumentation sont générées sous la forme d’une série d’événements et 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 des applications ou technologies spécifiques, mais il s’attend à ce que les informations suivent un format spécifique défini par un schéma. 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 la prise en charge de données provenant de diverses plateformes et de divers appareils. Un exemple d’infrastructure et de schéma largement utilisés est OpenTelemetry.

Un schéma commun doit inclure des champs que tous les événements d’instrumentation ont en commun, tels que le nom de l’événement, l’heure de l’événement, l’adresse IP de l’expéditeur. Il doit également inclure les détails requis pour la corrélation avec d’autres événements, tels qu’un ID d’utilisateur, un ID d’appareil et un ID d’application. N’oubliez pas que n’importe quel nombre d’appareils peuvent déclencher des événements. Par conséquent, le schéma ne doit pas dépendre du type d’appareil. En outre, différents appareils peuvent déclencher des événements pour la même application, et l’application peut prendre en charge l’itinérance ou une autre forme de distribution inter-appareils.

Le schéma peut également inclure des champs de domaine pertinents pour un scénario particulier commun entre différentes applications. Ces scénarios incluent des informations sur les exceptions, les événements de démarrage et de fin de l’application, ainsi que la réussite ou l’échec des appels d’API de service web. Toutes les applications qui utilisent le même ensemble de champs de domaine doivent émettre le même ensemble d’événements pour générer un ensemble de rapports et d’analyses communs.

Enfin, un schéma peut contenir des champs personnalisés pour capturer les détails des événements spécifiques à l’application.

Meilleures pratiques pour instrumenter des applications

La liste suivante récapitule les meilleures pratiques pour instrumenter une application distribuée qui s’exécute dans le cloud :

• Facilitez la lecture et l’analyse des logs. Utilisez la journalisation structurée si possible. Soyez concis et descriptif dans les messages de journal.

• Dans tous les journaux d’activité, identifier la source et fournir le contexte et les informations de minutage à mesure que chaque enregistrement est écrit.

• Utilisez le même fuseau horaire et le même format pour tous les horodatages. Cette pratique permet de mettre en corrélation des événements pour les opérations qui s’étendent sur le matériel et les services qui s’exécutent dans différentes régions géographiques.

• Classez les journaux et écrivez des messages dans le fichier journal approprié.

• Ne divulguez pas d’informations sensibles sur le système ou les informations personnelles sur les utilisateurs. Nettoyez ces informations avant de la consigner, mais assurez-vous de conserver les détails pertinents. Par exemple, supprimez l’ID et le mot de passe des chaînes de connexion de base de données. Écrivez les informations restantes dans le journal afin que vous puissiez déterminer si le système accède à la base de données correcte. Journaliser toutes les exceptions critiques, mais autoriser l’administrateur à activer et désactiver la journalisation pour des niveaux inférieurs d’exceptions et d’avertissements. En outre, capturez et journaliser toutes les informations logiques de nouvelle tentative. Vous pouvez utiliser ces données pour surveiller l’intégrité temporaire du système.

• Tracez les appels hors processus, tels que les demandes adressées à des services web externes ou des bases de données.

• Ne mélangez pas les messages de journal avec différentes exigences de sécurité dans le même fichier journal. Par exemple, n’écrivez pas les informations de débogage et d’audit dans le même journal.

• Lancez des appels de journalisation qui continuent à fonctionner de manière autonome. Ces types d’opérations ne bloquent pas la progression des opérations métier. Les événements d’audit sont une exception, car ils sont essentiels pour l’entreprise. Classifiez-les comme une partie fondamentale des opérations commerciales.

• Vérifiez que la journalisation est extensible et qu’elle n’a aucune dépendance directe vis-à-vis d’une cible concrète. Par exemple, au lieu d’écrire des informations à l’aide de System.Diagnostics.Trace, définissez une interface abstraite, telle que ILogger, qui expose les méthodes de journalisation et que vous pouvez implémenter par n’importe quel moyen approprié.

• Assurez-vous que la journalisation est à sécurité intégrée et ne déclenche jamais d’erreurs en cascade. La journalisation ne doit pas déclencher d’exceptions.

• Traitez l’instrumentation comme un processus itératif continu et examinez régulièrement les journaux, non seulement lorsqu’un problème se produit.

Collecter et stocker des données

L’étape de collecte récupère les informations générées par l’instrumentation, met en forme ces données pour faciliter la consommation pendant l’analyse et la phase de diagnostic, et enregistre les données transformées dans un stockage fiable. Vous pouvez stocker les données d’instrumentation que vous collectez à partir de différentes parties d’un système distribué dans différents emplacements et formats. Par exemple, votre code d’application peut générer des fichiers journaux de trace et des données du journal des événements d’application. D’autres technologies peuvent capturer des compteurs de performances qui surveillent les aspects clés de l’infrastructure utilisée par votre application. Tous les composants et services non Microsoft utilisés par votre application peuvent fournir des informations d’instrumentation dans différents formats à l’aide de fichiers de trace distincts, de stockage d’objets blob ou même d’un magasin de données personnalisé.

Un service de collecte qui s’exécute de manière autonome à partir de l’application qui génère les données d’instrumentation collecte généralement les données. Le diagramme suivant illustre un exemple de cette architecture et met en évidence le sous-système de collecte de données d’instrumentation.

Ce diagramme montre une vue simplifiée de la collecte de données. Le service de collecte comprend généralement de nombreuses parties qui s’exécutent sur différents ordinateurs. Si vous devez analyser rapidement les données de télémétrie, utilisez des composants locaux qui fonctionnent en dehors du service de collecte. Après le traitement analytique, les composants envoient les résultats directement au sous-système de visualisation et d’alerte. Les données soumises à une analyse à chaud ou à froid sont conservées dans le stockage pendant qu’elles attendent le traitement. Pour plus d’informations, consultez Prise en charge de l’analyse à chaud, tiède et à froid.

Pour Azure applications et services qui s’exécutent sur des machines virtuelles, l’agent Azure Monitor fournit une solution pour capturer des données. Vous définissez des règles de collecte de données qui spécifient les données à collecter à partir de chaque nœud de calcul et de l’espace de travail Log Analytics dans Azure Monitor pour l’envoyer. L’agent peut collecter des données à partir des sources suivantes :

• Journaux de bord des services Internet (IIS)
• Journaux d’événements Windows
• Compteurs de performance
• Syslog à partir de nœuds Linux
• Journaux d'activité texte et JSON que les applications écrivent

Stratégies de collecte des données d’instrumentation

En raison de la nature élastique du cloud et pour éviter de récupérer manuellement des données de télémétrie à partir de chaque nœud du système, organisez la consolidation des données et transférez-les vers un emplacement central. Dans un système qui s’étend sur plusieurs centres de données, vous souhaiterez peut-être collecter, consolider et stocker des données sur une base région par région, puis agréger les données régionales en un seul système central.

Pour optimiser l’utilisation de la bande passante, vous pouvez transférer des données moins urgentes en tant que lots. Ne retardez pas indéfiniment le transfert, en particulier si les données contiennent des informations sensibles au temps.

Données d’instrumentation pull et push

Le sous-système de collecte de données d’instrumentation peut récupérer activement les données d’instrumentation à partir des différents fichiers journaux et d’autres sources pour chaque instance de l’application. Cette méthode est appelée modèle d’extraction. Il peut également agir en tant que récepteur passif qui attend les composants qui constituent chaque instance de l’application pour envoyer les données. Cette méthode est appelée modèle push.

L’une des approches du modèle collecteur consiste à utiliser des agents de surveillance qui s’exécutent localement avec chaque instance de l’application. Un agent de surveillance est un processus distinct qui récupère régulièrement les données de télémétrie collectées au niveau du nœud local et écrit ces informations dans le stockage centralisé que toutes les instances du partage d’application. L’agent Azure Monitor implémente ce mécanisme. Vous configurez les données à collecter à partir de chaque instance de calcul via une règle de collecte de données. L’agent de surveillance qui s’exécute en même temps que chaque instance collecte les données spécifiées, telles que les journaux d’activité IIS, les journaux d’événements Windows et les compteurs de performances, et les envoie à un espace de travail Log Analytics dans Azure Monitor, où vous pouvez interroger et analyser. Le diagramme suivant illustre un exemple de cette architecture.

Vous pouvez utiliser les modèles pull et push pour stocker des données de télémétrie pour une application à petite échelle qui s’exécute sur un nombre limité de nœuds dans un seul emplacement. Une application cloud globale complexe, hautement évolutive, peut générer d’énormes volumes de données à partir de centaines d’instances de calcul, de partitions de base de données et d’autres services. Cette inondation de données peut facilement submerger la bande passante d’E/S disponible avec un emplacement central unique. Par conséquent, vous devez être en mesure de mettre à l’échelle votre solution de télémétrie pour éviter un goulot d’étranglement au fur et à mesure que le système se développe. Dans l’idéal, votre solution doit incorporer un degré de redondance pour réduire les risques de perte d’informations de surveillance importantes, telles que l’audit ou les données de facturation, si une partie du système échoue.

Pour résoudre ces problèmes, implémentez la mise en file d’attente. Dans l’exemple d’architecture suivant, l’agent de surveillance local ou le service de collecte de données personnalisé publie des données dans une file d’attente. Le service d’écriture de stockage, un processus asynchrone distinct, prend les données de cette file d’attente et les écrit dans le stockage partagé. Une file d’attente de messages convient à ce scénario, car elle fournit au moins une sémantique qui permet de s’assurer que les données mises en file d’attente ne sont pas perdues après sa publication. Vous pouvez implémenter le service d’écriture de stockage à l’aide d’un processus en arrière-plan distinct.

Le service de collecte de données local peut ajouter des données à une file d’attente immédiatement après sa réception. La file d’attente agit en tant que mémoire tampon et le service d’écriture de stockage peut récupérer et écrire les données à son propre rythme. Par défaut, une file d’attente fonctionne sur une base de première entrée et de première sortie. Toutefois, vous pouvez hiérarchiser les messages pour les accélérer via la file d’attente s’ils contiennent des données que vous devez gérer rapidement. Pour plus d’informations, consultez le modèle File d’attente prioritaire. Vous pouvez également utiliser différents canaux, tels que des rubriques Service Bus, pour diriger les données vers différentes destinations en fonction de la forme de traitement analytique nécessaire.

Pour la scalabilité, vous pouvez exécuter plusieurs instances du service d’écriture de stockage. Pour les volumes élevés d’événements, vous pouvez utiliser un hub d’événements pour distribuer les données à différentes ressources de calcul pour le traitement et le stockage.

Consolider les données d’instrumentation

Les données d’instrumentation récupérées par le service de collecte de données à partir d’une seule instance d’une application donnent une vue localisée de l’intégrité et des performances de cette instance. Pour évaluer l’état de santé global du système, consolidez certains aspects des données à partir des vues locales. Vous pouvez effectuer cette étape une fois les données stockées, mais dans certains cas, vous pouvez également le faire à mesure que les données sont collectées. Au lieu d’écrire directement dans un stockage partagé, les données d’instrumentation passent par un service distinct qui consolide, filtre et nettoie les données. Par exemple, les données d’instrumentation qui incluent les mêmes informations de corrélation, telles qu’un ID d’activité, peuvent être fusionnées. Un utilisateur peut démarrer une opération métier sur un nœud, puis être transféré vers un autre nœud si le nœud échoue ou en raison de l’équilibrage de charge. Ce processus peut également détecter et supprimer des données dupliquées, ce qui est possible si le service de télémétrie utilise des files d’attente de messages pour envoyer des données d’instrumentation vers le stockage. Le diagramme suivant illustre un exemple de cette structure.

Stocker les données d’instrumentation

Les sections précédentes montrent une vue simplifiée de la façon de stocker des données d’instrumentation. Dans la pratique, vous devez stocker différents types d’informations à l’aide des technologies qui conviennent à la façon dont vous envisagez de l’utiliser.

Par exemple, Stockage Blob Azure et Azure Table Storage ont des modèles d’accès similaires, mais les opérations qu’ils peuvent effectuer sont limitées et la granularité des données qu’ils stockent varient. Si vous devez effectuer des opérations analytiques ou exiger des fonctionnalités de recherche en texte intégral, vous devrez peut-être utiliser le stockage de données qui fournit les fonctionnalités de requête et d’accès aux données suivantes :

• Stockez les données de compteur de performances dans une base de données SQL pour activer l’analyse non planifiée.
• Stockez les journaux de trace dans Azure Cosmos DB.
• Écrire des informations de sécurité dans le système de fichiers distribué Hadoop (HDFS).
• Stockez des informations qui nécessitent une recherche en texte intégral à l’aide d’Elasticsearch, qui utilise l’indexation enrichie pour accélérer les recherches.

Le diagramme suivant montre comment implémenter un service supplémentaire qui récupère régulièrement les données à partir du stockage partagé, des partitions et filtre les données en fonction de son objectif, puis les écrit dans un ensemble approprié de magasins de données. Une autre approche consiste à inclure cette fonctionnalité dans le processus de consolidation et de nettoyage et à écrire les données directement dans ces magasins, au lieu de l’enregistrer dans une zone de stockage partagée intermédiaire. Chaque approche présente des avantages et des inconvénients. L’implémentation d’un service de partitionnement distinct réduit la charge sur le service de consolidation et de nettoyage. Il vous permet également de régénérer au moins certaines des données partitionnées si nécessaire, en fonction de la quantité de données conservée par le stockage partagé. Toutefois, cette approche consomme plus de ressources. Il peut également retarder la réception des données d’instrumentation de chaque instance d’application et la conversion de ces données en informations exploitables.

Vous aurez peut-être besoin des mêmes données d’instrumentation à plusieurs fins. Par exemple, les compteurs de performances peuvent fournir une vue historique des performances du système au fil du temps. Vous pouvez combiner ces informations avec d’autres données d’utilisation pour générer des informations de facturation client. Dans ces scénarios, envoyez les mêmes données à plusieurs destinations, telles qu’une base de données de documents qui stocke les informations de facturation et un magasin multidimensionnel qui gère des analyses de performances complexes.

Réfléchissez à l’urgence dont vous avez besoin des données. Les données qui fournissent des informations pour les alertes doivent être accessibles rapidement. Vous devez donc les stocker dans un stockage et un index de données rapides ou les structurer pour optimiser les requêtes système d’alerte. Dans certains cas, le service de télémétrie qui collecte les données sur chaque nœud peut avoir besoin de mettre en forme et d’enregistrer des données localement afin qu’une instance locale du système d’alerte puisse vous avertir rapidement des problèmes. Vous pouvez distribuer les mêmes données au service d’écriture de stockage que les diagrammes précédents affichent et les stockent de manière centralisée si vous en avez besoin à d’autres fins.

Les informations que vous utilisez pour une analyse plus complexe, pour la création de rapports et pour identifier les tendances historiques sont moins urgentes. Stockez-le de manière à prendre en charge l’exploration de données et les requêtes non planifiées. Pour plus d’informations, consultez Prise en charge de l’analyse à chaud, tiède et à froid.

Rotation des fichiers journaux et rétention des données

L’instrumentation génère beaucoup de données. Dans certains cas, une fois les données traitées et transférées, vous pouvez supprimer les données sources brutes d’origine de chaque nœud. Vous devrez peut-être enregistrer les informations brutes.

Les données de performances ont généralement une durée de vie plus longue afin que vous puissiez l’utiliser pour identifier les tendances de performances et planifier la capacité. Conservez la vue consolidée de ces données en ligne pendant une période finie afin de pouvoir y accéder rapidement. Vous devrez peut-être enregistrer les données collectées pour le contrôle et la facturation indéfiniment. En outre, les exigences réglementaires peuvent nécessiter l’archivage et l’enregistrement des informations collectées à des fins d’audit et de sécurité. Chiffrer ou protéger ces données sensibles pour empêcher la falsification. N’enregistrez jamais les mots de passe des utilisateurs ou d’autres informations personnelles. Nettoyez ces détails des données avant de les stocker.

Sous-échantillonnage des données

Stockez les données historiques pour repérer les tendances à long terme. Au lieu d’enregistrer toutes les anciennes données, vous pouvez réduire l’échantillon des données pour réduire sa résolution et réduire les coûts de stockage. Par exemple, au lieu d’économiser des indicateurs de performances minute par minute, vous pouvez consolider les données de plus d’un mois pour former une vue horaire par heure.

Meilleures pratiques pour collecter et stocker des données de logs

La liste suivante récapitule les meilleures pratiques pour capturer et stocker les informations de journalisation :

• L’agent de surveillance ou le service de collecte de données doit s’exécuter en tant que service hors processus et être simple à déployer.

• Toutes les sorties de l’agent de surveillance ou du service de collecte de données doivent être un format indépendant de l’ordinateur, du système d’exploitation ou du protocole réseau. Par exemple, émettez des informations dans un format auto-décrivant tel que JSON, MessagePack ou Protobuf plutôt que des fichiers ETL (Event Trace Log) sur Linux ou ETW. Utilisez un format standard pour que le système puisse construire des pipelines de traitement. Vous pouvez facilement intégrer des composants qui lisent, transforment et envoient des données au format convenu.

• Le processus de surveillance et de collecte de données doit être sécurisé et ne doit pas déclencher d’erreurs en cascade.

• Si un échec temporaire envoie des informations à un récepteur de données, l’agent de surveillance ou le service de collecte de données doit être prêt à réorganiser les données de télémétrie afin que les informations les plus récentes soient envoyées en premier. L’agent de surveillance ou le service de collecte de données peut choisir de supprimer les données plus anciennes ou de les enregistrer localement et de les transmettre ultérieurement pour rattraper leur retard, à sa propre discrétion.

Analyser les données et diagnostiquer les problèmes

Une partie importante de la surveillance et des diagnostics analyse les données collectées pour obtenir une image de l’intégrité globale du système. Définissez vos propres indicateurs de performance clés et métriques de performances et découvrez comment structurer les données pour répondre à vos besoins d’analyse. Découvrez comment les données capturées dans différentes métriques et fichiers journaux sont corrélées, car ces informations sont essentielles pour suivre une séquence d’événements et diagnostiquer les problèmes.

Les données de chaque partie du système sont généralement capturées localement, mais vous devez ensuite les combiner avec les données générées sur d’autres sites qui participent au système. Mettez en corrélation ces informations avec soin pour vous assurer que les données sont combinées avec précision. Par exemple, les données d’utilisation d’une opération peuvent s’étendre sur les nœuds suivants :

• Nœud qui héberge un site web auquel un utilisateur se connecte
• Nœud qui exécute un service distinct accessible dans le cadre de cette opération
• Nœud qui stocke des données

Vous devez mettre ces informations en relation afin de fournir une vue globale de l’utilisation des ressources et du traitement pour l’opération. Le nœud qui capture les données peut les prétraiter et les filtrer, mais les nœuds centraux agrègent et mettent généralement les données en forme. Pour plus d’informations, consultez Consolider les données d’instrumentation.

Prise en charge des analyses à chaud, tiède et à froid

L’analyse et la reformatage des données à des fins de visualisation, de création de rapports et d’alertes peuvent être un processus complexe qui consomme son propre ensemble de ressources. Certaines formes de surveillance nécessitent une analyse immédiate des données pour être efficace, également appelée analyse à chaud. Les exemples incluent l’analyse des alertes et de la surveillance de la sécurité. Pour une analyse à chaud, rendez les données disponibles et structurées pour un traitement efficace. Dans certains cas, vous devrez peut-être déplacer le traitement d’analyse vers les nœuds individuels qui contiennent les données.

D’autres formes d’analyse sont moins sensibles au temps et peuvent nécessiter un calcul et une agrégation une fois les données brutes reçues. Cette méthode est appelée analyse chaude. L’analyse des performances se situe souvent dans cette catégorie. Dans ce cas, un pic ou un glitch soudain peut entraîner un événement de performances unique isolé qui n’est pas statistiquement significatif. Les données d’une série d’événements fournissent une image plus fiable des performances du système.

Vous pouvez également utiliser l’analyse chaude pour diagnostiquer les problèmes de santé. Utilisez l’analyse à chaud pour traiter un événement d’état de santé et déclencher immédiatement une alerte. Utilisez ensuite l’analyse à chaud pour analyser les données et déterminer la cause de l’incident sanitaire.

Certains types de surveillance génèrent des données plus à long terme. Vous pouvez effectuer cette analyse à une date ultérieure, éventuellement selon une planification prédéfinie. Dans certains cas, l’analyse peut avoir besoin de filtrer de grands volumes de données capturées au fil du temps. Cette méthode est appelée analyse à froid. L’exigence clé est que vous stockez les données en toute sécurité après la capture. Par exemple, la surveillance et l’audit de l’utilisation nécessitent une image précise de l’état du système à intervalles réguliers, mais ces informations d’état n’ont pas besoin d’être immédiatement disponibles pour le traitement.

Vous pouvez également utiliser l’analyse hors ligne pour fournir les données nécessaires à l’analyse prédictive de l’état de santé. Rassemblez des informations historiques sur une période donnée et combinez-les avec les données de santé actuelles afin d’identifier des tendances susceptibles d’entraîner des problèmes de santé. Dans ces cas, vous devrez peut-être déclencher une alerte pour corriger la tendance.

Mettre en corrélation les données

Les données capturées par l’instrumentation peuvent fournir un instantané de l’état du système, mais l’objectif de l’analyse est de rendre ces données exploitables. Par exemple, vous pouvez déterminer la cause d’un chargement d’E/S intense au niveau du système à un moment spécifique et vous assurer que les temps de réponse de la base de données, le nombre de transactions par seconde et les temps de réponse d’application au même moment confirment vos résultats.

Une façon de réduire la charge consiste à partitionner les données sur d’autres serveurs. Les exceptions peuvent se produire en raison d’une erreur à n’importe quel niveau du système. Une exception à un niveau déclenche souvent une autre erreur au-dessus de celui-ci.

Pour ces raisons, vous devez mettre en corrélation les différents types de données de surveillance à chaque niveau pour produire une vue globale de l’état du système et des applications qui s’exécutent dessus. Utilisez ces informations pour déterminer si le système fonctionne de manière acceptable et déterminez ce que vous pouvez faire pour améliorer la qualité.

Assurez-vous que les données d’instrumentation brutes incluent des informations de contexte et d’ID d’activité suffisantes pour prendre en charge les agrégations requises pour la corrélation des événements. Ces données peuvent être conservées dans différents formats. Vous devrez peut-être l’analyser et la convertir dans un format standardisé pour l’analyse. Pour plus d’informations, consultez Informations sur la corrélation des données.

Résoudre et diagnostiquer les problèmes

Pour diagnostiquer les problèmes, vous devez effectuer une analyse des causes profondes (RCA) afin de déterminer la cause des défaillances ou des comportements inattendus. Vous avez généralement besoin des informations suivantes pour l’ensemble du système ou pour un sous-système spécifique pendant une fenêtre de temps spécifiée :

• Informations détaillées à partir des journaux d’événements et des traces
• Effectuez des traces de pile à partir d’exceptions et d’erreurs de n’importe quel niveau spécifié
• Vidages sur incident pour tous les processus ayant échoué
• Journaux d’activité qui enregistrent les opérations effectuées par tous les utilisateurs ou certains utilisateurs

Pour analyser les données à des fins de résolution des problèmes, vous avez besoin d’une compréhension technique approfondie de l’architecture système et de ses composants. Vous devez interpréter les données, établir la cause des problèmes et recommander une stratégie pour les corriger. Une autre stratégie consiste à stocker une copie de ces informations dans son format d’origine et à la rendre disponible pour l’analyse à froid par un expert.

Visualiser les données et déclencher des alertes

Les systèmes de surveillance doivent présenter des données afin que vous puissiez rapidement identifier les tendances ou les problèmes. Ils doivent également vous avertir immédiatement lorsqu’un événement nécessitant une attention se produit.

La présentation des données peut prendre plusieurs formes, notamment la visualisation à l’aide de tableaux de bord, d’alertes et de création de rapports.

Visualisation à l’aide de tableaux de bord

La façon la plus courante de visualiser les données consiste à utiliser des tableaux de bord qui affichent des informations sous la forme d’une série de graphiques, de graphiques ou d’autres illustrations. Vous pouvez paramétrer ces éléments et sélectionner les paramètres importants, tels que la période, pour une situation spécifique.

Vous pouvez organiser des tableaux de bord hiérarchiquement. Les tableaux de bord de niveau supérieur donnent une vue globale de chaque aspect du système et vous permettent d’explorer les détails. Par exemple, dans un tableau de bord qui représente les E/S de disque globales pour le système, vous pouvez afficher les taux d’E/S pour chaque disque individuel afin de déterminer si un ou plusieurs appareils spécifiques comptent pour un volume disproportionné de trafic. Le tableau de bord doit également afficher des informations connexes, telles que l’utilisateur ou l’activité qui génère ces E/S. Ces informations peuvent vous aider à répartir la charge plus uniformément entre les appareils.

Un tableau de bord peut également utiliser le codage de couleur ou d’autres indications visuelles pour indiquer des valeurs qui apparaissent anormales ou qui se trouvent en dehors d’une plage attendue. Tenez compte des exemples de codage de couleur suivants :

• Rouge pour un disque avec un taux d’E/S approchant de sa capacité maximale sur une période prolongée ou un disque chaud

• Jaune pour un disque avec un taux d’E/S qui s’exécute régulièrement à sa limite maximale sur de courtes périodes, ou un disque chaud

• Vert pour un disque qui présente une utilisation normale

Les systèmes de tableau de bord doivent disposer des données brutes pour fonctionner efficacement. Si vous créez votre propre système de tableau de bord ou utilisez un tableau de bord développé par une autre organisation, vous devez comprendre les données d’instrumentation que vous devez collecter, à quels niveaux de granularité et comment mettre en forme le tableau de bord à consommer.

Un tableau de bord efficace vous permet également de poser des questions sur les informations. Certains systèmes fournissent des outils de gestion que vous pouvez utiliser pour effectuer ces tâches et explorer les données sous-jacentes. Selon le référentiel qui contient les informations, vous pouvez interroger les données directement ou les importer dans des outils tels que Excel pour une analyse et des rapports supplémentaires.

Déclencher des alertes

L’alerte analyse les données de surveillance et d’instrumentation et génère une notification si elle détecte un événement significatif.

Les alertes permettent de s’assurer que le système reste sain, réactif et sécurisé. Il s’agit d’une partie importante de n’importe quel système qui garantit les performances, la disponibilité et la confidentialité des utilisateurs. Les alertes peuvent également vous avertir des événements qui déclenchent des alertes. Utilisez des alertes pour appeler des fonctions système comme la mise à l’échelle automatique.

Les alertes dépendent des données d’instrumentation suivantes :

• Événements de sécurité : Si les journaux d’événements indiquent que des échecs d’authentification ou d’autorisation répétés se produisent. Dans ce scénario, une alerte doit vous informer que le système peut être attaqué.

• Métriques de performances : Le système doit rapidement répondre si une métrique de performances dépasse un seuil spécifié.

• Informations de disponibilité : Si une erreur est détectée, vous devrez peut-être redémarrer rapidement un ou plusieurs sous-systèmes ou basculer vers une ressource de sauvegarde. Les erreurs répétées dans un sous-système peuvent indiquer des problèmes plus graves.

Vous pouvez recevoir des informations d’alerte via de nombreux canaux, tels que l’e-mail, un pagineur ou un sms. Une alerte peut également inclure une indication de la façon dont une situation est critique. De nombreux systèmes d’alerte prennent en charge les groupes d’abonnés, et tous les opérateurs membres du même groupe reçoivent le même ensemble d’alertes.

Personnalisez le système d’alerte et fournissez les valeurs appropriées à partir des données d’instrumentation sous-jacentes en tant que paramètres. À l’aide de cette approche, vous pouvez filtrer les données pour des seuils spécifiques ou des combinaisons de valeurs. Dans certains cas, vous pouvez fournir les données d’instrumentation brutes au système d’alerte. Ou il peut être plus approprié de fournir des données agrégées. Par exemple, une alerte se déclenche lorsque l’utilisation du processeur pour un nœud dépasse 90% au cours des 10 dernières minutes. Fournissez au système d’alerte les informations contextuelles et récapitulatives appropriées pour réduire la possibilité que les événements faux positifs déclenchent une alerte.

Signalement

Utilisez la création de rapports pour générer une vue globale du système. Il peut incorporer des données historiques et des informations actuelles. Les exigences de création de rapports appartiennent à des catégories opérationnelles et de sécurité.

Les rapports opérationnels incluent généralement les aspects suivants pour le système global ou les sous-systèmes spécifiques pendant une fenêtre de temps spécifiée :

• Statistiques agrégées que vous pouvez utiliser pour comprendre l’utilisation des ressources

• Tendances de l’utilisation des ressources

• Surveillance des exceptions

• Efficacité des applications en termes de ressources déployées et si vous pouvez réduire le volume de ressources sans affecter les performances

Les rapports de sécurité effectuent le suivi de la façon dont les clients utilisent le système. Il inclut généralement les aspects suivants :

• Auditer les opérations utilisateur. Enregistrez des demandes individuelles que chaque utilisateur effectue avec des dates et des heures. Structurez les données afin de pouvoir reconstruire rapidement la séquence d’opérations effectuées par un utilisateur sur une période spécifiée.

• Suivez l’utilisation des ressources pour chaque utilisateur. Enregistrez comment chaque requête d’un utilisateur accède aux ressources système et pendant combien de temps. Utilisez ces données pour générer un rapport d’utilisation pour chaque utilisateur sur une période spécifiée, éventuellement à des fins de facturation.

Dans de nombreux cas, les processus de traitement par lots peuvent générer des rapports selon une planification définie. La génération de rapports n’augmente généralement pas la latence. Vous pouvez donc générer des rapports à la demande si nécessaire. Si vous stockez des données dans une base de données relationnelle telle que Azure SQL Database, vous pouvez utiliser un outil comme SQL Server Reporting Services pour extraire et mettre en forme des données et les présenter sous la forme d’un ensemble de rapports.

Étapes suivantes

• Vue d’ensemble d’Azure Monitor
• Surveiller, diagnostiquer et résoudre les problèmes de stockage
• Overview des alertes dans Azure
• Vue d’ensemble d’Application Insights
• Diagnostics de performance pour les machines virtuelles Azure

Ressources associées

• Les conseils de mise à l’échelle automatique expliquent comment réduire la surcharge de gestion en réduisant la nécessité de surveiller continuellement les performances du système et de prendre des décisions pour ajouter ou supprimer des ressources.

• Le modèle Supervision de point de terminaison décrit l’implémentation des contrôles fonctionnels au sein d’une application à laquelle accèdent des outils externes par le biais de points de terminaison exposés à intervalles réguliers.

• Le modèle file d’attente prioritaire décrit comment hiérarchiser les messages mis en file d’attente afin que les systèmes reçoivent et traitent des demandes urgentes avant les messages moins urgents.