En DevOps, on a beau passer beaucoup de temps à rechercher de nouvelles solutions de monitoring ou de debug, il y a toujours un moment où l’on revient aux basics. Récemment, j’ai eu besoin d’activer le Failed Request Tracing de IIS. Je me suis alors rendu compte que de nombreux développeurs ne connaissaient pas cette fonctionnalité.

Pour faire simple : IIS Failed Request Tracing permet d’avoir un log de toutes les requêtes reçues par IIS qui sont tombées en erreurs. Cette fonctionnalité peut être utilisée unitairement (configuré au niveau du site à observer) ou globalement (à la racine de IIS pour tous les sites sans distinction). Les logs sont disponibles sous forme de fichiers qui peuvent être copiés pour être consulté sur une autre machine, ou consultés localement.

Attention : Si vous configurez Failed Request Tracing au niveau de la racine de la console IIS, vous ne pouvez pas configurer individuellement le Tracing des sites. Une erreur s’affiche systématiquement dans la section Failed Request Tracing de chaque site.

Pour personnaliser le tracing d’un site, il faut donc que la configuration à la racine soit désactivée.

Installer Failed Request Tracing

Si Failed Request Tracing est installé sur votre serveur, il est visible dans la section IIS à ma racine de la console ou du site.

Sur la capture suivante, Failed Request Tracing n’est pas installé.

Pour procéder à l’installation, il faut ouvrir la console Server Manager. Puis, utiliser le menu Manage et Add Roles and Features.

Failed Request Tracing est un composant du rôle IIS, il faut donc choisir une installation basée sur les rôles (Role-based installation).

On doit sélectionner le ou les serveurs web qui ont besoin de Failed Request Tracing.

Dans le rôle IIS, il faut dérouler le nœud Health and Diagnostics et cocher la case Tracing (le nom est un peu court, mais il s’agit bien de Failed Request Tracing).

La section Features n’a pas besoin d’être modifiée, on peut passer à la suite.

Le résumer de la configuration devrait alors ressembler à ceci. Il reste à lancer l’installation.

Après l’installation, si on ouvre la console IIS, Failed Request Tracing est visible dans la section IIS.

Configurer Failed Request Tracing

Via la console de IIS, il faut utiliser le bouton Failed Request Tracing.

Il faut ensuite utiliser la commande Add... qui se trouve à droite. Celle-ci va permettre de configurer une première règle de tracing.

Pour capturer l’ensemble des erreurs, toutes technologies et extensions confondues, la configuration suivante convient parfaitement (elle est conseillée pour n’exclure aucune erreur connexe aux problèmes que vous souhaitez diagnostiquer).

Par la suite, on peut choisir les codes d’erreurs ciblés. Dans le cas suivant, je prends volontairement les erreurs de 404 à 600 pour avoir toutes les erreurs serveur. J’ai exclu les erreurs de 400 à 403 pour ne pas être pollué par les demandes d’utilisateurs qui ne sont pas encore authentifiés.

Arrive alors la dernière étape : choisir les fournisseurs d’erreurs. Autant tous les sélectionner pour qu’aucune erreur ne passe entre les mailles du filet (j’ai déjà été dans le cas d’erreurs 404 qu’ASP .net ne capturait pas, car IIS prenait le dessus… cet écran est donc très utile).

Quand on revient sur la vue Failed Request Tracing, un avertissement est affiché en haut à droite. Il indique qu’il faut maintenant activer le tracing pour que la règle configurée soit prise en compte. Cela passe par l’utilisation de la commande Edit Site Tracing...(un peu en dessous à droite).

Sur l’écran qui suit, il faut cocher la case Enable. On peut modifier le dossier de destination des logs.

Après avoir fermé le précédent formulaire, l’avertissement disparait et l’on peut utiliser la commande View Trace logs... pour ouvrir le dossier contenant les logs.

Et voilà.