Introduction to NLog

The routing table is made up of the following main parts:

• targets (previously called "appenders") - which specify where log output will go
• rules - which describe the way log messages are routed to reach targets

Each definition consists of a logger name pattern, level specification and target information. The meaning is very simple: "Each time a logger name matches the pattern and level matches the level specification, write the formatted log message to the specified target".

As you can see the routing table is quite clean and simple, but very powerful. Some examples of what you can use with it include:

• send single log message to one or more targets (for example: both to the console and a log file)
• filter logging messages by their level
• filter logging messages by their logger name using wildcards

It's also possible to use filters and final rules, and this is described below in advanced section.

Layouts and layout renderers

Layouts are one of the coolest features of NLog. They let you annotate log messages with environmental information like:

• date and time in various formats
• stack trace information
• exception information
• classic ASP and ASP.NET session, request and application objects
• path information (such as appdomain base directory)
• log event information (logger name, log level)
• process and thread information
• machine name information
• diagnostic contexts
• counters, guids, and more

Each target has a parameter called layout that describes the log output formatting. By default it is:

${longdate}|${level:uppercase=true}|${logger}|${message}

so that each log line contains the data, log level, logger name and log message. This can be extended, for example, to provide some particular value from ASP.NET session state, thread id and call site (class and name of the invoking method):

${longdate} ${level:uppercase=true} ${logger} ${aspnet-session:variable=UserName} ${threadid} ${callsite} ${message}

Now, each logging message (a line in the output file) will contain all of the above useful information. Example of a real-life configuration that does just that and writes output to both a file and ASP.NET trace facility. Note how the file output is more detailed than ASP.NET trace output: