Logging in C#-Anwendungen: Best Practices in der Praxis

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 in der Praxis

Logging ist nicht einfach nur das Aufzeichnen von Nachrichten in eine Datei. Es ist ein äußerst wichtiges Werkzeug für Monitoring, Debugging und Auditing jeder Production-Anwendung in C#. Ein richtig konfiguriertes Logging ermöglicht es, die Ursachen von Fehlern schnell zu finden, das Systemverhalten zu analysieren und Vorfälle zu verhindern. In diesem Artikel besprechen wir die Best Practices für das Logging in .NET, die Sie sofort in Ihren Projekten anwenden können.

1. Bibliotheksauswahl: Serilog vs NLog vs integrierter ILogger

Im modernen .NET gibt es drei Hauptansätze für das Logging. Betrachten wir ihre Stärken.

Integrierter ILogger (Microsoft.Extensions.Logging) — eine grundlegende abstrakte Schnittstelle. Sie ist in ASP.NET Core integriert und minimal konfigurierbar. Geeignet für einfache Projekte, erfordert aber Drittanbieter-Provider für fortgeschrittene Szenarien.
Serilog — der De-facto-Standard in der Branche. Unterstützt strukturiertes Logging "out of the box", ein reichhaltiges Ökosystem an Sinks (Zielen) und eine einfache Konfiguration über die Konfiguration.
NLog — ein ausgereiftes Framework mit flexibler Weiterleitung und Unterstützung für Legacy-Systeme. Es zeichnet sich durch hohe Leistung und detaillierte Regelkonfiguration aus.

Empfehlung: Verwenden Sie für neue Projekte Serilog — es lässt sich am besten in moderne Praktiken (ELK, Application Insights) integrieren. Für hochlastige Systeme, bei denen die Leistung kritisch ist, ziehen Sie NLog in Betracht.

// Beispiel für die minimale Konfiguration von Serilog in Program.csusing Serilog;

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

try{    Log.Information("Anwendung gestartet");    // Ihr Code}catch (Exception ex){    Log.Fatal(ex, "Kritischer Fehler beim Start");}finally{    Log.CloseAndFlush();}

2. Logging-Levels: Wann und was schreiben

Die falsche Wahl des Logging-Levels ist einer der häufigsten Fehler. Lassen Sie uns jeden Level und seine Bedeutung durchgehen.

Trace / Verbose — nur für das Debugging durch den Entwickler. Niemals in der Produktion ohne äußerste Notwendigkeit aktivieren.
Debug — Diagnoseinformationen für die Entwicklung. Kann vorübergehend zur Fehlersuche aktiviert werden.
Information — normaler Betrieb der Anwendung: Anfragen, erfolgreiche Operationen, Geschäftsereignisse. Hauptlevel in der Produktion.
Warning — potenzielles Problem: wenig Speicherplatz, Wiederholungsversuche, veraltete API.
Error — Ausnahmen und Fehler, die die Anwendung verarbeitet hat, die der Benutzer aber als Problem bemerkt hat.
Fatal / Critical — nicht behebbare Fehler, die sofortiges Eingreifen des Administrators erfordern.

// Beispiel für die korrekte Verwendung von Levelspublic class OrderService{    private readonly ILogger<OrderService> _logger;

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

    public async Task<Order> CreateOrderAsync(CreateOrderRequest request)    {        _logger.LogInformation("Erstelle Bestellung für Benutzer {UserId}", request.UserId);

        try        {            var order = await _repository.SaveAsync(request);            _logger.LogInformation("Bestellung {OrderId} erfolgreich erstellt", order.Id);            return order;        }        catch (Exception ex)        {            _logger.LogError(ex, "Fehler beim Erstellen der Bestellung für Benutzer {UserId}", request.UserId);            throw;        }    }}