Résoudre les erreurs PHP avec le suivi des demandes ayant échoué

S’applique à : Internet Information Services

Lors de l’exécution de PHP, il est parfois impossible d’inspecter une page d’erreur pour diagnostiquer une condition d’erreur. Cette erreur peut se produire dans les cas suivants :

• Vous ne savez pas quelle URL rencontre une erreur.
• L’erreur se produit par intermittence et vous ne pouvez pas la reproduire manuellement (l’erreur peut dépendre d’une entrée utilisateur ou de conditions d’exploitation externes qui peuvent se produire rarement).
• L’erreur se produit uniquement dans l’environnement de production.

Dans ces cas, il est difficile de définir ce que l’erreur est, et encore plus difficile à diagnostiquer. Vous pouvez peut-être déterminer les URL qui provoquent les erreurs en inspectant les journaux de requête ou un journal des erreurs, mais vous pouvez toujours avoir des difficultés à déterminer ce qui a provoqué l’erreur.

Internet Information Services (IIS) facilite le suivi et le diagnostic de ces conditions d’erreur difficiles avec le suivi des demandes ayant échoué, ce qui vous permet de créer des définitions d’échec qui capturent automatiquement les traces d’exécution détaillées de certaines requêtes. Consultez Résoudre les problèmes liés aux demandes ayant échoué à l’aide du suivi dans IIS et utiliser le suivi des demandes ayant échoué pour suivre les règles de réécriture.

Pour faciliter les diagnostics PHP, ces traces peuvent également être effectuées pour capturer les données d’entrée de requête et les données de réponse à partir de PHP. Cela peut fournir l’insight nécessaire pour diagnostiquer ces conditions d’erreur.

Un autre problème d’application assez courant est le code qui bloque ou entre dans une boucle gourmande en ressources. Cela peut souvent se produire parce que :

• Une opération d’E/S bloquante sur un fichier ou un réseau prend beaucoup de temps, par exemple lors de l’accès à un service web distant ou à une base de données.
• Le code présente un bogue qui l’entraîne dans une boucle sans fin (ou longue), éventuellement en surchargeant le processeur ou en allouant de la mémoire.
• Le code se suspend ou s'enlise sur une ressource ou un verrou partagé.

Ces conditions entraînent des délais d’attente ou des délais d’attente longs pour l’utilisateur effectuant la requête, et les conditions peuvent également avoir un impact négatif sur les performances de l’application et même sur le serveur dans son ensemble.

IIS fournit un moyen rapide de déterminer quelles requêtes sont suspendues en inspectant les requêtes en cours d’exécution.

Utiliser le suivi des demandes ayant échoué pour diagnostiquer les erreurs inconnues ou difficiles à reproduire

Le suivi des demandes ayant échoué peut être un moyen efficace de suivre les conditions d’erreur intermittentes ou difficiles à reproduire et de diagnostiquer les conditions d’erreur en inspectant les détails de la demande, de la réponse et de la richesse des événements de trace des modules IIS.

Le suivi des demandes ayant échoué peut être utilisé dans un environnement de production, car il peut être configuré pour suivre uniquement les demandes répondant à la définition d’échec spécifique et éviter la majeure partie de la surcharge de suivi pour les requêtes réussies.

Pour activer le suivi des demandes ayant échoué pour un site (dans cet exemple, nous utilisons TroubleshootingPhp), procédez comme suit :

1. Basculez vers Gestionnaire IIS. S’il est fermé, sélectionnez Démarrer, puis sélectionnez Le Gestionnaire des services Internet (IIS).

2. Développez le nœud serveur, puis développez le nœud Sites.

3. Dans l’arborescence à gauche, recherchez et sélectionnez le nom de votre site.

4. Dans IIS, double-cliquez sur Règles de suivi des demandes ayant échoué.
   

5. Dans le panneau Actions, sélectionnez Modifier le suivi de site.

6. Cochez la case à cocher Activer.

7. Cliquez sur OK.

8. À présent, créez une règle de suivi des demandes ayant échoué. Dans le volet Actions , sélectionnez Ajouter.

9. Laissez l’option Tout le contenu sélectionné.
   

10. Cliquez sur Suivant.

11. Entrez 400-999 dans le ou les codes d’état.
    

12. Cliquez sur Suivant.

13. Laissez les fournisseurs de traces par défaut activés, puis sélectionnez Terminer.

14. À présent, vous pouvez effectuer des demandes. Supposons que ces étapes soient effectuées par d’autres utilisateurs de votre site et que vous ne connaissez pas leurs demandes ou réponses. Par exemple, effectuez les requêtes suivantes à l’aide d’Internet Explorer :

    • Requête http://localhost:84/hello.php
    • Requête http://localhost:84/products.php?productid=3
    • Demande http://localhost:84/products.php?productid=5 (cette page génère une erreur)

15. Recherchez la trace de la demande ayant échoué :

    • Sélectionnez Démarrer, puis sélectionnez Invite de commandes pour ouvrir la fenêtre Invite de commandes.

    • Exécutez la commande suivante pour répertorier les journaux de trace générés pour notre site :

      %windir%\system32\inetsrv\appcmd.exe list traces /site.name:"TroubleshootingPhp"
      

    • Vous obtenez une sortie similaire à :

      TRACE "troubleshootingPhp/fr000001.xml" (url:http://localhost:84/products.php?product=5,statuscode:500,wp:2864)
      

    • La sortie indique qu’un journal de trace a été généré pour une requête à /products.php?product=5, ce qui a entraîné une erreur HTTP 500. Il vous indique que :

      • La page Products.php a provoqué une erreur.
      • L’entrée qui a provoqué une erreur est probablement product=5, car vous ne voyez pas d’échecs pour d’autres chaînes de requête (cette conclusion serait plus précise si cette page est fréquemment accessible ; dans ce cas, vous voyez plusieurs erreurs uniquement pour cette chaîne de requête spécifique).

16. Vous pouvez maintenant obtenir un journal de suivi spécifique pour collecter plus d’informations sur la demande et la cause possible de l’échec. Pour ce faire, exécutez la commande suivante depuis l’invite de commande (à l’aide de l’ID entre guillemets du journal de suivi de la sortie précédente) :

    %windir%\system32\inetsrv\appcmd.exe list traces /site.name:"TroubleshootingPhp" /text:*
    

    Cela doit avoir la sortie similaire à ce qui suit :

    TRACELOG
      TRACE.NAME:" troubleshootingPhp/fr000001.xml"
      PATH:"C:\inetpub\logs\FailedReqLogFiles\W3SVC2\fr000001.xml"
    URL:"http://localhost:84/products.php?product=5"
      STATUSCODE:"500"
      SITE.ID:"2"
      SITE.NAME:"TroubleshootingPhp"
      WP.NAME:"2864"
      APPPOOL.NAME:"TroubleshootingPhp"
      verb:"GET"
      remoteUserName:""
      userName:""
      tokenUserName:"NT
    AUTHORITY\IUSR"
      authenticationType:"anonymous"
      activityId:"{ 00000000-0000-0000-1400-0080000000FA }"
      failureReason:"STATUS_CODE"
      triggerStatusCode:"500"
      timeTaken:"100"
    xmlns:freb:"http://schemas.microsoft.com/win/2006/06/iis/freb"
    

17. Inspectez le journal des traces. Ouvrez le fichier journal de trace dans le navigateur, en utilisant le chemin spécifié dans la sortie précédente (dans cet exemple, il s’agit de C :\inetpub\logs\FailedReqLogFiles\W3SVC2\fr000001.xml). L’onglet Résumé fournit des informations de base sur la requête. Vous pouvez voir que l’état d’erreur a été défini par FastCGIModule, ce qui suggère que l’erreur provient de PHP. Dans d’autres cas, vous pouvez constater que l’erreur provient d’autres modules IIS, auquel cas vous pouvez utiliser la richesse des informations de suivi dans le journal pour déterminer la cause. Dans ce cas, toutefois, vous devez voir la réponse générée par PHP pour obtenir plus d’informations sur l’erreur.
    Capture d’écran de l’onglet Résumé de la demande sur la page web de Diagnostic des requêtes.

18. Sélectionnez l’onglet Affichage compact. Cet onglet affiche la liste détaillée des événements de trace générés par les modules IIS et IIS pendant le traitement de la demande.
    

    Remarque :

    • L’événement GENERAL_REQUEST_START affiche des informations de base, notamment l’URL de la demande, le verbe, les informations d’exécution sur le site et l’application à laquelle la demande a été distribuée.
    • L’événement GENERAL_REQUEST_HEADERS donne la liste complète des en-têtes, qui, dans certains cas, peuvent être significatifs lors de la détermination de l’entrée utilisateur susceptible d’entraîner l’erreur.
    • Les événements GENERAL_RESPONSE_HEADERS et GENERAL_RESPONSE_ENTITY_BUFFER fournissent les en-têtes de réponse complets et le corps de la réponse qui a été envoyé au client. Dans ce cas, le corps de la réponse fournit les informations supplémentaires nécessaires pour diagnostiquer l’erreur, indiquant un ID de produit incorrect.

Voici d’autres sections que vous devez prendre en compte lors de l’inspection du journal de suivi :

• Le panneau Résumé de la demande fournit un résumé de la requête, son résultat et met également en évidence les événements d’avertissement ou d’erreur pendant l’exécution de la demande.
• Le panneau Détails de la demande fournit une vue hiérarchique de l’exécution de la demande, ce qui vous permet également de filtrer les événements selon différentes catégories, telles que les notifications de module, l’authentification/autorisation, etc. Il offre également l’affichage des performances, qui vous aide à comprendre quelles parties de l’exécution ont pris le plus de temps.
• L’affichage Compact offre la liste complète des événements, y compris une multitude d’informations sur l’exécution de la demande. De nombreux modules IIS produisent des informations sur leur exécution qui peuvent être utilisées pour comprendre différents aspects du traitement des demandes et du résultat. Ces informations peuvent être précieuses lors de la résolution des problèmes d’interactions complexes, telles que la réécriture d’URL ou l’authentification.

Localiser les requêtes en attente en inspectant l'exécution des demandes actuelles.

Cela permet de déterminer rapidement quelles requêtes sont suspendues en inspectant les requêtes en cours d’exécution dans IIS.

Supposons que vous demandez une page qui entre dans une boucle infinie en raison d’un bogue de programmation. Dans les étapes qui suivent, cette page est loop.php. Dans le gestionnaire de tâches, vous pouvez observer que le Php-cgi.exe est occupé, consommant près de 100 % du processeur (si vous avez plusieurs cœurs d’UC, vous voyez le processus consommant 1/# de cœurs du processeur total). Vous pouvez déterminer quelle demande est suspendue :

1. Sélectionnez Démarrer, puis sélectionnez Le Gestionnaire des services Internet (IIS).

2. Dans l’arborescence située à gauche, sélectionnez le nœud serveur .

3. Sous IIS, double-cliquez sur Processus de travail.

4. Sous Nom du pool d’applications, double-cliquez sur le nom de votre pool d’applications pour ouvrir la vue Demandes . (Dans cet exemple, c’est TroubleshootingPhp.)
   

5. Basculez vers un navigateur web et actualisez la page si la page a expiré. Cette opération peut être nécessaire tout au long de ces étapes. Revenez au Gestionnaire IIS, puis actualisez la vue des Demandes.

6. Observez la liste des demandes en cours d’exécution, montrant la demande à la page du problème, dans cet exemple, /loop.php. L'entrée de la requête indique :

   • Que la demande s’exécute depuis un certain temps (délai écoulé).
   • URL de la requête (dans cet exemple, /loop.php).
   • Nom du module (FastCGIModule).
   • Étape d’exécution (ExecuteRequestHandler).

Vous pouvez actualiser l’affichage plusieurs fois pour observer que la même requête continue à s’exécuter à la même étape, mettant en évidence la requête bloquée.

• Déterminez quelle requête est suspendue à l’aide de l’invite de commandes. Avec l’invite de commandes, vous pouvez filtrer les demandes d’intérêt, par exemple les demandes adressées à une application spécifique ou à une URL spécifique. Il peut être utilisé pour automatiser les scripts qui surveillent les demandes en cours d’exécution. Ouvrez la fenêtre d’invite de commandes en sélectionnant Démarrer, puis en sélectionnant Invite de commandes.

• Basculez vers un navigateur web, puis actualisez la page http://localhost:84/loop.php. (Notez que loop.php est un exemple de nom ; le nom de votre page doit être utilisé.) Vous devrez peut-être actualiser continuellement cette page pour les étapes suivantes. Basculez vers l’invite de commandes.

• Exécutez la commande suivante pour répertorier les requêtes qui ont été exécutées pendant plus d’une seconde :

  %windir%\system32\inetsrv\appcmd.exe list requests /elapsed:1000
  

  Vous obtenez une sortie similaire à ce qui suit, avec le nom de votre page au lieu de loop.php :

  REQUEST " fa000000080000026" (url:GET /loop.php, time:2840 msec, client:localhost, stage:ExecuteRequestHandler, module:FastCgiModule)
  

• Filtrez les requêtes retournées en spécifiant un nombre quelconque de critères en fonction des attributs de requête disponibles. Par exemple, pour afficher uniquement les requêtes à une URL spécifique :

  %windir%\system32\inetsrv\appcmd.exe list requests /url:/loop.php /elapsed:1000
  

• Vous pouvez également utiliser la liaison de commandes AppCmd pour effectuer des requêtes plus complexes, par exemple, pour déterminer toutes les applications qui ont des requêtes longues :

  %windir%\system32\inetsrv\appcmd.exe list requests /elapsed:1000 /xml | %windir%\system32\inetsrv\appcmd list apps /in
  

  Vous obtenez la liste des applications similaires à ce qui suit :

  APP "troubleshootingPhp/" (applicationPool:troubleshootingPhp)
  

• Voici un exemple d’action basée sur les données de requête actuelles : recyclage des pools d’applications avec des requêtes qui ont été exécutées depuis plus de cinq secondes :

  %windir%\system32\inetsrv\appcmd.exe list requests /elapsed:1000 /xml | %windir%\system32\inetsrv\appcmd list apppools /in /xml | %windir%\system32\inetsrv\appcmd recycle apppools /in
  

  Vous obtenez la sortie suivante, avec le nom de votre application :

  "TroubleshootingPhp" successfully recycled
  

Plus d’informations

• Gestion et enregistrement des erreurs