Dépanner une application dans Azure App Service à l'aide de Visual Studio

Article
06/01/2023

Remarque

Cet article concerne Visual Studio 2019. Pour la résolution des problèmes dans Visual Studio 2022, consultez Débogage distant ASP.NET Core sur Azure App Service.

Vue d’ensemble

Ce didacticiel explique comment utiliser les outils Visual Studio pour déboguer une application dans App Service en activant le Mode débogage à distance ou en consultant les journaux des applications et des serveurs web.

Vous apprendrez ce qui suit :

quelles sont les fonctions de gestion d'applications proposées par Visual Studio ;
comment utiliser l'affichage à distance de Visual Studio pour apporter des modifications rapides dans une application à distance ;
comment exécuter le mode débogage à distance lorsqu'un projet est exécuté dans Azure, pour une application comme pour une tâche web.
la création de journaux d’activité de suivi d’application et leur affichage pendant leur création par l’application ;
l’affichage des journaux d’activité de serveur Web, notamment des messages d’erreur détaillés et le suivi des demandes ayant échoué ;
l’envoi de journaux de diagnostic à un compte Azure Storage et leur affichage depuis ce compte.

Si vous disposez de Visual Studio Ultimate, vous pouvez également utiliser IntelliTrace à des fins de débogage. IntelliTrace n’est pas couvert dans ce didacticiel.

Prérequis

Ce didacticiel fonctionne avec l'environnement de développement, le projet web et l'application App Service que vous avez configurés dans Créer une application ASP.NET dans Azure App Service. Pour les sections WebJobs, vous aurez besoin de l’application créée dans le cadre de la Prise en main du Kit de développement logiciel (SDK) Azure WebJobs.

Les exemples de code inclus dans ce didacticiel sont destinés à une application Web C# MVC, mais les procédures de résolution de problèmes sont identiques pour les applications Visual Basic et Web Forms.

Ce tutoriel suppose que vous utilisez Visual Studio 2019.

La fonctionnalité de diffusion de journaux d’activité en continu est opérationnelle uniquement pour les applications ciblant .NET Framework 4 ou une version ultérieure.

Configuration et gestion de l'application

Visual Studio permet d'accéder à un sous-ensemble des fonctionnalités de gestion des applications et des paramètres de configuration disponibles sur le portail Azure. Cette section présente les éléments disponibles en cas d’utilisation de l’Explorateur de serveurs. Pour connaître les dernières fonctionnalités d’intégration d’Azure, essayez également Cloud Explorer . Vous pouvez ouvrir les deux fenêtres à partir du menu Affichage .

Si vous n’êtes pas encore connecté à Azure dans Visual Studio, cliquez avec le bouton droit sur Azure et sélectionnez Se connecter à Abonnement Microsoft Azure dans l’Explorateur de serveurs.

Vous pouvez aussi installer un certificat de gestion permettant d'accéder à votre compte. Si vous choisissez d’installer un certificat, cliquez avec le bouton droit sur le nœud Azure dans l’Explorateur de serveurs, puis sélectionnez Gérer et filtrer les abonnements dans le menu contextuel. Dans la boîte de dialogue Gérer les abonnements Microsoft Azure, cliquez sur l’onglet Certificats, puis sur Importer. Suivez la procédure pour télécharger et importer un fichier d’abonnement (portant l’extension .publishsettings ) pour votre compte Azure.

Notes

Si vous téléchargez un fichier d’abonnement, enregistrez-le dans un dossier situé hors de vos répertoires de code source (par exemple, dans le dossier Téléchargements), puis supprimez-le une fois l’importation terminée. Si un utilisateur malveillant accède au fichier d’abonnement, il peut modifier, créer et supprimer vos services Azure.

Pour plus d’informations sur la connexion aux ressources Azure à partir de Visual Studio, consultez Attribuer des rôles Azure à l’aide du portail Azure.
Dans l’Explorateur de serveurs, développez Azure, puis App Service.
Développez le groupe de ressources incluant l'application que vous avez créée dans Créer une application ASP.NET dans Azure App Service, puis cliquez avec le bouton droit sur le nœud d'application et sélectionnez Afficher les paramètres.

L'onglet Application web Azure apparaît, affichant les tâches de gestion et de configuration des applications disponibles dans Visual Studio.

Dans ce didacticiel, vous utiliserez les menus déroulants de suivi et de journalisation. Vous utiliserez également le débogage à distance en l'activant d'une façon différente.

Pour plus d'informations sur les cases à cocher Paramètres de l'application et Chaînes de connexion de cette fenêtre, consultez l'article Azure App Service: How Application Strings and Connection Strings Work (Fonctionnement des chaînes d’application et de connexion d’Azure Web Apps).

Pour effectuer une tâche de gestion d'application non exécutable dans cette fenêtre, cliquez sur Ouvrir dans le portail de gestion pour ouvrir une fenêtre de navigateur sur le portail Azure.

Accès aux fichiers d'applications dans l'Explorateur de serveurs

En général, vous déployez un projet Web avec l’indicateur customErrors défini sur la valeur On ou RemoteOnly dans le fichier Web.config, ce qui signifie que vous n’obtenez pas de message d’erreur utile en cas de problème. Généralement, ces messages se présentent sous la forme d’une page comme celles qui suivent :

Erreur de serveur dans l’application « / » :

Capture d’écran montrant une erreur Erreur de serveur dans l’application « / » dans un navigateur web.

Nous avons rencontré une erreur :

Capture d’écran montrant un exemple d’erreur générique survenant dans un navigateur web.

Le site Web ne peut pas afficher la page

Capture d’écran montrant le message **Le site web ne peut pas afficher l’erreur de page dans un navigateur web**.

Généralement, la méthode la plus simple pour rechercher la cause d’une erreur consiste à activer les messages d’erreur détaillés : la première capture d’écran de la série précédente montre comment procéder. Vous devez modifier le fichier Web.config déployé. Vous pouvez modifier le fichier Web.config dans le projet et redéployer ce dernier, ou vous pouvez créer une transformation Web.config et déployer une build de débogage, mais la solution la plus rapide est la suivante : dans l’Explorateur de solutions, vous pouvez afficher et modifier directement les fichiers dans l’application distante à l’aide de la fonctionnalité d’affichage à distance.

Dans l'Explorateur de serveurs, développez l'élément Azure, App Service, puis le groupe de ressources où se trouve votre application, et développez le nœud de votre application.

Vous voyez alors les nœuds qui vous donnent accès aux fichiers de contenu et aux fichiers journaux de l'application.
Développez le nœud Fichiers , puis double-cliquez sur le fichier Web.config .

Visual Studio ouvre le fichier Web.config à partir de l'application distante, puis affiche l'élément [Distant] en regard du nom du fichier sur la barre de titre.
Ajoutez la ligne suivante à l’élément system.web :

<customErrors mode="Off"></customErrors>
Actualisez le navigateur qui affiche le message d'erreur inutile : à présent, vous obtenez un message d'erreur détaillé, comme dans l'exemple suivant :

L’erreur affichée est générée par l’ajout de la ligne affichée en rouge à Views\Home\Index.cshtml.

La modification du fichier Web.config n'est qu'un exemple des scénarios dans lesquels la capacité de lire et de modifier des fichiers sur votre application App Service simplifie la résolution des problèmes.

Applications de débogage à distance

Si le message d'erreur détaillé ne fournit pas assez d'informations et que vous ne pouvez pas recréer l'erreur localement, une autre méthode pour résoudre le problème consiste à exécuter le mode de débogage à distance. Vous pouvez définir des points d'arrêt, manipuler directement la mémoire, parcourir le code en détail et même modifier le chemin d'accès du code.

Le débogage à distance ne fonctionne pas avec les éditions Express de Visual Studio.

Cette section illustre comment déboguer à distance à l'aide du projet que vous créez dans Créer une application ASP.NET dans Azure App Service.

Ouvrez le projet web que vous avez créé dans Créer une application ASP.NET dans Azure App Service.
Ouvrez Controllers\HomeController.cs.

Supprimez la méthode About() et insérez le code suivant à la place.

public ActionResult About()
{
    string currentTime = DateTime.Now.ToLongTimeString();
    ViewBag.Message = "The current time is " + currentTime;
    return View();
}

Définissez un point d’arrêt sur la ligne ViewBag.Message.
Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet, puis cliquez sur Publier.
Dans la liste déroulante Profil, sélectionnez le profil utilisé dans Créer une application ASP.NET dans Azure App Service. Puis, cliquez sur Paramètres.
Dans la boîte de dialogue Publier, cliquez sur l’onglet Paramètres et remplacez Configuration par Déboguer, puis cliquez sur Enregistrer.
Cliquez sur Publier. Au terme du déploiement, lorsque votre navigateur s'ouvre en affichant l'adresse URL Azure de votre application, fermez le navigateur.
Dans l'Explorateur de serveurs, cliquez avec le bouton droit sur votre application, puis cliquez sur Attacher le débogueur.

Le navigateur ouvre automatiquement votre page d'accueil exécutée dans Azure. Vous devrez peut-être attendre environ 20 secondes pendant qu'Azure configure le serveur pour le débogage. Ce retard se produit uniquement la première fois que vous exécutez le mode débogage sur une application au cours d'une période de 48 heures. Si vous commencez à déboguer à nouveau au cours de la même période, aucun retard ne se produit.

Notes

Si vous rencontrez des problèmes au démarrage du débogueur, essayez d’utiliser Cloud Explorer au lieu de l’Explorateur de serveurs.
Cliquez sur À propos de dans le menu.

Visual Studio s'arrête sur le point d'arrêt et le code s'exécute dans Azure, et non pas sur votre ordinateur local.
Passez la souris sur la variable currentTime pour afficher la valeur de temps.

Le temps affiché correspond au fuseau horaire du serveur Azure, qui peut différer de celui de votre ordinateur local.
Entrez une nouvelle valeur pour la variable currentTime , comme « En cours d’exécution dans Azure ».
Appuyez sur F5 pour continuer.

La page « À propos de » exécutée dans Azure affiche la nouvelle valeur entrée dans la variable currentTime.

Débogage à distance de WebJobs

Cette section explique comment déboguer un élément à distance en utilisant le projet et l'application que vous avez créés avec le didacticiel Prise en main du Kit de développement logiciel (SDK) Azure WebJobs.

Les fonctionnalités présentées dans cette section sont disponibles uniquement dans Visual Studio 2013 avec Update 4 ou version ultérieure.

Le débogage à distance fonctionne uniquement avec les tâches Web en continu. Les tâches Web planifiées et à la demande ne prennent pas en charge le débogage.

Ouvrez le projet Web que vous avez créé dans Prise en main du Kit de développement logiciel (SDK) Azure WebJobs.
Dans le projet ContosoAdsWebJob, ouvrez Functions.cs.
Définissez un point d’arrêt sur la première instruction dans la méthode GenerateThumbnail.
Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet web (pas le projet WebJobs), puis cliquez sur Publier.
Dans le menu déroulant Profil , sélectionnez le même profil que celui utilisé dans Prise en main du Kit de développement logiciel (SDK) WebJobs Azure.
Cliquez sur l’onglet Paramètres, remplacez Configuration par Debug, puis cliquez sur Publier.

Visual Studio déploie les projets de tâche web et web, et votre navigateur ouvre l'URL Azure de votre application.
Dans l’Explorateur de serveurs, développez Azure > App Service > votre groupe de ressources > votre application > WebJobs > Continu, puis cliquez avec le bouton droit sur ContosoAdsWebJob.
Cliquez sur Attacher le débogueur.

Le navigateur ouvre automatiquement votre page d'accueil exécutée dans Azure. Vous devrez peut-être attendre environ 20 secondes pendant qu'Azure configure le serveur pour le débogage. Ce retard se produit uniquement la première fois que vous exécutez le mode débogage sur une application au cours d'une période de 48 heures. Si vous commencez à déboguer à nouveau au cours de la même période, aucun retard ne se produit.
Dans le navigateur web ouvert à la page d’accueil Contoso Ads, créez une publicité.

La création d’une publicité provoque la création d’un message de file d’attente, qui est récupéré par la tâche web et traité. Quand le Kit SDK WebJobs appelle la fonction pour traiter le message de file d’attente, le code atteint votre point d’arrêt.
Quand le débogueur s’arrête au point d’arrêt, vous pouvez examiner et modifier les valeurs des variables pendant l’exécution du programme dans le cloud. Dans l’illustration suivante, le débogueur affiche le contenu de l’objet blobInfo qui a été passé à la méthode GenerateThumbnail.
Appuyez sur F5 pour continuer.

La méthode GenerateThumbnail achève la création de la miniature.
Dans le navigateur, actualisez la page Index ; la miniature apparaît.
Dans Visual Studio, appuyez sur Maj+F5 pour arrêter le débogage.
Dans l’Explorateur de serveurs, cliquez avec le bouton droit sur le nœud ContosoAdsWebJob et cliquez sur Afficher le tableau de bord.
Connectez-vous avec vos informations d’identification Azure, puis cliquez sur le nom de la tâche web pour accéder à la page de votre tâche web.

Le tableau de bord indique que la fonction GenerateThumbnail a été exécutée récemment.

(La prochaine fois que vous cliquez sur Afficher le tableau de bord, vous ne serez pas obligé de vous connecter et le navigateur accédera directement à la page de votre tâche Web).
Cliquez sur le nom de la fonction pour afficher les détails relatifs à son exécution.

Si votre fonction a écrit des journaux d’activité, vous pouvez cliquer sur ToggleOutput pour les afficher.

Notes à propos du débogage à distance

Nous vous déconseillons d'exécuter le mode débogage en production. Si votre application de production n'est pas montée en charge sur plusieurs instances de serveur, la fonction de débogage empêche le serveur web de répondre aux autres demandes. Si vous avez plusieurs instances de serveurs web, le fait de joindre le débogueur génère une instance aléatoire et vous empêche de vérifier que les demandes suivantes de votre navigateur parviennent à la même instance. De même, comme vous ne déployez généralement pas une version de débogage dans un environnement de production, les optimisations du compilateur pour les versions Release peuvent empêcher l'affichage des réactions ligne par ligne dans votre code source. Pour résoudre les problèmes de production, la meilleure ressource est constituée des journaux d’activité de suivi d’application et de serveur Web.
Évitez les arrêts longs aux points d'arrêt avec le débogage à distance. Azure considère qu'un processus arrêté pendant plus de quelques minutes ne répond pas, et l'arrête définitivement.
Pendant le débogage, le serveur envoie des données à Visual Studio, ce qui peut affecter les frais de bande passante. Pour plus d'informations sur les tarifs de bande passante, consultez les tarifs Azure.
Vérifiez que l’attribut debug de l’élément compilation du fichier Web.config est défini sur true. Il est défini sur true par défaut lorsque vous publiez une configuration de version de débogage.
```
<system.web>
  <compilation debug="true" targetFramework="4.5" />
  <httpRuntime targetFramework="4.5" />
</system.web>
```
Si le débogueur ne parcourt pas le code que vous voulez déboguer, vous devez modifier le paramètre « Uniquement mon code ». Pour plus d’informations, consultez la section Specify whether to debug only user code using Just My Code in Visual Studio (Déterminer s’il faut déboguer uniquement le code utilisateur via l’option Uniquement mon code dans Visual Studio).
Lorsque vous activez la fonctionnalité de débogage à distance, un compteur démarre sur le serveur : après 48 heures, la fonctionnalité est automatiquement désactivée. Cette limite de 48 heures a été définie à des fins de sécurité et de performances. Vous pouvez facilement réactiver la fonctionnalité autant de fois que nécessaire. Nous vous recommandons de la désactiver lorsque vous n'utilisez pas le débogage.
Vous pouvez manuellement connecter le débogueur à n'importe quel processus, et pas seulement au processus de l'application (w3wp.exe). Pour plus d'informations sur l'utilisation du mode débogage dans Visual Studio, consultez la page Débogage dans Visual Studio.

Présentation des journaux de diagnostic

Une application ASP.NET qui s’exécute dans une application App Service peut créer les types de journaux d’activité suivants :

Journaux d’activité de suivi d’application
: l’application crée ces journaux d’activité en appelant des méthodes de la classe System.Diagnostics.Trace .
Journaux d’activité des serveurs web
: le serveur web crée une entrée de journal pour chaque requête HTTP à destination de l'application.
Journaux d’activité détaillés des messages d’erreur
: le serveur Web crée une page HTML contenant certaines informations supplémentaires pour les requêtes HTTP ayant échoué (celles dont le code d’état est 400 ou plus).
Journaux d’activité de suivi de demandes ayant échoué
: le serveur Web crée un fichier XML avec des informations de suivi détaillées pour les requêtes HTTP ayant échoué. Le serveur Web fournit également un fichier XSL pour mettre en forme le XML dans un navigateur.

La fonction de journalisation affecte les performances des applications. Pour cette raison, Azure vous offre la possibilité d'activer ou de désactiver chaque type de journal, selon vos besoins. Vous pouvez définir un niveau minimal de gravité pour l’écriture des journaux d’activité d’application. Lorsque vous créez une application, la fonction de journalisation est désactivée par défaut.

Les journaux d’activité sont consignés dans des fichiers du dossier LogFiles, au sein du système de fichiers de votre application, et ils sont accessibles par FTP. Il est également possible d’écrire les journaux d’activité de serveur Web et d’application dans un compte Azure Storage. Vous pouvez conserver davantage de journaux d’activité sur un compte de stockage que sur le système de fichiers. Le système de fichiers peut conserver jusqu’à 100 Mo de journaux d’activité (il ne conserve pas les journaux d’activité très longtemps : Azure libère de l'espace pour les nouveaux fichiers journaux en supprimant les anciens une fois la limite atteinte).

Création et affichage des journaux d’activité de suivi d’application

Dans cette section, vous effectuerez les tâches suivantes :

ajout d’instructions de traçage au projet web que vous avez créé dans Prise en main d’Azure et ASP.NET.
affichage des journaux d’activité lorsque vous exécutez le projet localement ;
affichage des journaux d’activité durant leur génération par l’application exécutée dans Azure.

Pour plus d’informations sur la création de journaux d’activité d’application dans WebJobs, consultez Utilisation du stockage de file d’attente Microsoft Azure avec le Kit de développement logiciel (SDK) de WebJobs - Écriture de journaux d’activité. Les instructions suivantes permettant d’afficher les journaux d’activité et de contrôler la façon dont ils sont stockés dans Azure s’appliquent également aux journaux des applications créés par WebJobs.

Ajout d'instructions de suivi à l'application

Ouvrez Controllers\HomeController.cs, puis remplacez les méthodes Index, About et Contact par le code suivant afin d’ajouter les instructions Trace et une instruction using pour System.Diagnostics :

public ActionResult Index()
{
    Trace.WriteLine("Entering Index method");
    ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";
    Trace.TraceInformation("Displaying the Index page at " + DateTime.Now.ToLongTimeString());
    Trace.WriteLine("Leaving Index method");
    return View();
}

public ActionResult About()
{
    Trace.WriteLine("Entering About method");
    ViewBag.Message = "Your app description page.";
    Trace.TraceWarning("Transient error on the About page at " + DateTime.Now.ToShortTimeString());
    Trace.WriteLine("Leaving About method");
    return View();
}

public ActionResult Contact()
{
    Trace.WriteLine("Entering Contact method");
    ViewBag.Message = "Your contact page.";
    Trace.TraceError("Fatal error on the Contact page at " + DateTime.Now.ToLongTimeString());
    Trace.WriteLine("Leaving Contact method");
    return View();
}

Ajoutez une instruction using System.Diagnostics; en haut du fichier.

Affichage de la sortie de suivi en local

Appuyez sur F5 pour exécuter l'application en mode débogage.

L'écouteur de suivi par défaut écrit toutes les sorties de suivi dans la fenêtre Sortie , avec d'autres sorties de débogage. L’image suivante montre la sortie des instructions de suivi ajoutées à la méthode Index .

La procédure suivante montre comment afficher la sortie de suivi dans une page Web, sans procéder à la compilation en mode de débogage.

Ouvrez le fichier Web.config de l'application (celui situé dans le dossier de projet), puis ajoutez un élément <system.diagnostics> à la fin du fichier, juste avant l'élément de fermeture </configuration> :

<system.diagnostics>
<trace>
  <listeners>
    <add name="WebPageTraceListener"
        type="System.Web.WebPageTraceListener,
        System.Web,
        Version=4.0.0.0,
        Culture=neutral,
        PublicKeyToken=b03f5f7f11d50a3a" />
  </listeners>
</trace>
</system.diagnostics>

L’élément WebPageTraceListener vous permet d’afficher la sortie de suivi en accédant à /trace.axd.

Ajoutez un élément de suivi sous <system.web> dans le fichier Web.config, comme dans l’exemple suivant :
```
<trace enabled="true" writeToDiagnosticsTrace="true" mostRecent="true" pageOutput="false" />
```
Appuyez sur Ctrl+F5 pour exécuter l’application.
Dans la barre d’adresse du navigateur, ajoutez trace.axd à l’URL, puis appuyez sur Entrée (l’URL ressemble à http://localhost:53370/trace.axd).
Sur la page Suivi d’application, cliquez sur Afficher les détails sur la première ligne (pas la ligne BrowserLink).

La page Détails de la demande s’affiche et la section Informations de suivi affiche la sortie des instructions de suivi ajoutées à la méthode Index.

Par défaut, trace.axd est uniquement disponible localement. Si vous souhaitez le rendre disponible à partir d'une application distante, vous pouvez ajouter localOnly="false" à l'élément trace dans le fichier Web.config, comme le montre l'exemple suivant :
```
<trace enabled="true" writeToDiagnosticsTrace="true" localOnly="false" mostRecent="true" pageOutput="false" />
```
Toutefois, l'activation de trace.axd dans une application de production n'est pas recommandée pour des raisons de sécurité. Dans les sections suivantes, vous découvrirez une façon plus simple de lire les journaux d’activité de suivi dans une application App Service.

Affichage de la sortie de suivi dans Azure

Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet web, puis cliquez sur Publier.
Dans la boîte de dialogue Publier le site Web, cliquez sur Publier.

Une fois que Visual Studio a publié votre mise à jour, il ouvre une fenêtre de navigateur vers votre page d’accueil (en partant du principe que vous n’avez pas désactivé la case à cocher URL de destination sous l’onglet Connexion).
Dans l’Explorateur de serveurs, cliquez avec le bouton droit sur votre application et sélectionnez Afficher les journaux d’activité de diffusion en continu.

La fenêtre Sortie indique que vous êtes connecté au service de diffusion de journaux en continu et ajoute une ligne de notification à chaque minute passée sans affichage de journal.
Dans la fenêtre du navigateur qui affiche la page d'accueil de votre application, cliquez sur Contacter.

En quelques secondes, la sortie du suivi de l’erreur que vous avez ajouté à la méthode Contact apparaît dans la fenêtre Sortie.

Visual Studio affiche uniquement le suivi des erreurs, car il s'agit du paramètre par défaut lorsque vous activez le service de surveillance des journaux. Lorsque vous créez une application App Service, la journalisation est désactivée par défaut, comme vous l'avez vu lorsque vous avez ouvert la page Paramètres un peu plus tôt :

Cependant, lorsque vous avez sélectionné Afficher les journaux d’activité de streaming, Visual Studio a automatiquement remplacé Journal des applications (système de fichiers) par Erreur, ce qui signifie que les journaux d’activité d’erreur sont signalés. Pour afficher tous vos journaux d’activité de suivi, vous pouvez remplacer ce paramètre par Commentaires. Lorsque vous sélectionnez un niveau de gravité inférieur à l’erreur, tous les journaux d’activité correspondant aux niveaux de gravité supérieurs sont également signalés. Donc, lorsque vous sélectionnez Commentaires, vous pouvez également consulter des informations, des avertissements et des journaux d’activité d’erreurs.
Dans l'Explorateur de serveurs, cliquez avec le bouton droit sur l'application, puis cliquez sur Afficher les paramètres, comme vous l'avez fait précédemment.
Remplacez Journal des applications (Filesystem) par Commentaires, puis cliquez sur Enregistrer.
Dans la fenêtre du navigateur affichant votre page Contact, cliquez sur Accueil, sur À propos de, puis sur Contact.

Quelques secondes après, la fenêtre Sortie affiche toutes vos sorties de suivi.

Dans cette section, vous avez activé et désactivé la journalisation à l'aide des paramètres d'application. Vous pouvez également activer et désactiver les écouteurs de suivi en modifiant le fichier Web.config. Toutefois, le fait de modifier le fichier Web.config entraîne le recyclage du domaine d'application, ce que ne fait pas l'activation de la journalisation via la configuration de l'application. Si le problème met du temps à se reproduire ou s'il est intermittent, le recyclage du domaine d'application peut le « résoudre » temporairement et vous forcer à attendre qu'il se reproduise. L’activation des diagnostics dans Azure vous permet de commencer tout de suite à saisir des informations sur une erreur sans recyclage du domaine d’application.

Fonctionnalités de la fenêtre Sortie

L’onglet Journaux d’activité Microsoft Azure de la fenêtre Sortie contient plusieurs boutons et une zone de texte :

Capture d’écran montrant les boutons et la zone de texte de l’onglet Journaux Microsoft Azure dans la fenêtre Sortie.

Ces éléments permettent d'effectuer les opérations suivantes :

Suppression du contenu de la fenêtre Sortie
Activation ou désactivation du retour automatique à la ligne
Démarrage ou arrêt de la supervision des journaux d’activité
Sélection des journaux d’activité à surveiller
Téléchargement de journaux d’activité
Filtrage des journaux d’activité en fonction d’une chaîne de recherche ou d’une expression régulière
Fermeture de la fenêtre Sortie

Si vous entrez une chaîne de recherche ou une expression régulière, Visual Studio filtre les informations de journalisation au niveau du client. Cela signifie que vous pouvez entrer les critères après l’affichage des journaux d’activité dans la fenêtre Sortie et que vous pouvez modifier les critères de filtrage sans avoir à régénérer les journaux d’activité.

Affichage des journaux d’activité de serveur Web

Les journaux d’activité de serveur Web enregistrent toutes les activités HTTP de l’application. Afin de pouvoir afficher ces journaux dans la fenêtre Sortie, vous devez les activer pour l'application et indiquer à Visual Studio que vous souhaitez les surveiller.

Dans l’onglet Configuration de l’application web Azure que vous avez ouvert à partir de l’Explorateur de serveurs, remplacez la valeur du paramètre Journalisation du serveur web par Activé, puis cliquez sur Enregistrer.
Dans la fenêtre Sortie, cliquez sur le bouton Spécifier les journaux d’activité Microsoft Azure à surveiller.
Dans la boîte de dialogue Options de journalisation Microsoft Azure, sélectionnez Journaux d’activité du serveur web, puis cliquez sur OK.
Dans la fenêtre du navigateur qui affiche l'application, cliquez sur Accueil, À propos de, puis Contact.

Généralement, les journaux d’activité d’application s’affichent en premier, suivis par les journaux d’activité de serveur Web. Le processus d’affichage peut prendre un certain temps.

Par défaut, Azure écrit les journaux d’activité dans le système de fichiers lorsque vous activez les journaux d’activité de serveur Web en utilisant Visual Studio. Une autre méthode consiste à utiliser le portail Azure pour indiquer que les journaux d’activité de serveur web doivent être écrits sur un conteneur d’objets blob dans un compte de stockage.

Si vous utilisez le portail pour activer la journalisation de serveur web sur un compte de stockage Azure, puis désactivez la journalisation dans Visual Studio, les paramètres de votre compte de stockage sont restaurés lorsque vous réactivez la journalisation dans Visual Studio.

Affichage des journaux d’activité de messages d’erreur détaillés

Les journaux d’activité d’erreur détaillés fournissent des informations supplémentaires sur les requêtes HTTP ayant pour résultat des codes de réponse d’erreur (400 ou au-delà). Afin de pouvoir afficher ces journaux dans la fenêtre Sortie , vous devez les activer pour l'application et indiquer à Visual Studio que vous souhaitez les surveiller.

Dans l’onglet Configuration de l’application web Azure que vous avez ouvert à partir de l’Explorateur de serveurs, remplacez la valeur du paramètre Messages d’erreur détaillés par Activé, puis cliquez sur Enregistrer.
Dans la fenêtre Sortie, cliquez sur le bouton Spécifier les journaux d’activité Microsoft Azure à surveiller.
Dans la boîte de dialogue Options de journalisation Microsoft Azure, cliquez sur Tous les journaux d’activité, puis sur OK.
Dans la barre d’adresse de la fenêtre de navigateur, ajoutez un caractère supplémentaire à l’URL pour provoquer une erreur 404 (par exemple, http://localhost:53370/Home/Contactx) et appuyez sur Entrée.

Après quelques secondes, le journal des erreurs détaillé s’affiche dans la fenêtre Sortie de Visual Studio.

Maintenez la touche Ctrl appuyée tout en cliquant sur le lien pour afficher le journal de sortie mis en forme dans un navigateur :

Téléchargement de journaux d’activité du système de fichiers

Tous les journaux d’activité que vous pouvez surveiller dans la fenêtre Sortie peuvent aussi être téléchargés en tant que fichiers .zip .

Dans la fenêtre Sortie, cliquez sur Télécharger les journaux d’activité de diffusion en continu.

L'Explorateur de fichiers ouvre votre dossier Téléchargements dans lequel le fichier téléchargé est sélectionné.
Procédez à l'extraction du fichier .zip pour afficher la structure de dossiers suivante :
- Les journaux d’activité de suivi d’application sont dans des fichiers .txt dans le dossier LogFiles\Application.
- Les journaux d’activité de serveur web sont dans des fichiers .log dans le dossier LogFiles\http\RawLogs. Vous pouvez utiliser un outil tel que Log Parser pour afficher et manipuler ces fichiers.
- Les journaux d’activité de messages d’erreur détaillés sont dans des fichiers .html dans le dossier LogFiles\DetailedErrors.
  
  (Le dossier deployments contient les fichiers créés par la publication à partir du contrôle de code source : il n'a rien à voir avec la publication Visual Studio. Le dossier Git contient le suivi lié à la publication à partir du contrôle de code source et au service de diffusion de fichier journal en continu.)

Affichage des journaux d’activité de suivi de demandes ayant échoué

Les journaux d’activité de suivi de demandes ayant échoué sont utiles pour comprendre les détails de gestion IIS d’une requête HTTP, dans des scénarios tels que des problèmes de réécriture d’URL ou d’authentification.

Les applications App Service utilisent la même fonctionnalité de suivi de demandes ayant échoué que celle que proposait IIS 7.0 et versions ultérieures. Cependant, vous ne pouvez pas accéder aux paramètres IIS permettant de configurer les erreurs à journaliser. Lorsque vous activez le suivi des demandes ayant échoué, toutes les erreurs sont récupérées.

Vous pouvez activer le suivi des demandes ayant échoué en utilisant Visual Studio, mais vous ne pouvez pas les afficher dans Visual Studio. Ces journaux d’activité sont des fichiers XML. Le service de journaux de streaming surveille uniquement les fichiers jugés lisibles en mode texte brut : fichiers .txt, .html et .log.

Vous pouvez afficher les journaux d’activité de suivi des demandes ayant échoué directement dans un navigateur via FTP ou en local, après avoir utilisé un outil FTP pour les télécharger sur votre ordinateur local. Dans cette section, nous les afficherons directement dans un navigateur.

Dans l’onglet Configuration de la fenêtre Application web Microsoft Azure que vous avez ouverte à partir de l’Explorateur de serveurs, remplacez la valeur du paramètre Suivi des demandes ayant échoué par Activé, puis cliquez sur Enregistrer.
Sur la barre d'adresses de la fenêtre de navigateur qui affiche l'application, ajoutez un caractère supplémentaire à l'URL et appuyez sur Entrée pour provoquer une erreur 404.

Ceci génère un journal de suivi des demandes ayant échoué. La procédure suivante vous montre comment afficher ou télécharger ce journal.
Dans l’onglet Configuration de la fenêtre Application web Microsoft Azure de Visual Studio, cliquez sur Ouvrir l’élément dans le portail de gestion.
Sur le Portail Azure, dans la page Paramètres de votre application, cliquez sur Informations d’identification du déploiement, puis entrez un nouveau nom d’utilisateur et un nouveau mot de passe.

Notes

Lorsque vous vous connectez, vous devez utiliser le nom d'utilisateur complet, avec pour préfixe le nom de l'application. Par exemple, si vous entrez « monid » comme nom d’utilisateur et si le site est « monexemple », vous vous connectez en tant que « monexemple\monid ».
Dans une nouvelle fenêtre de navigateur, accédez à l'URL affichée sous Nom d'hôte FTP ou Nom d'hôte FTPS sur la page Vue d'ensemble de votre application.
Connectez-vous en utilisant les informations d'identification FTP que vous avez créées précédemment (incluant le nom de l'application en tant que préfixe pour le nom d'utilisateur).

Le navigateur affiche le dossier racine de l'application.
Ouvrez le fichier LogFiles .
Ouvrez le dossier nommé W3SVC avec une valeur numérique.

Ce dossier contient des fichiers XML pour plusieurs erreurs journalisées une fois le suivi des demandes ayant échoué activé, ainsi qu'un fichier XSL utilisable par un navigateur pour mettre en forme les fichiers XML.
Cliquez sur le fichier XML de la demande ayant échoué dont vous voulez consulter les informations de suivi.

L'image suivante montre une partie des informations de suivi d'un exemple d'erreur.

Étapes suivantes

Vous avez vu en quoi Visual Studio facilite l’affichage des journaux d’activité créés par une application App Service. Les sections suivantes fournissent des liens vers des ressources supplémentaires sur des rubriques connexes :

Résolution des problèmes App Service
Débogage dans Visual Studio
Débogage distant dans Azure
Suivi dans les applications ASP.NET
Analyse de journaux d’activité de serveur Web
Analyse des journaux d’activité de suivi des demandes ayant échoué
Débogage de Cloud Services

Résolution des problèmes App Service

Pour en savoir plus sur la résolution des problèmes liés aux applications dans Azure App Service, consultez les ressources suivantes :

Surveiller les applications
Étude des fuites de mémoire dans Azure App Service avec Visual Studio 2013. Article sur le blog ALM de Microsoft concernant les fonctionnalités de Visual Studio prévues pour l'analyse de problèmes de mémoire gérés.
Les outils en ligne d'Azure App Service que vous devez connaître. Article de blog par Amit Apple.

Pour obtenir des réponses sur une question relative à la résolution des problèmes, ouvrez un fil de discussion dans l'un des forums suivants :

Débogage dans Visual Studio

Pour plus d’informations sur l’utilisation du mode débogage dans Visual Studio, consultez Débogage dans Visual Studio, puis Conseils de débogage avec Visual Studio 2010.

Débogage distant dans Azure

Pour en savoir plus sur le débogage à distance des applications App Service et des tâches web, consultez les ressources suivantes :

Si votre application utilise une API Web Azure ou un système principal Mobile Services qu'il vous faut déboguer, consultez l'article Débogage du serveur principal .NET dans Visual Studio.

Suivi dans les applications ASP.NET

Il n'y a pas d'autre présentation du suivi ASP.NET plus détaillée et actualisée disponible sur Internet. Nous vous conseillons de commencer par consulter les anciens documents de présentation rédigés pour Web Forms, car MVC n'existait pas encore, et de compléter cela en consultant les billets de blog les plus récents traitant de problèmes plus précis. Les ressources suivantes constituent un bon début :

Surveillance et télémétrie (développement d’applications cloud concrètes avec Azure).
Chapitre de livre électronique contenant des recommandations pour le suivi dans les applications de cloud Azure.
Suivi ASP.NET
Une ressource ancienne mais toujours efficace pour une présentation de base du sujet.
Écouteurs de suivi
Contient des informations sur les écouteurs de suivi mais ne mentionne pas l’élément WebPageTraceListener.
Procédure pas à pas : intégration du suivi ASP.NET avec le suivi System.Diagnostics
Cet article est également ancien, mais vous y trouverez des informations complémentaires que l’article de présentation ne traite pas.
Suivi dans les vues d’ASP.NET MVC Razor
En plus du suivi dans les vues Razor, ce billet explique également comment créer un filtre d'erreur pour journaliser toutes les exceptions non gérées dans une application MVC. Pour plus d'informations sur la procédure de journalisation des exceptions non gérées dans une application Web Forms, consultez l'exemple de Global.asax dans Exemple complet pour les gestionnaires d'erreurs sur MSDN. Dans MVC ou Web Forms, si vous voulez journaliser certaines exceptions tout en laissant le Framework par défaut les gérer, vous pouvez utiliser l'exemple de code suivant :
```
try
{
   // Your code that might cause an exception to be thrown.
}
catch (Exception ex)
{
    Trace.TraceError("Exception: " + ex.ToString());
    throw;
}
```
Journalisation de suivi de diagnostics de diffusion à partir de l’outil en ligne de commande Azure (et Glimpse)
Apprenez à utiliser l’outil en ligne de commande pour effectuer ce que montre ce didacticiel dans Visual Studio. Glimpse est un outil pour le débogage d'applications ASP.NET.
Utilisation des fonctions de journalisation et de diagnostic des applications web - avec David Ebbo et Journaux d’activité de streaming dans Web Apps - avec David Ebbo
par Scott Hanselman et David Ebbo.

Pour la journalisation d'erreurs, vous pouvez éviter d'avoir à écrire votre propre code de suivi en utilisant un Framework de journalisation Open Source comme ELMAH. Pour plus d'informations, consultez les billets du blog de Scott Hanselman sur ELMAH.

En outre, vous n’avez pas besoin d’utiliser ASP.NET ou le suivi System.Diagnostics pour obtenir les journaux d’activité de streaming à partir d’Azure. Le service de journaux de diffusion en continu de l'application App Service diffuse tous les fichiers .txt, .html ou .log qu'il trouve dans le dossier LogFiles. Par conséquent, vous pouvez créer votre propre système de journalisation, qui écrit des données dans le système de fichiers de l'application ; votre fichier est automatiquement diffusé en continu et téléchargé. Tout ce que vous avez à faire est d’écrire un code d’application qui crée les fichiers dans le dossier d:\home\logfiles.

Analyse de journaux d’activité de serveur Web

Pour plus d’informations sur l’analyse des journaux d’activité de serveur Web, consultez les ressources suivantes :

LogParser
Un outil pour afficher les données des journaux d’activité de serveur Web (fichiers .log ).
Résolution des problèmes de performances IIS ou des erreurs d’application à l’aide de LogParser
Une introduction à l’outil LogParser que vous pouvez utiliser pour analyser les journaux d’activité de serveur Web.
Billets du blog de Robert McMurray sur l’utilisation de LogParser
Code d’état HTTP dans IIS 7.0, IIS 7.5 et IIS 8.0

Analyse des journaux d’activité de suivi des demandes ayant échoué

Le site web Microsoft TechNet comporte une section Utilisation du suivi des demandes ayant échoué qui permet de comprendre l’utilisation de ces journaux d’activité. Toutefois, cette documentation se concentre principalement sur la configuration du suivi des demandes ayant échoué dans IIS, ce que vous ne pouvez pas faire dans Azure App Service.

Partage via