Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Tracer les requêtes en échec

Poster un commentaire

Il arrive parfois qu’un site Web plante ou bien qu’il devienne anormalement lent. Une erreur remonte dans certains cas. Parfois elle nous informe fort peu sur ce qui est arrivé, vous savez la fameuse erreur 500…

 

IIS propose un outil qui peut être fort utile pour dépatouiller ce genre de problème. Découvrons le ensemble.

Voici les bases. J’ai fait un exemple plus élaboré dans un autre article:

https://amethyste16.wordpress.com/2016/12/07/debogage-de-la-reecriture-durl-avec-iis/

 

Il n’est pas installé par défaut, on doit le configurer parmi les rôles du serveur:

2016-07-23_21-48-52

 

Et on voit apparaître dans les paramètres du site.

2016-07-23_21-50-23

 

C’est notre outil, il ne reste plus qu’à le configurer. On clique dessus:

2016-07-23_22-01-52

 

Pour l’instant il n’y a pas grand chose. Cliquons sur Add, mais avant relisez tout de même la description de cet outil:

2016-07-23_22-09-53

La documentation se trouve ici:

https://technet.microsoft.com/fr-FR/library/hh831510.aspx

 

Allez continuons:

2016-07-23_22-13-27

On sélectionne le type de formulaire que l’on souhaite tracer, puis Next.

2016-07-23_22-19-58

Les choses intéressantes se passent ici. On peut s’intéresser à 3 conditions:

  1. Un code de retour Http
  2. Une requête anormalement longue
  3. Sévérité de l’événement

2016-07-23_22-24-33

Un autre Next:

2016-07-23_22-32-11

On fait Finish:

2016-07-23_22-34-58

Provoquons un événement. Où se trouvent les logs? Pas très loin:

2016-07-23_22-37-39

Deux fichiers ont été générés, l’un est une feuille de styles appelé fred.xsl. FREB est le nom interne de cet outil chez Microsoft (Failed Request Event Buffering).

On double clique sur l’autre, un fichier de ce style s’ouvre:

2016-07-23_22-41-54

 

Et Azure?

On peut activer notre outil dans Azure. Prenons le cas d’une Web App:

2016-07-28_19-13-03

 

On sélectionne le menu Troubleshoot.

2016-07-28_19-14-39

On sélectionne la première option et on clique sur Enable Failed Request Tracing.

Une nouvelle option apparaît:

2016-07-28_19-20-02

 

Qui nous amène aux logs de l’outil.

On peut activer/désactiver l’outil d’une façon plus standard:

2016-07-28_19-27-11

 

On se rend dans Settings/Features. On sélectionne Diagnostics logs, puis Failed request tracing.

Et si ce n’est pas une erreur que l’on recherche?

Le problème est que par défaut, Azure n’active les logs que pour les erreurs clients sur le serveur. Ce n’est pas toujours suffisant, il arrive que l’on cherche à investiguer un ralentissement par exemple. dans ce cas on n’a pas d’exception, mais toujours des codes retour 200.

 

On peut résoudre le problème en modifiant un peu le fichier de configuration web.config dans sa section <system.webServer>. Par exemple ainsi:


<tracing>
   <traceFailedRequests>
      <remove path="*"/>
      <add path="*">
         <traceAreas>
            <add provider="ASP.NET" areas="Infrastructure,Module,Page" verbosity="Verbose"/>
         </traceAreas>
         <failureDefinitions statusCodes="200"/>
      </add>
   </traceFailedRequests>
</tracing>

 

 

Important: La fonctionnalité a un impact sur les performances, il est important de la désactiver lorsqu’elle ne sert plus.

 

Bibliographie

 

 

 

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s