Logging, wann und was?

1 - Erstellen Sie ein einzelnes Protokoll mit einem standardisierten Format. Es spielt keine Rolle, was es ist, aber stellen Sie sicher, dass jeder Eintrag die gleichen grundlegenden Felder hat. Wenn Sie "printf" aufrufen, wird es wahrscheinlich nicht geschnitten (ersetzen Sie System.err.println oder was auch immer).

2 - Zulassen, dass mindestens ein Feld eine beliebige Zeichenkette ist ... der Entwickler wird besser wissen, was dort sein muss.

3 - Fügen Sie jedem Eintrag einen hochauflösenden Zeitstempel hinzu. Du wirst es irgendwann brauchen, vertrau mir.

4 - Wenn möglich, fügen Sie die Datei- und Zeilennummer des Fehlerhergangs hinzu. Das ist einfach in C und ein bisschen in Java. Aber es ist unglaublich später nützlich, vor allem wenn Leute anfangen, Code zu schneiden + einzufügen, einschließlich der Fehlermeldungen.

5 - Stellen Sie sicher, dass sich das Protokoll an einer Stelle befindet, an der es von einer beliebigen Codeebene verwendet werden kann.

6 - Ich habe oft "primäre" und "sekundäre" Fehler-Tags verwendet, wobei "primär" bedeutet "Ich bin der Typ, der ein Problem festgestellt hat" und "sekundär" bedeutet "Ich habe eine Funktion aufgerufen, die hat einen Fehler gemeldet ". Das macht es einfach, die Ursache des Problems zu finden ("Primär: Datei nicht gefunden") und meldet immer noch die Bedeutung des Fehlers ("Sekundär: Kalibriertabelle kann nicht geladen werden").

7 - Fügen Sie einige Funktionen hinzu, um sowohl Fehler als auch Fehler zu protokollieren.

Der schwierigste Teil, den ich finde, ist, wenn ein Fehler nicht unbedingt ein Fehler ist. Wenn Sie eine Funktion mit einer Datei aufrufen und die Datei nicht existiert, ist das ein Fehler, der protokolliert werden sollte oder nicht? Manchmal ist es ein kritischer Fehler und manchmal wird es erwartet. Es ist ziemlich genau die API der Funktion; Wenn die Funktion eine Möglichkeit hat, einen Fehler zurückzugeben, werde ich das normalerweise ohne Protokollierung tun; dann ist es die Aufgabe des Codes auf höherer Ebene zu entscheiden, ob er diesen Fehler melden muss oder ob er erwartet wird.

Zunächst einmal sollten Sie sich ein Protokollierungs-Framework besorgen - Sie haben keine bestimmte Sprache erwähnt, aber eines der Frameworks, die auf dem Apache log4j basieren, wäre eine sichere Sache. Das Wichtigste ist, dass das Framework verschiedene Ausführlichkeitsstufen unterstützt (Debug-Meldungen, Warnungen, Fehlermeldungen). Sie können den Logger zur Laufzeit konfigurieren, welche Nachrichten er tatsächlich schreiben wird und wo - es hat keinen Sinn, das Rad neu zu erfinden, um mit der Protokollierung zu arbeiten.

Implementieren Sie das Protokollierungsframework in Ihrer Quelle. Sie sollten mindestens versuchen, Ausnahmen aufzuzeichnen und dann "Wert hinzuzufügen", die in Ihrer Anwendung auftreten können. Das Schreiben eines Stack-Trace in eine Protokolldatei ist gut und gut, aber es ist sehr selten genug, um das Problem zu diagnostizieren - z. B. das Protokollieren von Dingen wie dem Wert von Methodenparametern in einem Catch {}.

Auf einer höheren Ebene können Sie die Stärke der verschiedenen Ausführlichkeitsstufen nutzen, um aufzuzeichnen, was in Ihrer Anwendung geschieht. Dies ist besonders nützlich, wenn Fehler nur auf Produktionssystemen auftreten, auf denen Sie keinen Remote-Debugger anhängen können. Sie können einfach die Ausführlichkeit in der Konfigurationsdatei des Log-Frameworks erhöhen und alle Debug-Vorgänge beobachten ("Methode X mit Parameter aufrufen Y ") Nachrichten erscheinen im Protokoll.

Ich möchte nur das kleine Teil hinzufügen, dass für eine große unternehmenskritische Anwendung, bei der Probleme nur untersucht werden können, sobald sie bereitgestellt wird, mithilfe von Protokollen, die über Clients gesendet werden, ein gutes Gefühl dafür, wann und wo protokolliert wird Zeitpunkt, zu dem die Anwendung reifer wird (wobei die Laufzeit direkt mit der Zeit zusammenhängt, die die Anwendung an einem Ort verwendet und genutzt wird, und der Anzahl der verschiedenen Bereitstellungen [an verschiedenen Clients / Standorten]).

Solange Sie für die Leistung nicht viel bezahlen müssen, ist die Protokollierung wichtig.

Nach meiner Erfahrung sind die wichtigsten Dinge, die Sie protokollieren wollen, diese Art von Warnungen, Ups, Plausibilitätsprüfungen, Regentageszenarien usw., die man bei der Codierung der Sonnentageszenarien vernachlässigt und manchmal darauf verzichtet mit einem Aufdruck "Wir sollten nicht hierher kommen", etc. Diese Dinge neigen dazu, während der Tests nicht zu erscheinen, sondern während der Bereitstellung aufzutauchen, wo sie natürlich nicht erfasst werden.

Wenn Sie die Ergebnisse per Fernzugriff protokollieren und beabsichtigen, die Ergebnisse zu lesen, müssen Sie den genauen Zeitstempel, den Speicherort und eine Art Sitzungs-ID erfassen (falls mehrere Instanzen gleichzeitig ausgeführt werden und in die Protokolldatei geschrieben werden). . Je einfacher es für Sie ist zu bestimmen, welche Nachrichten Teil einer Ausführung sind, desto besser sind Sie.

Fehlerstufen und -typen sind ebenfalls wichtig. Es ist auch wichtig, eine Suche durchzuführen, um sicherzustellen, dass Sie nicht die gleiche Nachricht von mehreren Orten aus schreiben oder die Verfolgung schwierig wird.

Seien Sie äußerst vorsichtig bei der Protokollierung von Fehlern, wenn Ihre Benutzer Mac OS X ausführen: Aus irgendeinem seltsamen Grund wird der standardmäßige Protokollierungsmechanismus selbst in Leopard teuer verarbeitet und kann eine Menge CPUs verschwenden.

Wir entwickeln ein großes Telefoniesystem, das weltweit eingesetzt wird und seit Jahren unser eigenes Logging-System für Anwendungen einsetzt. Debug-Levels sind sehr wichtig, und unsere Apps werden mit dem Debug-Set auf "Nur Fehler" geliefert, wobei Log-to-File auf allen außer den zeitkritischsten aktiviert ist. Wir unterstützen auch die Umleitung unserer Ausgabe auf das Debug-Trace-System (das ist Windows, daher ist es ein einfacher Aufruf von OutputDebugString, und unsere Entwickler haben Zugriff auf einen Debug-Catcher namens DBWIN32). Dies ist wichtig, da einige Klassen von Fehlern erfordern, dass Sie die Ausgabe von mehreren serialisierten Apps sehen können. Ich habe einige sehr schwierige Multi-App-Interaktionsfehler durch die Anwendung dieser Technik gelöst. Apps fügen der Ausgabe normalerweise ein für Menschen lesbares Tag hinzu, sodass wir in diesem Szenario erkennen können, welche Zeile aus welcher App stammt.

Die Ebenen, die wir verwenden, sind normalerweise: Aus, Nur Fehler, grundlegend, detailliert, "ausführlich" (wo ausführlich ein Platzhalter ist, der mehrere Dinge wie Umfrageergebnisse, Benutzeroperationen, Nachrichteninhalte usw. beinhaltet - was immer der Autor für wichtig hält).

Oh, und das erste, was eine App in ihre Protokolldatei schreibt, ist eine Kopfzeile, die ihre Versionsressource angibt, damit wir erkennen können, mit welchem ​​Build wir es zu tun haben - vertrauen Sie dem Benutzer oder dem lokalen Ingenieur nicht: )

AOP ist sehr nützlich für nicht-intrusive Protokollierung. Beispielsweise können Sie mit AOP die Parameterwerte protokollieren und den Wert jedes Methodenaufrufs zurückgeben, ohne die Protokollierungsanweisungen zu jeder Methode hinzuzufügen.

Die genauen Details dazu hängen natürlich von Ihrer Zielsprache und Plattform ab (die Sie nicht angegeben haben). Ein Beispiel für das Hinzufügen eines solchen Loggers zu einer Java Spring-basierten Anwendung finden Sie hier .