Résoudre les problèmes liés aux demandes ayant échoué à l’aide du suivi dans IIS 8.5

S’applique à : Internet Information Services 8.5

Introduction

Le suivi basé sur les requêtes 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 ce qui se passe exactement avec vos demandes et pourquoi il se produit. Les problèmes tels que les performances médiocres sur certaines demandes, les échecs liés à l’authentification sur d’autres demandes ou l’erreur server 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 décrit le 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 demande et les vider uniquement sur le disque en cas d’échec de la requête, où vous fournissez la définition de l’échec. Si vous souhaitez savoir pourquoi vos requêtes retournent un code status HTTP spécifique, par exemple 401 ou 404, ou si le traitement d’une requête prend un certain temps ou ne répond pas, vous pouvez utiliser le suivi des demandes ayant échoué.

Voici quelques-unes des tâches expliquées dans cet article :

• Activation du module Suivi des demandes ayant échoué.
• Configuration de la sémantique du fichier journal du 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.

Configuration requise

Installer IIS

Installez IIS 8.5 avant de pouvoir effectuer les tâches décrites dans cet article. Accédez à http://localhost/ et vérifiez que l’écran de démarrage des services Internet Information 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, veillez à installer é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 - Traçage)

Se connecter en tant qu’administrateur

Vérifiez que le compte que vous utilisez pour vous connecter est le compte administrateur ou qu’il fait partie du groupe Administrateurs.

Remarque

Le fait d’être dans le groupe Administrateurs ne vous accorde pas de droits d’utilisateur d’administrateur complets 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 :

1. Sélectionnez simultanément la touche de logo Windows et la touche X, sélectionnez Invite de commandes (Administration),puis oui.

   

2. 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 les fichiers de configuration de sauvegarde dans %windir%\system32\inetsrv\backup.

Créer un exemple de contenu

1. Accédez à %systemdrive%\inetpub\wwwroot.

2. Déplacez le contenu vers un emplacement sécurisé (si vous souhaitez restaurer le contenu existant) ou supprimez-le.

3. Créez un fichier vide et nommez-le test.asp.

4. Dans l’invite de commandes, accédez au fichier test.asp dans \inetpub\wwwroot.

5. 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 est désactivé uniquement à titre d’exemple et pour les besoins des tâches décrites dans cet article.

Pour désactiver ASP, procédez comme suit :

1. Ouvrez le Gestionnaire des services Internet et sélectionnez le serveur.

2. Double-cliquez sur Restrictions ISAPI et CGI.

   

3. Dans le volet Restrictions ISAPI et CGI , sélectionnez Pages serveur actives. Dans le volet Actions , sélectionnez Refuser pour désactiver ASP. Les pages Active Server 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

1. Ouvrez une invite de commandes avec des droits d’utilisateur d’administrateur et accédez à %systemdrive%\windows\system32\inetsrv.

2. Exécutez inetmgr pour ouvrir le Gestionnaire des services Internet.

3. Dans le volet Connections, développez le nom de l’ordinateur, développez Sites, puis sélectionnez Site web par défaut.

4. Dans le volet Actions , sous Configurer, sélectionnez Suivi des demandes ayant échoué....

   

5. Dans la boîte de dialogue Modifier les paramètres de suivi des demandes ayant échoué sur un site web , configurez les éléments suivants :

   • Cochez la case Activer .
   • Conservez les valeurs par défaut pour les autres paramètres.

   

6. Sélectionnez OK.

   Échec de la journalisation du suivi des demandes est désormais activée pour le site web par défaut. Vérifiez le fichier %windir%\system32\inetsrv\config\applicationHost.config pour confirmer 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 pour votre URL, y compris les zones à suivre. Vous allez résoudre les problèmes d’un code status 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 les extensions particulières que vous devez activer. Pour plus d’informations, consultez Codes status HTTP dans IIS.

1. Ouvrez une invite de commandes avec des droits d’utilisateur d’administrateur et accédez à %systemdrive%\windows\system32\inetsrv.

2. Exécutez inetmgr pour ouvrir le Gestionnaire des services Internet.

3. Dans le volet Connections, développez le nom de l’ordinateur, développez Sites, puis sélectionnez Site web par défaut.

4. Double-cliquez sur Règles de suivi des demandes ayant échoué.

   

5. Dans le volet Actions , sélectionnez Ajouter....

6. Dans l’Assistant Ajout d’une règle de suivi des demandes ayant échoué, dans la page Spécifier le contenu à la trace, sélectionnez Tout le contenu (*),puis suivant.

   

7. Dans la page Définir les conditions de trace, cochez la case Code(s) d’état et entrez 404.2 comme code status à suivre.

   

8. Sélectionnez Suivant.

9. Dans la page Sélectionner les fournisseurs de traces , sous Fournisseurs, cochez la case Serveur WWW et désactivez toutes les autres cases à cocher. Sous Zones, cochez la case Sécurité et désactivez toutes les autres cases à cocher.

   Le problème que vous générez entraîne la levée d’un événement de trace d’erreur de sécurité. En général, les problèmes d’authentification et d’autorisation (y compris les problèmes de liste de restriction ISAPI) peuvent être diagnostiqués à l’aide de la configuration serveur WWW - Zone de sécurité pour le suivi. Toutefois, étant donné que la feuille de style FREB.xsl permet de mettre en évidence les erreurs et les avertissements, vous pouvez toujours utiliser la configuration par défaut pour journaliser tous les événements dans tous les domaines et tous les fournisseurs.

10. Sous Détail, sélectionnez Verbose.

    Remarque

    Lorsque vous installez le service de rôle de suivi, IIS installe les fournisseurs de trace du serveur WWW, d’ASP et de l’extension ISAPI par défaut. Si vous installez ASP.NET 2.0 ou version ultérieure, IIS ajoute automatiquement le fournisseur de trace ASPNET. Des fournisseurs supplémentaires sont installés par le package d’installation ARR (Application Request Routing), qui installe également le module de réécriture d’URL, la gestion de la batterie de serveurs web et le cache externe. Vous pouvez ajouter d’autres fournisseurs de trace à l’aide de l’élément <add> dans l’élément <traceProviderDefinitions> .

    

11. Sélectionnez Terminer.

12. Vous voyez la définition suivante pour le site web par défaut :

    

    Le Gestionnaire des services Internet écrit la configuration dans le fichier à l’aide %systemdrive%\inetpub\wwwroot\web.config d’une <location> balise. La configuration doit réémêler 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 http://localhost/*.asp les requêtes qui échouent avec un code de réponse HTTP de 404.2. Vérifiez maintenant qu’il fonctionne.

Étape 1 : Générer une erreur et le fichier journal de la demande d’échec

1. Ouvrez une nouvelle fenêtre internet Explorer.

2. Entrez et http://localhost/test.aspappuyez sur Entrée. Le message d’erreur « Erreur HTTP 404.2 - Introuvable » s’affiche.

   

Étape 2 : Afficher le fichier journal des demandes d’échec

1. Maintenant que vous avez généré une demande ayant échoué, ouvrez Windows Explorer et accédez à %systemdrive%\inetpub\logs\FailedReqLogFiles\W3SVC1.

   

   Remarque

   Quand 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, une par répertoire. Cela est utile lorsque vous affichez les fichiers journaux des demandes d’échec (comme fr000001.xml dans cet exemple).

2. 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. Si c’est le cas, vous voyez les éléments suivants :

   

3. Dans la boîte de dialogue Internet Explorer, ajoutez about :internet à la liste des sites approuvés en procédant comme suit :

   1. Sélectionnez le menu Outils , puis Sélectionnez Options Internet.
   2. Sélectionnez l’onglet Sécurité.
   3. Sélectionnez Zone approuvée, puis Sites.
   4. Cela permet au XSL de fonctionner.

4. Une page Résumé de la demande s’affiche 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 Erreurs & Avertissements identifiant tous les événements de WARNINGgravité , ERRORou CRITICAL ERROR . Dans cet exemple, le WARNING niveau de gravité est dû à la RESTRICTION ISAPI. L’image que vous avez essayé de charger était %windir%\system32\inetsrv\asp.dll.

5. 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é afin de capturer les traces pour toute requête retournée par IIS avec un code de status 404.2 et la vérification qu’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 était désactivée pour cette demande. Vous pouvez essayer d’autres pages non HTML (comme les fichiers .gif ou .jpg) et notez que le fichier journal n’ajoute pas ces traces. Vous pouvez également facilement modifier cet événement sur 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 décrites dans 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