Einleitung: Warum Logging die Grundlage einer stabilen Anwendung ist
Jeder Entwickler, insbesondere Anfänger, stößt früher oder später auf die Situation, dass die Anwendung abstürzt und die Ursache nicht nachvollziehbar ist. Ohne Logs sind Sie blind. Logging ist nicht nur das Aufzeichnen von Nachrichten in eine Datei, sondern ein leistungsstarkes Werkzeug für Monitoring, Debugging und Analyse des Programmverhaltens. Im C# (.NET)-Ökosystem gibt es mehrere ausgereifte Frameworks, die eine flexible Konfiguration der Logausgabe ermöglichen. In diesem Artikel behandeln wir die besten Logging-Praktiken für Anfänger: von der Bibliotheksauswahl bis zur strukturierten Datenausgabe.
1. Bibliotheksauswahl für Logging: NLog vs. Serilog
Für .NET-Anwendungen gibt es zwei Hauptakteure: NLog und Serilog. Beide sind kostenlos, werden aktiv unterstützt und bieten tausende Integrationen. Welche soll man wählen?
NLog
- Einfache Konfiguration über XML oder Code.
- Hervorragende Leistung unter hoher Last.
- Integrierte Unterstützung für Dateirotation, E-Mail-Versand, Datenbank-Logging.
- Geeignet für Projekte, die einen schnellen Start ohne überflüssige Abhängigkeiten benötigen.
Serilog
- Fokus auf strukturiertes Logging (structured logging).
- Logs werden nicht als Zeichenketten, sondern als Objekte mit Feldern gespeichert – das vereinfacht Suche und Analyse.
- Ideal für Microservices und Systeme, bei denen Logs in Elasticsearch oder Grafana gesammelt werden.
- Syntax mit Platzhaltern
{Property}macht den Code lesbarer.
Tipp für Anfänger: Beginnen Sie mit Serilog, wenn Sie mit modernen Monitoring-Tools arbeiten möchten. Wenn das Projekt klein und lokal ist, ist NLog ausreichend.
// Beispiel für die Serilog-Konfiguration in Program.cs (.NET 6+)using 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(); // Serilog an den Host anbinden2. Log-Level: Wann und was protokollieren
Einer der häufigsten Fehler von Anfängern ist, alles auf der Ebene Info oder Error zu protokollieren. Das überfrachtet die Logs und macht sie nutzlos. In .NET sind folgende Level üblich (aufsteigend nach Wichtigkeit):
- Trace – kleinste Details: Methodenein-/austritte, Schleifendurchläufe. Nur bei tiefergehendem Debugging verwenden.
- Debug – Debug-Informationen für den Entwickler: Variablenwerte, Objektzustände.
- Information – Schlüsselereignisse des Anwendungsbetriebs: Start, Stopp, erfolgreiche Verarbeitung einer Anfrage.
- Warning – potenzielle Probleme, die den Betrieb nicht stören: langsame Anfrage, veraltete API-Version.
- Error – Ausnahmen und Fehler, die ein Eingreifen erfordern: Datenbankfehler, Timeout.
- Fatal – kritische Fehler, nach denen die Anwendung nicht weiterarbeiten kann.
// Beispiel für die Verwendung verschiedener LevelILogger<MyService> _logger;
public async Task ProcessOrderAsync(int orderId){ _logger.LogInformation("Start der Auftragsverarbeitung {OrderId}", orderId);
try { var result = await _repository.GetOrderAsync(orderId); if (result == null) { _logger.LogWarning("Auftrag {OrderId} nicht gefunden", orderId); return; } // ... Logik } catch (Exception ex) { _logger.LogError(ex, "Fehler bei der Verarbeitung von Auftrag {OrderId}", orderId); throw; // Weiterleiten, wenn keine Wiederherstellung möglich ist }}Beste Pra