log4net versus TraceSource

Dans ce fil, de nombreuses personnes ont indiqué utiliser log4net. Je suis un fan de TraceSources et je voudrais savoir pourquoi log4net est utilisé.

Voici pourquoi j’aime les sources de trace:

  • Écouteurs enfichables – XML, TextFile, Console, EventLog, lancez vos propres
  • Commutateurs de trace personnalisables (erreur, avertissement, info, verbose, start, end, custom)
  • Configuration personnalisable
  • Le bloc d’application de journalisation est juste un grand ensemble de TraceListeners
  • Corrélation des activités / scopes (par exemple, associer tous les journaux dans une requête ASP.NET à un client donné)
  • Le visualiseur de trace de service vous permet de visualiser les événements par rapport à ces activités individuellement
  • Tout est configurable dans app.config / web.config.

Comme le framework .NET utilise en interne TraceSources, cela me permet également de configurer de manière cohérente le traçage – avec log4net, je dois configurer log4net ainsi que TraceSources.

Qu’est-ce que log4net me donne que TraceSources ne fait pas (ou cela ne pourrait pas être fait en écrivant quelques TraceListeners personnalisés)?

Je pense que log4net fait tout ce que vous avez énuméré pour moi.

Les écouteurs enfichables ressemblent à des utilisateurs – il y en a beaucoup et en fait, j’ai même piraté le fichier journal continu pour finir par .log (pour les associations de fichiers), ajouté un champ cc à l’appender email et enfin mes valeurs préférées pour l’appendeur de la console colorée. Si je peux être si audacieux – mon bonheur de console colorée:

                               

Commutateurs de trace personnalisables: Log4net est fourni uniquement avec FATAL ERROR WARN INFO DEBUG par ordre de verbosité croissante. Le seul qui me manque est AUDIT pour savoir qui a fait quoi.

Configuration personnalisable: j’utilise un fichier log4net.config que je charge au moment de l’exécution (ou écris un journal dans c: \ whining pour ne pas trouver la configuration).

  Try ' Get log4net configuration from file Dim logConfigFile As FileInfo logConfigFile = New FileInfo(".\log4net.config") If logConfigFile.Exists Then XmlConfigurator.Configure(logConfigFile) Else CreateEmergenceLogFile(logConfigFile.FullName) End If Catch ex As Exception Console.Out.WriteLine("Could not load the log4net config file") End Try 

juste un grand ensemble de TraceListeners: désolé de sauter celui-ci – je vais prendre votre mot pour cela.

Corrélation des activités / scopes: voulez-vous dire que chaque fichier (classe de lecture) obtient son propre journal nommé qui peut avoir des seuils de niveau de journalisation distincts. En fait, vous pouvez segmenter la journalisation même dans une seule classe (cela peut en réalité avoir trop évolué …)

Dans un fichier de classe:

  Private Shared _logger As log4net.ILog = _ log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType) Private Shared _loggerAtsortingbute As log4net.ILog = _ log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName & ".Atsortingbute") Private Shared _loggerCache As log4net.ILog = _ log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName & ".Cache") 

Le Service Trace Viewer: dans le fichier log4net.config:

        

Tout est configurable dans app.config / web.config: eh bien, peut-être que c’est une bonne chose dans ASP.NET, je ne sais pas, mais lorsque j’utilise des applications de comptage de beans client enrichi, j’aime un fichier de configuration séparé.

Tout ici n’est que mes propres petites astuces d’utilisation.

hth, -Mike

Au tout début (.NET 1.0), le traçage dans .NET Framework était assez limité.

Par exemple, le partitionnement TraceSource n’est pas arrivé avant .NET 2.0 et vous n’aviez que quatre niveaux (Error, Warning, Information, Verbose), bien que vous puissiez utiliser une demi-douzaine de commutateurs booléens pour le partitionnement.

log4j est populaire en Java et a donc beaucoup de support pour un port .NET, et une fois qu’il est devenu populaire, il est resté comme ça, même si les gens ne l’utilisent même pas correctement (par exemple, l’envelopper dans un singleton et perdre c’est la caractéristique principale).

Pourtant, je pense que log4net et les autres frameworks (par exemple NLog, Common.Logging et même EntLib) ont été mal adaptés en implémentant leur propre système de journalisation, c’est-à-dire en changeant même la façon dont vous écrivez les instructions de journal.

J’aurais beaucoup préféré voir des efforts, surtout depuis .NET 2.0, pour étendre la base solide de ce qui existe déjà dans .NET. Pour un projet qui étend ce qui existe déjà, consultez le projet Essential Diagnostics sur CodePlex ( http://essentialdiagnostics.codeplex.com/ ).

Quelques points forts de log4net:

  • Il est similaire à log4j si vous exécutez un environnement mixte et souhaitez une journalisation cohérente.

  • La hiérarchie de journalisation automatique qui hérite des parameters est plutôt simple, comparée au nombre de sources de trace que vous implémentez et que vous devez configurer. (bien que probablement exagéré dans certains cas).

  • Log4net a déjà environ 28 appenders (équivalant à des auditeurs de trace), alors que System.Diagnostics n’en a que 10 (mais voyez le projet Essential.Diagnostics pour plus d’informations), donc si vous pensez vraiment avoir besoin de RemoteSyslogAppender, NetSendAppender, vous avez de la chance.

Inconvénients (par rapport à System.Diagnostics):

  • Vous devez utiliser une syntaxe de journalisation différente. Par conséquent, si vous utilisez déjà source.TraceEvent (), vous devez tout remplacer.

  • Cela s’étend également à différentes syntaxes pour la corrélation. Vous devez donc passer de CorrelationManager à des contextes log4net.

  • Ne s’intègre pas facilement avec le suivi de structure (par exemple, WCF).

  • Mauvaise prise en charge des ID d’événement (besoin d’utiliser un projet d’extension distinct IEventLog).

  • Ne prend pas encore en charge le suivi des événements pour Windows (Vista) ou le format XML de l’outil de suivi des traces de service.

Une autre raison d’utiliser TraceSources au lieu de Log4Net est la fonction Tracing lui-même: Log4Net ne peut être utilisé que pour la journalisation (messages), mais comment tracer un object (plusieurs informations en même temps)? Bien sûr, Log4Net a beaucoup d’auditeurs implémentés, mais ai-je besoin de tout cela? Dans la plupart des cas pas. Et si j’ai besoin d’un auditeur spécial, ce n’est pas aussi difficile de mettre en œuvre mon propre auditeur, n’est-ce pas? Par exemple, j’ai besoin d’un auditeur pour tracer dans une firebase database (pas seulement des messages mais des informations différentes {chaîne, int, etc.} en même temps).

Est-ce que j’ai raison?

La raison pour laquelle je préfère Log4Net à l’utilisation de Trace One – avec Log4Net, je peux instrumenter de manière indépendante différentes couches de mon application (access aux données, services, logique métier, etc.) et différents sous-systèmes (authentification, traitement, etc.) et activer / désactiver la journalisation de chaque sous-système indépendamment.

Cette flexibilité me permet de configurer la journalisation détaillée pour un sous-système sans activer le firehose pour l’ensemble du système.

Les méthodes statiques fournies dans la classe Trace [telles que TraceInformation ()] ne fournissent aucun moyen de spécifier de quel sous-système provient la journalisation, ce n’est donc pas chose facile en écrivant mon propre TraceListener.

Une autre raison est la performance – il y a des parties de mon application qui enregistrent potentiellement plusieurs milliers de messages par seconde. Log4Net impose une surcharge minimale. En revanche, la dernière fois que je l’ai examiné, le bloc Application de journalisation a republié sa configuration XML pour chaque message consigné, ce qui a rendu le bloc très lourd et lent.

Bien que je ne sois au courant que du fonctionnement de log4net, un avantage évident à utiliser ce framework est la familiarité immédiate pour ceux qui sont habitués à utiliser log4j.

Un autre petit avantage est que l’enregistrement de la conduite de test à l’aide de log4net est extrêmement simple. Les enregistreurs implémentent log4net.ILog. Encore une fois je ne suis pas familier avec la solution Microsoft, mais je me demande comment on pourrait le faire sans écrire au préalable une façade dans la classe System.Diagnostics.Trace.

En examinant rapidement la documentation des sources de trace, je n’ai pas pu trouver d’équivalent aux dispositions et je serais intéressé de savoir si un tel équivalent existe. Le PatternLayout est très pratique pour formater les entrées de journal avec des données communes telles que les datestamps, les informations sur les threads, le contexte des journaux, etc.

De plus, étant donné que l’écriture d’extensions dans une structure de journalisation est probablement un «méta-problème» classique, log4net apporte une liste impressionnante d’équivalents écouteurs connectables à la table.

Liste des appenders: http://logging.apache.org/log4net/release/config-examples.html