Verwenden von Microsoft.Extensions.Logging in EF Core

Microsoft.Extensions.Logging ist ein erweiterbarer Protokollierungsmechanismus mit Plug-In-Anbietern für viele gängige Protokollierungssysteme. Sowohl von Microsoft bereitgestellte Plug-Ins (z. B. Microsoft.Extensions.Logging.Console) als auch Plug-Ins von Drittanbietern (z. B. Serilog.Extensions.Logging) sind als NuGet-Pakete verfügbar.

Entity Framework Core (EF Core) lässt sich vollständig in Microsoft.Extensions.Logging. Erwägen Sie jedoch die einfache Protokollierung für eine einfachere Methode zum Protokollieren, insbesondere für Anwendungen, die keine Abhängigkeitsinjektion verwenden.

ASP.NET Core-Anwendungen

Microsoft.Extensions.Logging wird standardmäßig in ASP.NET Core-Anwendungen verwendet. Das Aufrufen von AddDbContext oder AddDbContextPool veranlasst EF Core automatisch, die Protokollierungseinrichtung zu nutzen, die über den regulären ASP.NET-Mechanismus konfiguriert ist.

Andere Anwendungstypen

Andere Anwendungstypen können das GenericHost verwenden, um dieselben Abhängigkeitsinjektionsmuster abzurufen, wie in ASP.NET Core verwendet werden. AddDbContext oder AddDbContextPool kann dann wie in ASP.NET Core-Anwendungen verwendet werden.

Microsoft.Extensions.Logging kann auch für Anwendungen verwendet werden, die keine Abhängigkeitseinfügung verwenden, obwohl einfache Protokollierung einfacher einzurichten sein kann.

Microsoft.Extensions.Logging erfordert die Erstellung eines LoggerFactory. Diese Factory sollte an einer beliebigen Stelle als statische/globale Instanz gespeichert und jedes Mal verwendet werden, wenn ein DbContext erstellt wird. Beispielsweise ist es üblich, die Loggerfabrik als statische Eigenschaft im DbContext zu speichern.

public static readonly ILoggerFactory MyLoggerFactory
    = LoggerFactory.Create(builder => { builder.AddConsole(); });

Diese Singleton- oder globale Instanz sollte dann auf dem DbContextOptionsBuilder bei EF Core registriert werden. Beispiel:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .UseLoggerFactory(MyLoggerFactory)
        .UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=EFLogging;Trusted_Connection=True;ConnectRetryCount=0");

Abrufen detaillierter Nachrichten

Sensible Daten

Standardmäßig enthält EF Core nicht die Werte von Daten in Ausnahmemeldungen. Dies liegt daran, dass solche Daten vertraulich sein können und in der Produktionsverwendung offenbart werden können, wenn eine Ausnahme nicht behandelt wird.

Das Wissen von Datenwerten, insbesondere für Schlüssel, kann jedoch beim Debuggen sehr hilfreich sein. Dies kann in EF Core aktiviert werden, indem EnableSensitiveDataLogging() aufgerufen wird. Beispiel:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder.EnableSensitiveDataLogging();

Detaillierte Abfrageausnahmen

Aus Leistungsgründen umschließt EF Core nicht jeden Aufruf, um einen Wert vom Datenbankanbieter in einem Try-Catch-Block zu lesen. Dies führt jedoch manchmal zu Ausnahmen, die schwer zu diagnostizieren sind, insbesondere, wenn die Datenbank einen NULL-Wert zurückgibt, wenn das Modell nicht zulässig ist.

EnableDetailedErrors Das Aktivieren führt dazu, dass EF diese Try-Catch-Blöcke einführt und dadurch detailliertere Fehler bereitstellt. Beispiel:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder.EnableDetailedErrors();

Konfiguration für bestimmte Nachrichten

Mit der EF Core-API ConfigureWarnings können Anwendungen ändern, was passiert, wenn ein bestimmtes Ereignis auftritt. Dies kann verwendet werden, um:

• Ändern der Protokollebene, auf der das Ereignis protokolliert wird
• Protokollierung des Ereignisses vollständig überspringen
• Eine Ausnahme auslösen, wenn das Ereignis eintritt

Ändern der Protokollebene für ein Ereignis

Manchmal kann es hilfreich sein, die vordefinierte Protokollebene für ein Ereignis zu ändern. Zum Beispiel kann dies verwendet werden, um zwei zusätzliche Ereignisse von LogLevel.Debug bis LogLevel.Information zu fördern.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .ConfigureWarnings(
            b => b.Log(
                (RelationalEventId.ConnectionOpened, LogLevel.Information),
                (RelationalEventId.ConnectionClosed, LogLevel.Information)));

Unterdrücken der Protokollierung eines Ereignisses

Auf ähnliche Weise kann ein einzelnes Ereignis aus der Protokollierung unterdrückt werden. Dies ist besonders nützlich, um eine Warnung zu ignorieren, die überprüft und verstanden wurde. Beispiel:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .ConfigureWarnings(b => b.Ignore(CoreEventId.DetachedLazyLoadingWarning));

Ereignis auslösen

Schließlich kann EF Core so konfiguriert werden, dass es für ein bestimmtes Ereignis ausgelöst wird. Dies ist besonders nützlich, um eine Warnung in einen Fehler zu ändern. (Tatsächlich war dies der ursprüngliche Zweck der ConfigureWarnings Methode, daher der Name.) Zum Beispiel:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .ConfigureWarnings(b => b.Throw(RelationalEventId.QueryPossibleUnintendedUseOfEqualsWarning));

Filtern und andere Konfigurationen

Anleitungen zur Protokollfilterung und anderen Konfigurationen finden Sie unter Protokollierung in .NET .

EF Core-Protokollierungsereignisse werden in einer der folgenden definiert:

• CoreEventId für Ereignisse, die allen EF Core-Datenbankanbietern gemeinsam sind
• RelationalEventId für Ereignisse, die allen relationalen Datenbankanbietern gemeinsam sind
• Eine ähnliche Klasse für Ereignisse, die für den aktuellen Datenbankanbieter spezifisch sind. Beispiel: SqlServerEventId für den SQL Server-Anbieter.

Diese Definitionen enthalten die Ereignis-IDs, das Loglevel und die Kategorie für jedes Ereignis, wie von Microsoft.Extensions.Logging.