Partager via


Utiliser le suivi des demandes ayant échoué pour résoudre les erreurs ASP classiques

S’applique à : Internet Information Services

L’une des principales fonctionnalités de résolution des problèmes intégrées à Internet Information Services (IIS) est le suivi des demandes ayant échoué. La fonctionnalité vous permet de configurer des règles de suivi sur votre serveur, qui créent des fichiers journaux de résolution des problèmes détaillés pour les conditions d’échec personnalisées que vous définissez. Par exemple, vous pouvez capturer les détails des échecs d’authentification en créant des règles de suivi qui créent des fichiers journaux pour les erreurs HTTP 401.

Le suivi des échecs de requêtes dans IIS peut être configuré pour suivre les échecs de manière passive. Cela signifie que vous pouvez ajouter des règles de suivi à IIS qui créent des fichiers journaux lorsque des erreurs se produisent, même si vous ne surveillez pas activement votre serveur. Par exemple, les étapes décrites dans cet article vous montrent comment créer une règle de suivi qui créera des journaux de suivi chaque fois qu’une erreur HTTP 500 se produit. Cette méthode de suivi passif est connue sous le nom de suivi « no-repro », ce qui signifie que vous pouvez régulièrement examiner les journaux de votre serveur pour vérifier si des défaillances se sont produites, puis prendre des mesures uniquement lorsque IIS a créé des journaux.

Utiliser le contrôle d’accès utilisateur

Pour vous assurer que vous suivez les étapes décrites dans cet article à l’aide d’un compte disposant d’autorisations d’administration complètes, utilisez l’une des méthodes suivantes :

  • Connectez-vous à votre ordinateur à l’aide du compte d’administrateur local.
  • Si vous êtes connecté à l’aide d’un compte disposant d’autorisations d’administration au lieu du compte d’administrateur local, ouvrez toutes les applications et toutes les sessions d’invite de commandes à l’aide de l’option Exécuter en tant qu’administrateur .

Ces conditions sont requises, car le composant de sécurité UAC (User Account Control) dans Windows empêche l’accès administratif aux paramètres de configuration IIS. Pour plus d'informations sur le contrôle de compte d'utilisateur, voir Contrôle de compte d’utilisateur.

Installation du suivi des demandes ayant échoué

Le suivi des demandes ayant échoué n’est pas installé par défaut sur IIS. Installez le suivi des demandes ayant échoué en fonction de votre version de Windows.

Système d’exploitation client Windows

  1. Sélectionnez Démarrer>Panneau de configuration.
  2. Dans Panneau de configuration, sélectionnez Programmes et fonctionnalités>activer ou désactiver les fonctionnalités Windows.
  3. Développez Internet Information Services World Wide Web Services>>Health and Diagnostics.
  4. Sélectionnez Suivi, puis OK.

Système d’exploitation Windows Server

  1. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez Gestionnaire de serveur.
  2. Dans le volet Gestionnaire de serveur hiérarchie, développez Rôles, puis sélectionnez Serveur web (IIS).
  3. Dans le volet Serveur web (IIS), faites défiler jusqu’à la section Services de rôle, puis sélectionnez Ajouter des services de rôle.
  4. Dans la page Sélectionner les services de rôle de l’Assistant Ajouter des services de rôle, sélectionnez Suivi, puis Sélectionnez Suivant.
  5. Dans la page Confirmer les sélections d’installation, sélectionnez Installer.
  6. Dans la page Résultats , sélectionnez Fermer.

Pour plus d’informations sur l’installation du suivi des demandes ayant échoué pour IIS, consultez le suivi de suivi<>.

Comment activer le suivi des demandes ayant échoué

  1. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez Le Gestionnaire des services Internet (IIS).
  2. Dans le volet Connexions , sélectionnez la connexion du serveur, le site, l’application ou le répertoire pour lequel vous souhaitez configurer le suivi des demandes ayant échoué.
  3. Dans le volet Actions , sélectionnez Suivi des demandes ayant échoué...
  4. Configurez les options suivantes dans la boîte de dialogue Modifier les paramètres de suivi des demandes ayant échoué :
    • Cochez la case Activer pour activer le suivi.
    • Conservez la valeur par défaut ou entrez un nouveau répertoire dans lequel vous souhaitez stocker les fichiers journaux des demandes ayant échoué dans la zone Répertoire .
    • Entrez le nombre de fichiers de trace des demandes ayant échoué que vous souhaitez stocker dans la zone Nombre maximal de fichiers de trace.
  5. Cliquez sur OK.

Note

Vous pouvez personnaliser le paramètre pour ASP classique, ASP.NET ou pour d’autres conditions spécifiques, mais une règle générique pour les erreurs HTTP 500 est utile pour découvrir diverses conditions d’erreur sur votre serveur web.

Vous pouvez également activer le suivi des demandes ayant échoué à partir d’une invite de commandes à l’aide de l’utilitaire de AppCmd.exe avec la syntaxe suivante :

appcmd.exe set config -section:system.applicationHost/sites /[name='Default Web Site'].traceFailedRequestsLogging.enabled:"True" /commit:apphost

appcmd.exe set config -section:system.applicationHost/sites /[name='Default Web Site'].traceFailedRequestsLogging.directory:"%SystemDrive%\inetpub\logs\FailedReqLogFiles" /commit:apphost

appcmd.exe set config -section:system.applicationHost/sites /[name='Default Web Site'].traceFailedRequestsLogging.maxLogFiles:"50" /commit:apphost

Résoudre les erreurs ASP classiques

Dans cette section, nous générons quelques erreurs à l’aide d’ASP classique afin d’examiner la façon dont le suivi des demandes ayant échoué permet d’identifier les problèmes potentiels. Même si ces exemples ciblent des circonstances spécifiques où vous connaissez la cause de l’échec, vous pouvez utiliser les techniques présentées pour résoudre les situations où la cause de l’échec est inconnue.

Résoudre les erreurs HTTP 500

IIS retourne des erreurs HTTP 500 lorsque les pages ASP ne parviennent pas à s’exécuter, et sans la fonctionnalité de suivi des demandes ayant échoué d’IIS, ces erreurs HTTP 500 peuvent être difficiles à résoudre. Cela est dû au fait que les erreurs ASP se produisent généralement lorsque vous ne résolvez pas activement votre système, de sorte que parfois votre seule option consiste à rechercher dans vos journaux d’activité IIS et à espérer que le module ASP retourne des informations supplémentaires dans les entrées de journal pour les demandes ayant échoué. Dans l’exemple suivant qui utilise le suivi des échecs de requêtes, vous disposez d’un enregistrement détaillé de l’échec que vous pouvez utiliser pour résoudre la situation.

Comment ajouter une règle de suivi pour les erreurs HTTP 500

Les étapes suivantes configurent une règle de suivi des demandes ayant échoué pour les erreurs HTTP 500, que vous utilisez ultérieurement pour résoudre les messages d’erreur ASP classiques :

  1. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez Le Gestionnaire des services Internet (IIS).
  2. Dans le volet Connexions , accédez à la connexion, au site, à l’application ou au répertoire pour lequel vous souhaitez configurer le suivi des demandes ayant échoué.
  3. Dans le volet Accueil, double-cliquez sur Règles de suivi des demandes ayant échoué.
  4. Dans le volet Actions , sélectionnez Ajouter...
  5. Dans la page Spécifier le contenu à suivre de l’Assistant Ajout d’une règle de suivi des échecs de requêtes, vous sélectionneriez généralement le type de contenu que vous souhaitez suivre. Dans ce cas, acceptez la valeur par défaut pour tout le contenu, puis sélectionnez Suivant.
  6. Dans la page Définir les conditions de trace, entrez 500 dans la zone de texte Codes d’état afin de suivre les erreurs HTTP 500, puis sélectionnez Suivant.
  7. Dans la page Sélectionner les fournisseurs de trace, acceptez les valeurs par défaut, puis sélectionnez Terminer.

Créer une page qui appelle une classe COM non valide

Dans cette section, vous examinez une page ASP qui tente de créer une instance d’une classe COM non valide, et cette situation est le plus souvent produite par l’orthographe incorrecte d’une classe COM valide. Pour tester ce problème, enregistrez le code ASP suivant en tant que Bad_class.asp dans le dossier wwwroot d’un site web où vous avez activé le suivi des demandes ayant échoué pour les erreurs HTTP 500 :

<html>
<body>
<h1>Bad Class</h1>
<%
   Set objObject = CreateObject("Bad.Class.Name")
%>
</body>
</html>

Lorsque vous utilisez un navigateur web pour accéder à ce fichier, IIS doit renvoyer un message d’erreur HTTP 500, et IIS crée un journal de suivi des demandes ayant échoué qui est créé dans votre dossier %SystemDrive%\Inetpub\FailedRequestLogFiles\W3SVCnnn par défaut, où W3SVCnnn contient l’identificateur unique de votre site web répertorié dans le Gestionnaire IIS. Les journaux de suivi des échecs de requêtes sont des fichiers XML et IIS crée un fichier XSL qui transforme le code XML en format de présentation que vous pouvez ouvrir dans Internet Explorer.

Lire le journal de trace dans Internet Explorer

Lorsque vous utilisez Internet Explorer ou le mode Internet Explorer dans le navigateur Edge pour ouvrir un fichier journal de suivi des demandes ayant échoué, différentes informations s’affichent dans un résumé de la demande. Ce résumé contient les informations générales relatives à l’environnement pour la condition d’échec, telles que l’URL en cours d’exécution, le pool d’applications, le type d’authentification et le nom d’utilisateur et d’autres informations. Vous remarquez que la raison de l’échec est le code d’état et que l’état est une erreur HTTP 500.

Dans la section Erreurs et Avertissement du résumé, vous voyez un lien de trace d’affichage, comme illustré dans l’illustration suivante :

Capture d’écran d’une fenêtre de navigateur affichant le résumé de la demande d’une erreur de journal de suivi ayant échoué.

Lorsque vous sélectionnez le lien de trace d’affichage, le navigateur passe à la section de la trace où l’échec du script ASP s’est produit. Si vous développez les événements de suivi individuels, vous pouvez afficher les détails spécifiques de l’événement, tels que le chemin d’accès au fichier physique, le numéro de ligne, le code d’erreur ASP et la description et l’extrait de code ASP qui a provoqué l’échec, ce qui, dans ce cas, a été la tentative d’instancier une classe COM non valide.

Un exemple est représenté sur l'illustration suivante :

Capture d’écran d’une fenêtre de navigateur affichant la section de la trace où l’erreur s’est produite.

Résoudre les problèmes liés aux pages lentes

Vous pouvez configurer le suivi des échecs de requêtes pour générer des fichiers journaux pour les pages qui dépassent un intervalle de temps que vous spécifiez, pas seulement pour les erreurs HTTP. Dans un exemple pratique, si vos utilisateurs web se plaignent que les parties du site web semblent parfois lentes, mais qu’elles ne savent pas quelles pages semblent affectées, vous pouvez créer une règle de suivi pendant un intervalle de temps pour créer un fichier journal quand des pages dépassent cet intervalle. Cela vous permet de limiter l’étendue de résolution des problèmes aux pages étant affectées en attendant que IIS crée des fichiers journaux qui répertorient la page. Sans suivi des échecs de requêtes, vous pouvez interroger vos journaux d’activité IIS pour les pages qui prennent beaucoup de temps à s’exécuter mais cela limite uniquement votre étendue à la liste des pages où un problème se produit, pas au problème lui-même. Dans l’exemple suivant, vous localisez la source de l’échec dans la page lente.

Comment ajouter une règle de suivi pour le contenu lent

Les étapes suivantes configurent une règle de suivi des demandes ayant échoué pour les requêtes qui dépassent une période spécifique, que vous utilisez ultérieurement pour résoudre les problèmes liés aux pages ASP lentes.

  1. Sélectionnez Démarrer, pointez sur Outils d’administration, puis sélectionnez Le Gestionnaire des services Internet (IIS).
  2. Dans le volet Connexions , accédez à la connexion, au site, à l’application ou au répertoire pour lequel vous souhaitez configurer le suivi des demandes ayant échoué.
  3. Dans le volet Accueil, double-cliquez sur Règles de suivi des demandes ayant échoué.
  4. Mettez en surbrillance la règle que vous avez créée dans l’exemple précédent, puis sélectionnez Supprimer dans le volet Actions.
  5. Dans le volet Actions , sélectionnez Ajouter...
  6. Dans la page Spécifier le contenu à suivre de l’Assistant Ajout d’une règle de suivi des échecs de requêtes, vous sélectionneriez généralement le type de contenu que vous souhaitez suivre. Dans ce cas, acceptez la valeur par défaut pour tout le contenu, puis sélectionnez Suivant.
  7. Dans la page Définir les conditions de trace :
    • Effacer le ou les codes d’état.
    • Sélectionnez Temps nécessaire (en secondes).
    • Entrez 5 pour le nombre de secondes.
    • Cliquez sur Suivant.
  8. Dans la page Sélectionner les fournisseurs de trace, acceptez les valeurs par défaut, puis sélectionnez Terminer.

Créer une page qui effectue une boucle sans fin

Dans cette condition d’erreur, vous examinez une page qui effectue une boucle sans fin. Ce problème est fréquemment dû au fait qu’une session utilisateur ne parvient pas à quitter correctement une boucle, par exemple lorsque votre code effectue une boucle dans les enregistrements de liste dans une table de base de données. Pour tester ce problème, enregistrez le code ASP suivant en tant que Slow_page.asp dans le dossier wwwroot d’un site web sur lequel vous avez activé le suivi des demandes ayant échoué :

<html>
<body>
<h1>Slow Page</h1>
<%
   Do
      If Response.IsClientConnected = False Then
         Exit Do
      End If
   Loop
%>
</body>
</html>

Lorsque vous utilisez un navigateur web pour accéder à ce fichier, vous ne devez pas voir d’erreur dans votre navigateur web, mais votre navigateur peut ne jamais retourner une page et éventuellement expirer.

Note

Cette page est écrite pour quitter la boucle après avoir fermé votre navigateur Web. Si vous souhaitez quitter la boucle avant que le délai d’expiration du script soit atteint, vous devez fermer manuellement votre navigateur après dix secondes.

Après cinq secondes, IIS crée un journal de suivi des demandes ayant échoué dans votre %dossier SystemDrive%\Inetpub\FailedRequestLogFiles\W3SVCnnn par défaut, où W3SVCnnn contient l’identificateur unique, comme indiqué dans le Gestionnaire DES SERVICES Internet, pour votre site web.

Lire le journal de trace dans Internet Explorer

Comme indiqué dans l’exemple précédent, lorsque vous utilisez le mode Internet Explorer ou Internet Explorer dans le navigateur Microsoft Edge pour ouvrir un fichier journal de suivi des demandes ayant échoué, les informations importantes sont affichées dans un résumé de la demande. Ce résumé contient les informations générales relatives à l’environnement pour la condition d’échec, telles que l’URL en cours d’exécution, le pool d’applications, le type d’authentification et le nom d’utilisateur et d’autres informations. Notez que la raison de l’échec était le temps nécessaire et que le temps était légèrement supérieur à cinq secondes, ce qui était le temps que vous avez entré dans la règle de suivi des demandes ayant échoué.

Note

Vous remarquerez également que le code d’état HTTP de la réponse était HTTP 200, qui est une réponse réussie. Il s’agit de l’un des facteurs qui rendent souvent plus difficile le diagnostic des pages lentes, ce qui les rend plus difficiles à localiser.

Dans la section Erreurs et Avertissement du résumé, vous voyez un lien de trace d’affichage, comme illustré dans l’illustration suivante :

Capture d’écran d’une fenêtre de navigateur affichant le résumé de la demande d’un avertissement de journal de suivi ayant échoué.

Lorsque vous sélectionnez le lien de trace d’affichage, le navigateur accède à la section de la trace où l’échec du script ASP s’est produit. Si vous développez les événements de trace individuels, vous pouvez afficher les détails spécifiques de l’événement, tels que le chemin d’accès au fichier physique, le numéro de ligne, le code d’erreur ASP et la description, ainsi que l’extrait de code ASP qui s’exécutait lors de la création du fichier journal. En utilisant ces informations, vous pouvez examiner votre page ASP et localiser la ligne de code qui s’exécutait à l’intérieur d’une boucle sans fin.

Un exemple est représenté sur l'illustration suivante :

Capture d’écran d’une fenêtre de navigateur affichant la section de la trace où l’avertissement s’est produit.

Plus d’informations

Pour plus d’informations sur le suivi des demandes ayant échoué dans IIS, consultez les articles suivants :