Protokollierung in C#-Anwendungen: Best Practices für Einsteiger

Einleitung: Warum ist Protokollierung wichtig?

Stellen Sie sich vor, Ihre C#-Anwendung läuft in der Produktion. Plötzlich melden Benutzer einen Fehler, aber Sie können nicht nachvollziehen, was schiefgelaufen ist. Ohne Logs sind Sie wie ein Pilot ohne Instrumente. Protokollierung ist der Prozess der Aufzeichnung von Informationen über den Betrieb einer Anwendung: Fehler, Warnungen, Debug-Meldungen und wichtige Ereignisse.

In diesem Artikel behandeln wir die Best Practices für die Protokollierung für Einsteiger-Entwickler in C# (.NET). Sie erfahren, wie Sie die Protokollierung einrichten, welche Tools Sie verwenden und wie Sie typische Fehler vermeiden.

1. Auswahl des Tools für die Protokollierung in C#

Im .NET-Ökosystem gibt es mehrere beliebte Bibliotheken für die Protokollierung. Für Einsteiger empfehlen wir drei Hauptoptionen:

1.1. Integrierter ILogger (Microsoft.Extensions.Logging)

Seit .NET Core bietet Microsoft die integrierte Schnittstelle ILogger. Sie ist einfach zu verwenden und erfordert keine Installation von Drittanbieter-Bibliotheken.

using Microsoft.Extensions.Logging;\n\npublic class OrderService\n{\n    private readonly ILogger<OrderService> _logger;\n\n    public OrderService(ILogger<OrderService> logger)\n    {\n        _logger = logger;\n    }\n\n    public void ProcessOrder(int orderId)\n    {\n        _logger.LogInformation("Verarbeitung der Bestellung {OrderId}", orderId);\n        // Verarbeitungslogik\n    }\n}

1.2. Serilog – flexibel und leistungsstark

Serilog ist eine der beliebtesten Bibliotheken. Sie unterstützt strukturierte Protokollierung, was die Datenanalyse erleichtert. Installation über NuGet: Install-Package Serilog.AspNetCore

using Serilog;\n\npublic class Program\n{\n    public static void Main(string[] args)\n    {\n        Log.Logger = new LoggerConfiguration()\n            .MinimumLevel.Debug()\n            .WriteTo.Console()\n            .WriteTo.File("logs/app.log", rollingInterval: RollingInterval.Day)\n            .CreateLogger();\n\n        try\n        {\n            Log.Information("Anwendung gestartet");\n            CreateHostBuilder(args).Build().Run();\n        }\n        catch (Exception ex)\n        {\n            Log.Fatal(ex, "Anwendung mit Fehler beendet");\n        }\n        finally\n        {\n            Log.CloseAndFlush();\n        }\n    }\n}

1.3. NLog – die klassische Wahl

NLog ist eine weitere ausgereifte Bibliothek mit umfangreichen Konfigurationsmöglichkeiten über Konfigurationsdateien.

// Konfiguration über appsettings.json\n{\n  "NLog": {\n    "targets": {\n      "console": {\n        "type": "Console",\n        "layout": "${longdate}|${level:uppercase=true}|${message}"\n      },\n      "file": {\n        "type": "File",\n        "fileName": "logs/app.log",\n        "layout": "${longdate}|${level:uppercase=true}|${message}"\n      }\n    },\n    "rules": [\n      { "logger": "*", "minLevel": "Info", "writeTo": "console,file" }\n    ]\n  }\n}

2. Protokollierungsebenen: Wann was verwenden

Die korrekte Verwendung von Protokollierungsebenen ist die Grundlage guter Praxis. In C# (.NET) sind die folgenden Ebenen definiert (von der kritischsten zur am wenigsten kritischen):

\n
• Trace (0) – äußerst detaillierte Debug-Informationen. Wird nur für die tiefergehende Diagnose verwendet.
\n
• Debug (1) – Debug-Meldungen für Entwickler. In der Entwicklungsumgebung aktiviert, in der Produktion deaktiviert.
\n
• Information (2) – allgemeine Informationsmeldungen über den Betrieb der Anwendung (Start, erfolgreiche Vorgänge).
\n
• Warning (3) – Warnungen über potenzielle Probleme, die keine Fehler sind (z. B. Überschreitung der Ausführungszeit).
\n
• Error (4) – Fehler, die Aufmerksamkeit erfordern, aber für die Anwendung nicht fatal sind.
\n
• Critical (5) – kritische Fehler, nach denen die Anwendung nicht mehr weiterarbeiten kann.
\n