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

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 2

Advantage for using "logger per file" in NLog: you have possibility to manage/filter logs by namespace and class name. Example:

<logger name="A.NameSpace.MyClass"      minlevel="Debug" writeTo="ImportantLogs" /> 
<logger name="A.NameSpace.MyOtherClass" minlevel="Trace" writeTo="ImportantLogs" /> 
<logger name="StupidLibrary.*"          minlevel="Error" writeTo="StupidLibraryLogs" />

<!-- Hide other messages from StupidLibrary -->
<logger name="StupidLibrary.*" final="true" /> 

<!-- Log all but hidden messages -->
<logger name="*" writeTo="AllLogs" /> 

NLogger has a very useful code snippet to do this. The nlogger snippet will create the following code:

private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();

So only few keystrokes and you have logger per class. It will use namespace and class name as the name of the logger. To set different name to your class logger, you can use this:

private static NLog.Logger logger = NLog.LogManager.GetLogger("MyLib.MyName");

And, as @JeremyWiebe said, you don't have to use tricks to get the name of the class which is trying to log a message: Name of the logger (which is usually the name of the class) can be easy logged to file (or other target) by using ${logger} in layout.

Answer 3

If you are using NLOG you can specify the callsite in the config, this will record the class name and method where the logging statement was located.

<property name="CallSite" value="${callsite}" />

You could then use a constant for your logger name or the assembly name.

Disclaimer: I don't know how NLOG collects this information, my guess would be reflection so you may need to consider the performance. There are a few issues with Async methods if you are not using NLOG v4.4 or later.

Answer 4

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 5

Makes it easy to configure appenders by namespace or class.

Answer 6

There is also a performance benefit in the case of NLog. Most users will use

Logger logger = LogManager.GetCurrentClassLogger()

Looking up the current class from stack trace take some (but not much) performance.