La façon la plus simple de tracer une Azure Web App

Tout récemment, on m’a demandé mon aide pour résoudre un bug qui se produisait dans une Azure Web App en production.

Pour compliquer les choses, il n’y avait pas d’environnement de test pour cette application. De plus, l’accès à l’application est sécurisé par un Azure Active Directory (AAD) sur lequel, ni André ni moi ne sommes administrateurs.

En temps normal, il est possible de déployer l’application en mode Debug et de s’y attacher dans Visual Studio pour déboguer le code. Mais dans ce cas-ci, pour une raison inexpliquée, ça n’a pas fonctionné. Je dois avouer que nous ne nous y sommes pas attardés longtemps, vu l’urgence de la situation. Toutefois, si cela t’intéresse, j’écrirai un article expliquant le procédé.

Devant l’urgence de la situation, nous avons pris 3 décisions :

1. En informer les utilisateurs car « la communication est clé ! »
2. Faire un backup de la BD de production (une BD SQL Database sur Azure)
3. Ajouter des traces applicatives

Pour ce qui est du backup de la BD, il y a plusieurs techniques que je couvrirai dans une série d’articles prochainement.

Nous allons, dans le cadre de cet article, nous intéresser au 3^e point, soit l’ajout de traces applicatives. Tu verras qu’Azure nous offre un moyen très simple pour ça.

Ajout de traces dans le code

Dans le code, rien de nouveau que tu ne connaisses déjà…

Il suffit d’utiliser les méthodes de la classe « Trace » du namespace « System.Diagnostics ».

Activer les traces au niveau de la Web App Azure App Service

Connecte-toi à ton portail Azure puis va dans le blade de ta Web App.

Rendu là, tu noteras différents types de logs. Passons-les en revue :

• Application logging: contient tes logs applicatifs. C’est ce qui nous intéresse dans le cadre de cet article.
• Web server logging: contient les informations sur les transactions HTTP.
• Detailed error messages: lorsque ton serveur web retourne un code d’erreur HTTP 400 ou supérieur, tu peux trouver le détail de l’erreur dans ces logs.
• Failed requests tracing: contient les informations sur les requêtes HTTP en échec ainsi que le temps de traitement au niveau du serveur. Ça peut te permettre de déterminer la cause de l’erreur (les timeout, par exemple).

Dans notre cas, on va activer le « application logging » au niveau du file system. Ça permettra de conserver nos traces sur le serveur web.

Je vais donc cliquer sur le bouton « On » juste en dessous de « Application Logging (Filesystem) », choisir « Verbose » dans la liste déroulante « Level » et cliquer sur le bouton « Save ».

Si on voulait centraliser les traces de nos diverses applications dans un même endroit, j’aurais probablement activé les traces au niveau du Blob Storage.

Emplacement des traces

Dépendamment du type de traces que tu as choisi d’activer, tu les trouveras dans le répertoire « LogFiles » si tu as choisi « Filesystem » comme destination. Ainsi :

• Application logging se retrouve dans « /LogFiles/Application »
• Web server logging se retrouve dans « /LogFiles/http/RawLogs »
• Detailed error messages se retrouve dans « /LogFiles/DetailedErrors »
• Failed requests tracing se retrouve dans « /LogFiles/W3SVC######### »

Taille maximale des traces

Pour la taille de ma web app, j’ai choisi 10 Go de stockage. J’ai donc pas mal d’espace pour mes traces.

Consulter les traces applicatives via la console Kudu

Il y a plusieurs façons de consulter les traces :

• Je peux les télécharger via un script PowerShell
• Je peux les télécharger via un script Azure CLI
• Je peux les télécharger via le panneau Server Explorer de Visual Studio (en me connectant à mon compte Azure depuis ce panneau)
• Je peux les télécharger ou les consulter en temps réel via la console Kudu

C’est cette dernière option que je te propose de découvrir ici car c’est celle qu’on a utilisé dans le cas dont je t’ai parlé au début de cet article. Les autres options seront couvertes dans d’autres articles.

Tu ne sais pas ce qu’est la console Kudu ? Je posterai bientôt un article à ce sujet. Mais rassures-toi, à la fin de cet article, tu sauras au moins comment consulter et/ou télécharger les traces applicatives via cette console.

Étape 1 : accéder à la console Kudu

Tu accèdes à la console Kudu en reprenant l’URL de ta web app et en la modifiant légèrement.

Supposons que l’URL de ta web app soit : masuperwebapp.azurewebsites.net

Tu dois ajouter à l’URL la particule « .scm » comme ceci : masuperwebapp.scm.azurewebsites.net

Et te voilà dans la console Kudu. Ce n’est pas plus compliqué que ça !

Étape 2 : consulter/télécharger les traces

Dans le menu du haut, cliques sur « Debug console » puis sur « CMD ». Apparaitra alors un explorateur de fichiers et une console en ligne de commandes.

Console Kudu

Cliques ensute sur le répertoire « LogFiles » puis sur le répertoire « Application ».

Logs applicatifs via Kudu

Tu verras apparaitre une liste de fichiers textes. À gauche de chaque entrée de la liste, tu verras 3 boutons :

• Download: te permets de télécharge le fichier de trace
• Edit: te permet d’éditer le fichier de trace. C’est sur ce bouton que tu dois cliquer pour le consulter. Il va se mettre à jour au fur et à mesure que de nouvelles traces sont inscrites.
• Delete: te permets de supprimer ce fichier de trace

Consulter les traces en direct (streaming)

Le portail d’Azure te permets aussi de consulter les traces en direct via l’onglet « Log stream ». Tu peux y consulter les logs applicatifs ainsi que ceux du serveur web.

Cela s’avère très utile quand tu investigue un bug : tu lances le streaming log et tu exécutes l’application. Tu verras passer les exceptions et les traces que tu auras mis dans le code en (quasi) temps réel (il peut y avoir un décalage de quelques secondes parfois).

Pour consulter les traces en direct, il faut tout d’abord activer les traces comme on l’a vu plus tôt. Ensuite, va dans le portail d’Azure et rends-toi à ta Web App. Enfin, cliques sur l’onglet « Log stream ». Ça ne prendra que quelques instants pour te connecter au service et tu commenceras à voir s’afficher les premiers messages :

Console Log stream

Avantages et inconvénients

L’avantage évident est que c’est beaucoup plus facile de consulter les traces par ce moyen que par la console Kudu.

L’inconvénient est que ce sont des traces en direct. Tu ne peux donc pas utiliser cette fonctionnalité pour consulter des traces antérieures. Pour cela, il te faudra passer par la console Kudu.

Désactiver les traces

La beauté de la chose est que, pour désactiver les traces, il te suffit de retourner au même endroit que tout à l’heure, de cliquer sur le bouton « Off » sous « Application Logging (Filesystem) » et le tour est joué!

En conclusion…

Un coup mal pris, cette fonctionnalité des Web App peut s’avérer fort utile. Elle nous a permis de découvrir l’origine du bug et de le corriger. J’espère qu’elle te sera autant utile qu’à moi.

À la prochaine !