Ich bin auf eine sehr gute Bibliothek zum Parsen von CUE-Dateien gestoßen. Aber als ich anfing, den Quellcode zu lesen, stellte ich fest, dass es fast unlesbar ist:
%Vor%Jede Methode verfügt über Meldungen logger.entering () und logger.exiting (). Ist das nicht zu viel?
Es gibt eine weitere Java-Bibliothek zum Parsen von Audio-Tags. Es hatte auch 15 Protokollnachrichten für jede Datei, die es gelesen hat. Es war nervig, also habe ich jeden Anruf zum Logger auskommentiert. Und die Bibliothek wurde doppelt so schnell, weil sie viele Zeichenfolgen für Protokollnachrichten verwendeten.
Die Frage ist also: Soll ich wirklich alles protokollieren, auch wenn es keine Großunternehmensanwendung ist? Weil diese Bibliotheken offensichtlich keine Protokollierung benötigen, außer für Fehlermeldungen. Und meine Erfahrung zeigt, dass Logger ein schreckliches Werkzeug zum Debuggen sind. Warum sollte ich es benutzen?
Wie kann ich wissen, wann zu viel Logging stattfindet? Wenn Sie wissen, dass die protokollierten Informationen auf lange Sicht nicht wichtig sind, da es sich um Debug-Aktionen oder Fehlerkorrekturen handelt oder wenn die Anwendung nicht mit zu wichtigen Informationen arbeitet.
Manchmal müssen Sie fast alles protokollieren. Ist die Leistung oder die volle Möglichkeit der Analyse der wichtigste Teil einer Anwendung? Es kommt wirklich darauf an.
Ich habe in der Vergangenheit mit einigen Integration mit vielen verschiedenen Webservices, wie 10 in der gleichen App gearbeitet. Wir haben alle XML-Anfragen und -Antworten protokolliert. Ist das ein Overhead? Auf lange Sicht glaube ich das nicht, da wir mit vielen Kreditkartenoperationen gearbeitet haben und jeden Prozess mit dem Server protokolliert haben sollten. Wie kann ich was bei einem Fehler erkennen?
Sie würden nicht glauben, was ich in einigen der XML-Antworten gesehen habe. Ich habe sogar ein XML erhalten, ohne Tags zu schließen, von einer großen Flugzeugfirma. Waren die "übermäßigen Logs" eine schlechte Übung? Sagen Sie das Ihren Kunden, wenn Sie beweisen müssen, dass der Fehler vom anderen Anbieter kam.
Die meisten Protokollierungsbibliotheken bieten eine Möglichkeit zu bestätigen, dass die Protokollierung vor der Verarbeitung einer Anweisung aktiviert ist:
Zum Beispiel:
%Vor%Je nach Effizienz der bar.toString () -Methode kann dies sehr kostspielig sein. Wenn Sie dies jedoch vor der Zeichenfolgenverkettung in eine Prüfung für die Protokollierungsebene einbinden:
%Vor%Dann tritt die String-Verkettung nur auf, wenn mindestens ein Appender für die Klasse auf Trace gesetzt ist. Jede komplizierte Protokollnachricht sollte dies tun, um unnötige String-Erstellung zu vermeiden.
Idealerweise verwenden Sie einen Logger, der Protokollierungsstufen zulässt. log4j hat zum Beispiel fatal / error / warn / debug / info. Wenn Sie die Stufe auf "Nur Fehler anzeigen" setzen, verlieren Sie auf diese Weise nicht die Geschwindigkeit für die Protokollmeldungen, die Sie nicht benötigen.
Das heißt, es ist nur zu viel Protokollierung, bis Sie etwas benötigen, das protokolliert worden wäre. Es klingt wie die meisten der Protokollierung, die Sie verlangsamt, sollte jedoch "Trace" -Level sein; es zeigt Ihnen, was ein Profiler haben würde.
Kommt es darauf an, diesen Code für eine Anwendung oder eine Bibliothek? Für eine Anwendung sind Logger nützlich, sobald der Code in Produktion ist. Es sollte nicht zum Debuggen verwendet werden, sondern um einen Fehler zu replizieren. Wenn ein Benutzer Ihnen mitteilt, dass Ihre Anwendung abgestürzt ist, möchten Sie immer die maximale Protokollierungsinformation.
Ich stimme zu, dass es den Code weniger lesbar macht. Es macht sogar die Anwendung langsamer!
Es ist ein völlig anderes Spiel für eine Bibliothek. Sie sollten eine konsistente Protokollierung mit einem angemessenen Level haben. Die Bibliothek SOLLTE das Entwicklungsteam informieren, wenn ein Fehler auftritt.
Die Protokollierung sollte Ihnen Informationen liefern, die ein Stack-Trace nicht ermitteln kann, um ein Problem zu finden. Dies bedeutet normalerweise, dass die Information eine Art historischer Hinweis darauf ist, was das Programm gemacht hat, im Gegensatz zu dem Zustand, in dem es sich zum Zeitpunkt des Scheiterns befindet.
Zu viele historische Daten werden ignoriert. Wenn Sie sicher ableiten können, dass eine Methode aufgerufen wurde, ohne ihre Eingabe und ihren Exit tatsächlich protokollieren zu müssen, können Sie diese Protokolleinträge sicher entfernen.
Ein weiteres schlechtes Zeichen ist, dass Ihre Logging-Dateien sehr viel Speicherplatz belegen. Sie opfern nicht nur Platz, Sie verlangsamen wahrscheinlich die App zu sehr.
Um die Frage zu beantworten, warum sollte ich Logger verwenden?
Haben Sie jemals eine Software gefunden, bei der der einzige angezeigte Fehler für den Endbenutzer Fatal error occured ist. Wäre es nicht schön, herauszufinden, was es verursacht hat?
Logging ist ein Werkzeug, das Ihnen helfen kann, diese Art von Problemen in diesem Bereich einzugrenzen. Denken Sie daran, dass Endbenutzersysteme keine guten IDEs zum Debuggen haben und die Endanwender in der Regel nicht über ausreichende Kenntnisse verfügen, um diese Tools auszuführen. Endbenutzer sind jedoch in den meisten Fällen in der Lage, Protokollkonfigurationsdateien (die von uns geschrieben wurden, clevere Programmierer) in vordefinierte Standort- und Abrufprotokolldateien zu kopieren und sie uns per E-Mail zurückzusenden (schlechte Sohlen, um Megabytes von Protokollausgaben analysieren zu müssen) Sie stoßen auf Probleme.
Nachdem dies gesagt wurde, sollte die Protokollierung in hohem Maße konfigurierbar sein und unter normalen Bedingungen eine minimale Ausgabe erzeugen. Außerdem sollten Wächter die feinere Protokollierung davor schützen, zu viele Ressourcen zu verbrauchen.
Ich denke, in dem Beispiel, das Sie angegeben haben, sollte die Protokollierung auf einer TRACE-Ebene erfolgen. Da zwischen Funktionseinstiegspunkt und Exit wirklich nichts Schlechtes passieren kann, ist es wahrscheinlich sinnvoll, dort nur eine Loganweisung zu haben.
Im Laufe der Jahre habe ich mich hin und her bewegt zwischen der Förderung der Holzfällerei auf den entsprechenden Ebenen (Spuren, Informationen usw.) und dem Gedanken, dass alles eine Zeitverschwendung ist. In der Realität hängt es davon ab, was nützlich sein wird, um aufzuspüren oder erforderlich (Protokollierung kann eine billige Möglichkeit sein, einen Audit-Trail aufrechtzuerhalten).
Persönlich tendiere ich dazu, den Eintritt / Austritt auf einer Komponenten- oder Serviceebene zu protokollieren und dann wichtige Punkte in der Verarbeitung zu protokollieren, wie zum Beispiel eine Geschäftslogikentscheidung oder einen Anruf bei einem anderen Dienst / einer anderen Komponente. Natürlich werden Fehler immer protokolliert, aber nur einmal und an dem Ort, an dem sie behandelt wurden (die Stack-Trace- und Exception-Nachricht sollte ausreichende Informationen zur Diagnose des Problems enthalten) und jede Service- / Komponentenschnittstelle sollte immer einen Fehler behandeln (auch wenn es gerade ist) in einen anderen, der für den Anrufer passender ist, umwandeln.)
Das Problem mit dem Loggen von Sachen, wenn etwas schief geht, ist, dass Sie zu viele Informationen haben, dass es unmöglich ist, das Problem zu identifizieren, besonders wenn es unter einem Server läuft, da Sie mit vielen ineinander verschlungenen Logs enden Einträge. Natürlich können Sie das umgehen, indem Sie eine Anfrage-ID in den Eintrag einfügen und eine Software verwenden, um darauf zu filtern. Natürlich haben Sie auch den Fall, dass Ihre Anwendung verteilt ist und / oder Cluster und Sie mehrere Protokolle haben.
Heutzutage würde ich nie wirklich Einträge schreiben / eingeben, der Code ist nur im Weg und es ist so viel einfacher, etwas wie aspectj zu verwenden, wenn es wirklich benötigt wird. Die Verwendung von aspectj garantiert auch, dass es konsistent ist (Sie können das Protokollformat an einer Stelle ändern, anstatt jede Operation ändern zu müssen) und genau (falls ein Refactoring einen neuen Parameter hinzufügt und der Entwickler vergisst, es zur Protokollierung hinzuzufügen) / p>
Eine Sache, über die ich nachgedacht habe, ob jemand bereits einen Logger hat, der die Einträge im Speicher hält, dann wird bei einem Fehler geschrieben, wenn der Vorgang erfolgreich ist, werden die Einträge einfach verworfen. Wenn jemand davon weiß (idealerweise für log4j), lass es mich wissen, oder ich habe ein paar Ideen, wie ich das umsetzen kann, falls jemand daran interessiert ist.