.net Diagnostics Best Practices?

Question

Wir haben zunächst keine Protokollierung oder Debug-Tracing verwendet, aber nach ein paar Wochen einige Daten Korruption zu verfolgen, haben wir beschlossen, Debug.Write and Trace für die Produktion und Debug.Assert setzen

So jetzt Frage ist was ist Die beste Vorgehensweise für die Debug- und Trace-Protokollierung. Ich suche nur etwas Generisches.

public void AddRectodatabase(object record) 
{ 
    Debug.WriteLine(record.ToString()); 
    Trace.WriteLine(record.ToString()); 

    // Add it to databse 

    Debug.Assert(true, "Use this on case by case basis"); 
} 

Ist das gut genug für allgemeine Zwecke, mache ich etwas falsch darin?

Wir wollen mit .net System.Diagnostics über andere Alternativen wie log4net bleiben.

Gibt es noch etwas anderes in System.Diagnostics?

Answer 1

Sie sollten ETW-Trace-Ereignisse in Ihrer gesamten App ansetzen - nicht nur, um die Benutzer auf Probleme aufmerksam zu machen, sondern auch um das Verhalten und sogar die Leistung Ihrer Apps und Komponenten sichtbar zu machen.

ETW ist eine (wahnsinnig) hohe Leistung und (erstaunlicherweise) wenig wirkungsvolle Möglichkeit, Ereignisse zu erzeugen, die gesammelt und analysiert werden können - sogar in Produktionsumgebungen. Es ist die Protokollierung & Tracing-Infrastruktur im gesamten Windows, SQL, etc. verwendet

Drei nützliche Links für Sie:

1. Diagnostics: Using ETW tracing in .NET 3.5 (EventProviderTraceListener)
2. Controlling .NET Framework Logging link text
3. Two Minute Drill: Introduction to XPerf

alle 3 um Lesen und dann erneut lesen - später werden Informationen sehr nützlich sein, aber es wird schwieriger zu verstehen sein, wenn Sie nicht begreifen Die Grundlagen zuerst;) Ignorieren Sie die Anweisungen, LogMan zu verwenden, um Ihre Trace-Sammlungen zu starten und zu stoppen; Verwenden Sie stattdessen XPerf.

Wenn Sie noch nicht the Perf toolkit and XPerf viewer gesehen haben, dann sind Sie in einem Genuss! : D

I stark fördern Sie erhöhen & Stopp Ereignisse am Anfang und Ende aller Ihrer Anwendungen zu betrachten beginnen wichtigsten Merkmale, so dass Sie diese Ereignisse mit anderen Telemetrie überlagern können, so dass Sie sehen können, für B. die Auswirkung Ihrer Apps-Funktionen auf Disk, Netzwerk, Speicher, CPU usw.

Hoffe, das hilft.

Answer 2

Sie verwenden es in Ordnung außer für Assert mit dem ersten Argument hardcoded zu true. Sie sollten dort wahrscheinlich eine Bedingung hinzufügen und die Nachricht (zweites Argument) wird nur gedruckt, wenn die Bedingung falsch ist. In Ihrem Codebeispiel wird es also nie angezeigt. In einigen Fällen kann WriteLineIf nützlich sein, wenn Sie Ihre Debug-Anweisungen nicht in bedingte Blöcke umbrechen möchten.

Überprüfen Sie die Debug class reference es hat einige nützliche Methoden und Eigenschaften, die Ihnen helfen, Dinge zu protokollieren.

Answer 3

System.Diagnostics enthält auch EventLog.WriteEntry, aber möglicherweise möchten Sie das EventLog nicht mit Trace-Nachrichten überfluten, obwohl es eine einfache Möglichkeit ist, wichtige App-Ereignisse zu protokollieren.

Answer 4

Diese Antwort ist spät, aber ...

Ich denke, man beachten sollte, Trace statt Debug.WriteLine und/oder Trace.WriteLine verwenden. Mit TraceSources können Sie eine bessere Kontrolle über Ihre Protokollierung erreichen. Die Ebene jeder TraceSource kann wie auch das Ziel der TraceSource (TraceListener) gesteuert werden. Sie können Code wie folgt schreiben:

public class RectToSqlServer : IDatabaseUtilities 
{ 
    private static readonly TraceSource ts = new TraceSource("RectToSqlServer"); 

    public void AddRectToDatabase(object record) 
    { 
    ts.TraceEvent(TraceEventType.Information, "record = {0}", record.ToString()); 

    //Add record to database ... 

    } 
} 

public class RectToOracle : IDatabaseUtilities 
{ 
    private static readonly TraceSource ts = new TraceSource("RectToOracleServer"); 

    public void AddRectToDatabase(object record) 
    { 
    ts.TraceEvent(TraceEventType.Information, "record = {0}", record.ToString()); 

    //Add record to database ... 

    } 
} 

Jetzt können Sie die Protokollierung (Ebene, das Ziel, etc.) steuern für jede unabhängig Klasse. Beachten Sie außerdem, dass Sie nicht sowohl Trace.WriteLine als auch Debug.WriteLine hinzufügen müssen, um die Protokollierung von Debug- und Release-Builds zu erhalten. Wenn Sie TraceSources verwenden, können Sie ETW in Zukunft besser nutzen, da ab .NET ein ETWTraceListener verfügbar ist (vielleicht 3.5, sicherlich 4.0). ABER diese spezielle ETW-Funktionalität ist nur für Vista und spätere Betriebssysteme verfügbar.

Um System.Diagnostics Funktionen hinzuzufügen (hauptsächlich - vielleicht nur - wenn Sie über TraceSource protokollieren), sehen Sie sich Ukadc.Diagnostics an. Ukadc.Diagnostics fügt zu System.Diagnostics ziemlich coole Formatierungsfähigkeiten hinzu (ähnlich wie Sie es mit log4net und NLog tun können). Es gibt keine Codeabhängigkeit (installieren Sie einfach Ukadc.Diagnostics und fügen Sie Ihrer app.config eine Konfiguration hinzu). Ich muss sagen, dass ich denke, dass es wirklich cool ist.

Wenn Sie in einer wenig Arbeit setzen Sie Ihren Zugang zu Trace wickeln, siehe here für eine interessante Implementierung eines Trace Wrapper, der im Wesentlichen Trace die Fähigkeit, „erbt“ Logging-Konfiguration von „Vorfahren“ Trace gibt (wie, wie log4net- und NLog-Logger können Protokollierungseinstellungen übernehmen.