Pour ceux qui sont habitués à utiliser ASP.NET Core 1.0 couplé avec Kestrel, vous allez sûrement être familier avec l’image qui va suivre, pour les autres, il s’agit des différents logs applicatifs émis en ASP.NET Core 1.0 :

Ces logs s’affichent automatiquement dans la console, si vous lancez votre application Web avec Kestrel. Ils permettent ainsi d’avoir des informations sur comment se comporte l’application avec notamment le détail des appels effectués, les messages des middlewares, les exceptions, … Ces informations peuvent être une première approche pour débugger votre application.

Cependant, pour ceux qui utilisent leur application avec IIS, IIS Express ou Azure, ces logs ne sont pas accessibles, mais ils ne sont pas perdus ! Vous avez la possibilité d’activer une option qui permet d’écrire ces logs dans des fichiers et ainsi d’obtenir les mêmes informations que ceux affiché dans la console. Pratique non ?

Activer la sauvegarde des logs

Vous devez avoir à la racine de votre projet ASP.NET Core 1.0, un fichier web.config. Dans ce fichier, il suffit simplement de modifier la propriété “stdoutLogEnabled” à “true”, vous avez également la possibilité de modifier le chemin où seront stockés les fichiers. Voici un web.config avec l’activation des logs et la sauvegarde dans le dossier “logs”.

<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%"
                stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout"
                forwardWindowsAuthToken="false"/>
  </system.webServer>
</configuration>

Mais, attention, il est important de savoir que :

• celui-ci n’est pas utilisé par Kestrel, ce qui signifie que vos logs seront uniquement sauvegardés lorsque vous utilisez IIS, IIS Express (par extension, Azure).
• le dossier qui est spécifié pour stocker les fichiers doit exister, vous serez peut-être amener à le créer !
• les fichiers de logs ne sont pas supprimés automatiquement, il est donc à votre charge de limiter la taille allouée, ou de les supprimer/archiver régulièrement.
• un fichier de log est créé par session. Ce qui signifie que vos fichiers peuvent devenir très gros, puisqu’ils ne sont recréés que lors d’un redémarrage de l’application ou lors d’un recyclage IIS de celle-ci.
• un fichier de logs a comme nom “stdout_15616_201685103648.log” la seconde chaîne de chiffres correspond à la date et l’heure du début d’écriture du fichier (ce qui peut être assez pratique pour retrouver un log en particulier).

Définir le niveau d’affichage des logs

Vous pouvez définir le niveau des logs que vous voulez afficher pour réduire les logs qui s’affichent et donc également réduire la taille des fichiers de logs. Pour cela, dans le fichier appsettings.json de votre application, vous devez avoir un noeud correspondant au “Logging”, et c’est notamment “LogLevel” qui nous intéresse plus particulièrement ici.

"Logging": {
  "IncludeScopes": false,
  "LogLevel": {
    "Default": "Debug",
    "System": "Information",
    "Microsoft": "Information"
  }
}

Vous pouvez définir le niveau de chacun “System”, “Micosoft” et “Default” qui émettent des logs dans votre application. Il existe 6 niveaux de log (Critical, Error, Warning, Information, Debug, Trace). Lorsqu’un log est émis dans la console, il est préfixé du niveau pour mieux analyser le log, les préfixes associés aux niveaux sont :

Retrouver les fichiers de logs

Avec IIS, IIS Express

Lorsque vous utilisez IIS et IIS Express, le chemin où seront stockés les fichiers de logs peut être soit absolu, soit relatif par rapport à l’emplacement du fichier web.config. C’est donc vous qui choisissez l’endroit où vous souhaitez stocker vos logs (gardez toujours en mémoire que le dossier doit exister !). Voici un exemple avec la configuration du fichier web.config ci-dessus :

Pour avoir accès aux fichiers de logs, vous n’avez plus qu’à aller dans votre dossier, avec votre explorateur de fichier.

Avec Azure

Lorsque vous publiez votre application Web sur Azure, le chemin du stdoutLogFile est normalement réécrit automatiquement sous la forme de “\\?\%home%\LogFiles\stdout”. Comme vous pouvez le voir, vos logs vont être placés dans le dossier “LogFiles”, ce dossier est déjà présent à la racine de votre serveur, vous n’aurez donc pas à le créer !

Pour avoir accès à ces fichiers de logs, il faut se connecter au serveur qui héberge l’application Web, soit via un client FTP (type FileZilla), via Visual Studio et de Serveur Explorer, soit via la console Kudu proposée par le portail Azure. Une fois la connexion effectuée, vous aurez 3 dossiers “data”, “LogFiles”, “site”, c’est bien évidemment dans le dossier LogFiles que seront sauvegardés les logs.