Freigeben über


Protokollierung und Ablaufverfolgung mit .NET

Code kann instrumentiert werden, um ein Protokoll zu erzeugen, das als Aufzeichnung interessanter Ereignisse dient, die während der Ausführung des Programms aufgetreten sind. Um das Verhalten der Anwendung zu verstehen, können Protokolle überprüft werden. Sowohl bei der Protokollierung als auch bei der Ablaufverfolgung wird dieses Verfahren eingesetzt. .NET hat im Laufe der Zeit mehrere verschiedene Protokollierungs-APIs entwickelt, und in diesem Artikel erfahren Sie mehr über die verfügbaren Optionen.

Die Begriffe „Protokollierung“ und „Ablaufverfolgung“ sind in der Regel synonym. Der Unterschied besteht darin, dass bei der Protokollierung ständig gesammelt wird, sodass der Aufwand gering sein sollte. Die Ablaufverfolgung ist in der Regel invasiver und es werden mehr Informationen aus der Tiefe der Anwendung und der .NET-Runtime gesammelt. Sie wird entweder bei der Diagnose bestimmter Probleme oder automatisch für kurze Zeit im Rahmen tiefer gehender Leistungsanalysesysteme verwendet.

Ein weiterer Dreh- und Angelpunkt für den Begriff der Ablaufverfolgung ist die verteilte Ablaufverfolgung. Bei der verteilten Ablaufverfolgung werden allgemeine Aktivitäts- und Zeiterfassungsdaten für anforderungsbasierte Systeme erfasst, und die Anforderungen werden dienstübergreifend korreliert, um eine Übersicht darüber zu erhalten, wie jede Anforderung vom gesamten System verarbeitet wird.

Wichtige Unterscheidungen bei Protokollierungs-APIs

Strukturierte Protokollierung

Protokollierungs-APIs können entweder strukturiert oder unstrukturiert sein:

  • Unstrukturiert: Protokolleinträge enthalten Freiformtextinhalte, die von Menschen angezeigt werden können.
  • Strukturiert: Protokolleinträge weisen ein klar definiertes Schema auf und können in verschiedenen Binär- und Textformaten codiert werden. Diese Protokolle sind so konzipiert, dass sie maschinell übersetzt und abgefragt werden können, sodass sowohl Menschen als auch automatisierte Systeme problemlos mit ihnen arbeiten können.

APIs, die die strukturierte Protokollierung unterstützen, sollten vorzugsweise für nicht triviale Zwecke eingesetzt werden. Sie bieten mehr Funktionalität, Flexibilität und Leistung bei geringem Unterschied in der Benutzerfreundlichkeit.

Konfiguration

Für einfache Anwendungsfälle sollten Sie APIs verwenden, die Nachrichten direkt in die Konsole oder eine Datei schreiben. Für die meisten Softwareprojekte ist es jedoch nützlich zu konfigurieren, welche Protokollereignisse aufgezeichnet und wie sie gespeichert werden. Wenn Sie beispielsweise in einer lokalen Entwicklungsumgebung arbeiten, sollten Sie zur leichteren Lesbarkeit Nur-Text auf der Konsole ausgeben. Wenn die Anwendung dann in einer Produktionsumgebung bereitgestellt wird, können Sie zu den Protokollen wechseln, die in einer dedizierten Datenbank oder mehreren rollierenden Dateien gespeichert sind. APIs mit guten Konfigurationsoptionen erleichtern diese Übergänge, während bei weniger konfigurierbaren Optionen der Instrumentierungscode überall aktualisiert werden müsste, um Änderungen vorzunehmen.

Senken

Die meisten Protokollierungs-APIs erlauben das Senden von Protokollnachrichten an verschiedene Ziele, die als Senken bezeichnet werden. Einige APIs verfügen über eine große Anzahl vorgefertigter Senken, während andere nur einige wenige haben. Wenn keine vordefinierte Senke vorhanden ist, gibt es in der Regel eine Erweiterungs-API, mit der Sie eine benutzerdefinierte Senke erstellen können, auch wenn dies das Schreiben von etwas mehr Code erfordert.

.NET-Protokollierungs-APIs

ILogger

In den meisten Fällen ist die ILogger-Infrastruktur eine gute Standardauswahl, unabhängig davon, ob Sie einem vorhandenen Projekt Protokollierung hinzufügen oder ein neues Projekt erstellen. ILogger unterstützt die schnelle strukturierte Protokollierung, flexible Konfiguration und eine Sammlung allgemeiner Senken, einschließlich der Konsole, die beim Ausführen einer ASP.NET-App angezeigt wird. Darüber hinaus kann ILogger auch als Schnittstelle für viele Protokollierungsimplementierungen von Drittanbietern dienen, die eine reichhaltige Funktionalität und Erweiterbarkeit bieten.

ILogger stellt den Protokollierungsverlauf für die Open Telemetry-Implementierung für .NET bereit, die die Versendung von Protokollen aus Ihrer Anwendung an eine Vielzahl von APM-Systemen zur weiteren Analyse ermöglicht.

EventSource

EventSource ist eine ältere Hochleistungsnachverfolgungs-API mit strukturierter Protokollierung. Sie wurde ursprünglich so konzipiert, dass sie sich gut mit Ereignisablaufverfolgung für Windows (ETW) integrieren lässt, wurde aber später erweitert, um die plattformübergreifende Ablaufverfolgung mit EventPipe und EventListener für benutzerdefinierte Senken zu unterstützen. Im Vergleich zu ILogger verfügt EventSource über relativ wenige vordefinierte Protokollierungssenken, und es gibt keine integrierte Unterstützung für die Konfiguration über separate Konfigurationsdateien. EventSource eignet sich hervorragend, wenn Sie eine bessere Steuerung der ETW- oder EventPipe-Integration benötigen, aber für die universelle Protokollierung ist ILogger flexibler und einfacher zu verwenden.

Trace

System.Diagnostics.Trace und System.Diagnostics.Debug sind die ältesten Protokollierungs-APIs von NET. Diese Klassen verfügen über flexible Konfigurations-APIs und ein großes Ökosystem von Senken, unterstützen jedoch nur die unstrukturierte Protokollierung. In .NET Framework können sie über eine app.config-Datei konfiguriert werden, aber in .NET Core gibt es keinen integrierten, dateibasierten Konfigurationsmechanismus. Sie werden in der Regel verwendet, um während der Ausführung im Debugger eine Diagnoseausgabe für den Entwickler zu erzeugen. Das .NET-Team unterstützt diese APIs aus Gründen der Abwärtskompatibilität weiterhin, es werden jedoch keine neuen Funktionen hinzugefügt. Diese APIs sind eine gute Wahl für Anwendungen, die sie bereits verwenden. Für neuere Apps, bei denen noch keine Protokollierungs-API verwendet wird, bietet ILogger möglicherweise eine bessere Funktionalität.

Spezialisierte Protokollierungs-APIs

Konsole

Die Klasse System.Console hat die Methoden Write und WriteLine, die in einfachen Protokollierungsszenarios verwendet werden können. Diese APIs sind sehr einfach zu verwenden, aber die Lösung ist nicht so flexibel wie eine universelle Protokollierungs-API. Die Konsole lässt nur die unstrukturierte Protokollierung zu, und es gibt keine Konfigurationsunterstützung, um auszuwählen, welche Protokollmeldungen aktiviert werden sollen, oder um eine andere Senke zu verwenden. Die Verwendung der ILogger- oder Ablaufverfolgungs-APIs mit einer Konsolensenke erfordert keinen großen zusätzlichen Aufwand und sorgt dafür, dass die Protokollierung konfigurierbar bleibt.

DiagnosticSource

System.Diagnostics.DiagnosticSource ist für die Protokollierung vorgesehen, bei der die Protokollmeldungen prozesssynchron analysiert und nicht in einen Speicher serialisiert werden. Dadurch können die Quelle und der Listener beliebige .NET-Objekte als Meldungen austauschen, während bei den meisten Protokollierungs-APIs das Protokollereignis serialisierbar sein muss. Diese Technik kann auch extrem schnell sein und Protokollereignisse innerhalb von zehn Nanosekunden verarbeiten, wenn der Listener effizient implementiert ist. Tools, die diese APIs verwenden, verhalten sich oft eher wie prozessinterne Profiler, obwohl die API hier keine Einschränkungen auferlegt.

EventLog

System.Diagnostics.EventLog ist eine reine Windows-API, die Meldungen in das Windows-EventLog schreibt. In vielen Fällen kann die Verwendung von ILogger mit einer optionalen EventLog-Senke bei der Ausführung unter Windows ähnliche Funktionen bieten, ohne dass die App eng an das Windows-Betriebssystem gekoppelt wird.