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:
Install the DotNET SDK for fast error logging
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 messageslog4net.Filter.StringMatchFilter– Filters messages to ones that match a stringlog4net.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 logging and triaging, making fixing errors easier than ever. Try it today!
