Before you begin: Join our book community on Discord

Give your feedback straight to the author himself and chat to other early readers on our Discord server (find the “architecting-aspnet-core-apps-3e” channel under EARLY ACCESS SUBSCRIPTION).

https://packt.link/EarlyAccess

This chapter covers a .NET-specific feature and closes the Designing for ASP.NET Core section. The logging feature that comes with a few patterns is another building block that most applications need: built-in ASP.NET Core. We explore the system hands-on while not trying to master every aspect.Logging is a crucial aspect of application development and serves various purposes, such as debugging errors, tracing operations, analyzing usage, and more.The logging abstractions we explore here are another improvement of .NET Core over .NET Framework. Instead of relying on third-party libraries, the new, uniform system offers clean interfaces backed by a flexible and robust mechanism that helps implement logging into our applications.At the end of this chapter, you will understand what logging is and how to write application logs.In this chapter, we cover the following topics:

• About logging
• Writing logs
• Log levels
• Logging providers
• Configuring logging
• Structured logging

Let’s start by exploring what logging is.

About logging

Logging is the practice of writing messages into a log and cataloging information for later use. That information can be used to debug errors, trace operations, analyze usage, or any other reason we can come up with. Logging is a cross-cutting concern, meaning it applies to every piece of your application. We talk about layers in Chapter 14, Layering and Clean Architecture, but until then, let’s just say that a cross-cutting concern affects all layers and cannot be centralized in just one; it affects a bit of everything.A log is made up of log entries. We can view each log entry as an event that happened during the program’s execution. Those events are then written to the log. This log can be a file, a remote system, stdout, or a combination of multiple destinations.When creating a log entry, we must also think about the severity of that log entry. In a way, this severity level represents the type of message or the level of importance that we want to log. We can also use it to filter those logs. Trace, Error, and Debug are examples of log entry levels. Those levels are defined in the Microsoft.Extensions.Logging.LogLevel enum.Another important aspect of a log entry is how it is structured. You can log a single string. Everyone on your team could log single strings in their own way. But what happens when someone searches for information? Chaos ensues! There’s the stress of not finding what that person is looking for and the displeasure of the log’s structure, as experienced by that same person. One way to fix this is by using structured logging. It is simple yet complex; you must create a structure the program follows for all log entries. That structure could be more or less complex or be serialized into JSON. The important part is that the log entries are structured. We won’t get into this subject here, but if you must decide on a logging strategy, I recommend digging into structured logging first. If you are part of a team, then chances are someone else already did. If that’s not the case, you can always bring it up. Continuous improvement is a key aspect of life.We could write a whole book on logging, best logging practices, structured logging, and distributed tracing, but this chapter aims to teach you how to use .NET logging abstractions.