Résoudre les échecs de requêtes à l’aide du suivi dans IIS 7
S’applique à : Internet Information Services 7.0
Note
Cet article s’applique à IIS 7.0. Pour les versions plus récentes, consultez Résoudre les échecs de requêtes à l’aide du suivi dans IIS 8.5.
Le suivi basé sur les demandes est disponible à la fois dans les serveurs IIS autonomes et sur les applications web Azure et permet de déterminer exactement ce qui se passe avec vos demandes et pourquoi, si vous pouvez reproduire le problème que vous rencontrez. Des problèmes tels que des performances médiocres sur certaines demandes, ou des échecs liés à l’authentification sur d’autres demandes, ou l’erreur de serveur 500 provenant d’ASP ou d’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 applications web 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 demande et les vider uniquement sur le disque en cas d’échec de la demande, où vous fournissez la définition de « échec ». Si vous souhaitez savoir pourquoi vous recevez des messages d’erreur 404.2 ou une demande de démarrage suspendu, utilisez le suivi des demandes ayant échoué.
Les tâches illustrées 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
Vous devez installer IIS 7 ou version ultérieure avant de pouvoir effectuer les tâches décrites dans cet article. Accédez à http://localhost/
pour voir si IIS est installé. Si IIS n’est pas installé, consultez l’installation d’IIS sur Windows Server 2008 pour obtenir des instructions d’installation. Lors de l’installation d’IIS, vérifiez que vous installez également les fonctionnalités suivantes :
- ASP.NET (sous fonctionnalités de développement - d’applications world wide web services - ASP.NET)
- Suivi (sous World Wide Web Services - Health and Diagnostics - Tracing)
Se connecter en tant qu’administrateur
Vérifiez que le compte que vous utilisez pour vous connecter est le compte 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 complets par défaut. Vous devez exécuter des applications en tant qu’administrateur, que vous pouvez faire 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
Vous devez effectuer une sauvegarde de la configuration avant d’effectuer les tâches dans les sections suivantes.
Pour effectuer une sauvegarde de la configuration, procédez comme suit :
Sélectionnez Démarrer>tous les accessoires de programmes.>
Cliquez avec le bouton droit sur l’invite de commandes, puis sélectionnez Exécuter en tant qu’administrateur.
Dans une invite de commandes, exécutez la commande suivante :
%windir%\system32\inetsrv\appcmd add backup cleanInstall
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
Ouvrez Gestionnaire des services Internet (IIS) .
Double-cliquez sur Restrictions ISAPI et CGI.
Sélectionnez Pages de serveur actif. Dans le volet Actions , sélectionnez Refuser pour désactiver ASP.
Activer le suivi des demandes ayant échoué
Après avoir activé le suivi des demandes ayant échoué, vous devez configurer l’emplacement des fichiers journaux. Dans cette tâche, vous allez activer le suivi des demandes ayant échoué pour le site web par défaut et spécifier où placer les fichiers journaux. Vous allez ensuite configurer l’échec pour lequel générer des journaux d’échec.
Étape 1 : Activer le suivi des demandes ayant échoué pour le site et configurer le répertoire de fichiers journaux
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 demandes 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>
<sites>
<!-- site & app defaults -->
<site name="Default Web Site" id="1">
<!-- other site configuration -->
<traceFailedRequestsLogging enabled="true" />
</site>
</sites>
</system.applicationHost>
Étape 2 : Configurer vos définitions d’échec
Dans cette étape, vous allez configurer les définitions d’échec de votre URL, y compris les zones à tracer. Vous allez dépanner une version 404.2 retournée par IIS pour toutes les demandes adressées aux extensions qui n’ont pas encore été activées. Cela vous aide à déterminer quelles extensions particulières vous devez activer.
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é.
Sélectionnez Terminer.
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 (*). Cliquez sur 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 des fournisseurs de trace, sous Fournisseurs, cochez la case Serveur WWW . 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.
Sélectionnez Terminer. Vous devriez voir la définition suivante pour le site web par défaut :
Le Gestionnaire IIS écrit la configuration dans le fichier %windir%\system32\inetsrv\config\applicationHost.config
à l’aide d’une balise <location>
. La configuration doit se présenter comme suit :
<location path="Default Web Site">
<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>
</location>
Tester et afficher le fichier journal des demandes d’échec
Dans cette tâche, vous allez 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 l’adresse suivante :
http://localhost/test.asp
.Vous obtenez une erreur « Erreur HTTP 404.2 - Introuvable ».
Étape 2 : Afficher le fichier journal des demandes d’échec
Maintenant que vous avez généré une demande ayant échoué, ouvrez une invite de commandes avec des droits utilisateur d’administrateur et accédez à %systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1.
Exécutez démarrer pour démarrer une fenêtre Internet Explorer à partir du répertoire.
Notez quelques points ici : lorsqu’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 , sélectionnez Ajouter... pour ajouter about :Internet à la liste des sites approuvés. Cela permet au XSL de fonctionner. Vous verrez ce qui suit 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 AVERTISSEMENT, ERROR ou CRITICAL ERROR in Severity. Dans cet exemple, le niveau de gravité WARNING 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 chaque é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 vérifié que IIS a capturé la trace pour votre demande. Vous avez également vérifié que le fichier journal freb.xml ne contenait aucune autre requête pour les demandes que vous avez effectuées, car les requêtes n’avaient pas de code de retour 404.2. Lorsque vous consultez 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 (comme .gif ou .jpg fichiers) et noter que le fichier journal n’ajoute pas ces traces. Vous pouvez également modifier facilement cette valeur 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