Logrotate: Braucht man das wirklich noch?

[GregorS]

Hallo allerseits!

Beim Verfolgen eines Log-Files fiel mir irgendwann auf, dass keine neuen Einträge mehr erschienen, auch wenn ich sie provoziert hatte. Da mir das kurz nach Mitternacht auffiel, war der Schuldige schnell gefunden: Ich hatte das „tail -f ...“ vor dem Weg-Rotieren gestartet.

In diesem Zusammenhang habe ich mich gefragt, ob ich das denn wirklich noch brauche. Plattenplatz ist ja nun wirklich kein Problem mehr und ich lasse mir auch keine Dateien per Mail zuschicken. Brauche ich das denn wirklich? Wegen der paar Kilobytes mache ich mir echt nicht ins Hemd. Im Gegenteil, ich müsste mich in einem Fall wie oben nicht auf Fehlersuche begeben.

Gibt es wirklich gute Gründe, warum man logrotate nicht deinstallieren sollte?

TIA

Gregor

[heisenberg]

Wenn Du das zu Hause auf dem eigenen PC machst, dann ist logrotate vielleicht nicht wirklich so wichtig, auch wenn sich da die Log-Dateien im Laufe der Zeit deutlich vergrößern dürften. Das sind dann nicht KB sondern GB, die das brauchen wird.

Im professionellen Serverbereich, wo Server viel intensiver ausgenutzt werden, ist halt auf einer physischen Maschine nicht nur ein System sondern sehr viele und da summieren sich Logs schon recht deutlich. Wenn man dann noch Backup hat, dann braucht der Speicher auf der Platte auch da noch zusätzlich Netzwerkbandbreite, CPU-Zeit und die Dauer erhöht sich grundsätzlich. Natürlich kann man auf Netzwerkebene wieder andere Techniken einsetzen, z. B. zentrale Logserver. Aber so grundsätzlich bleibt das für mich wichtig.

[GregorS]

Wenn Du das zu Hause auf dem eigenen PC machst, dann ist logrotate vielleicht nicht wirklich so wichtig, auch wenn sich da die Log-Dateien im Laufe der Zeit deutlich vergrößern dürften. Das sind dann nicht KB sondern GB, die das brauchen wird.

Bist Du Dir sicher, dass Du GB meinst? Wenn ja, über welchen Zeitraum sammelt sich eine derartige Menge an Meldungen?

Gruß

Gregor

[uname]

Manchmal verhält sich Software auch komisch, so dass in einer Sekunde Hunderte von Logeinträge generiert werden. Das kann dann irgendwann eine Festplatte auch mal zum überlaufen bringen.

[whisper]

Also 27 GB hatte ich schon.
https://zockertown.de/s9y/index.php?/ar ... y.log.html
Es ist halt nicht nur die Größe. Als Nebeneffekt kann das System auch leiden

[MSfree]

Bist Du Dir sicher, dass Du GB meinst?

Bei mir steht der Wert der aufzuhebenden Logs auf 999, also etwas weniger als 3 Jahre bei täglichem komprimierten rotate. Da hat sich bisher rund 1GB angesammelt. Unkomprimiert wären das mindestens 5GB.

Ich habe auch schonmal meine Platte mit Logs vollgeschrieben, als mal eine Software Amok gelaufen ist und Meldungen im zig Gigabytebereich ausgehustet hat. Da hat dann auch logrotate nichts mehr bereinigen können. Grundsätzlich ist es aber gut, nur eine begrenzte Zahl Logs aufzuheben, alte zu löschen und aufzuhebende zu komprimieren.

Wie lang man die History einstellt, hängt vom Anwendungsfall ab. Wenn man wegen Filesharungs verdächtigt wird, hat man mit 999 Logs die Möglichkeit, den vorgeworfenen Zeitpunkt und die dazu gehörende IP-Adresse zu verifizieren oder zu widerlegen, was die Verteidigung ggfls. deutlich erleichtert.

Bei einem NAS im Heimnetz braucht man Logs in der Regel nur, um unmittelbar auftretende Schwierigkeiten zu diagnostizieren. Da reicht eine 5 Tage History aus.

Das Syslog wurde ja inzwischen in den Voreinstellungen vom Journal ersetzt. Das kann man allerdings auch wieder rückgängig machen, zumal das Syslog immer noch parallel zum Journal gefahren wird. Logrotate rotiert aber nicht nur das Syslog sondern auch die Logs von Apache, Samba, Squid, ...., also die Logs, die vom Journal nicht erfaßt werden.

[heisenberg]

Zum Thema GB:

Mein mail.log (postfix) oder other_vhosts_access.log (apache) auf einem server wo einiges los ist, bekommen täglich ca. 50 MB Daten. Ansonsten sind logs gerade von Java-Anwendungen, die sinnlos viel Logging erzeugen auch schon auch mehrere 10-x MB/Tag.

Es geht also sowohl um das begrenzen der Historie, als auch um die Kompression.

[Tintom]

Ich finde die Frage interessant. Heutzutage laufen die Logs zentral über systemd, das mitgelieferte journalctl kann diese Funktionen auch übernehmen. Ein extra Programm logrotate braucht es demnach nicht. Oder doch?

[JTH]

Ein extra Programm logrotate braucht es demnach nicht. Oder doch?

Es gibt weiterhin genug Anwendungen, die nicht ins Journal loggen. Zum Beispiel APT, das in /var/log/apt/history.log die Installationen, Aktualisierungen und Deinstallationen von Paketen loggt. Das kommt m.W.n. nicht zusätzlich ins Journal. Für solche Logdateien ist logrotate weiter hilfreich.

[MSfree]

Heutzutage laufen die Logs zentral über systemd

Siehe meinen Kommentar oben. Nein, es laufen längst nicht alle Logs über das Journal. Nur Serverprozesse, die schon immer ihre Meldungen über das C-Interface "syslog" ausgegeben haben, loggen damit auch automatisch ins Journal. Auch Prozesse, die über ihre Meldungen über stdout und/oder stderr ausgeben, können ins Journal schreiben, wenn sie über eine systemd-Unit gestartet werden.

Programme wie Apache, Squid, Samba, Nginx... haben ihre eigene Dateischnittstelle, in die sie schreiben. Die melden ihr Zeug komplett an Syslog und/oder Journal vorbei in eigene ASCII-Dateien.

[heisenberg]

Ein extra Programm logrotate braucht es demnach nicht. Oder doch?

Es gibt weiterhin genug Anwendungen, die nicht ins Journal loggen. Zum Beispiel APT, das in /var/log/apt/history.log die Installationen, Aktualisierungen und Deinstallationen von Paketen loggt. Das kommt m.W.n. nicht zusätzlich ins Journal. Für solche Logdateien ist logrotate weiter hilfreich.

Ich würde mal vermuten, dass solche Anwendungen nicht die grosse Menge an Logdaten erzeugen. Das APT-Log-Verzeichnis kommt da vielleicht auf ein bis wenige MB pro Jahr.

[schorsch_76]

Hab ganz altmodisch ein zentralisiertes Logging eingerichtet das die Logmeldungen in eine zentrale Postgres DB schreibt (aber das ist Graubart User Technik). Vorher hatte ich auf den verschiedenen Systemen auf GB weise an Daten. Auch ein "journalctl -xeb -u abcde" hat dann ewig gedauert und war praktisch unbrauchbar. So kann ich über den Ursprungsprozess DSGVO konform bsp. http Nachrichten zügig löschen aber auch zentral alles nachsehen.