.NET Core In Production – Changing Log Level Temporarily

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.

In diesem Artikel:

.NET Core In Production – Changing Log Level Temporarily
Pawel Gerr ist Architekt und Consultant bei Thinktecture. Er hat sich auf .NET Core Backends spezialisiert und kennt Entity Framework von vorne bis hinten.
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…

Kostenloser
Newsletter

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Diese Artikel könnten Sie interessieren
.NET
Incremental Roslyn Source Generators in .NET 6: Adapt Code Generation Based on Project Dependencies – Part 5

Incremental Roslyn Source Generators in .NET 6: Adapt Code Generation Based on Project Dependencies – Part 5

The Roslyn Source Generator, implemented in the previous articles of the series, emits some C# code without looking at the dependencies of the current .NET (Core) project. In this article our DemoSourceGenerator should implement a JsonConverter, but only if the corresponding library (e.g. Newtonsoft.Json) is referenced by the project.
08.07.2022
Unterschiede
.NET
Blazor WebAssembly vs. Blazor Server – Welche Unterschiede gibt es und wann wähle ich was?

Blazor WebAssembly vs. Blazor Server – Welche Unterschiede gibt es und wann wähle ich was?

Das Blazor Framework von Microsoft gibt es inzwischen in drei "Geschmacksrichtungen". Die erste ist Blazor WebAssembly, die zweite Blazor Server, und zu guter Letzt gibt es noch Blazor Hybrid. In diesem Artikel wollen wir uns die zwei "echten", also Browser-basierten, Web-Anwendungs-Szenarien WebAssembly und Server anschauen.
04.07.2022
Three different textured walls
.NET
Dependency Injection Scopes in Blazor

Dependency Injection Scopes in Blazor

The dependency injection system is a big part of how modern ASP.NET Core works internally: It provides a flexible solution for developers to structure their projects, decouple their dependencies, and control the lifetimes of the components within an application. In Blazor - a new part of ASP.NET Core - however, the DI system feels a bit odd, and things seem to work a bit differently than expected. This article will explain why this is not only a feeling but indeed the case in the first place and how to handle the differences in order to not run into problems later on.
31.05.2022
.NET
Asynchrone Operationen: Blazor WebAssembly für Angular-Entwickler – Teil 5 [Screencast]

Asynchrone Operationen: Blazor WebAssembly für Angular-Entwickler – Teil 5 [Screencast]

Eine Webanwendung will natürlich auch mit Daten gefüttert werden. Doch diese müssen irgendwo her kommen. Nichts liegt näher als diese von einer Web API zu laden. Dieser Screencast zeigt, wie asynchrone Operationen in Blazor funktionieren und welche gravierenden Unterschiede es zu Angular gibt.
26.05.2022
.NET
Typings: Blazor WebAssembly für Angular-Entwickler – Teil 4 [Screencast]

Typings: Blazor WebAssembly für Angular-Entwickler – Teil 4 [Screencast]

C# und TypeScript entstammen der Feder der selben Person. Doch sind sie deshalb auch gleich? In diesem Teil der Screencast-Serie erfahren Sie, wie mit Typen in den beiden Programmiersprachen verfahren wird und welche Unterschiede es gibt.
19.05.2022
.NET
Bindings: Blazor WebAssembly für Angular-Entwickler – Teil 3 [Screencast]

Bindings: Blazor WebAssembly für Angular-Entwickler – Teil 3 [Screencast]

Wer Komponenten einsetzt, steht früher oder später vor der Fragestellung, wie man Daten an die Komponente übergibt oder auf Ereignisse einer Komponente reagiert. In diesem Screencast wird gezeigt wie Bindings bei Komponenten funktionieren, also wie eine Komponente Daten von außerhalb benutzen und Rückmeldung bei Aktionen geben kann.
12.05.2022