Partager via

Utilisation des règles de suivi des demandes ayant échoué pour résoudre les problèmes de routage des demandes d’application

  • Article

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 de suivre les étapes 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 de requêtes ayant échoué à l’aide du suivi dans IIS 8.5.

Objectif

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.

Configuration requise

Cette procédure pas à pas nécessite les prérequis suivants :

  • IIS 7.0 ou version ultérieure sur Windows 2008 (n’importe quelle référence SKU) ou version ultérieure avec le service de rôle Suivi installé pour IIS.
  • Routage des demandes d’application Microsoft et modules dépendants.
  • Au moins deux serveurs d’applications 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 suivi 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 fonctionnement 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.

Guide pratique pour configurer des règles de suivi des demandes ayant échoué à l’aide de l’interface utilisateur

  1. Lancez le Gestionnaire des services Internet (IIS) (inetmgr).
  2. Sélectionnez Site web par défaut.
    Capture d’écran montrant la liste sites développée. Le site web par défaut est mis en surbrillance.
  3. Dans le volet Actions , sous Configurer, sélectionnez Suivi des demandes ayant échoué....
    Capture d’écran axée sur le suivi des demandes ayant échoué dans le volet Actions.
  4. Dans la boîte de dialogue Modifier les paramètres de suivi des demandes ayant échoué sur un site web , cochez la case Activer.
    Capture d’écran de la boîte de dialogue Modifier les paramètres de suivi des demandes ayant échoué.
  5. Sélectionnez OK pour enregistrer les modifications.
  6. Sélectionnez Site web par défaut.
  7. Double-cliquez sur Règles de suivi des demandes ayant échoué.
  8. Dans le volet Actions , sélectionnez Ajouter....
    Capture d’écran de la fenêtre Ajouter une règle de suivi des demandes ayant échoué. Tout le contenu est sélectionné.
    Sélectionnez Tout le contenu (*), puis Suivant.
  9. Sélectionnez Code(s) d’état : et entrez 200-399.
    Capture d’écran de l’ajout d’une règle de suivi des demandes ayant échoué. Le code d’état est vérifié.
    Sélectionnez Suivant. La configuration ci-dessus a créé une règle de suivi des demandes ayant échoué qui écrit des traces lorsque le code status est compris entre 200 et 399.
  10. Désélectionnez ASP, ASPNET et Extension ISAPI. Après avoir sélectionné le serveur WWW, désélectionnez tout sous Zones :, à l’exception de Réécriture et RequestRouting. Étant donné que le routage des demandes d’application s’appuie sur le module de 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).
    Capture d’écran de la fenêtre Modifier la règle de suivi des demandes ayant échoué. Le serveur W W est sélectionné dans la section Fournisseurs.
    Pour plus d’informations sur les traces de module de réécriture d’URL, consultez Using Failed Request Tracing to Trace Rewrite Rules .
  11. Sélectionnez Terminer.

Guide pratique pour configurer des règles de suivi des demandes ayant échoué à l’aide de la ligne de commande

  1. Ouvrez une invite de commandes avec des privilèges d’administrateur.

  2. Accédez à la page %windir%\system32\inetsrv.

  3. 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

  4. 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 demandes ayant échoué

  1. Accédez au répertoire dans lequel les journaux de suivi des demandes ayant échoué sont écrits. Par défaut, l’emplacement est %SystemDrive%\inetpub\Logs\FailedReqLogFiles\.

  2. Remplacez le répertoire par le dossier qui correspond au site web par défaut. Par défaut, il s’agit de W3SVC1. Si vous n’êtes pas sûr, 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).

  3. S’il existe des fichiers XML, supprimez-les en tapant :

    del *.xml

  4. Envoyer une requête au routage des demandes d’application. Si le routage des demandes d’application fonctionne correctement, il génère une réponse 200, qui se situe dans la plage de 200 à 399 spécifiée à l’étape 1. Par conséquent, les journaux sont écrits à l’emplacement ci-dessus.

  5. Répertoriez les fichiers dans le répertoire pour vérifier que les nouveaux fichiers XML sont écrits.

  6. Ouvrez le fichier XML. Sélectionnez Détails de la demande. Sélectionnez Suivi complet de la demande, 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 :
    Capture d’écran d’une fenêtre de navigateur montrant l’onglet Demander des diagnostics pour l’exemple de site web.

  7. Portez une attention particulière aux sections suivantes :

    • GENERAL_REQUEST_HEADERS :

      • En-têtes : affiche l’en-tête HTTP reçu par le routage des demandes 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 qui explique pourquoi le serveur est sélectionné.

    • ARR_SERVER_STATS :

      • État : disponibilité du serveur de destination.
      • TotalRequests : statistique d’exécution sur le nombre de demandes 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 qui ont été 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 du serveur de destination.

    • GENERAL_RESPONSE_ENTITY_BUFFER

      • Mémoire tampon : affiche l’entité de réponse du serveur de destination.

    • Les éléments suivants ont été ajoutés avec les horodatages pour indiquer les heures de début et de fin des événements correspondants afin de profiler les performances du routage des demandes 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 correctement 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 résoudre les problèmes et déboguer le routage des demandes d’application, ainsi que pour comprendre les décisions de routage, y compris les algorithmes d’équilibrage de charge, qu’elle a prises lors de la sélection du serveur de destination pour une requête donnée.