The ASP.NET Core logging system is characterized by some key attributes that are always present in each log record. Furthermore, it is essential to keep logs as coherent as possible. The crucial components of the ASP.NET Core logging system are the log category, the log level, the log event id, and the log message.

The log category is specified when the ILogger<T> interface is initialized. It is an essential part of the logging process because it identifies the component that is emitting the log record. The log category usually corresponds to the type or class that's firing the log records. Let's use the ItemController class of the catalog service as an example. The log category is defined during the ILogger interface injection process:

namespace Catalog.API.Controllers
{
    [Route("api/items")]
    [ApiController]
    [JsonException]
    [Authorize]
    public class ItemController : ControllerBase
    {
        private readonly IItemService _itemService;
        private readonly IEndpointInstance _messageEndpoint;
        private readonly ILogger<ItemController> _logger;

        public ItemController(IItemService itemService, 
        IEndpointInstance messageEndpoint,
            IDistributedCache distributedCache, 
            ILogger<ItemController> logger)
        {
            _itemService = itemService;
            _messageEndpoint = messageEndpoint;
            _logger = logger;
        }
...

The ItemController class uses the widespread technique of constructor injection to initialize the ILogger<ItemController> type. Therefore, the log category is implicitly defined in the signature of the _logger property. Although the log category helps us identify which component is firing that specific log message, we also need to define the importance of that message.

The log level provides information that indicates the severity or importance of the log record. ASP.NET Core provides a helpful extension method that offers some abstraction over the log level:

_logger.LogInformation, _logger.LogWarning, _logger.LogError, _logger.LogCritical

Each of these methods is an abstraction that's provided by the Microsoft.Extensions.Logging namespace. For example, if we examine the _logger.LogInformation method implementation, under the hood, it merely calls the generic logger.Log method:

public static void LogInformation(
  this ILogger logger,
  EventId eventId,
  Exception exception,
  string message,
  params object[] args)
{
  logger.Log(LogLevel.Information, eventId, exception, message, args);
}

The LogInformation extension method wraps the logger.Log method calls by implicitly defining the level of information provided by the framework. The LogLevel attribute is an enum structure that's exposed by the Microsoft.Extension.Logging namespace, which provides the following out of the box logging levels:

namespace Microsoft.Extensions.Logging
{
  public enum LogLevel
  {
    Debug,
    Warning,
    Error,
    Critical,
    None,
  }
}

The preceding code describes the different log levels that are provided by the LogLevel enumerator. The log levels go from Trace, which describes detailed information about the system, to the Critical level, which means that the service is unable to work correctly and is shutting down. The LogLevel attribute is essential because it is usually used to filter the log messages which tells us of the priority of a logging message.

Once we've identified the level of severity of a specific log message, we need to provide the log event id, which helps us identify a specific event in the logging output. While the log category usually represents the full path of the class, the log event id is useful if we wish to express the method that is currently generating the logging output. Let's use the action methods contained in the ItemController class as an example (Get, GetById, Create, Update, and Delete). It is possible to create a log event class that maps each action method to a specific event id:

namespace Catalog.API
{
    public class LoggingEvents
    {
            public const int Get = 1000;
            public const int GetById = 1001;
            public const int Create = 1002;
            public const int Update = 1003;
            public const int Delete = 1004;
    }
}

Therefore, we can pass the corresponding log event id when we call the ILogger interface in an action method of the ItemController class. By doing this, it is possible to identify and group events:

 _logger.LogInformation(LoggingEvents.GetById, "Getting item");

Finally, another essential part of logging records is the message associated with the log record. The logging system of ASP.NET Core also provides a templating system that's analogous to the C# string interpolation feature. Therefore, it is possible to use the templating system in the following way:

 _logger.LogInformation(LoggingEvents.GetById, "GetById {id} ", id);

The preceding code logs a message about information severity using the LoggingEvents.GetById event id and adds the message "GetById {id} ". Now that we have looked at the different logging characteristics provided by ASP.NET Core, we will look at a concrete implementation that's been applied to the catalog service project.