Log4net vs TraceSource

Question

In this thread, many people have indicated that they use log4net. I am a fan of TraceSources and would like to know why log4net is used.

This is why I like trace sources:

• Pluggable listeners - XML, TextFile, Console, EventLog, collapse your own.
• Customizable trace switches (error, warning, information, verbose, start, end, user)
• Custom configuration
• The registration application block is just a large set of TraceListeners
• Correlation of actions / areas (for example, associate all the logs in an ASP.NET request with this client
• The trace viewer allows you to visualize events against these actions individually.
• All this is configured in app.config / web.config.

Since the .NET environment uses TraceSources internally, it also gives me a consistent way to configure tracing - with log4net, I need to configure log4net as well as TraceSources.

What does log4net do for me that there are no TraceSources (or is it impossible to do this by writing a couple of custom TraceListeners)?

Answer 1

I think log4net does everything you specify for me.

Pluggable listeners sound like prefixes - there are a lot of them, and in fact I even cracked a sliding log file that always ended with .log (for file associations), added a cc field to the email application, and finally set up my favorite values ​​for the color console applications. If I can be so bold - my color console happiness is:

<appender name="ColoredConsoleAppender" type="log4net.Appender.ColoredConsoleAppender"> <!-- Can Use: Blue Green Red White Yellow Purple Cyan HighIntensity --> <mapping> <level value="FATAL" /> <foreColor value="Yellow, HighIntensity" /> <backColor value="Red" /> </mapping> <mapping> <level value="ERROR" /> <foreColor value="White" /> <backColor value="Purple, HighIntensity" /> </mapping> <mapping> <level value="WARN" /> <backColor value="Blue" /> <foreColor value="White" /> </mapping> <mapping> <level value="INFO" /> <backColor value="Green" /> <foreColor value="White" /> </mapping> <mapping> <level value="DEBUG" /> <foreColor value="White" /> </mapping> <layout type="log4net.Layout.PatternLayout"> <!--<conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />--> <!--<conversionPattern value="%-5level %file:%line - %message%newline" />--> <conversionPattern value="%level %logger:%line %newline %message%newline" /> </layout> 

Customizable trace switches: Log4net ships with FATAL ERROR WARN INFO DEBUG in order to increase granularity. The only thing I really missed was AUDIT for those who did what they recorded.

Custom configuration: I use the log4net.config file that I load at runtime (or write a log to c: \ whining that I cannot find the 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 

just a great set of TraceListeners: sorry to skip this - I'll take your word for it.

The ratio of actions / areas: you mean that each file (reading class) receives its own named log, which can have separate log-level thresholds. In fact, you can segment records even in one class (this, in truth, can increase to do too much ...)

In the class file:

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

Service Trace Viewer: in the log4net.config file:

  <logger name="NipissingU.ADWrapper.EntryTools.Attribute"> <level value="INFO" /> </logger> <logger name="NipissingU.ADWrapper.EntryTools.Cache"> <level value="WARN" /> </logger> 

All this is configured in app.config / web.config: well, maybe it’s good in ASP.NET, I don’t know, but when creating a rich bean client for counting applications I like the separate configuration file.

Everything here is just my own little tricks.

NTN, -Mike

Answer 2

At the very beginning (.NET 1.0), tracing in the .NET Framework was pretty limited.

For example, partitioning on TraceSource did not appear before .NET 2.0, and you only had four levels (Error, Warning, Information, Verbose), although you could use half a dozen Boolean switches to partition if you want.

log4j is popular in Java and therefore received great support for the .NET port, and as soon as it became popular, it remained so, although people do not even use it properly (for example, wrapping it in a singleton logger and losing the main function).

However, I think that log4net and other frameworks (e.g. NLog, Common.Logging and even EntLib) went wrong by implementing their own logging system from scratch, that is, even changing the way you write log entries to the first a place.

I would rather see the effort, especially since .NET 2.0 has laid the foundation for a solid foundation of what .NET already has. For a project that extends what already exists, see the Essential Diagnostics project on CodePlex ( http://essentialdiagnostics.codeplex.com/ ).

Some advantages of log4net:

• It is similar to log4j if you are running a mixed environment and want to agree on logging.

• The automatic logger hierarchy that inherits settings is pretty neat compared to how many trace sources you implement and need to configure. (although probably in some cases it may be redundant).

• Log4net already has about 28 applications (which is equivalent to trace listeners), while System.Diagnostics only has 10 (but more for the Essential.Diagnostics project), so if you really think you might need RemoteSyslogAppender, NetSendAppender, AnsiColorTerminalAppender or TelnetAppender then you are lucky.

Disadvantages (compared to System.Diagnostics):

• You need to use a different logging syntax, so if you are already using source.TraceEvent (), you need to go through and replace everything.

• It also extends to different syntax for correlation, so you need to switch from the CorrelationManager context to log4net.

• It does not integrate easily with the Framework trace (e.g. WCF).

• Poor support for the event identifier (you must use a separate IEventLog extension project).

• It does not yet support event tracing for Windows (Vista) or the XML format of the Service Trace Viewer.

Answer 3

Another reason to use TraceSources instead of Log4Net is tracing: Log4Net can only be used for logging (messages), but how to track an object (multiple information at once)? Of course, there are many Listeners performers in Log4Net, but do I need all this? In most cases, no. And if I need a special listener, it's not that difficult to implement my own, is it? For example, I need a listener to track in the database (at the same time not only messages, but also different information {string, int, etc.}).

I'm right?

Answer 4

The reason why I prefer Log4Net to use Trace for one of the targeting is with Log4Net, I can independently use different levels of my application (Data Access, Services, Business Logic, etc.) and various subsystems (authentication, processing, etc. .) and Turn on / off the registration of each subsystem independently.

This flexibilty allows me to set up detailed logging for a single subsystem without turning on the fire engine for the entire system.

The static methods provided in the Trace class [such as TraceInformation ()] make it impossible to indicate which subsystem logging comes from, so this is not so easy to do by writing my own TraceListener.

Another reason - performance - is part of my application that can log several thousand messages per second. Log4Net imposes a small overhead. In contrast, the last time I looked at it, the Application Logging block re-phrased its XML configuration for each logged message, making the block very heavy and slow.

Answer 5

So far, I will only talk about how log4net works, the obvious advantage of using this structure is that you are directly acquainted with those who used log4j.

Another small advantage is that driving logging using log4net is extremely simple; loggers implement log4net.ILog. Again, I am not familiar with the Microsoft solution, but I wonder how this can be done without first writing the facade to the System.Diagnostics.Trace class.

With a quick look at the documentation of the trace sources, I could not find the equivalent of the layouts, and it would be interesting to know if such an equivalent exists. PatternLayout is quite convenient for formatting log entries with common data such as datestamps, stream information, log context, etc. Log4net PatternLayout docs: http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html

Also, given that writing extensions to the logging structure is probably a classic "meta problem", log4net does lead to a large list of hooked listener equivalents to the table.

List of add- ons : http://logging.apache.org/log4net/release/config-examples.html