What .NET Logging Framework Should I Use?

When adding logging to your application there are two separate choices to make - what Logging API to code with and what Sink (sometimes called an Appender or Extender) to use for capturing the log data for analyzing and viewing later. The first choice is more difficult to change later because it requires code changes.

Logging API Framework Options

Since the early days of .NET there have been numerous logging API’s to choose from. Each of the following offer a different API experience to meet different developer preferences.

• Trace - Built into the .NET Framework, Trace offers rudimentary logging support but is present in every version of .NET without any dependencies.
• Log4Net - One of the first available in .NET, Log4Net is a port of Log4j from Java to .NET. It provides extensive configuration options to determine where your log messages get written to and how they are formatted but can be complicated to set up and get going.
• NLog - Designed from the ground up for .Net, NLog supports the useful flexibility of Log4Net with a more capable API and better performance.
• Serilog - A newer logging framework, Serilog emphasizes Structured Logging - where instead of rendering messages as text, data structures can be recorded with a template message to be rendered and evaluated in a log viewer.
• Microsoft.Extensions.Logging - A logging API designed to replace Trace as a common, available API to code against that supports many different logging systems behind it. In general, this is our recommended choice.
• Loupe - A logging framework that combines logging & metrics in one framework and supports both structured and traditional logging.

For new applications targetting .NET Core or .NET Standard, Microsoft.Extensions.Logging is a good choice. It provides a reasonable API and extensive options for where to route log data to. Using this in your libraries maximizes the options other application developers have to merge your logging data with theirs.

Centralized .NET Logging

Once you’ve incorporated a logging API, how do you get the data to where it can do some good? Each logging API supports some form of data Sink - a method of writing data out to a file, network, database, or other storage. Most API’s ship with a basic Sink in the box - typically to a log file. But, this isn’t very good if you can’t get to the file system where your application is running. Once you’re application is deployed you’ll need a way to get that data to where you are- safely and reliably.

Writing directly across a network has some challenges: What happens if the network is unavailable (like on a laptop or tablet)? Or if networking problems are causing errors which in turn cause a surge in logging? Ideally, you want a Sink that will buffer data locally and send it to a central server in the background when bandwidth and resources are available.

Loupe solves this problem - buffering data locally in highly compressed data files and then copying those files to the Loupe server where they can be viewed from anywhere, analyzed to find errors, and aggregated with other logs to create a full picture of how your application is working.

Add Centralized Logging to your App Easily with Loupe View

How To Write Log Messages

We’ve helped hundreds of teams get logging write, so take advantage of our experience and check out:

• What Should I Log In My Application: Covers the range of things to consider logging, and what to avoid, in your application.
• Why Should I Care About Logging?