Résoudre les échecs de requêtes à l’aide du suivi dans IIS 8.5
S’applique à : Internet Information Services 8.5
Introduction
Le suivi basé sur les demandes est disponible à la fois dans les serveurs IIS autonomes et sur les sites web Microsoft Azure (WAWS). Si vous pouvez reproduire le problème que vous rencontrez, le suivi basé sur les demandes permet de déterminer exactement ce qui se passe avec vos demandes et pourquoi cela se produit. Des problèmes tels que des performances médiocres sur certaines demandes, des échecs liés à l’authentification sur d’autres demandes, ou l’erreur serveur 500 d’ASP ou de ASP.NET peuvent souvent être difficiles à résoudre, sauf si vous avez capturé la trace du problème lorsqu’il se produit. Cet article traite du suivi des demandes ayant échoué sur le serveur IIS. Pour plus d’informations sur cette opération avec les sites web Microsoft Azure, consultez Résoudre les problèmes d’une application dans Azure App Service à l’aide de Visual Studio.
Le suivi des demandes ayant échoué est conçu pour mettre en mémoire tampon les événements de trace d’une requête et les vider uniquement sur le disque en cas d’échec de la demande, où vous fournissez la définition d’échec. Si vous souhaitez savoir pourquoi vos demandes retournent un code d’état HTTP spécifique, par exemple, 401 ou 404, ou si une demande prend un certain temps pour traiter ou ne répond pas, vous pouvez utiliser le suivi des demandes ayant échoué.
Les tâches décrites dans cet article sont les suivantes :
- Activation du module Suivi des demandes ayant échoué.
- Configuration de la sémantique du fichier journal de suivi des demandes ayant échoué.
- Définition de l’URL pour laquelle conserver les traces des demandes ayant échoué, y compris les définitions d’échec et les zones à suivre.
- Génération de la condition d’échec et affichage de la trace résultante.
Prerequisites
Installer IIS
Installez IIS 8.5 avant de pouvoir effectuer les tâches décrites dans cet article. Accédez à http://localhost/
et que l’écran de démarrage des services d’Internet Information Services s’affiche. Si IIS n’est pas installé, consultez Installation d’IIS 8.5 sur Windows Server 2012 R2 pour obtenir des instructions d’installation. Lors de l’installation d’IIS, vérifiez que vous installez également les fonctionnalités suivantes :
- ASP.NET 3.5 (sous Web Server (IIS)Web/ Server/Application Development Features/ASP.NET 3.5)
- ASP.NET 4.5 (sous Web Server (IIS)Web/ Server/Application Development Features/ASP.NET 4.5)
- Suivi (sous Serveur Web (IIS)Intégrité/ et diagnostics du serveur/web - Suivi)
Se connecter en tant qu’administrateur
Vérifiez que le compte que vous utilisez pour vous connecter est le compte d’administrateur ou se trouve dans le groupe Administrateurs.
Note
Le fait d’être dans le groupe Administrateurs ne vous accorde pas les droits d’utilisateur d’administrateur par défaut. Vous devez exécuter des applications en tant qu’administrateur en cliquant avec le bouton droit sur l’icône de l’application et en sélectionnant Exécuter en tant qu’administrateur.
Effectuer une sauvegarde
Effectuez une sauvegarde des fichiers de configuration avant d’effectuer les tâches suivantes :
Sélectionnez simultanément la touche de logo Windows et la touche X, sélectionnez Invite de commandes (Administrateur), puis Oui.
Dans l’invite de commandes, exécutez la commande suivante :
%windir%\system32\inetsrv\appcmd add backup cleanInstall
Cette commande crée un dossier cleanInstall contenant des fichiers de configuration de sauvegarde dans %windir%\system32\inetsrv\backup.
Créer un exemple de contenu
Accédez à %systemdrive%\inetpub\wwwroot.
Déplacez le contenu vers un emplacement sûr (au cas où vous souhaiteriez restaurer le contenu existant) ou supprimez-le.
Créez un fichier vide et nommez-le test.asp.
Dans l’invite de commandes, accédez au fichier test.asp dans \inetpub\wwwroot.
Dans le fichier test.asp , collez le contenu suivant :
<h2>Failed Request Tracing Lab</h2><br> <br>Today's date is <% response.write(Date()) %>
Désactiver ASP
ASP doit être désactivé pour cette tâche. ASP n’est désactivé qu’à titre d’exemple et pour les besoins des tâches de cet article.
Pour désactiver ASP, procédez comme suit :
Ouvrez le Gestionnaire IIS et sélectionnez le serveur.
Double-cliquez sur Restrictions ISAPI et CGI.
Dans le volet Restrictions ISAPI et CGI, sélectionnez Pages Active Server. Dans le volet Actions , sélectionnez Refuser pour désactiver ASP. Les pages de serveur active s’affichent comme non autorisées.
Activer le suivi des demandes ayant échoué
Après avoir activé le suivi des demandes ayant échoué, vous devez configurer le chemin des fichiers journaux. Dans cette section, vous allez activer le suivi des demandes ayant échoué pour le site web par défaut et spécifier où stocker les fichiers journaux, puis configurer l’échec pour lequel générer les journaux d’échec.
Étape 1 : Activer le suivi des demandes ayant échoué pour le site et configurer le répertoire du fichier journal
Ouvrez une invite de commandes avec des droits utilisateur d’administrateur et accédez à %systemdrive%\windows\system32\inetsrv.
Exécutez pour
inetmgr
ouvrir le Gestionnaire IIS.Dans le volet Connexions, développez le nom de l’ordinateur, développez Sites, puis sélectionnez Site web par défaut.
Dans le volet Actions, sous Configurer, sélectionnez Suivi des requêtes ayant échoué....
Dans la boîte de dialogue Modifier les paramètres de suivi des demandes ayant échoué sur le site web, configurez les éléments suivants :
- Cochez la case Activer .
- Conservez les valeurs par défaut pour les autres paramètres.
Cliquez sur OK.
La journalisation du suivi des demandes ayant échoué est désormais activée pour le site web par défaut. Vérifiez le fichier %windir%\system32\inetsrv\config\applicationHost.config pour vérifier que la configuration se présente comme suit :
<system.applicationHost> <!-- other system configuration --> <sites> <site name="Default Web Site" id="1"> <!-- other site configuration --> <traceFailedRequestsLogging enabled="true" /> </site> <!-- site & app defaults --> <!-- other sites configuration --> </sites> <!-- other system configuration --> </system.applicationHost>
Étape 2 : Configurer vos définitions d’échec
Dans cette étape, configurez les définitions d’échec de votre URL, y compris les zones à suivre. Vous allez dépanner un code d’état 404.2 retourné par IIS pour toutes les demandes adressées aux extensions qui n’ont pas encore été activées. Il vous aide à déterminer quelles extensions particulières vous devez activer. Pour plus d’informations, consultez les codes d’état HTTP dans IIS.
Ouvrez une invite de commandes avec des droits utilisateur d’administrateur et accédez à %systemdrive%\windows\system32\inetsrv.
Exécutez pour
inetmgr
ouvrir le Gestionnaire IIS.Dans le volet Connexions, développez le nom de l’ordinateur, développez Sites, puis sélectionnez Site web par défaut.
Double-cliquez sur Règles de suivi des requêtes ayant échoué.
Dans le volet Actions , sélectionnez Ajouter....
Dans l’Assistant Ajouter une règle de suivi des demandes ayant échoué, dans la page Spécifier le contenu à suivre , sélectionnez Tout le contenu (*), puis sélectionnez Suivant.
Dans la page Définir les conditions de trace, cochez la case Codes d’état et entrez 404.2 comme code d’état à suivre.
Cliquez sur Suivant.
Dans la page Sélectionner les fournisseurs de trace, sous Fournisseurs, cochez la case Serveur WWW et désactivez toutes les autres cases. Sous Zones, cochez la case Sécurité et décochez toutes les autres cases.
Le problème que vous générez provoque la levée d’un événement de suivi des erreurs de sécurité. En général, les problèmes d’authentification et d’autorisation (y compris les problèmes de liste de restrictions ISAPI) peuvent être diagnostiqués à l’aide de la configuration de la zone de sécurité WWW Server - Security pour le suivi. Toutefois, étant donné que la feuille de style FREB.xsl permet de mettre en surbrillance les erreurs et les avertissements, vous pouvez toujours utiliser la configuration par défaut pour journaliser tous les événements dans toutes les zones et fournisseurs.
Sous Verbosité, sélectionnez Détaillée.
Remarque
Lorsque vous installez le service de rôle suivi, IIS installe par défaut les fournisseurs de trace d’extension WWW Server, ASP et ISAPI. Si vous installez ASP.NET 2.0 ou version ultérieure, IIS ajoute automatiquement le fournisseur de suivi ASPNET. Des fournisseurs supplémentaires sont installés par le package d’installation Application Request Routing (ARR), qui installe également le module réécriture d’URL, la gestion de batterie de serveurs web et le cache externe. Vous pouvez ajouter d’autres fournisseurs de suivi à l’aide de l’élément
<add>
dans l’élément<traceProviderDefinitions>
.Sélectionnez Terminer.
Vous voyez la définition suivante pour le site web par défaut :
Le Gestionnaire IIS écrit la configuration dans le fichier
%systemdrive%\inetpub\wwwroot\web.config
à l’aide d’une balise<location>
. La configuration doit resembler les éléments suivants :<configuration> <system.webServer> <tracing> <traceFailedRequests> <add path="*"> <traceAreas> <add provider="WWW Server" areas="Security" verbosity="Verbose" /> </traceAreas> <failureDefinitions statusCodes="404.2" /> </add> </traceFailedRequests> </tracing> </system.webServer> </configuration>
Tester et afficher le fichier journal des demandes d’échec
Cette section vous aide à générer une demande ayant échoué et à afficher le journal de trace résultant. Vous avez déjà configuré IIS pour capturer les journaux de trace pour les demandes http://localhost/*.asp
qui échouent avec un code de réponse HTTP de 404.2. Vérifiez maintenant qu’elle fonctionne.
Étape 1 : Générer une erreur et le fichier journal des demandes d’échec
Ouvrez une nouvelle fenêtre Internet Explorer.
Entrez et
http://localhost/test.asp
appuyez sur Entrée. Le message d’erreur « Erreur HTTP 404.2 - Introuvable » s’affiche.
Étape 2 : Afficher le fichier journal des demandes d’échec
Maintenant que vous avez généré une requête ayant échoué, ouvrez l’Explorateur Windows et accédez à %systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1.
Note
Lorsque IIS écrit le fichier journal des demandes ayant échoué, il écrit un fichier par demande ayant échoué. Une feuille de style freb.xsl est également écrite, à raison d’une par répertoire. Cela vous permet d’afficher les fichiers journaux des demandes d’échec résultants (par exemple, fr000001.xml dans cet exemple).
Cliquez avec le bouton droit sur le fichier journal pour l’erreur 404.2, puis sélectionnez Ouvrir avec ->Internet Explorer. Si c’est la première fois que vous ouvrez un fichier de suivi des demandes ayant échoué, vous devez ajouter about :Internet à la liste des sites approuvés, car la configuration de sécurité renforcée d’Internet Explorer est activée par défaut. Dans ce cas, vous voyez les éléments suivants :
Dans la boîte de dialogue Internet Explorer , ajoutez about :Internet à la liste des sites approuvés en procédant comme suit :
- Sélectionnez le menu Outils , puis sélectionnez Options Internet.
- Sélectionnez l’onglet Sécurité.
- Sélectionnez Zone approuvée, puis sélectionnez Sites.
- Cela permet au XSL de fonctionner.
Vous voyez une page Résumé de la demande après avoir ajouté about :Internet à la liste des sites approuvés :
Un résumé de la demande ayant échoué est enregistré en haut, avec la table Errors &Warnings identifiant les événements qui sont
WARNING
,ERROR
ouCRITICAL ERROR
en gravité. Dans cet exemple, leWARNING
niveau de gravité est dû à la restriction ISAPI. L’image que vous avez tenté de charger était %windir%\system32\inetsrv\asp.dll.Ouvrez le fichier XML brut directement à l’aide d’un éditeur de texte et examinez le contenu de l’événement.
Résumé
Vous avez effectué deux tâches : la configuration du suivi des demandes ayant échoué pour capturer les traces pour toute requête retournée par IIS avec un code d’état 404.2 et en vérifiant que IIS a capturé la trace pour votre demande. Vous avez également vérifié que le fichier journal freb.xml ne contenait pas de requêtes autres que celles avec un code de retour 404.2. Lorsque vous avez consulté le fichier journal des échecs, vous avez déterminé que la cause de l’échec était que l’extension a été désactivée pour cette demande. Vous pouvez essayer d’autres pages non HTML (telles que des .gif ou des fichiers .jpg) et noter que le fichier journal n’ajoute pas ces traces. Vous pouvez également modifier facilement cet événement en 404 ou capturer l’échec si la demande prend plus de 30 secondes en définissant le champ timeTaken dans votre failureDefinitions.
Restaurer votre sauvegarde
Maintenant que vous avez terminé les tâches de cet article, vous pouvez restaurer la sauvegarde de la configuration. Exécutez la commande suivante avec les droits d’utilisateur d’administrateur :
%windir%\system32\inetsrv\appcmd restore backup cleanInstall