log4j als separate Dateien in Schleife?

[MiMa]

Beim starten meines Programms protokolliert log4j alles in die Datei, bis das Programm abgebrochen oder beendet wurde.
Mein Programm läuft mittlerweile mit allen zu untersuchende Dateien bis zum Ende ohne Programmabbruch durch (> 58.300 Dateien, 129 min).

Die Logdatei hat eine Größe von 657 MB und kann weder mit dem Editor, Notepad+ als auch Word geöffnet werden.
Die Anzeige mit dem Google Crome Browser funktioniert, aber wirklich hilfreich ist die Logdatei in dieser weise nicht wirklich.
Daher wollte ich mal nachfragen, ob man Logdateien Stückeln kann?

1. Mein Programm startet und lädt alle Dateien in eine Liste
2. Holt die erste Datei aus der Liste und verarbeitet diese
3. Holt die nächste Datei aus der Liste und verarbeitet diese
4. Holt die nächste Datei aus der Liste und verarbeitet diese

Wäre es möglich nachdem die erste Datei verarbeitet wurde dieses Logfile mit einen eigenen Namen zu speichern und dann mit der nächsten Datei weiter zu machen?
Es wäre auch viel sinnvoller eine Datei mit einer eigenen Protkolldatei zu haben, denn aus einer riesigen Protokolldatei für eine Datei etwas heraus zu suchen ist nichts womit man arbeiten möchte.

Danke
Mi

 

[kneitzel]

Also bezüglich Logging: Es gibt RollingAdapter, die bei einer bestimmten Größe eine neue Datei erstellen. Und da kann man dann auch eine gewisse Menge an Dateien erzeugen / vorhalten lassen. Das ist das, was bei uns ausreicht.

Um dann die richtige Logdatei zu finden (a.la. wo finde ich das Log von der Verarbeitung der Datei xyz?) reicht uns dann ein einfaches grep um den Start zu finden. (Wobei es das wohl auch als Tools gibt mit Suche und so ... Aber da kenne ich mich nicht aus... Ich hatte nur einmal eine Demonstration gesehen von einer Arbeitsgruppe. Da sind alle Logs in eine zentrale Datenbank geflossen. Elasticsearch ist da wohl ein Schlüsselwort - das kann aber ggf. jemand anderes besser was zu sagen... @httpdigest vielleicht? Er bringt immer sehr gute, fundierte Beiträge aus seiner Erfahrung. ... ich hätte da so auf Anhieb nur einen Link zur Hand: https://www.elastic.co/de/log-monitoring - das wollte ich mir halt auch schon lange mal ansehen 🙂 )

Das aber nur, um einmal Alternativen aufzuzeigen, denn ich halte es immer für unnötig, in log4j Konfigurationen im Code vorzunehmen. Das geht eigentlich immer alles schön über die separate Konfiguration und ich sehe halt das Risiko, dass externe Konfiguration und interne (unerwartete) Spielchen sich ins Gehege kommen ...

Ansonsten kannst Du im Code die Appenders verändern:

Log4j – Log4j 2 Appenders - Apache Log4j 2

Beispiel für Hinzufügen von Appendern:

How to add Log4J2 appenders at runtime programmatically?

Is it possible to add Log4J2 appenders programmatically using the specifications from the XML configuration? I plan to define it all in the log4j2.xml and then pick appenders situationally like th...

stackoverflow.com

Beispiel für Entfernen / bekommen von Appendern:

How can I access the configured Log4J appenders at runtime?

I want to configure an appender at startup and then dynamically add and remove it from various loggers on demand. I'd prefer to have log4j configure this appender itself, and just grab a reference...

stackoverflow.com

Aber wie gesagt: Die Log-Konfiguration ist etwas, das aus meiner Sicht in Admin / Kundenhand ist. Als Entwickler bietet man nur die Option an und der Kunde kann sich überlegen, was er nun möchte. Aber das kann natürlich jeder so sehen, wie er möchte und natürlich möchte ich nicht ausschließen, dass es Konstellationen gibt, bei denen die "üblichen Vorgehensweisen" nicht reichen oder nicht funktionieren.

 

[httpdigest]

Meine Erfahrung mit Elasticsearch ist leider noch null. 🙂 Alle Kundenprojekte, die ich in letzter Zeit mitgemacht hatte, hatten ein Clouddeployment (meist AWS, einmal Azure und jetzt hab ich ein Google Cloud Projekt am Wickel). Dort ist Log Rotation bzw. Logfile-Handling dann ein Aspekt, um den man sich in seiner Anwendung glücklicherweise nicht mehr zu kümmern braucht, schreibt also einfach nur noch alles nach stdout/stderr und nutzt die Logging Tools der Clouddienstleister wie halt AWS CloudWatch Logs oder Google Logs Explorer mit sehr mächtigen Suchfunktionen, die Volltext in Plaintext-Lognachrichten oder JSON-Felder indexieren können. Das kann natürlich Elasticsearch auch alles, nur hab ichs leider noch nie eingesetzt.
Wie @kneitzel aber schon sagte, brauchst du erstmal Log File Rotation, was du in der log4j Config einfach realisieren kannst.

 

[MiMa]

Aus einen vorherigen Post den ich mit euch schon mal diskutiert hatte war ebenfalls Logdateien mit verschiedenen Dateinamen an verschiedenen Orten zu speichern. Das hatte ich damals mit log4j nicht hinbekommen und hatte eine eigene Klasse dafür geschrieben um dies zu tun.

Nachdem ich das fertig implementiert hatte und mir den Code nachher angeschaut habe, wurde mir klar, das es nicht wirklich eine gute Lösung war.
Auch gab es hier und da mit dem Logging Probleme und daher bin ich immer noch auf der suche nach einer besseren Lösung.
Das Logging ab einer bestimmten größe ab zu brechen ist für mich keine Lösung, da ich gerne für jede Datei ein eigenes Logile hätte.
Cloudlösungen möchte ich nicht verwenden und elastic Search kommt auch erst mal nicht in Frage, da ich mich nicht mit noch etwas beschäftigen möchte.

Ich suche nach einer Lösung die so aussehen sollte.

 

[httpdigest]

Du kannst ja die "Programmatic API" von Log4j nehmen und Log4j für jede sequenziell von deinem Programm einzulesende Datei rekonfigurieren: https://logging.apache.org/log4j/2....ng_ConfigurationBuilder_with_the_Configurator

 

[LimDul]

Meist ist es keine gute Idee Logging selber zu implementieren 🙂

Eigentlich sollte alles mit Log4j gehen, man muss es nur richtig nutzen. Man muss nur verstehen, wie log4j funktioniert. Im Groben funktioniert es so:

* Schreibe in einen benannten Logger eine Log-Message mit einem Log-Level.
* Log4j schaut dann in der Konfiguration nach, in welcher Appender diese Message geschrieben. Dazu nutzt es sowohl den Logger-Namen als auch das Level.
* Der Appender wiederum entscheidet dann, wie diese Nachrichtig verarbeitet wird (Konsolen-Ausgabe, Datei etc.)

Du müsstest jetzt mal deine Anforderungen auf diese Sachen mappen. Das "fange eine neue Datei nach Kriterium x, wobei x nicht fachlich ist" ist eine klassische Anforderung die in die Appender reingehört und wie schon geschrieben, mit dem RollingFileAppender gelöst ist. Das ist bei vielen Logs aus Anwendungen auch Standard. So hab ich im JBoss eine server.log, eine server.log.1 eine server.log.2 usw.. Das ist rein über die Konfiguration zu lösen und da sollte in der Anwendung nichts für gemacht werden. Das nutzt man klassisch entweder zeitgesteuert (jeden Tag) oder Größen gesteuert (nach X Zeilen / nach Y MB) eine neue Datei anzufangen.

Willst du dagegen fachlich entscheiden in unterschiedliche Dateien zu loggen (So gibt es z.B. bei JBoss einer server.log, ein audit.log, etc), dann nutzt man in der Regel dazu Logger mit verschiedenen Namen. Normalerweise nimmt man als Namen des Loggers immer den Klassennamen (damit bekommt man auch für die Konfiguration direkt eine Hierarchie mit), aber das ist kein muss. Man kann durchaus noch weitere Suffixe dranhängen. Das klappt aber nur, solange vorher klar ist, wie viele verschiedene Dateien es gibt. Wenn dein Programm Dateien verarbeitet und du willst für jede Datei eine Log-Datei haben, dann reicht die reine Konfiguration nicht mehr aus. Da sehe ich zwei Möglichkeiten:

* Du erzeugt einen FileAppender im Programm für jede zu loggende Datei und hängst ihn programmatisch in die Konfiguration rein
* Du schreibst einen eigenen Appender, der aus dem Logger-Namen den Dateinnamen raus-extrahiert wohin er loggen oll.

Vermutlich ist die erste Variante die sauberste.

 

[MiMa]

Du schreibst einen eigenen Appender, der aus dem Logger-Namen den Dateinnamen raus-extrahiert wohin er loggen oll.

vielen Dank,
ich denke einen eigenen Appender zu schreiben wäre die beste Lösung.
Wie viele Dateien es sind kann ich im voraus nicht sagen, aber die Datei aus dem Dateinamen wird bereits extrahiert und ist somit verwendbar.
Ich werde dann jetzt mal tiefer in log4j einsteigen und versuche mal das Problem aus diese weise zu lösen.
Danke
Mi