Why do loggers recommend using a logger per class?

Question

As per NLog's documentation:

Most applications will use one logger per class, where the name of the logger is the same as the name of the class.

This is the same way that log4net operates. Why is this a good practice?

Answer 1

Probably because you want to be able to log methods that are only visible to the class without breaking encapsulation, this also makes it easy to use the class in another application without breaking the logging functionality.

Answer 2

Two reasons immediately spring to mind:

1. Having a separate log for each class makes it easy to group together all log messages/errors pertaining to a given class.
2. Having a log within a class allows you to log internal details which may not be accessible outside the class (e.g., private state, information dealing with a class's implementation, etc.).

Answer 3

I can see a few reasons for this choice.

• You will always know where a particular log statement came from, if you include the name of the logger in your log output format.
• You can control what log statements you see at a fine grained level by turning certain loggers on or off, or setting their level.

Answer 4

In most cases, the name of the class provides a good name for the logger. When scanning the log files, you can see the log message and associate it directly with a line of code.

A good example where this is not the best approach, is Hibernate's SQL logs. There is a shared logger named "Hibernate.SQL" or something like that, where a number of different classes write raw SQL out to a single logger category.

Answer 5

With log4net, using one logger per class makes it easy to capture the source of the log message (ie. the class writing to the log). If you don't have one logger per class, but instead have one logger for the entire app, you need to resort to more reflection tricks to know where the log messages are coming from.

Compare the following:

Log per class

using System.Reflection;
private static readonly ILog _logger = 
    LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);    

public void SomeMethod()
{
    _logger.DebugFormat("File not found: {0}", _filename);
}

One logger per app (or similar)

Logger.DebugFormat("File not found: {0}", _filename); // Logger determines caller

-- or --

Logger.DebugFormat(this, "File not found: {0}", _filename); // Pass in the caller

Using the second example, the Logger would need to build a stack trace to see who was calling it or your code would always have to pass in the caller. With the logger-per-class style, you still do this, but you can do it once per class instead of once per call and eliminate a serious performance problem.

Answer 6

Makes it easy to configure appenders by namespace or class.

Answer 7

The question has been already answered here so I'm just posting my favorite NLog usage:

    static class MyLogger
{

    private static readonly Logger ms_Logger = LogManager.GetLogger("MyLogger");

    public static Logger Logger { get { return ms_Logger; } }

}

Now there's no need to instantiate a logger for each class. I can send logs from anywhere in the code in the following way:

MyLogger.Logger.Fatal("blahblah");

And if I want the class & method names to automatically always be a part of the line, I add the ${callsite} layout to the output target in the config file.