Dépannage des applications

  • Article

AppFabric offre des fonctionnalités de gestion des services WCF et WF .NET Framework version 4 hébergés par IIS. Ces fonctionnalités incluent des mécanismes de fiabilité pour l'hébergement des services de flux de travail durables, une configuration simplifiée des applications et des outils de surveillance du fonctionnement des services WCF et WF .NET Framework 4. Cette section décrit l'utilisation des outils de surveillance à des fins de dépannage des services.

Le tableau de bord permet de commencer à dépanner les services WCF et WF. Cliquez sur l'icône Tableau de bord au sein du groupe AppFabric dans le Gestionnaire des services Internet pour afficher la page Tableau de bord. Cette page composite offre une vue résumée du fonctionnement des applications déployées sur une étendue particulière dans IIS et propose des liens permettant d'examiner des informations de dépannage plus spécifiques. Si les mesures du tableau de bord et les pages associées ne fournissent pas les informations détaillées dont vous avez besoin pour résoudre un problème, vous pouvez utiliser les outils d'AppFabric pour activer le suivi System.Diagnostics et dépanner une application WCF ou WF.

Dépannage à l'aide du tableau de bord

Pour identifier un problème dans les applications distribuées, il ne suffit pas d'examiner un compteur ou d'utiliser un simple outil de détection. Au contraire, la résolution d'un problème dans un environnement de services distribués implique généralement l'établissement d'une corrélation entre des données recueillies par divers outils ou compteurs afin de mettre à jour la véritable cause d'un problème. Les trois widgets du tableau de bord (Instances WF persistantes, Historique des appels WCF et Historique des instances WF) permettent d'établir une corrélation entre des informations dans le but de dépanner les applications. Les deux derniers widgets sont des mesures d'historique : les éléments affichés sont affectés par le sélecteur de temps Période situé dans la partie supérieure du tableau de bord (Dernière minute, Dernières 24 heures, etc.).

Lorsque vous ouvrez ou affichez un des trois widgets pour la première fois, vous apercevez une vue résumée de l'état des mesures associées qui vous permet de détecter les problèmes éventuels à ce niveau. Par exemple, le widget Instances WF persistantes affiche l'état des instances de flux de travail durable actives qui ont enregistré leur état dans le magasin de persistance. Vous obtenez ainsi un état résumé du nombre d'instances persistantes dans les états Actif, Inactif et Interrompu et êtes rapidement informé de l'existence d'un problème au niveau des flux de travail persistants. Vous pouvez cliquer sur les liens de la page de résumé pour obtenir des informations supplémentaires sur le compteur résumé spécifique.

Utilisation des mesures du widget Instances WF persistantes

Le widget Instances WF persistantes affiche l'état des instances de flux de travail durable actives qui ont enregistré leur état dans le magasin de persistance. Il indique le nombre d'instances persistantes dans les états Actif, Inactif et Interrompu. Chaque en-tête, et le nombre résumé lui-même, constitue un lien vers la page Instances WF persistantes contenant les données brutes.

Pour mieux appréhender le problème lors du dépannage des instances interrompues, cliquez sur le lien Instances interrompues dans le tableau de bord. La page Instances WF persistantes affiche toutes les instances interrompues. La sélection de l'une d'entre elles affiche des informations résumées relatives aux instances interrompues dans le volet Détails, situé dans la partie inférieure de l'écran. L'onglet Erreurs affiche le motif d'interruption de l'instance. Si vous avez besoin d'informations supplémentaires, cliquez avec le bouton droit sur une instance, puis sélectionnez l'option Afficher les événements suivis. Cette action permet d'accéder à la page Événements suivis qui affiche tous les événements suivis associés à l'instance de flux de travail interrompue. Par défaut, les événements les plus récents sont répertoriés en premier.

Utilisation des mesures du widget Historique des appels WCF

Le widget Historique des appels WCF affiche le nombre d'appels WCF reçus et enregistrés dans le magasin de surveillance. L'en-tête affiche un nombre résumé des appels ayant abouti, des appels ayant rencontré des exceptions et le nombre de fois qu'une limitation a été dépassée. La première colonne affiche les cinq premiers services présentant le plus grand nombre d'appels ayant abouti. La deuxième colonne affiche une décomposition des erreurs WCF, regroupées par type d'erreur. La troisième colonne affiche les cinq premiers services présentant le plus grand nombre d'exceptions de service. Chaque mesure inclut un lien vers la page Événements suivis qui affiche les données brutes résumées dans le tableau de bord.

Par exemple, pour obtenir davantage d'informations sur un appel n'ayant pas abouti, cliquez sur le compteur résumé Appels n'ayant pas abouti, puis accédez à la page Événements suivis. Celle-ci indique les derniers appels WCF n'ayant pas abouti sur l'étendue sélectionnée dans la hiérarchie IIS. La sélection d'un de ces événements affiche des informations associées dans le volet Détails, situé dans la partie inférieure de l'écran. L'onglet Erreurs contient des informations d'exception relatives à l'échec. Si vous avez besoin d'informations supplémentaires sur l'appel n'ayant pas abouti, cliquez avec le bouton droit sur l'événement, puis sélectionnez l'option Afficher tous les événements associés. Cette action actualise la page Événements suivis et y affiche tous les événements associés à l'événement d'origine.

Notes

Pour utiliser l'option Afficher tous les événements associés, la surveillance de l'application doit être définie sur le niveau Surveillance de bout en bout ou un niveau supérieur. À ce niveau, l'infrastructure de surveillance collecte les événements de transfert qui associent deux ID d'activité de bout en bout (E2EActivityId).

Utilisation des mesures du widget Historique des instances WF

Le widget Historique des instances WF affiche le nombre d'instances de flux de travail activées, échouées et exécutées. La première colonne affiche les cinq premiers services présentant le plus grand nombre d'activations. La deuxième colonne affiche les cinq premiers services présentant le plus grand nombre d'instances en échec. La troisième colonne affiche le nombre d'instances en échec qui ont été récupérées. Par exemple, si une instance de flux de travail a rencontré une erreur la forçant à s'interrompre, mais qu'elle a été reprise puis exécutée correctement par la suite, la valeur 1 doit figurer dans la colonne Échec et dans la colonne Récupéré(e).

La méthodologie de dépannage à l'aide des informations du widget Historique des instances WF est semblable à celle utilisant les informations du widget Instances WF persistantes. Cliquez sur l'un des en-têtes pour accéder à la page Instances WF suivies qui affiche les informations résumées relatives à l'instance de flux de travail. Comme le widget Historique des instances WF affiche des instances de flux de travail éventuellement déjà exécutées, les actions de contrôle dans la page Instances WF persistantes ne sont toutefois plus disponibles ici. Dans la page Instances WF suivies, cliquez avec le bouton droit sur une instance pour afficher les événements suivis associés et consulter les données de suivi détaillées sur cette instance.

Dépannage à l'aide du suivi System.Diagnostics

AppFabric tire parti des améliorations apportées au traçage WCF et au suivi WF dans .NET Framework 4 qui émettent des événements dans le sous-système ETW (Event Tracing for Windows). ETW offre une infrastructure de suivi des événements rapide. Dans certains cas, il est toutefois nécessaire de consulter toutes les informations de diagnostic disponibles. Dans AppFabric, vous pouvez activer le suivi System.Diagnostics au niveau de l'application ou du site. Ces informations de suivi sont enregistrées dans des fichiers sur le disque et peuvent être consultées à l'aide de l'outil Service Trace Viewer.

Avertissement

Le suivi System.Diagnostics réduit les performances de vos applications et génère des fichiers de suivi volumineux. Il est recommandé d'activer le suivi System.Diagnostics uniquement lors du dépannage d'une application.

Dépannage d'une application ASP.NET distribuée

Vous pouvez utiliser l'ID d'activité (tel que mentionné dans la section Utilisation des mesures du widget Historique des appels WCF précédente) pour rechercher un ID d'instance durable et dépanner une application ASP.NET qui communique via plusieurs serveurs AppFabric avec les services WCF. Pour ce faire, définissez le niveau de surveillance sur Surveillance de bout en bout (au minimum) pour configurer le suivi des activités. Voici un exemple illustrant ce cas de figure.

Alors qu'il surveille l'application Web à l'aide des outils de surveillance ASP et IIS, l'administrateur remarque une augmentation des erreurs de délai d'expiration pour l'application ASP.NET au cours de la communication avec un service. Après vérification des erreurs, il obtient l'ID d'activité qui était actif au moment de l'erreur. À l'aide du tableau de bord d'AppFabric, il crée et exécute une requête pour celui-ci. Un seul événement est renvoyé (événement de réception sur l'instance Y du service X). Il consulte le flux de messages associé à cet événement et remarque un événement « Limitation du nombre maximal d'appels simultanés dépassée ». En consultant les pages Résumé du service, il remarque que l'option « Dépassements de limitation WCF » est définie sur 20, et que sur une période de 24 heures, les appels ont augmenté considérablement au cours des 30 dernières minutes. En consultant les autres jours, il remarque que l'événement se reproduit à la même heure chaque jour. Il en vient à la conclusion que la charge augmente à ce moment précis de la journée et que le paramètre Limitation du nombre maximal d'appels simultanés doit être défini sur 25.  Après un examen approfondi, il remarque que l'incidence des événements de limitation diminue de manière significative, ainsi que les erreurs de l'application ASP.NET lors de l'appel des services WCF.

Travaux du service Windows Agent SQL Server

Le service Windows Agent SQL Server surveille les opérations SQL Server, automatise certaines tâches d'administration, génère des alertes au besoin, et assure la planification et l'exécution des travaux. Un travail SQL Server est une série d'opérations déterminées exécutée de manière séquentielle par l'Agent SQL Server et couvrant un large éventail de tâches liées aux bases de données. Lorsqu'AppFabric est configuré pour utiliser SQL Server, il utilise l'Agent SQL Server pour importer des événements dans le magasin de surveillance et purger régulièrement le magasin des données anciennes.

Si l'Agent SQL Server n'est pas en cours d'exécution, les travaux planifiés d'AppFabric ne peuvent pas être exécutés au sein de l'installation SQL Server. Pour vous assurer que ces travaux sont exécutés comme prévu à l'aide du service Windows Agent SQL Server, procédez comme suit :

  1. Vérifiez que le service Windows Agent SQL Server est en cours d'exécution en consultant son état. Cliquez sur Outils d'administration, sélectionnez Services, Agent SQL Server (MSSQLSVR), puis vérifiez que l'État affiche la valeur Démarré. Si ce n'est pas le cas, démarrez le service.

  2. Quatre travaux SQL Server sont créés lorsque le magasin est initialisé :

    • Microsoft_ApplicationServer_Monitoring_AutoPurge_<nom BD surveillance>

    • Microsoft_ApplicationServer_Monitoring_ImportWfEvents_<nom BD surveillance>

    • Microsoft_ApplicationServer_Monitoring_ImportWcfEvents_<nom BD surveillance>

    • Microsoft_ApplicationServer_Monitoring_ImportTransferEvents_<nom BD surveillance>

    Si le service Windows Agent SQL Server est démarré mais que les travaux d'AppFabric ne sont pas en cours d'exécution, consultez les erreurs rencontrées lors de la dernière exécution du travail.

  3. Si les instances de travail ont été correctement exécutées et qu'aucun événement ne figure dans la table des événements, consultez la table ASFailedStagingTable sous le magasin de surveillance. Celle-ci contient des colonnes telles que ErrorNumber et ErrorMessage qui peuvent vous permettre d'identifier le motif de l'échec. Si aucune erreur ne s'est produite, la table est vide.

L'identité Windows (propriétaire) sous laquelle est exécuté un travail de l'Agent SQL Server pour AppFabric ne doit pas être identique à celle de l'utilisateur ayant ouvert la session. Elle doit être celle du compte de sécurité Windows prédéfini AS_MonitoringDbJobsAdmin. Dans l'idéal, ce compte doit être un compte de domaine. L'octroi des autorisations appropriées à ce compte s'effectue dans le magasin de surveillance lors de l'exécution de la cmdlet Initialize-ASMonitoringDatabase après l'installation.

L'Agent SQL Server traite les différents propriétaires d'un travail d'AppFabric envoyé comme suit :

  • Si le propriétaire d'un travail de l'Agent SQL Server est un compte de domaine, SQL Server contacte le contrôleur de domaine pour vérifier la validité du compte. Si le compte est valide, SQL Server est exécuté sous le compte de domaine. Sinon, SQL Server tente de s'exécuter sous un compte local.

  • Si le propriétaire d'un travail est un compte d'administrateur système local, l'Agent SQL Server respecte l'identité « RunAs » durant l'étape de travail et émet la commande d'exécution de l'utilisateur en tant que AS_MonitoringDbJobsAdmin. Cela signifie que le travail est exécuté sous l'identité du compte AS_MonitoringDbJobsAdmin.

    Notes

    Pour afficher l'identité « RunAs » d'un travail dans SQL Server Management Studio, cliquez avec le bouton droit sur le travail, cliquez sur Propriétés, puis sur l'onglet Avancé. Cette valeur doit être définie sur le compte AS_MonitoringDbJobsAdmin.

  • Si le propriétaire d'un travail est un compte local ne possédant pas les autorisations d'administrateur système, l'identité « RunAs » fournie lors de l'étape de travail est ignorée. Dans ce cas, le service Agent SQL Server exécute le travail en tant que propriétaire local.

  • En cas de déconnexion du domaine (ordinateur portable, par exemple), si l'identité d'un travail de surveillance SQL Server est un utilisateur de domaine, l'Agent SQL Server tente de valider le compte en contactant le contrôleur de domaine. Si l'ordinateur qui exécute le travail de l'Agent SQL Server est déconnecté du domaine, le processus échoue. Deux options permettent de résoudre ce problème :

    1. La première et la plus simple consiste à configurer le travail (via l'exécution de la cmdlet Initialize-ASMonitoringDatabase) à l'aide d'un compte d'utilisateur local.

    2. La deuxième option est comme suit : si un travail est configuré par un propriétaire à l'aide d'un compte de domaine, l'utilisateur peut modifier le propriétaire d'un travail par la suite sur un compte d'utilisateur local à l'aide de la procédure stockée SQL Server sp_update_job.

Il est recommandé de configurer le service Windows Agent SQL Server de sorte qu'il utilise un compte d'ouverture de session local. Le service peut ainsi être exécuté sur un ordinateur AppFabric même si la connexion réseau est interrompue. Si le service est exécuté sous un compte de domaine mais que le domaine est inaccessible, le service Windows Agent SQL Server ne peut pas obtenir les informations d'identification et les événements de surveillance ne peuvent pas être déplacés correctement vers leurs tables de destination. Aucune nouvelle donnée n'est affichée dans le tableau de bord.

Travaux de SQL Server Express

Bien que la méthodologie de diagnostic des raisons de l'échec d'un travail soit relativement semblable à celle employée avec SQL Server, il est toutefois nécessaire de consulter la table ASJobsTable dans le cadre de l'utilisation de SQL Server Express. Celle-ci est spécifique d'une installation SQL Server Express : elle n'existe pas dans une installation SQL Server. Dans cette table, vous pouvez consulter les valeurs des colonnes LastRunOn et LastRunSuccess dans une ligne de travail spécifique pour déterminer si un travail a été exécuté correctement ou non.

SQL Server Express n'utilise pas le service Windows Agent SQL Server, Celle-ci inclut une fonctionnalité temporelle associée à une valeur d'expiration définie sur l'intervalle dans lequel le travail Microsoft_ApplicationServer_Monitoring_AutoPurge_<nom BD surveillance> est configuré pour être exécuté. À l'expiration du délai, un message est envoyé à la file d'attente des travaux SQL Server. Ce message active la procédure stockée exécutée dans le cadre du travail Microsoft_ApplicationServer_Monitoring_AutoPurge_<nom BD surveillance>. La fonctionnalité de purge est ensuite exécutée automatiquement sur le magasin SQL Server Express.

L'exécution des requêtes T-SQL suivantes permet de surveiller la progression de la purge automatique du magasin :

  • Affichage des travaux actuellement planifiés : SELECT * FROM ASJobsTable

  • Recherche dans la colonne dialog_timer (heure UTC) pour déterminer la prochaine exécution du travail : SELECT * FROM sys.conversation_endpoints

  • Affichage du nombre de procédures d'activation en cours d'exécution : SELECT * FROM sys.dm_broker_activated_tasks

  • Recherche du nombre de messages encore présents dans la file d'attente. Lorsqu'aucun travail n'est en cours d'exécution, la valeur renvoyée est 0 : SELECT * FROM ASScheduledJobQueue

Voir aussi

Autres ressources

Dashboard Page
Persisted WF Instances Page
Tracked WF Instances Page
Tracked Events Page

  2012-03-05