How To Log Messages (Information, Errors, Warnings) In ASP.NET Core

Problem

How to log messages (information, errors, warnings) in ASP.NET Core.

Solution

Starting from an empty project (previous post), inject ILogger as dependency and use various Log<log-level> methods.

Running the application will show the messages in Debug/Console window.

ASP.NET Core

Discussion

The framework provides logging capability through ILoggerFactory, to which you could attach one or more providers. Providers act on the logged data in some form i.e.,  log it to file, database, Azure etc.

Both built-in and third-party providers exist and they attach themselves to the ILoggerFactory via its AddProvider() method, however, they all expose extension methods on ILoggerFactory to simplify this task.

Although it seems like magic (how was the Console logger setup!) ASP.NET Core 2.0 hides the adding of logging providers behind CreateDefaultBuilder() method of WebHost, in Program.cs. To see this, replace the BuildWebHost() method in Program.cs and run the program, you’ll get the same result,

To use logging providers, simply inject ILogger as a dependency, where T is the category of logs. Category is normally the fully qualified name of class in which logs are written, and it is written with every log message.

Log Category

You could override category value by injecting ILoggerFactory as a dependency (rather than ILogger) and using ILoggerFactory.CreateLogger() method to build a new ILogger:

ASP.NET Core

Log Levels

Every log message you write will have a severity indicated by LogLevel enum. In practice, you would use the following extension methods that encapsulate the call to ILogger.Log() and pass in log levels,

  • LogTrace/LogDebug - to log information useful during development and debugging.
  • LogInformation - to log messages showing application flow.
  • LogWarning - to log exceptions that can be handled.
  • LogError - to log exceptions that can’t be handled and show failure of an operation
  • LogCritical - to log exceptions of serious consequences to the entire application.
Log Event ID

Every log message you write can has an event ID (integer), which is useful to group messages of a certain type. Every provider will deal with event ID in their own way. In the solution given above, you could see Console output showing these in square brackets.

Tip - use a class with constants or static read-only fields to represent the event IDs.

Log Filters

You could filter the log messages using AddFilter() method.

Third-party Providers

To see how a third-party provider works, please refer to my post on Structured Logging using Serilog.

Source Code

GitHub