Partager via

Création et redirection de journal IIS

  • Article

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 9 de cet article.

Avertissement

Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la Stratégie de prise en charge de .NET et .NET Core. Pour la version actuelle, consultez la version .NET 8 de cet article.

Important

Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Pour la version actuelle, consultez la version .NET 9 de cet article.

Le module ASP.NET Core redirige la sortie de console stdout et stderr vers le disque si les attributs stdoutLogEnabled et stdoutLogFile de l’élément aspNetCore sont définis. Tous les dossiers du chemin stdoutLogFile sont créés par le module au moment de la création du fichier journal. Le pool d’applications doit avoir un accès en écriture à l’emplacement auquel les journaux sont écrits (utilisez IIS AppPool\{APP POOL NAME} pour fournir les autorisations d’écriture, où l’espace réservé {APP POOL NAME} est le nom du pool d’applications).

Aucune rotation n’est appliquée aux journaux, sauf en cas de recyclage/redémarrage du processus. Il incombe à l’hébergeur de limiter l’espace disque utilisé par les journaux.

L’utilisation du journal stdout est recommandée uniquement pour résoudre les problèmes de démarrage d’application lors de l’hébergement sur IIS ou lors de l’utilisation de la prise en charge au moment du développement pour IIS avec Visual Studio, et non lors du débogage local et de l’exécution de l’application avec IIS Express.

N’utilisez pas le journal stdout à des fins de journalisation d’application générale. Pour les opérations de journalisation courantes dans une application ASP.NET Core, utilisez une bibliothèque de journalisation qui limite la taille du fichier journal et applique une rotation aux journaux. Pour plus d’informations, consultez Fournisseurs de journalisation tiers.

Un horodatage et une extension de fichier sont ajoutés automatiquement quand le fichier journal est créé. Le nom du fichier journal est créé en ajoutant l’horodatage, un ID de processus et une extension de fichier (.log) au dernier segment du chemin d’accès stdoutLogFile (généralement stdout), séparés par des traits de soulignement. Si le chemin d’accès stdoutLogFile se termine par stdout, un journal pour une application avec un PID de 1934 créé le 5/2/2018 à 19:42:32 affiche le nom de fichier stdout_20180205194132_1934.log.

Si stdoutLogEnabled a la valeur false, les erreurs qui se produisent au moment du démarrage de l’application sont capturées et émises dans le journal des événements (30 Ko maximum). Après le démarrage, tous les journaux supplémentaires sont ignorés.

L’exemple d’élément aspNetCore suivant configure la journalisation stdout au niveau du chemin d’accès relatif .\log\. Vérifiez que l’identity de l’utilisateur AppPool à l’autorisation d’écrire dans le chemin d’accès fourni.

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="true"
    stdoutLogFile=".\logs\stdout"
    hostingModel="inprocess">
</aspNetCore>

Lors de la publication d’une application pour le déploiement d’Azure App Service, le SDK web définit la valeur stdoutLogFile sur \\?\%home%\LogFiles\stdout. La variable d’environnement %home est prédéfinie pour les applications hébergées par Azure App Service.

Pour créer des règles de filtre de journalisation, consultez la section Appliquer des règles de filtre de journal dans le code de la documentation de journalisation ASP.NET Core.

Pour plus d’informations sur les formats de chemin d’accès, consultez Formats de chemin d’accès aux fichiers sur les systèmes Windows.

Journaux de diagnostic améliorés

Le module ASP.NET Core est configurable pour proposer des journaux de diagnostic améliorés. Ajoutez l’élément <handlerSettings> à l’élément <aspNetCore> dans web.config. L’affectation de la valeur TRACE à debugLevel expose une fidélité plus élevée des informations de diagnostic :

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />
    <handlerSetting name="debugLevel" value="FILE,TRACE" />
  </handlerSettings>
</aspNetCore>

Tous les dossiers dans le chemin d’accès (logs dans l’exemple précédent) sont créés par le module lorsque le fichier journal est créé. Le pool d’applications doit avoir un accès en écriture à l’emplacement auquel les journaux sont écrits (utilisez IIS AppPool\{APP POOL NAME} pour fournir les autorisations d’écriture, où l’espace réservé {APP POOL NAME} est le nom du pool d’applications).

Les valeurs du niveau de débogage (debugLevel) peuvent inclure à la fois le niveau et l’emplacement.

Niveaux (dans l’ordre du moins au plus détaillé) :

  • ERROR
  • WARNING
  • INFO
  • TRACE

Emplacements (plusieurs emplacements sont autorisés) :

  • CONSOLE
  • EVENTLOG
  • FILE

Les paramètres de gestionnaire peuvent également être fournis par le biais de variables d’environnement :

  • ASPNETCORE_MODULE_DEBUG_FILE : Chemin du fichier journal de débogage. (Valeur par défaut : aspnetcore-debug.log)
  • ASPNETCORE_MODULE_DEBUG : Paramètre du niveau de débogage.

Avertissement

Ne laissez pas la journalisation du débogage activée dans le déploiement plus longtemps que nécessaire pour résoudre un problème. La taille du journal n’est pas limitée. Si vous laissez la journalisation du débogage activée, vous risquez d’épuiser l’espace disque disponible et de bloquer le serveur ou le service d’application.

Consultez Configuration du module ASP.NET Core avec web.config pour obtenir un exemple de l’élément aspNetCore dans le fichier web.config.