When running the application in production then the log level is set somewhere between Information and Error. The question is what to do if you or your customer experiences some undesired behavior and the logs with present log level aren't enough to pinpoint the issue.

The first solution that comes to mind is to try to reproduce the issue on a developer's machine with lower log level like Debug. It may be enough to localize the bug but sometimes it isn't. Even if you are allowed to restart the app in production with lower log level, the issue may go away ... temporarily, i.e. the app still has a bug.

Better solution is to change the log level temporarily without restarting the app.

First step is to initialize the logger with the IConfiguration. That way the logger changes the level as soon as you change the corresponding configuration (file).

In this post I will provide 2 examples, one that is using the ILoggingBuilder of the ASP.NET Core and the other example is using Serilog because it is not tightly coupled to ASP.NET Core (but works very well with it!). 

Using ILoggingBuilder:

// the content of appsettings.json
{
    "Logging": {
        "LogLevel": { "Default": "Information" } 
    }
}
-----------------------------------------
var config = new ConfigurationBuilder().
    AddJsonFile("appsettings.json", false, true) // reloadOnChange=true
    .Build();

// Setup of ASP.NET Core application
WebHostWebHost
    .CreateDefaultBuilder()
    .ConfigureLogging(builder =>
    {
        builder.AddConfiguration(config); // <= init logger
        builder.AddConsole();
    })
    ...

Using Serilog:

// the content of appsettings.json
{
    "Serilog": {
        "MinimumLevel": { "Default": "Information" }
    }
}
-----------------------------------------
var config = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json", false, true)  // reloadOnChange=true
    .Build();

var serilogConfig = new LoggerConfiguration()
    .ReadFrom.Configuration(config) // <= init logger
    .WriteTo.Console();

In case you are interested in integration with (ASP).NET Core 

// If having a WebHost
WebHost
    .CreateDefaultBuilder()
    .ConfigureLogging(builder => 
    {
        builder.AddSerilog(serilogConfig.CreateLogger());
    })
    ...;

// If there is no WebHost
var loggerFactory = new LoggerFactory()
    .AddSerilog(serilogConfig.CreateLogger());

At this point the loggers are coupled to IConfiguration or rather to appsettings.json, i.e if you change the level to Debug the app starts emitting debug-messages as well, without restarting it.

This solution has one downside, you need physical access to the appsettings.json. Even if you do, it still would be better to not change the configuration file. What we want is a component that let us set and reset a temporary log level and if this temporary level is not active then the values from appsettings.json should be used. That way you can change the level from the GUI or via an HTTP request against the Web API of your web application.

Luckily, the implementation effort for that feature is pretty low, but that's for another day...

Related Articles

.net core
(ASP).NET Core in production - Changing log level temporarily - 2nd approach
In the previous blog post I talked about how to change the log level at runtime by coupling the (or rather the ) with the . However, the solution has one drawback: you need to change the file  for that. In this post we will be able to change the log level without changing the…
Pawel Gerr
.net
.NET Core - Lowering the log level of 3rd party components
With the new .NET Core framework and libraries we have got an interface called Microsoft.Extensions.Logging.ILogger to be used for writing log messages. Various 3rd party and built-in components make very good use of it. To see how much is being logged just create a simple Web…
Pawel Gerr
entity framework core
Do Not Waste Performance by Not Using Temp Tables With Entity Framework Core
It has been a while since I released my article about the usage of temp tables in Entity Framework (v6). Meanwhile, Microsoft has released a completely rewritten version of its O/R mapper so my old approach is no longer applicable. But before we learn about a new one, let us…
Pawel Gerr
entity framework core
Better Entity Framework Core Performance by Reading Execution Plans
Both a LINQ query and an SQL statement are descriptions that state which data should be fetched, but not how.. Sure, when reading LINQ or SQL, we can make assumptions about the performance but not in every case. Some queries are either too fancy or too big to grasp, so our…
Pawel Gerr