10 .NET Core Logging Best Practices

Logging is an important part of any application, and .NET Core applications are no exception. Logging can be used for a variety of purposes, such as debugging, auditing, and monitoring.

There are a number of different logging frameworks available for .NET Core, and each has its own strengths and weaknesses. In this article, we will discuss 10 best practices for logging in .NET Core applications.

1. Logging is not a cross-cutting concern

Cross-cutting concerns are features that are required by multiple parts of an application, but which are not central to the application’s main purpose. For example, security and logging are often cited as cross-cutting concerns.

The problem with treating logging as a cross-cutting concern is that it leads to code duplication and a lot of unnecessary complexity. In .NET Core, there is already a built-in logging framework that can be used by all components in an application. There’s no need to duplicate this functionality by creating your own logging infrastructure.

Furthermore, when logging is treated as a cross-cutting concern, it’s often difficult to get a clear picture of what’s going on in an application. This is because each component is responsible for its own logging, and there’s no centralized place where all the logs can be viewed.

By contrast, when logging is not treated as a cross-cutting concern, it’s much easier to get a clear picture of what’s going on in an application. This is because all the logs are stored in a central location, and they can be easily viewed and analyzed.

So, if you’re working on a .NET Core application, make sure you’re not treating logging as a cross-cutting concern. It will save you a lot of time and effort in the long run.

2. Use the right logging framework

The first reason is that the right logging framework will make it easier to add logging to your code. This is because the logging framework will provide you with an API that makes it easy to add logging statements to your code.

The second reason is that the right logging framework will make it easier to configure your logging. This is because the logging framework will provide you with a configuration file that you can use to configure your logging.

The third reason is that the right logging framework will make it easier to control your logging. This is because the logging framework will provide you with a way to control the level of logging, so that you can log only the information that you need.

The fourth reason is that the right logging framework will make it easier to manage your logs. This is because the logging framework will provide you with a way to manage your logs, so that you can delete old logs, rotate logs, and so on.

The fifth reason is that the right logging framework will make it easier to troubleshoot problems. This is because the logging framework will provide you with a way to view the logs, so that you can troubleshoot problems.

3. Don’t log everything

If you log everything, your logs will be filled with noise that makes it difficult to find the information you’re looking for. When something goes wrong, you’ll have to wade through all of the irrelevant information to find the few relevant pieces that can help you solve the problem.

Instead, only log the information that is actually useful. This means being selective about what you include in your logs, and making sure that the information you do include is well-organized and easy to understand.

To make sure you’re only logging useful information, start by identifying the most important aspects of your system. What are the key components? What are the most critical pieces of information? Once you know what’s important, you can decide what information to include in your logs.

Remember, less is more when it comes to logging. By being selective about what you include, you can make your logs more useful, and easier to work with.

4. Avoid using magic strings in your logs

A magic string is a hard-coded string that’s used in your code to represent something. For example, you might have a magic string that represents the name of your application.

The problem with magic strings is that they’re brittle. If the thing that they represent changes, you have to go through your code and update all of the magic strings. This can be a time-consuming and error-prone process.

It’s much better to use constants or variables to represent things in your code. That way, if the thing that they represent changes, you only have to update the constant or variable once.

When it comes to logging, there are two main things that you might want to use magic strings for: log levels and loggers.

Log levels are the different types of events that you can log, such as “Error” or “Warning”. There are six log levels in .NET Core: Trace, Debug, Information, Warning, Error, and Critical.

Loggers are the different places where you can send your logs, such as a file or a database. In .NET Core, you can create custom logger providers to send your logs to any destination that you want.

Both log levels and loggers are represented by strings in .NET Core. However, there are constants and classes that you can use instead of magic strings.

For log levels, you can use the LogLevel class. For example, instead of using the string “Error”, you can use LogLevel.Error.

For loggers, you can use the ILoggerFactory class. For example, instead of using the string “MyLogger”, you can use ILoggerFactory.CreateLogger(“MyLogger”).

Using the LogLevel class and the ILoggerFactory class will make your code more robust and easier to maintain.

5. Use structured logging

With traditional logging, also known as unstructured logging, your log messages are just strings. This can make it difficult to parse and query your logs because you have to rely on string matching.

Structured logging, on the other hand, uses a predefined format for your log messages. This allows you to easily query and filter your logs based on the different fields in the message.

There are many different ways to achieve structured logging in .NET Core. One popular option is to use the Serilog library.

Serilog is a third-party logging library that provides structured logging for .NET Core applications. It comes with a number of features that make it easy to get started with structured logging.

For example, Serilog automatically includes contextual information in each log message, such as the date and time, the thread ID, and the log level. This saves you from having to manually add this information to each message.

Serilog also supports a wide range of output formats, making it easy to send your logs to different destinations. For example, you can send your logs to the console, a file, or a central logging server.

To get started with Serilog, check out the official documentation.

6. Use correlation IDs to track requests through your system

When a request comes into your system, it will likely touch many different parts of your code before it finally completes. This could be dozens or even hundreds of different methods. If something goes wrong with the request, it can be very difficult to figure out where the problem occurred.

This is where correlation IDs come in. A correlation ID is simply a unique identifier that is attached to a request as it flows through your system. Then, when something goes wrong, you can look at the logs for all of the different methods that were called and find the one (or ones) that have the same correlation ID. This will help you narrow down where the problem occurred.

There are many ways to generate correlation IDs, but one easy way is to use the Guid.NewGuid() method. Just make sure to add the ID to the log message so that it will be included in the output.

7. Add context data to your logs

When you’re troubleshooting an issue, context data is key. It can help you understand what was happening in the system at the time of the issue, and it can provide clues that lead you to a resolution.

Unfortunately, many developers don’t take advantage of this important logging best practice. They either don’t add context data to their logs at all, or they only add a few pieces of information.

If you want to get the most out of your .NET Core logging, make sure you’re adding as much context data as possible. Include information about the request, the user, the environment, and anything else that might be relevant. The more information you have, the easier it will be to resolve issues.

8. Centralize your logs

If you have multiple applications and services running on different servers, it can be difficult to get a clear picture of what’s going on if you’re looking at logs from each individual server. Centralizing your logs in one place makes it much easier to get an overview of your system and quickly identify any issues.

There are a few different ways to centralize your .NET Core logs. One option is to use a logging library that supports sending logs to a central location, such as Serilog. Alternatively, you can use a tool like Microsoft’s Azure Monitor to collect and view your logs.

Whichever method you choose, make sure you test it out before putting it into production, so you can be sure it’s working as expected.

9. Monitor your logs

Your logs are a valuable source of information about your application. They can tell you what’s going wrong, what’s working well, and give you insight into how your users are interacting with your app.

Unfortunately, logs can also be a huge pain to deal with. They’re often unstructured, hard to read, and difficult to search. This is why it’s so important to have a logging solution in place that can help you make sense of your logs and find the information you need quickly and easily.

Loggly is one such solution. It’s a cloud-based log management service that makes it easy to collect, search, and visualize your logs. It’s also designed specifically for .NET Core, so you can be sure that it will work well with your applications.

If you’re not already using a logging solution, we highly recommend giving Loggly a try.

10. Test your logging configuration

When you’re developing an application, it’s easy to forget about logging until something goes wrong in production. By then, it’s too late to fix any problems with your logging configuration.

To avoid this, make sure to test your logging configuration before deploying your application. That way, you can be confident that your logs will contain the information you need to debug any issues that arise.

There are a few different ways to test your logging configuration. One is to use a tool like Microsoft’s Log Parser to query your log files and verify that they contain the information you expect.

Another option is to write unit tests for your logger. This approach is especially useful if you’re using a third-party logging library, as it allows you to verify that the library is configured correctly.

Finally, you can also use a tool like Glimpse to inspect the contents of your logs in real time. This can be helpful for troubleshooting issues that are difficult to reproduce.