Blog |

.NET Error Logging Best Practices

.NET Error Logging Best Practices

Following best practices when logging helps make sure they contain the right information when needed. Some common best practices for logging errors in .NET are listed below:

1.Use a Third Party .NET Logging Library

Logging frameworks in .NET such as NLog, Log4Net and Serilog provide high level APIs and handle the heavy lifting involved with logging errors. This helps developers use a field-tested option and not reinvent the wheel. Choosing the right library for .NET frameworks depends on the application architecture but these libraries are quite similar in functionality at a high level.

2.Using .NET Logging Levels

Logging frameworks associate a log level to each message by default. The levels are usually - DEBUG, INFO, WARN, ERROR and FATAL. These levels are useful for conveying the kind of information being logged.

ERROR indicates that an .NET error occurred in the application. Usually, ERROR messages should be logged when exceptions are caught. FATAL generally indicates that a major irrecoverable .NET error occurred that requires termination of the application.

3.Enabling Appropriate Log Levels in Production

In a development or test environment, all .NET log messages of DEBUG level and above are useful and can be enabled for analysis. However, in production, only high-severity logs should be enabled. Usually, DEBUG and INFO levels should not be enabled - only WARN/ERROR and above. This helps improve performance, reduce storage and ensure more important .NET logs aren't obscured.

4.Contextual .NET Error Logging

Context is important to understand any issues that occur in an application. Using contextual items available in an application such as the request, current thread, state, user information and timestamp provides context to .NET error log messages.

Context should be logged with all exceptions since it helps developers better identify and resolve issues. All .NET logging libraries support reporting context. Using structured error logging to provide context is best, since it allows searching and filtering relevant logs.

5.Structured .NET Error Logging

As applications grow in size, their logs also grow along with them and can become hard to manage and inspect. In .NET, structured error logging provides the tools to search for relevant logs, aggregate them according to context and analyze them.

6.Log Filters

.NET error logging libraries provide a number of filters that can finely control the messages logged by appenders. Here are some examples of filters in Log4Net:

  • log4net.Filter.DenyAllFilter – Denies all messages
  • log4net.Filter.StringMatchFilter – Filters messages to ones that match a string
  • log4net.Filter.LevelRangeFilter – Filters messages within a range of log levels

7.Sensitive Information

Production logs in the .NET framework should not contain any sensitive or private information for example, passwords, credit card numbers, social security numbers etc. This can also include information like user preferences and patterns.

Setting the minimum log level to WARN or ERROR in production helps minimize this. However, error logs can still contain sensitive information and developers should be careful that any such information is not logged for .NET applications.

Track, Analyze and Manage .NET Errors With Rollbar

Managing errors and exceptions in your code is challenging. It can make deploying production code an unnerving experience. Being able to track, analyze, and manage errors in real-time can help you to proceed with more confidence. Rollbar automates .NET error monitoring and triaging, making fixing errors easier than ever. Try it today!

Related Posts

See all posts

"Rollbar allows us to go from alerting to impact analysis and resolution in a matter of minutes. Without it we would be flying blind."

Start continuously improving your code today.

Get Started Shape