Utilisation des règles de suivi des demandes ayant échoué pour résoudre les problèmes de routage des demandes d’application
S’applique à : Internet Information Services 7.0 et versions ultérieures
Le suivi des demandes ayant échoué est un outil puissant pour résoudre les échecs de traitement des demandes dans IIS 7.0 et versions ultérieures. Cet article décrit les étapes permettant d’activer les règles de suivi des demandes ayant échoué pour déboguer les échecs et suivre les étapes de suivi dans le routage des demandes d’application. Pour plus d’informations sur les règles de suivi des demandes ayant échoué, consultez Résoudre les problèmes liés aux demandes ayant échoué à l’aide du suivi dans IIS 8.5.
But
Pour configurer les règles de suivi des demandes ayant échoué et comprendre ce qu’il faut rechercher lors de la résolution des problèmes de routage des demandes d’application.
Prérequis
Cette procédure pas à pas nécessite les prérequis suivants :
- IIS 7.0 ou version ultérieure sur Windows 2008 (toute référence SKU) ou ultérieure avec le service de rôle de suivi installé pour IIS.
- Routage des demandes d’application Microsoft et modules dépendants.
- Minimum de deux serveurs d’application avec des sites de travail et des applications.
Si le routage des demandes d’application n’a pas été installé, téléchargez-le à partir du Centre de téléchargement et installez-le en suivant les étapes décrites dans Installer le routage des demandes d’application.
Un autre prérequis est que vous avez effectué l’utilisation du module de routage des demandes d’application et que vous avez configuré le routage des demandes d’application. Le routage des demandes d’application doit être en ordre de travail avant de passer aux sections suivantes.
Étape 1 : Configurer les règles de suivi des demandes ayant échoué
Configurez les règles de suivi des demandes ayant échoué pour le routage des demandes d’application à l’aide de l’interface utilisateur ou de la ligne de commande.
Comment configurer des règles de suivi des demandes ayant échoué à l’aide de l’interface utilisateur
- Lancez le Gestionnaire des services Internet (IIS) (inetmgr).
- 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é du site web, cochez la case Activer .
- Sélectionnez OK pour enregistrer les modifications.
- 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....
Sélectionnez Tout le contenu (*), puis sélectionnez Suivant. - Sélectionnez Le ou les codes d’état : entrez 200-399.
Cliquez sur Suivant. La configuration ci-dessus a créé une règle de suivi des demandes ayant échoué qui écrit les traces lorsque le code d’état tombe entre 200 et 399. - Désélectionnez les extensions ASP,ASPNET et ISAPI. Après avoir sélectionné WWW Server, désélectionnez tout sous Zones :, à l’exception de Réécrire et de RequestRouting. Étant donné que le routage des demandes d’application s’appuie sur le module réécriture d’URL pour inspecter les demandes entrantes, il est recommandé d’activer les traces pour le routage des demandes d’application (RequestRouting) et le module de réécriture d’URL (réécriture).
Pour plus d’informations sur les traces de module de réécriture d’URL, consultez Utilisation du suivi des demandes ayant échoué pour suivre les règles de réécriture. - Sélectionnez Terminer.
Comment configurer les règles de suivi des demandes ayant échoué à l’aide de la ligne de commande
Ouvrez une invite de commandes avec des privilèges administrateur.
Accédez à
%windir%\system32\inetsrv
.Pour activer le suivi des demandes ayant échoué sur le site web par défaut, exécutez la commande suivante :
appcmd set site "Default Web Site" -traceFailedRequestsLogging.enabled:"true" /commit:apphost
Pour configurer les règles de suivi des demandes ayant échoué, comme indiqué dans l’interface utilisateur ci-dessus, exécutez les commandes suivantes :
appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*']"
appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*'].traceAreas.[provider='WWW Server',areas='Rewrite,RequestRouting',verbosity='Verbose']"
appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /[path='*'].failureDefinitions.statusCodes:"200-399"
Étape 2 : Analyser les journaux de suivi des demandes ayant échoué
Dans cette étape, vous allez envoyer des demandes au routage des demandes d’application et analyser les journaux de suivi des demandes ayant échoué.
Pour afficher les journaux de suivi des requêtes ayant échoué
Accédez au répertoire dans lequel les journaux de suivi des requêtes ayant échoué sont écrits. Par défaut, l'emplacement est
%SystemDrive%\inetpub\Logs\FailedReqLogFiles\
.Remplacez le répertoire par le dossier correspondant au site web par défaut. Par défaut, il s’agit de W3SVC1. Si vous ne savez pas, sélectionnez le site web par défaut dans le Gestionnaire des services Internet, puis sélectionnez Paramètres avancés... dans le volet Actions . La valeur de l’ID indique le dossier correspondant. (Par exemple, l’ID 1 correspond à W3SVC1).
S’il existe des fichiers XML, supprimez-les en tapant :
del *.xml
Envoyez une demande au routage des requêtes d’application. Si le routage des demandes d’application fonctionne correctement, il génère une réponse de 200, qui se situe dans la plage 200 à 399 spécifiée à l’étape 1. Par conséquent, les journaux sont écrits à l’emplacement ci-dessus.
Répertoriez les fichiers dans le répertoire pour vérifier que les nouveaux fichiers XML sont écrits.
Ouvrez le fichier XML. Sélectionnez Détails de la demande. Sélectionnez Terminer la trace des demandes, puis sélectionnez Développer tout. L’image suivante est un exemple de journal de suivi des demandes ayant échoué pour le routage des demandes d’application :
Faites attention aux sections suivantes :
GENERAL_REQUEST_HEADERS :
- En-têtes : affiche l’en-tête HTTP reçu par le routage des requêtes d’application.
ARR_REQUEST_ROUTED :
- WebFarm : indique le nom du groupe de serveurs où la requête est routée.
- Serveur : indique le serveur de destination où la requête est routée.
- Algorithme : indique l’algorithme d’équilibrage de charge utilisé.
- RoutingReason : indique la décision derrière la raison pour laquelle le serveur est sélectionné.
ARR_SERVER_STATS :
- État : disponibilité du serveur de destination.
- TotalRequests : statistique d’exécution sur le nombre de requêtes envoyées à ce serveur.
- CurrentRequests : statistique d’exécution sur le nombre simultané de requêtes HTTP adressées à ce serveur.
- BytesSent : statistique d’exécution sur la quantité de données en Ko envoyées à ce serveur.
- BytesReceived : statistique d’exécution sur la quantité de données en Ko reçues de ce serveur.
- ResponseTime : statistique d’exécution sur la réactivité en ms de ce serveur.
GENERAL_RESPONSE_HEADERS
- En-têtes : affiche l’en-tête HTTP de réponse à partir du serveur de destination.
GENERAL_RESPONSE_ENTITY_BUFFER
- Mémoire tampon : affiche l’entité de réponse du serveur de destination.
Les horodatages suivants ont été ajoutés pour indiquer les heures de début et de fin des événements correspondants pour profiler les performances du routage des requêtes d’application :
- ARR_REQUEST_HEADERS_START
- ARR_REQUEST_HEADERS_END
- ARR_RESPONSE_HEADERS_START
- ARR_RESPONSE_HEADERS_END
- ARR_RESPONSE_ENTITY_START
- ARR_RESPONSE_ENTITY_END
- ARR_RESPONSE_ENTITY_START
- ARR_RESPONSE_ENTITY_END
Si vous collectez les journaux de suivi des demandes ayant échoué sur le cœur du serveur, copiez les journaux avec la feuille de style freb.xsl sur un ordinateur sur lequel un navigateur est disponible.
Résumé
Vous avez maintenant configuré les règles de suivi des demandes ayant échoué pour le routage des demandes d’application. Les règles de suivi des demandes ayant échoué peuvent être utilisées pour dépanner et déboguer le routage des demandes d’application, ainsi que comprendre les décisions de routage, y compris les algorithmes d’équilibrage de charge, qu’elle a effectuées lors de la sélection du serveur de destination pour une demande donnée.