strukturierte/kombinierte Protokollierung mit Log4J

Question

Ich hoffe, Sie können mir helfen.

Ich habe einen Webdienst, der Transaktionen protokollieren muss. Da es viele Treffer gibt, erscheinen die Protokollanweisungen in der Protokolldatei disjunkt/fragmentiert.

Ich habe darüber nachgedacht, eine StringBuilder-Instanz durch die Layer zu übergeben und die Anweisungen an diese Instanz anzuhängen, dann protokolliere ich ihren Inhalt einmal ganz am Ende (schließlich Klausel im Hauptcontroller), bevor ich eine Antwort an den Client zurücksende . Das scheint unnötig und ich bin sicher, es gibt eine sauberere Möglichkeit, es mit Log4J zu tun.

Kann jemand das Problem beleuchten?

Dank

Answer 1

Das Gute ist, dass Sie Log4j verwenden. Die Bibliothek selbst implementiert das Konzept verschachtelten Diagnosekontext (org.apache.log4j.NDC) und zugeordneten Diagnosekontext (org.apache.log4j.MDC). Ich denke, Sie sollten sich beide unbedingt ansehen, da Sie damit einen Kontext erstellen können, den Sie in Ihrem Logout-Layout verwenden können.

Answer 2

Sie erwägen könnte, um das Problem drehen: Statt alle Teile eines Eintrags zu konsolidieren, wenn zur Laufzeit anmelden, konsolidieren sie später bei der Analyse der Daten.

Zum Beispiel haben wir eine Anwendung, die viele Daten protokolliert, wo schnelle Antwort wichtig ist. Wir haben kürzlich ein (benutzerdefiniertes) System implementiert, das sich bei einer relationalen Datenbank anmeldet. Der Protokollierungsteil ist jedoch für die Protokollierung optimiert. Wir fügen Tupel-Daten einfach in der Reihenfolge in die Logdatei ein, in der die Anwendung sie generiert. Wir haben Werkzeuge, die Abfragen gegen dieses Format durchführen können und auch neue Versionen der in einem anderen Format gespeicherten Datenbank erzeugen wollen, wenn wir uns darüber ärgern, dass jede Abfrage gegen das Protokollformat eine Tabellensuche jeder Tabelle in der Datenbank erfordert.

Auch wenn Sie diese Technik nicht direkt anwenden können, können Sie sich nur Gedanken darüber machen, wie Sie in Log4J etwas Besseres tun können.

Answer 3

Wir mussten etwas Ähnliches in der Vergangenheit lösen. Wir haben ein umhülltes Nachrichtenobjekt erstellt, das auch Metadaten über Nachrichten (z. B. Benutzertransaktions-ID) und eine benutzerdefinierte Appender-Klasse enthält. In dieser Appender-Klasse verwenden wir instanceof-Anweisung, um die Metadaten aus der Hülle zu erhalten, und rufen einfach nur toString auf (was ein schönes Protokoll für allgemeine Appender zurückgeben sollte).

Oder Sie können die Verwendung von SLF4J in Erwägung ziehen und es ist standardmäßig möglich, Marker Objekte mit Protokollnachrichten zu übergeben. Z.B. siehe Javadoc für ihre debug(Marker marker, String msg) Methodenüberlastung.

Answer 4

Eine weitere Idee, stattdessen eine String Instanz, die durch-aus den Schichten, die ziemlich umständlich API (zusätzlichen Verfahrensparameter) führen könnten, könnten Sie mit java.lang.ThreadLocal betrachten den aktuellen Kontext zu halten, die es zu abgeladen könnte das Protokoll am Ende.

Answer 5

Sie müssen wirklich alle Protokollanweisungen in Reihenfolge haben, ich meine, sie werden protokolliert, wie sie auftreten. Wenn Sie die Reihenfolge ändern, verpassen Sie möglicherweise die Reihenfolge einiger Ereignisse, die Sie benötigen, um knifflige Fehler zu finden.

Sie können Ihren Nachrichten keinen Bezeichner hinzufügen, wie sie mit einer Thread-ID oder Benutzer-ID beginnen, von der die Anfrage stammt. Auf diese Weise können Sie Abfragen in den Protokollen mit etwas wie grep ausführen.

Die Anweisung gibt alle Protokollanweisungen für diesen Benutzer in der richtigen Reihenfolge und schnell zurück.

Wir verwenden diese Technik auf einer Handelsplattform mit hohem Durchsatz und es ist der einfachste Weg, eine Handels- oder Benutzeranforderung über das System in den Protokolldateien zu verfolgen. Sie müssen auch nicht Ihren eigenen Logger erweitern oder schreiben.