it-swarm-eu.dev

Best Practices für die Protokollierung und Ablaufverfolgung in .NET

Ich habe viel über das Nachverfolgen und Protokollieren gelesen und versucht, eine goldene Regel für Best Practices in dieser Angelegenheit zu finden, aber es gibt keine. Die Leute sagen, dass gute Programmierer eine gute Ablaufverfolgung produzieren, aber sagen wir es so und es muss aus Erfahrung kommen.

Ich habe auch ähnliche Fragen hier und über das Internet gelesen und sie sind nicht wirklich dasselbe, was ich stelle, oder sie haben keine zufriedenstellende Antwort, vielleicht weil die Fragen nicht detailliert genug sind.

Die Leute sagen also, dass die Ablaufverfolgung die Erfahrung des Debuggens der Anwendung in Fällen replizieren sollte, in denen Sie keinen Debugger anhängen können. Es sollte genügend Kontext bereitstellen, damit Sie sehen können, welcher Pfad an jedem Kontrollpunkt in der Anwendung verwendet wird.

Wenn Sie tiefer gehen, können Sie sogar zwischen Ablaufverfolgung und Ereignisprotokollierung unterscheiden, da "die Ereignisprotokollierung sich von der Ablaufverfolgung dadurch unterscheidet, dass wichtige Zustände erfasst werden und kein detaillierter Kontrollfluss".

Angenommen, ich möchte meine Ablaufverfolgung und Protokollierung nur mit den Standard-.NET-Klassen durchführen, die in System.Diagnostics Namespace. Ich habe festgestellt, dass die TraceSource-Klasse für den Job besser ist als die statische Trace-Klasse, da ich zwischen den Trace-Ebenen unterscheiden möchte und mithilfe der TraceSource-Klasse einen Parameter übergeben kann, der den Ereignistyp informiert, während ich die Trace-Klasse verwende, die ich verwenden muss Trace.WriteLineIf und überprüfe dann Dinge wie SourceSwitch.TraceInformation und SourceSwitch.TraceErrors, und es hat nicht einmal Eigenschaften wie TraceVerbose oder TraceStart.

In Anbetracht dessen würden Sie eine gute Vorgehensweise in Betracht ziehen, um Folgendes zu tun:

  • Verfolgen Sie ein "Start" -Ereignis, wenn Sie eine Methode starten, die eine einzelne logische Operation oder eine Pipeline darstellen soll, sowie eine Zeichenfolgendarstellung der an die Methode übergebenen Parameterwerte.
  • Verfolgen Sie ein "Information" -Ereignis, wenn Sie ein Element in die Datenbank einfügen.
  • Verfolgen Sie ein "Information" -Ereignis, wenn Sie den einen oder anderen Pfad in einer wichtigen if/else-Anweisung verwenden.
  • Verfolgen Sie einen "Kritischen" oder "Fehler" in einem Catch-Block, je nachdem, ob es sich um einen behebbaren Fehler handelt.
  • Verfolgen Sie ein "Stop" -Ereignis, wenn Sie die Ausführung der Methode abgeschlossen haben.

Bitte klären Sie auch, wann Verbose- und Warning-Ereignistypen am besten nachverfolgt werden können. Wenn Sie Beispiele für Code mit Nice Trace/Logging haben und bereit sind, diese zu teilen, wäre dies hervorragend.

Hinweis: Ich habe hier einige gute Informationen gefunden, aber immer noch nicht das, wonach ich suche: http://msdn.Microsoft. com/de-de/magazine/ff714589.aspx

53
Levidad

Die Wichtigkeit von Trace-Typen muss nicht aufgrund der Position des Trace im Code ausgewählt werden, sondern weil die verfolgte Nachricht mehr oder weniger wichtig ist. Beispiel:

Verfolgen Sie ein "Start" -Ereignis, wenn Sie eine Methode starten, die eine einzelne logische Operation oder eine Pipeline darstellen soll, sowie eine Zeichenfolgendarstellung der an die Methode übergebenen Parameterwerte.

Verwenden Sie den Starttyp, wenn Sie eine logische Operation starten. Dies bedeutet nicht, dass sich der Start-Trace am Anfang einer Methode befinden muss, und es bedeutet auch nicht, dass eine Methode einen Start-Trace haben muss.

In den meisten Fällen beginnt eine logische Operation jedoch tatsächlich am Anfang der Methode. Andernfalls sollten Sie sich fragen, ob der Code korrekt überarbeitet wurde.

Tracing-Parameter können auch eine schlechte Idee sein. Sie müssen sich von Fall zu Fall überlegen, was Sie verfolgen sollen. Zum Beispiel ist es wirklich schlecht, Parameter einer Methode void Authenticate(string userName, string plainPassword) zu verfolgen.

Verfolgen Sie ein "Information" -Ereignis, wenn Sie ein Element in die Datenbank einfügen.

Es hängt davon ab, ob. Einige Elemente müssen zurückverfolgt werden, aber nicht jedes Element.

  • Stellen Sie sich zum Beispiel vor, Sie fügen tatsächlich ein Protokollelement in Ihre Datenbank ein. Würden Sie Protokolle verfolgen? Und dann Spuren protokollieren? Und dann die Protokollierung der Ablaufverfolgung verfolgen?
  • Ein weiteres Beispiel: Sie fügen vertrauliche Daten ein. Dies erfordert eine Prüfung. Warum sollten Sie die Einfügung nachverfolgen, nachdem Sie sie überprüft haben?

Verfolgen Sie ein "Information" -Ereignis, wenn Sie den einen oder anderen Pfad in einer wichtigen if/else-Anweisung verwenden.

Auch hier kommt es darauf an.

Verfolgen Sie je nach Wetterlage einen "Kritischen" oder "Fehler" in einem Fangblock. Dies ist ein behebbarer Fehler.

Die Aktion, die nach einem nicht behebbaren Fehler ausgeführt wird, kann mehr als nur eine Nachverfolgung sein. Beispielsweise möchten Sie serverseitig die Ausnahme zur weiteren Analyse in der Datenbank speichern. Außerdem sind einige Ausnahmen weniger wichtig als andere und erfordern keine Rückverfolgung.

Verfolgen Sie ein "Stop" -Ereignis, wenn Sie die Ausführung der Methode abgeschlossen haben.

Siehe den ersten Punkt.

bitte klären Sie, wann Verbose- und Warning-Ereignistypen am besten nachverfolgt werden können.

Verbose :

Verbose wird verwendet, um zu verfolgen, was Sie verfolgen müssen, wenn etwas wirklich schief geht. Dies bedeutet, dass Sie in den meisten Fällen die Ablaufverfolgung ausführlicher Nachrichten deaktivieren. Manchmal müssen Sie jedoch einige Teile Ihres Codes debuggen, um zu verstehen, warum in einem Edge-Fall etwas fehlschlägt.

Normalerweise haben Sie viele ausführliche Nachrichten, mit denen Sie den Anwendungsfluss wirklich gut verstehen können. Dies bedeutet auch, dass diese Nachrichten die meiste Zeit deaktiviert werden müssen, weil:

  • andernfalls wächst das Protokoll sehr schnell.
  • du brauchst sie die meiste Zeit nicht,
  • sie können vertrauliche Daten zum Anwendungsfluss enthalten.

Stellen Sie sich verbose als ein Tool vor, das Sie verwenden müssen, wenn Sie keinen Zugriff auf den Debugger haben.

Warnung :

Die Ablaufverfolgung vom Warnungstyp wird verwendet, wenn etwas Falsches und Wichtiges passiert, ist jedoch nicht zu wichtig, um als Fehler behandelt zu werden. Zum Beispiel kann low RAM eine Warnung ausgeben, aber es gibt keinen Grund, einen Fehler zu verfolgen, da Ihre Anwendung fortgesetzt werden kann, auch wenn sie langsamer als gewöhnlich ist.

Beispiele :

  • Beispiel 1: Die Anwendung konnte die vom Benutzer angeforderte Datei nicht öffnen. Die Datei ist vorhanden und wird nicht verwendet. Die Berechtigungen sind korrekt festgelegt, aber etwas blockiert das Öffnen einer Datei. In diesem Fall verfolgen Sie einen Fehler, da Ihre Anwendung diesen Fall nicht verwalten kann und weiterhin wie vom Benutzer erwartet arbeitet (d. H. Die Datei tatsächlich liest).

  • Beispiel 2: Nach Überprüfung des Fehlers im ersten Beispiel stellen Sie fest, dass der Fehler durch die Tatsache verursacht wird, dass der Dateipfad länger als 259 Zeichen ist. Sie überarbeiten also Ihren Code, um PathTooLongException abzufangen. Wenn der Benutzer das nächste Mal versucht, dieselbe Datei zu öffnen, wird in der neuen Version der Anwendung eine Meldung angezeigt, dass die Datei zu lang ist und in einen anderen Ordner verschoben werden muss, um den vollständigen Pfad zu verkürzen und diese Datei zu öffnen Diese Anwendung. Sie verfolgen auch eine Nachricht.

  • Beispiel 3: Ihre Anwendung hat 20 Sekunden damit verbracht, eine kleine Datei zu öffnen und zu analysieren, während die meisten Dateien zehn bis einhundert Millisekunden benötigen, um sie zu öffnen und zu analysieren. Sie verfolgen ein Warnung mit relevanten Informationen: dem Datenträgertyp, auf dem sich die Datei tatsächlich befindet, dem Dateisystem, der Dateigröße, der genauen Zeitaufwand, der Betriebszeit des Computers usw. Wann Der Benutzer beschwert sich, dass das Öffnen der Datei 20 Sekunden dauert. Sie nehmen die Ablaufverfolgung, um herauszufinden, was passiert. Sie stellen beispielsweise fest, dass das Laden der Dateien von einer Netzwerkfreigabe so lange dauert, wenn der Computer gerade gestartet wurde. Sie erklären dem Benutzer, dass die Verzögerung auf das Netzwerk zurückzuführen ist und nicht mit Ihrer Anwendung zusammenhängt.

  • Beispiel 4: Die geöffnete Datei wird falsch angezeigt. Sie aktivieren verbose trace, wo Sie tatsächlich sehen, wie die Daten aus der Datei geladen und dann Schritt für Schritt analysiert werden.

17
 > say I want to do my tracing and logging using only the standard .NET classes

System.Diagnostics Ist großartig, da Sie konfigurieren können, wohin welche Trace-Informationen wohin gehen sollen (Datei, Ereignisprotokoll, Datenbank, ....)

Wenn Sie System.Diagnostics Verwenden möchten, müssen Sie leider im Voraus wissen (zur Entwurfszeit), welchen Trace-Streams Sie folgen können sollten. (Im Beispielartikel sind dies Transfer, Resume, Suspend, ...). Diese können als Deaktiviert, Debuglevel oder Errorlevel konfiguriert werden.

Ich bevorzuge ein Protokollierungssystem, in dem ich zur Laufzeit entscheiden kann, wie detailliert die Protokollierung sein soll. classlevel/namespacelevel. Zum Beispiel alle Debug und höher von MyNamespace.Business.*, Aber nicht MyNamespace.Business.Calculations.

Wenn Sie log4net (oder Common.logging) verwenden, erhält jede Klasse einen eigenen Logger, sodass Sie leicht entscheiden können, welche Klassen auf welcher Ebene protokolliert werden.

Da sich Datenbankoperationen in einer separaten Klasse befinden, ist keine eindeutige Regel mehr erforderlich

Trace an "Information" event when inserting an item into the database.

Stattdessen bevorzuge ich diese Richtlinien:

  • Tracelevel sollte den grundlegenden Workflow anzeigen
  • Debuglevel sollte detaillierte Daten und Verarbeitung innerhalb des Workflows anzeigen, einschließlich Entscheidungen im Programmablauf mit Gründen (Erstellen eines neuen Elements, da das Element in der Datenbank nicht vorhanden war)
  • Infolevel zum Starten/Stoppen von Diensten und ein Eintrag für jede gestartete Workflow-/GUI-Aktion
5
k3b

Sie können das Story-Framework ausprobieren. Es hat einen einzigartigen Ansatz für die Protokollierung, da es Sie dazu bringt, alle Protokolle im Kontext zu schreiben (und andere relevante Informationen hinzuzufügen). Wenn Sie sie später lesen müssen, erhalten Sie sie Alles, was du brauchst.

Die Konzepte "Start" und "Stopp" werden automatisch als Anfang und Ende einer Geschichte hinzugefügt.

Und mit einem regelbasierten System können Sie steuern, was mit jeder Story (Kontext) zu tun ist, basierend auf den Informationen, die sie enthält, z. B. alle Storys drucken, die einen Fehler aufweisen oder vom Benutzer "admin" stammen.

Auch mehr Informationen zu dieser Blog-Beitrag

4
Amit Apple