Einleitung

Logging ist OF COURSE ein kritischer Teil von Anwendungen, aber ich sehe es oft missverstanden / missbraucht in ASP.NET-Anwendungen. Dies ist Teil Post und Teil Manifest, wie man effektiv in ASP.NET Anwendungen anmelden.

Dies ist keine vollständige Anleitung zum Protokollieren; es gibt LOTS von denen da draußen; es geht mehr darum, eine effektive Protokollierungsstrategie für Ihre ASP.NET-Anwendungen zu wählen.

In der Hauptprotokollierung sollte NUTZLICH sein; ob es sich um die Protokollierung während der Entwicklung oder der Protokollierung in der Produktion handelt, es sollte nützlich für Sie / Ihr Team / Ihre Benutzer sein.

Das Problem

Zu oft wird Logging als das "nur tun, wenn es Ausnahmen" Sache gesehen. Ich denke, das missversteht, was Logging sein sollte.

LOGGING ist nicht nur für Exzeptionen

Im Allgemeinen sollten Sie in der Lage sein, einen wesentlichen Teil Ihrer Anwendung lokal auszuführen; in diesem Zusammenhang log.LogInformation ist dein Freund.

Die Lösung

Protokollierungserfolg

Im Laufe der 30 Jahre habe ich Code geschrieben Ich habe ein paar Beispiele für gute Protokollierung und WAY mehr Beispiele für schlechte Protokollierung gesehen.

Grundsätze des guten Holzeinschlags:

Logging in Development sollte ausreichende Informationen darüber geben, wie Ihre Anwendung läuft, um zu verstehen, was passiert, wenn.
Die Anmeldung in der Produktion sollte Ihnen einen super schnellen und einfachen Mechanismus geben, um zu verstehen, wie Ihre Anwendung fehlschlägt.
Zuviel Protokollierung in der Produktion ist ein negatives; es kann Ihre Anwendung verlangsamen und es schwieriger machen, die wichtigen Sachen zu finden.

Denken Sie daran; das Protokollieren IMMER zieht Ihre Anwendungsleistung herunter; Sie sollten protokollieren, was Sie benötigen, um ein Problem zu diagnostizieren, aber nicht mehr in der Produktion / wo Leistung kritisch ist (z.B. führen Sie keinen Leistungstest durch, wenn Sie volle Debug-Protokollierung verwenden).

Arten der Anmeldung in ASP.NET

Serilog vs Microsoft.Extensions.Logging

In ASP.NET haben Sie bereits ein Build in der Protokollierung System; Microsoft.Extensions.Logging......................................................................................................... Das ist ein gutes Protokollierungssystem, aber es ist nicht so flexibel wie Serilog. Serilog ist ein flexibleres Protokollierungssystem, mit dem Sie sich an mehreren Waschbecken (Ausgänge) anmelden und Ihre Protokolle mit zusätzlichen Informationen bereichern können.

BootStrap-Protokollierung

Dies ist die Protokollierung, die passiert, wenn Ihre Anwendung startet. Es ist das erste, was passiert, und es ist das erste, was Sie sehen sollten, wenn Sie Ihre Anwendung ausführen. In ASP.NET vor allem, wenn Sie die Konfiguration verwenden, ist es wichtig, dass Sie verstehen, was passiert, wenn Ihre Anwendung startet. Es ist eine super gemeinsame Quelle von Problemen in ASP.NET-Anwendungen.

Zum Beispiel in Serilog können Sie dies tun:

Log.Logger = new LoggerConfiguration()
             .WriteTo.Console()
             .WriteTo.File("logs/boot-*.txt", rollingInterval: RollingInterval.Day, retainedFileCountLimit: 7)
             .CreateBootstrapLogger();

HINWEIS: Dies ist begrenzt, da Sie an dieser Stelle keinen Zugriff auf die Konfiguration haben, um z.B. AppInsights zu verwenden, die Sie wahrscheinlich brauchen würden. #if RELEASE Blockieren, um den entsprechenden Schlüssel zu setzen.

Was dies tut, ist, Ihnen Daten über alle Startprobleme in Ihrer Anwendung zu geben; es schreibt sowohl an Konsole und eine Datei. Es ist auch wichtig, sicherzustellen, dass Sie nicht alle Protokolldateien speichern; Sie können hier sehen, dass wir nur 7 Tage im Wert von Protokollen speichern.

Sie möchten auch Ihre Start-Methode wickeln (in dieser App verwende ich die neue Program.cs Methode) in einem Versuch / fangen und protokollieren Sie alle Ausnahmen, die dort passieren.

try
 {
        ..all your startup code
 }
catch (Exception ex)
{
    if(args.Contains("migrate"))
    {
        Log.Information("Migration complete");
        return;
    }
    Log.Fatal(ex, "Application terminated unexpectedly");
}
finally
{
    Log.CloseAndFlush();
}

Der Log.CloseAndFlush() ist wichtig, da er sicherstellt, dass alle Protokolle auf die Festplatte geschrieben werden (Ihre App stürzt ab, sonst wird sie beendet, bevor sie dies tut).

Hier erkenne ich auch, ob die App in einem Migrationsmodus läuft und wenn ja, logge ich das und beende.

Log.Fatal ist die schwerste Log-Ebene; es wird verwendet, wenn Ihre Anwendung im Begriff ist, zu stürzen. Nicht alle Ausnahmen sind tödlich - Sie sollten Log.Error für diejenigen (es sei denn, sie bedeuten die APP (nicht der Antrag) kann nicht über diesen Punkt hinausgehen).

Protokollebenen

In ASP.NET (und.NET allgemeiner) haben Sie eine Reihe von Log-Levels:

Log.Fatal - Dies ist die schwerste Log-Ebene; es wird verwendet, wenn Ihre Anwendung im Begriff ist, abstürzen.
Log.Error - Dies wird verwendet, wenn eine Ausnahme auftritt, die bedeutet, dass die APP (nicht die Anfrage) nicht über diesen Punkt hinausgehen kann.
Log.Warning - Dies wird verwendet, wenn etwas passiert, das kein Fehler ist, aber etwas ist, das Sie beachten sollten (z.B. ein degradierter Service / etwas nicht ganz richtig aber kein Irrtum).
Log.Information - Dies wird für allgemeine Informationen über das, was in Ihrer Anwendung geschieht, verwendet.
Log.Debug - Dieses wird für Informationen verwendet, die nur nützlich sind, wenn Sie Ihre Anwendung debuggen (es ist EVERYWHERE in der Entwicklung, aber sollte in der Produktion deaktiviert werden).

Für die Produktion würde ich in der Regel die Protokollierung als Log.Fatal, Log.Error und Log.Warning Nur.

Laufzeitprotokollierung

Im Gegensatz zum Startprotokollieren ist dies die Protokollierung, die passiert, wenn Ihre Anwendung läuft. Dies ist die Protokollierung, die Ihnen sagt, was in Ihrer Anwendung zu jeder Zeit geschieht.

Zum Beispiel, um diese in Serilog zu verwenden, würden Sie dies tun:

  "Serilog": {
    "Enrich": ["FromLogContext", "WithThreadId", "WithThreadName", "WithProcessId", "WithProcessName", "FromLogContext"],
    "MinimumLevel": "Warning",
    "WriteTo": [
        {
          "Name": "Seq",
          "Args":
          {
            "serverUrl": "http://seq:5341",
            "apiKey": ""
          }
        },
      {
        "Name": "Console"
      },
      {
        "Name": "File",
        "Args": {
          "path": "logs/applog-.txt",
          "rollingInterval": "Day"
        }
      }

    ],
    "Properties": {
      "ApplicationName": "mostlylucid"
    }
  },

Anreicherungen

Wie Sie sehen werden, bin ich ein ziemlich großer Fan von Serilog; es ist eine großartige Logging-Bibliothek, die sehr flexibel ist. Eines der Dinge, die ich daran mag, ist die Fähigkeit, Ihre Protokolle mit zusätzlichen Informationen zu bereichern. Dies kann sehr nützlich sein, um Probleme in Ihrer Anwendung zu diagnostizieren. Im obigen Beispiel sehen Sie, dass ich meine Protokolle mit der Thread-ID, dem Thread-Namen, der Prozess-ID und dem Prozess-Namen anreichere. Dies kann sehr nützlich sein, um Probleme in Ihrer Anwendung zu diagnostizieren.

Ich habe auch das Logging auf mehrere 'Sinks' (Outputs) gesetzt; in diesem Fall schicke ich es an die Konsole, an eine Datei und an Seq (ein Logging-Dienst).

Mehrere Waschbecken zu haben ist praktisch, falls man versagt, in diesem Fall ist mein bevorzugter Logging-Service Seq, also schicke ich es zuerst dorthin. Wenn das fehlschlägt, schicke ich es an die Konsole und an eine Datei.

Ich habe auch die Eigenschaft ApplicationName in den Protokollen gesetzt; dies kann nützlich sein, wenn Sie mehrere Anwendungen haben, die sich auf denselben Dienst einloggen (was Sie häufig für verteilte Anwendungen tun werden; zusammen mit einer Korrelations-ID, um

Bei der Anmeldung in ASP.NET-Anwendungen (Teil 1...wahrscheinlich)