Logging in C#-Anwendungen: Best Practices für die .NET-Entwicklung

Online Python-Trainer für Anfänger

Lernen Sie Python einfach ohne theoretische Überlastung. Lösen Sie praktische Aufgaben mit automatischer Überprüfung und schreiben Sie Code direkt im Browser.

Kurs starten

Logging in C#-Anwendungen: Best Practices



Logging ist nicht einfach nur das Schreiben von Nachrichten in eine Datei. In modernen .NET-Anwendungen ist es ein kritisches Werkzeug für Monitoring, Debugging und Audit. Ein gut konfiguriertes Logging ermöglicht es, Fehlerursachen schnell zu finden, die Leistung zu analysieren und Sicherheitsanforderungen zu erfüllen. In diesem Artikel behandeln wir die Best Practices für Logging in C#, die Ihnen helfen, ein zuverlässiges System zur Erfassung diagnostischer Informationen aufzubauen.



Auswahl der Logging-Bibliothek: Serilog vs NLog vs integrierter ILogger



In .NET gibt es mehrere beliebte Lösungen. Betrachten wir ihre Stärken und Schwächen.



  • Microsoft.Extensions.Logging (ILogger) — integriertes abstraktes Interface. Geeignet für einfache Projekte. Unterstützt strukturiertes Logging nicht "out of the box".
  • Serilog — Marktführer in Bezug auf Beliebtheit. Zeichnet sich durch einfache Konfiguration, leistungsstarke Unterstützung für strukturierte Logs und eine umfangreiche Sammlung von Sinks (Datenempfängern) aus.
  • NLog — ausgereiftes Framework mit flexibler Konfiguration über XML oder Code. Hervorragend geeignet für Legacy-Systeme und komplexe Routing-Szenarien.


Für neue Projekte wird Serilog empfohlen. Es lässt sich einfach in ILogger integrieren und bietet eine prägnante API. Beispiel für die Einbindung:



// Installation: dotnet add package Serilog.AspNetCoreusing Serilog;

Log.Logger = new LoggerConfiguration() .MinimumLevel.Information() .WriteTo.Console() .WriteTo.File("logs/app-.log", rollingInterval: RollingInterval.Day) .CreateLogger();

var builder = WebApplication.CreateBuilder(args);builder.Host.UseSerilog(); // Ersetzt den Standard-Logger


Richtige Verwendung von Logging-Levels



Mischen Sie nicht alle Nachrichten in eine Ebene. Verwenden Sie die folgende Abstufung:



  • Trace (0) — maximal detaillierte Informationen zum Debuggen. Enthält Details zur Ausführung jeder Funktion. Nur in der Dev-Umgebung aktivieren.
  • Debug (1) — nützliche Daten für den Entwickler: Variablenwerte, Ergebnisse von Methodenaufrufen.
  • Information (2) — Geschäftsereignisse: "Benutzer hat sich angemeldet", "Bestellung erstellt". Sollten auch für Nicht-Programmierer verständlich sein.
  • Warning (3) — Anomalien, die den Betrieb nicht unterbrechen: Überschreitung der Ausführungszeit, erneute Verbindungsversuche.
  • Error (4) — Ausnahmen und Fehler, die ein Eingreifen erfordern. Loggen Sie immer den vollständigen Call Stack.
  • Critical (5) — fatale Fehler: Verbindungsverlust zur Datenbank, Speicherüberlauf. Erfordern sofortige Benachrichtigung.


Beispiel für korrektes Logging in einem Controller:



[ApiController][Route("api/orders")]public class OrdersController : ControllerBase{    private readonly ILogger<OrdersController> _logger;

public OrdersController(ILogger<OrdersController> logger) { _logger = logger; }

[HttpPost] public IActionResult CreateOrder(OrderDto order) { _logger.LogInformation("Erstelle Bestellung {OrderId} für Benutzer {UserId}", order.Id, order.UserId); try { // Geschäftslogik _logger.LogInformation("Bestellung {OrderId} erfolgreich erstellt", order.Id); return Ok(); } catch (Exception ex) { _logger.LogError(ex, "Fehler beim Erstellen der Bestellung {OrderId}", order.Id); return StatusCode(500); } }}


Strukturiertes Logging und Kontext



Vermeiden Sie String-Konkatenation in Logs. Verwenden Sie anstelle von Log.Information("User: " + user.Name) Vorlagen mit Parametern:



_logger.LogInformation("Benutzer {UserName} hat ausgeführt", userName);

Blogs

Buchempfehlungen