Richtlinien für Protokollierung

Question

Ich möchte Geschichten darüber bekommen, wie Menschen Tracing und Logging in realen Anwendungen handhaben. Hier sind einige Fragen, die helfen können, Ihre Antwort zu erklären.

Frameworks

Welche Frameworks verwenden Sie?

• log4net
• System.Diagnostics.Trace
• System.Diagnostics.TraceSource
• Logging Application Block
• Sonstiges?

Verwenden Sie bei der Tracing die Trace.Correlation.StartLogicalOperation Methode?

Schreiben Sie diesen Code manuell oder verwenden Sie eine Form von aspektorientierter Programmierung? Möchten Sie einen Code-Schnipsel teilen?

Bieten Sie eine Form der Granularität über Trace-Quellen an? Z.B. WPF TraceSources ermöglichen es Ihnen, sie auf verschiedenen Ebenen zu konfigurieren:

• System.Windows - Einstellungen für das gesamte WPF
• System.Windows.Animation - Spezifische Überschreibung für Animation.

Listeners

Welche Log-Ausgaben verwenden Sie?

• Textdateien
• XML-Dateien
• Ereignisprotokoll
• Sonstiges?

Wenn Sie Dateien verwenden, verwenden Sie rollende Protokolle oder nur eine einzelne Datei? Wie stellen Sie die Protokolle für Personen zur Verfügung, die sie nutzen möchten?

Anzeige

Welche Tools verwenden Sie zur Anzeige der Protokolle?

• Notepad
• Tail
• Ereignisanzeige
• Systems Center Operations Manager/Microsoft Operations Manager
• WCF Service Trace Viewer
• Sonstiges?

Wenn Sie eine ASP.NET-Lösung erstellen, verwenden Sie auch das ASP.NET Health Monitoring? Enthalten Sie Trace-Ausgaben in den Health Monitor-Ereignissen? Was ist mit Trace.axd?

Wie sieht es mit benutzerdefinierten Leistungsindikatoren aus?

Answer 1

Ich muss mich dem Chor anschließen und log4net empfehlen, in meinem Fall aus der Perspektive der Plattformflexibilität (Desktop .Net/Compact Framework, 32/64-Bit).

Allerdings ist es ein großes Anti-Muster, es in eine private Label-API einzupacken. log4net.ILogger ist das .Net-Gegenstück des Commons Logging Wrappers API, was bedeutet, dass die Kopplung bereits minimiert ist, und da es sich auch um eine Apache-Bibliothek handelt, ist das normalerweise nicht einmal ein Problem, da man keine Kontrolle aufgeben muss: Fork es, wenn nötig.

Die meisten eigenen Wrapper-Bibliotheken, die ich gesehen habe, begehen außerdem einen oder mehrere Fehler:

42. Die Verwendung eines globalen Singleton-Loggers (oder äquivalent eines statischen Einstiegspunkts), der die feine Auflösung des empfohlenen Logger-pro-Klasse-Musters verliert, ohne dabei einen anderen Selektivitätsgewinn zu erzielen.
43. Das Versäumnis, das optionale Exception-Argument freizugeben, was zu mehreren Problemen führt:
    • Es macht eine Ausnahme-Logging-Richtlinie noch schwieriger zu pflegen, so dass nichts einheitlich mit Ausnahmen gemacht wird.
    • Selbst mit einer konsistenten Richtlinie, führt das Umformatieren der Ausnahme in einen String dazu, dass Daten vorzeitig verloren gehen. Ich habe einen benutzerdefinierten ILayout-Decorator geschrieben, der eine detaillierte Analyse einer Ausnahme durchführt, um die Ereigniskette zu bestimmen.
44. Das Versäumnis, die Is_Level_Enabled-Eigenschaften freizugeben, was die Möglichkeit verwirft, Formatierungscodes zu überspringen, wenn Bereiche oder Ebenen des Loggens deaktiviert sind.

Answer 2

Ich entwickle nicht oft in asp.net, aber wenn es um Logger geht, denke ich, dass viele Best Practices universell sind. Hier sind einige meiner zufälligen Gedanken zum Logging, die ich im Laufe der Jahre gelernt habe:

Frameworks

• Verwenden Sie ein Logger-Abstraktions-Framework - wie slf4j (oder erstellen Sie Ihr eigenes), damit Sie die Logger-Implementierung von Ihrer API entkoppeln können. Ich habe schon einige Logger-Frameworks kommen und gehen sehen und es ist besser, ein neues ohne viel Aufwand übernehmen zu können.
• Versuchen Sie, ein Framework zu finden, das eine Vielzahl von Ausgabeformaten unterstützt.
• Versuchen Sie, ein Framework zu finden, das Plugins / benutzerdefinierte Filter unterstützt.
• Verwenden Sie ein Framework, das über externe Dateien konfiguriert werden kann, damit Ihre Kunden / Verbraucher das Protokollausgabe leicht anpassen können, damit es von kommerziellen Protokollverwaltungsanwendungen problemlos gelesen werden kann.
• Achten Sie darauf, nicht übermäßig benutzerdefinierte Log-Level zu verwenden, sonst können Sie möglicherweise nicht zu anderen Logging-Frameworks wechseln.

Logger-Ausgabe

• Versuchen Sie, XML/RSS-ähnliche Protokolle für das Logging zu vermeiden, das katastrophale Ausfälle erleben könnte. Dies ist wichtig, weil wenn der Netzschalter ausgeschaltet wird, ohne dass Ihr Logger das Schließen des Tags schreibt, ist Ihr Protokoll kaputt.

• Loggen Sie Threads. Andernfalls kann es sehr schwierig sein, den Ablauf Ihres Programms nachzuverfolgen.

• Wenn Sie Ihre Protokolle internationalisieren müssen, möchten Sie möglicherweise nur Entwickler-Protokolle auf Englisch (oder Ihre Sprache nach Wahl) haben.

• Manchmal kann es in Debugging-Situationen ein Lebensretter sein, die Möglichkeit zu haben, Protokollanweisungen in SQL-Abfragen einzufügen. Wie zum Beispiel:

  -- Aufrufende Klasse: com.foocorp.foopackage.FooClass:9021
  SELECT \* FROM foo;

• Sie möchten Klassen-Protokollierung. Normalerweise möchten Sie auch keine statischen Instanzen von Loggern - es lohnt sich nicht für die Mikro-Optimierung.

• Das Markieren und Kategorisieren von protokollierten Ausnahmen ist manchmal nützlich, da nicht alle Ausnahmen gleich sind. Daher ist es hilfreich, im Voraus eine Teilmenge wichtiger Ausnahmen zu kennen, wenn Sie einen Protokollmonitor haben, der Benachrichtigungen bei kritischen Zuständen senden muss.

• Duplikatfilter werden Ihre Sehkraft und Festplatte retten. Möchten Sie wirklich dieselbe Protokollanweisung 10^10000000 Mal wiederholen sehen? Wäre es nicht besser, einfach eine Nachricht wie zu erhalten: Dies ist meine Protokollanweisung - 100 Mal wiederholt

Siehe auch diese Frage von mir.

Answer 3

Ich bin nicht qualifiziert, um mich zum Protokollieren für .Net zu äußern, da mein Brot und Butter Java ist, aber wir haben in den letzten 8 Jahren eine Migration in unserem Protokollierungssystem durchgeführt, die Sie als nützliche Analogie für Ihre Frage finden könnten.

Wir begannen mit einem Singleton-Logger, der von jedem Thread innerhalb des JVM verwendet wurde, und setzten das Protokollierungslevel für den gesamten Prozess fest. Dies führte zu riesigen Protokollen, wenn wir auch einen sehr spezifischen Teil des Systems debuggen mussten, also Lektion Nummer eins ist, Ihr Protokollierungssystem zu segmentieren.

Unsere aktuelle Version des Loggers ermöglicht mehrere Instanzen, wovon eine als Standard definiert ist. Wir können beliebig viele Kind-Logger instanziieren, die unterschiedliche Protokollierungslevel haben, aber die nützlichste Facette dieser Architektur ist die Möglichkeit, Logger für einzelne Pakete und Klassen zu erstellen, indem einfach die Protokollierungseigenschaften geändert werden. Lektion Nummer zwei ist, ein flexibles System zu erstellen, das es ermöglicht, sein Verhalten zu überschreiben, ohne den Code zu ändern.

Wir verwenden die Apache commons-logging Bibliothek, die um Log4J gewickelt ist.

Hoffe, das hilft!

* Bearbeiten *

Nachdem ich den Beitrag von Jeffrey Hantin unten gelesen habe, ist mir klar geworden, dass ich hätte erwähnen sollen, was aus unserem internen Log-Wrapper tatsächlich geworden ist. Es ist jetzt im Wesentlichen eine Fabrik und wird streng verwendet, um einen funktionierenden Logger mit der entsprechenden Eigenschaftendatei zu erhalten (die aus Gründen der Abwärtskompatibilität nicht an die Standardposition verschoben wurde). Da Sie die Protokollierungskonfigurationsdatei jetzt über die Befehlszeile angeben können, vermute ich, dass sie sogar schlanker wird und wenn Sie eine neue Anwendung starten, würde ich definitiv zustimmen, dass Sie den Logger nicht einmal mehr umwickeln sollten.

Answer 4

Wir verwenden Log4Net in der Arbeit als Logging-Provider, mit einem Singleton-Wrapper für die Log-Instanz (obwohl das Singleton überprüft wird und die Frage aufkommt, ob sie eine gute Idee sind oder nicht).

Wir haben es aus folgenden Gründen ausgewählt:

• Einfache Konfiguration/Rekonfiguration in verschiedenen Umgebungen
• Gute Anzahl von vorinstallierten Appenders
• Eines der CMS, die wir verwenden, hatte es bereits integriert
• Schöne Anzahl von Log-Levels und Konfigurationen dazu

Ich sollte erwähnen, dass dies aus der Sicht der ASP.NET-Entwicklung gesprochen wird

Ich sehe einige Vorteile darin, das Trace zu verwenden, das im .NET Framework vorhanden ist, bin aber nicht vollständig überzeugt, hauptsächlich weil die Komponenten, mit denen ich arbeite, keine Trace-Aufrufe machen. Das einzige, was ich häufig verwende und das Trace-Aufrufe macht, ist System.Net.Mail soweit ich das beurteilen kann.

Also haben wir eine Bibliothek, die log4net umschließt, und in unserem Code benötigen wir einfach so etwas:

Logger.Instance.Warn("Etwas, worüber gewarnt werden soll");
Logger.Instance.Fatal("Etwas ist schiefgegangen!", new Exception());

try {
  var i = int.Parse("Hello World");
} catch(FormatException, ex) {
  Logger.Instance.Error(ex);
}

In den Methoden überprüfen wir, ob das Logging-Level aktiviert ist, damit keine redundanten Aufrufe an die log4net-API entstehen (also wenn Debug nicht aktiviert ist, werden die Debug-Statements ignoriert). Aber wenn ich etwas Zeit habe, werde ich es aktualisieren, um diese Funktionen freizulegen, damit Sie die Überprüfungen selbst durchführen können. Dies verhindert, dass Bewertungen durchgeführt werden, wenn sie nicht durchgeführt werden sollten, z.B.:

Logger.Instance.Debug(string.Format("Etwas zum Debuggen um {0}", DateTime.Now);

Dies wird zu:

if(Logger.DebugEnabled) Logger.Instance.Debug(string.Format("Etwas zum Debuggen um {0}", DateTime.Now);

(Spart etwas Ausführungszeit)

Standardmäßig loggen wir an zwei Orten:

1. Dateisystem der Website (in einer nicht veröffentlichten Dateierweiterung)
2. E-Mail-Versand für Fehler & Fatal

Dateien werden täglich oder alle 10 MB (so weit ich mich erinnere) geändert. Wir verwenden das EventLog nicht, da es oft eine höhere Sicherheit erfordern kann als wir einer Seite geben möchten.

Ich finde, dass Notepad zum Lesen von Logs gut funktioniert.

Answer 5

Welche Frameworks verwenden Sie?

Wir verwenden eine Mischung aus dem Logging Application Block und einem benutzerdefinierten Logging-Helfer, der um die .Net-Framework-Bits herum arbeitet. Der LAB ist so konfiguriert, dass er ziemlich umfangreiche Protokolldateien ausgibt, einschließlich separater allgemeiner Trace-Dateien für den Service-Methodeneintritt/-austritt und spezifischer Fehlerdateien für unerwartete Probleme. Die Konfiguration umfasst Datum/Uhrzeit, Thread, pId etc. zur Unterstützung bei der Fehlerbehebung sowie die vollständigen Ausnahmedetails und den Stack (im Falle einer unerwarteten Ausnahme).

Der benutzerdefinierte Logging-Helfer verwendet die Trace.Correlation und ist besonders nützlich im Kontext des Loggens in WF. Beispielsweise haben wir eine Zustandsmaschine, die eine Reihe sequenzieller Workflows aufruft. Bei jeder dieser Aufruf-Aktivitäten protokollieren wir den Start (unter Verwendung von StartLogicalOperation) und am Ende beenden wir die logische Operation mit einem generischen Rückmeldung-Eventhandler.

Dies hat sich bereits einige Male als nützlich erwiesen, wenn es darum ging, Fehler in komplexen Geschäftsabläufen zu debuggen, da es uns ermöglicht, Dinge wie If/Else-Zweigentscheidungen etc. basierend auf der Aktivitätsausführungsreihenfolge schneller zu bestimmen.

Welche Protokollausgaben verwenden Sie?

Wir verwenden Textdateien und XML-Dateien. Textdateien sind durch den App-Block konfiguriert, aber wir haben auch XML-Ausgaben von unserem WF-Dienst. Dadurch können wir die Laufzeitevents (Persistenz usw.) sowie generische geschäftsbezogene Ausnahmen erfassen. Die Textdateien sind rollende Protokolle, die täglich und in der Größe gerollt werden (ich glaube, dass insgesamt 1 MB die Rollover-Grenze darstellt).

Welche Tools verwenden Sie zum Anzeigen der Protokolle?

Wir verwenden Notepad und den WCF Service Trace Viewer, je nachdem, auf welche Ausgabegruppe wir schauen. Der WCF Service Trace Viewer ist wirklich sehr praktisch, wenn Sie Ihre Ausgabe richtig eingerichtet haben, und kann das Lesen der Ausgabe wesentlich vereinfachen. Das heißt, wenn ich sowieso ungefähr weiß, wo der Fehler liegt - das Lesen einer gut annotierten Textdatei ist ebenso gut.

Die Protokolle werden in ein einzelnes Verzeichnis gesendet, das dann in Unterverzeichnisse auf der Grundlage des Quelldienstes unterteilt wird. Das Stammverzeichnis ist über eine Website zugänglich, dessen Zugriff durch eine Support-Benutzergruppe kontrolliert wird. Dadurch können wir uns die Produktionsprotokolle ansehen, ohne Anfragen zu stellen und langwierige bürokratische Prozesse für Produktionsdaten durchlaufen zu müssen.