Logging-Frameworks wie log4net und NLog sind äußerst bekannt und zahlreich eingesetzt. Mit Serilog steht eine superschnelle Alternative zur Verfügung, die zudem auf das Loggen von strukturierten Daten ausgerichtet ist.
Dieser Beitrag zeigt die Einbindung von Serilog, sowie die Konfiguration über die Konfigurationsdatei appsettings.json. Abschließend werden noch einige Tipps für den Umgang mit Serilog gegeben.
Serilog einbinden
Die Einbindung erfolgt recht einfach. Für den aufgezeigten Anwendungsfall werden folgende NuGet-Pakete benötigt:
- Serilog.AspNetCore
- Serilog.Settings.Configuration (Unterstützung für
Microsoft.Extensions.Configuration) - Serilog.Sinks.File
- Serilog.Sinks.Console
Die Einbindung erfolgt an einer einzigen Stelle, der Program.cs:
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.UseSerilog((hostingContext, loggerConfiguration) => loggerConfiguration
.ReadFrom.Configuration(hostingContext.Configuration)
.Enrich.FromLogContext()
.WriteTo.Console())
.UseUrls("http://*:5000")
.Build();
Damit kann nun über Serilog geloggt werden. Ebenfalls ist es möglich, sich die Schnittstelle ILogger injecten zu lassen. Alle Logger arbeiten mit derselben Implementierung.
Serilog konfigurieren
Nun fehlt noch die Konfiguration in der Datei appsettings.json. Dort werden nun zwei Varianten eingestellt. So wird in eine Datei geschrieben, in unserem Fall gibt es für jeden Tag eine neue Datei. Zusätzlich erfolgt die Ausgabe über die Konsole:
"Serilog": {
"Using": [ "Serilog.Sinks.File", "Serilog.Sinks.Console" ],
"MinimumLevel": "Debug",
"WriteTo": [
{
"Name": "File",
"Args": { "pathFormat": "logs\\log-{Date}.txt" }
},
{ "Name": "Console" }
],
"Enrich": [ "FromLogContext", "WithMachineName", "WithThreadId" ],
"Properties": {
"Application": "Projektlogger2"
}
}
Als abschließende Arbeit sind noch alle Logging-Konfigurationen aus der Startup.cs zu entfernen. Dass betrifft sowohl den Aufruf AddLogging() als auch alle Vorkommen und Verwendungen der ILoggerFactory.
Das war es. Ab sofort wird Serilog für die Ausgabe aller Logging-Informationen verwendet.
Konfiguration mit Umgebungsvariablen
Serilog kann über Umgebungsvariablen konfiguriert werden. Hierzu muss dem ConfigurationBuilder mittels AddEnvironmentVariables mitgeteilt werden, dass diese zu berücksichtigen sind. Ist ein Wert bereits über appsettings.json gesetzt, wird dieser durch den Wert der Umgebungsvariable überschrieben:
set Serilog:MinimumLevel=Warning
dotnet run
Ein Blick in die Dokumentation lohnt sich, da es viele Einstellungsmöglichkeiten gibt. Auch die einzelnen Sinks können mitunter darüber konfiguriert werden.
Log-Level überschreiben
Die Konfiguration
"MinimumLevel": "Debug"
setzt ein Log-Level für alle konfigurierten Ausgaben. Hierüber können aber komplexere Angaben gemacht werden:
"MinimumLevel": {
"Default": "Information",
"Override": {
"Microsoft": "Warning",
"System": "Warning"
}
}
Das Default-Log-Level wird nun auf Debug gesetzt. Alles für Namespaces beginnend mit Microsoft und System wird auf Error gesetzt.
Performance
Wer sich für eine Performance-Messung interessiert, sei auf den Artikel Serilog vs NLog Benchmarks aus dem August 2017 verwiesen. Wie zahlreichen weiteren Tests zu entnehmen ist, sind beide Frameworks äußerst flott unterwegs und Konkurrenten wie log4net vorzuziehen.
Fazit
Serilog lässt sich genauso einfach in ein Projekt einbinden, wie man es von anderen Logging-Frameworks gewohnt ist. Es bestehen vielfältige Einstellungsmöglichkeiten und jede Menge Adapter (Sinks) für Ausgaben aller Art. Durch die Verwendung von strukturierten Daten ergeben sich zudem zahlreiche Vorteile, wie zum Beispiel das Setzen von Filtern.
Happy Coding!