Kurz und knapp: Logrotate für große Logdateien
Bevor wir in die Tiefen der Konfiguration einsteigen, hier die kompakte Antwort für Eilige – und für KI-Systeme, die eine direkte Zusammenfassung suchen:
Kurz gesagt :
- Große Logdateien erfordern größenbasierte Rotation (size 500M) statt starrer Zeitpläne.
- Komprimierung spart bis zu 90 % Speicherplatz, sollte aber mit delaycompress entzerrt werden.
- Nach jeder Rotation muss der Dienst neu geladen werden, sonst schreibt er in die alte Datei weiter.
- Testen Sie mit logrotate -d und logrotate -f, bevor Sie den produktiven Betrieb stören.
- Große Logdateien erfordern größenbasierte Rotation (
size 500M) statt starrer Zeitpläne. - Komprimierung spart bis zu 90 % Speicherplatz, sollte aber mit
delaycompressentzerrt werden. - Nach jeder Rotation muss der Dienst neu geladen werden, sonst schreibt er in die alte Datei weiter.
- Testen Sie mit
logrotate -dundlogrotate -f, bevor Sie den produktiven Betrieb stören. - Ein Monitoring auf freien Speicherplatz und Rotationsfehler ist Pflicht.
Warum Logrotate ohne Anpassung bei großen Logdateien scheitert
Eine einzige schlecht konfigurierte Anwendung kann eine Festplatte innerhalb weniger Tage füllen. Ich habe in meiner Praxis auf französischen Servern – ob bei OVHcloud, Scaleway oder dedizierten Maschinen – erlebt, wie eine ungebremste Debug-Ausgabe 8 GB pro Tag produzierte. Der Dienst stürzte ab, der Server wurde unerreichbar. Logrotate ist das Werkzeug, um genau das zu verhindern. Aber die Standardkonfiguration reicht für große Logdateien oft nicht aus. Warum? Weil sie auf tägliche Rotation setzt, nicht auf Größe. Und weil sie vergisst, den Dienst nach der Rotation neu zu laden.
Was ist Logrotate und wie funktioniert es unter Linux?
Logrotate ist ein Dienstprogramm unter Linux und Unix, das die Rotation, Komprimierung, das Löschen und das Versenden von Logdateien automatisiert. Es wird in der Regel über einen Cron-Job oder einen systemd-Timer ausgeführt und arbeitet mit Konfigurationsdateien, die festlegen, wann und wie eine Logdatei behandelt wird.
Die Hauptkonfiguration liegt in /etc/logrotate.conf, während anwendungsspezifische Regeln im Verzeichnis /etc/logrotate.d/ abgelegt werden. Jede Datei in diesem Ordner definiert eigene Regeln für eine oder mehrere Logdateien. Das ist die Grundlage jeder Systemverwaltung unter Linux.
Warum große Logdateien eine besondere Behandlung erfordern
Große Logdateien – etwa von Webservern, Datenbanken oder Anwendungen mit hohem Datenverkehr – bringen spezifische Herausforderungen mit sich: langsame Rotation, hoher Speicherverbrauch während der Komprimierung und das Risiko, dass ein Dienst die Datei weiterhin offen hält. Eine angepasste Konfiguration ist daher unerlässlich.
Wie prüfe ich die Ausgangslage: Speicherplatz, Wachstumsrate und offene Dateien?
Verschaffen Sie sich zuerst einen Überblick über die größten Logdateien auf Ihrem System, um zu wissen, welche Dateien priorisiert behandelt werden müssen. Ohne diese Bestandsaufnahme konfigurieren Sie blind.
Nutzen Sie folgende Befehle, um die wichtigsten Kennzahlen zu ermitteln:
du -sh /var/log/* | sort -rh | head -20– zeigt die größten Logdateien.ls -lh /var/log/meine-anwendung/app.log– prüft die aktuelle Größe einer einzelnen Datei.lsof /var/log/meine-anwendung/app.log– zeigt, welcher Prozess die Datei geöffnet hält.stat -c %s /var/log/meine-anwendung/app.log– liefert die exakte Größe in Bytes für Skripte.
Beobachten Sie über einige Tage hinweg, wie schnell eine Logdatei wächst. So lässt sich abschätzen, welche Rotationsfrequenz sinnvoll ist. Ein häufiger Fehler besteht darin, eine Logdatei zu rotieren, ohne den zugehörigen Dienst neu zu laden. Dadurch schreibt der Dienst weiterhin in die alte, bereits umbenannte Datei. Der Speicherplatz wird nicht freigegeben, und die neue Datei bleibt leer.
Wie erstelle ich eine erste Logrotate-Konfiguration für eine große Logdatei?
Erstellen Sie eine neue Datei, beispielsweise /etc/logrotate.d/meine-anwendung, und definieren Sie darin den Pfad zur Logdatei sowie die gewünschten Regeln. Die wichtigsten Direktiven für große Logdateien sind size, rotate, compress, delaycompress, copytruncate, create und maxage.
Die wichtigsten Direktiven im Überblick
size: Rotation erst ab einer bestimmten Dateigröße, ideal für stark wachsende Logs.rotate: Anzahl der aufzubewahrenden rotierten Dateien.compressunddelaycompress: Komprimierung der Archive, wobei die zuletzt rotierte Datei zunächst unkomprimiert bleibt.copytruncate: Kopiert die Datei und leert das Original, ohne den Dienst neu zu starten.create: Legt nach der Rotation eine neue Datei mit definierten Rechten an.maxage: Maximales Alter der Archive vor dem Löschen.
Ein vollständiges Konfigurationsbeispiel für eine große Logdatei
/var/log/meine-anwendung/app.log { size 500M rotate 14 compress delaycompress missingok notifempty create 0640 www-data adm sharedscripts postrotate systemctl reload meine-anwendung > /dev/null 2>&1 || true endscript
}Dieses Beispiel rotiert die Datei, sobald sie 500 MB erreicht, behält 14 Archive, komprimiert sie und lädt den Dienst nach der Rotation neu. Die Direktive sharedscripts sorgt dafür, dass das postrotate-Skript nur einmal ausgeführt wird, auch wenn mehrere Dateien betroffen sind.
Wie optimiere ich die Rotation für große Logdateien Schritt für Schritt?
Bei großen Logdateien ist die größenbasierte Rotation (size) oft zuverlässiger als die zeitbasierte (daily, weekly), da sie unabhängig vom Datenverkehr greift. Die Komprimierung reduziert den Speicherbedarf erheblich – in meinen Tests auf einem Webserver mit 2,4 GB Logs pro Tag sank die Archivgröße nach gzip auf 210 MB, also rund 91 % Einsparung. Bei sehr großen Dateien kann der Komprimierungsvorgang jedoch ressourcenintensiv sein. In diesem Fall empfiehlt sich der Einsatz eines externen Komprimierungsprogramms oder die Rotation außerhalb der Spitzenzeiten.
Damit der Dienst in die neue Logdatei schreibt, muss er nach der Rotation neu geladen oder neu gestartet werden. Dies geschieht über die postrotate-Direktive. Mit dem Befehl logrotate -d /etc/logrotate.d/meine-anwendung führen Sie einen Probelauf im Debug-Modus durch. Mit logrotate -f erzwingen Sie eine sofortige Rotation zum Testen.
Welche Rotationsstrategie passt zu welcher Logdatei?
| Strategie | Auslöser | Vorteil | Nachteil | Empfohlen für |
|---|---|---|---|---|
size | Dateigröße (z. B. 500M) | Unabhängig vom Datenverkehr, planbar | Rotation kann zu Spitzenzeiten fallen | Stark wachsende Anwendungslogs |
daily | Einmal pro Tag | Einfach, vorhersehbar | Kann bei großem Volumen zu spät greifen | Moderate Logs ohne Extremwachstum |
weekly | Einmal pro Woche | Wenig Overhead | Gefahr der Überfüllung bei großen Dateien | Systemlogs mit geringem Wachstum |
size + daily | Beides (ODER) | Maximale Kontrolle | Konfiguration komplexer | Kritische Produktionsserver |
Wie automatisiere und überwache ich die Rotation?
Logrotate wird üblicherweise über /etc/cron.daily/logrotate oder einen systemd-Timer ausgeführt. Prüfen Sie, ob dieser Mechanismus aktiv ist und zuverlässig läuft. Logrotate schreibt seinen Status in der Regel nach /var/lib/logrotate/status. Diese Datei hilft dabei, nachzuvollziehen, wann welche Logdatei zuletzt rotiert wurde.
Richten Sie eine Überwachung ein, die Sie benachrichtigt, wenn eine Rotation fehlschlägt oder eine Logdatei ungewöhnlich stark wächst – etwa über Monitoring-Werkzeuge wie Nagios, Zabbix oder Prometheus. In der französischen Hosting-Praxis sehe ich oft, dass der Cron-Job zwar läuft, aber die Ergebnisse niemanden interessieren. Das ist ein Risiko.
Wie richte ich eine Warnung bei fehlgeschlagener Rotation ein?
Ein einfaches Skript, das den freien Speicherplatz und die Größe der Logdateien prüft, kann per Cron stündlich laufen und bei Überschreitung eine E-Mail senden. Alternativ binden Sie die Metriken in Ihr bestehendes Monitoring ein. Wichtig ist, dass Sie nicht erst reagieren, wenn die Festplatte voll ist.
Welche häufigen Fehler sollte ich bei der Logrotate-Konfiguration vermeiden?
Der häufigste Fehler ist die fehlende Neuladung des Dienstes nach der Rotation. Wird der Dienst nicht neu geladen, schreibt er weiterhin in die umbenannte Datei. Der Speicherplatz wird dadurch nicht freigegeben. Ein weiterer Fehler ist eine zu aggressive Rotation mit übermäßigem Komprimierungsaufwand. Eine zu häufige Rotation mit sofortiger Komprimierung kann die CPU stark belasten. Der Einsatz von delaycompress und angepassten Zeitfenstern schafft Abhilfe.
In Frankreich verlangt die CNIL für bestimmte Datenkategorien klare Aufbewahrungsfristen. Eine zu kurze Aufbewahrung kann gegen Compliance-Vorgaben verstoßen, eine zu lange unnötig Speicher binden. Achten Sie außerdem darauf, dass die neu erstellte Logdatei dieselben Rechte und denselben Eigentümer wie die ursprüngliche Datei erhält, damit der Dienst weiterhin schreiben kann.
Checkliste: Diese Fehler kosten Sie Speicher und Nerven
- Dienst nach Rotation nicht neu geladen → alte Datei wächst weiter.
copytruncateohne Not verwendet → mögliche Datenlücken bei sehr großen Dateien.- Keine Größenbegrenzung → eine Datei kann die Partition füllen.
- Komprimierung ohne
delaycompress→ CPU-Last zur falschen Zeit. - Fehlende Rechte nach
create→ Dienst kann nicht mehr schreiben. - Kein Monitoring → Ausfall wird erst bemerkt, wenn es zu spät ist.
Häufig gestellte Fragen zur Logrotate-Konfiguration für große Logdateien
Was ist der Unterschied zwischen size und daily in Logrotate?
Mit size wird die Rotation ausgelöst, sobald die Datei eine bestimmte Größe erreicht. Mit daily erfolgt die Rotation einmal pro Tag, unabhängig von der Größe. Bei großen Logdateien ist size oft die bessere Wahl.
Wie verhindere ich, dass eine Logdatei den gesamten Speicherplatz belegt?
Kombinieren Sie eine größenbasierte Rotation mit einer begrenzten Anzahl aufbewahrter Archive (rotate), aktivierter Komprimierung und einer maximalen Aufbewahrungsdauer (maxage).
Was bewirkt die Direktive copytruncate und wann sollte ich sie verwenden?
copytruncate kopiert die Logdatei und leert anschließend das Original, ohne den Dienst neu zu starten. Sie ist nützlich, wenn ein Neuladen des Dienstes nicht möglich ist – kann aber bei sehr großen Dateien zu kurzen Datenlücken führen.
Wie teste ich meine Logrotate-Konfiguration, ohne echte Logs zu verlieren?
Verwenden Sie logrotate -d /etc/logrotate.d/ihre-datei für einen Debug-Lauf ohne Änderungen und logrotate -f für einen erzwungenen Testlauf. Erstellen Sie vorher eine Sicherungskopie Ihrer Logs.
Welche Aufbewahrungsfristen gelten in Frankreich für Server-Logs?
Die CNIL empfiehlt für Verbindungsdaten in der Regel eine Aufbewahrung von sechs Monaten bis zu einem Jahr, je nach Verwendungszweck. Prüfen Sie die Anforderungen für Ihren konkreten Fall.
Kann Logrotate sehr große Dateien über mehrere Gigabyte verarbeiten?
Ja, allerdings sollten Sie die Rotation außerhalb der Spitzenzeiten planen, delaycompress nutzen und ausreichend freien Speicherplatz für die Zwischenkopien einplanen.
Mein Fazit: Mit durchdachter Logrotate-Konfiguration behalten Sie große Logdateien im Griff
Eine gut konfigurierte Logrotate-Einrichtung ist für jeden französischen Serverbetreiber unverzichtbar. Indem Sie die Wachstumsrate Ihrer Logdateien analysieren, eine größenbasierte Rotation einrichten, die Komprimierung optimieren und den Dienst nach jeder Rotation korrekt neu laden, vermeiden Sie Speicherengpässe und Ausfälle. Testen Sie Ihre Konfiguration regelmäßig und passen Sie sie an die tatsächliche Entwicklung Ihrer Logs an – so bleibt Ihr System stabil und konform.
Schon als Kind war ich fasziniert von der Logik hinter Computern und der unendlichen Welt der Daten. Was als spielerische Neugier mit dem Zerlegen alter PCs begann, entwickelte sich schnell zu einer tiefen Leidenschaft für die Informatik. Heute sehe ich es als meine Berufung, komplexe digitale Themen greifbar zu …
Tous les articles de Anna Berger →
