logrotate optimieren der protokollverwaltung in linux systemen

Ich sehe oft dasselbe Problem: Logs wachsen, niemand schaut hin, und irgendwann ist die Platte voll. Dann wird aus sauberer Protokollverwaltung ein Feueralarm. Genau hier musst du logrotate optimieren, statt einfach nur die Standardkonfiguration laufen zu lassen.

Wenn du Linux-Server betreibst, brauchst du drei Dinge: Kontrolle über Speicherverbrauch, klare Aufbewahrung und verlässliche Rotation. logrotate kann das alles. Aber nur, wenn du es richtig einstellst.

Was ist logrotate und warum solltest du es optimieren?

logrotate ist das Standard-Tool auf vielen Linux-Systemen, um Logdateien automatisch zu rotieren, zu komprimieren, zu löschen und bei Bedarf neu zu erstellen. Das ist simpel. Der Fehler ist, es einfach auf den Default-Werten zu lassen und zu hoffen, dass es passt.

Optimieren heißt für mich: weniger Speicherstress, weniger I/O-Last, bessere Übersicht und eine Log-Strategie, die zu deinem System passt. Nicht zu irgendeinem Beispiel aus dem Internet.

logrotate optimieren der protokollverwaltung in linux systemen: Die Basis

Die wichtigsten Konfigurationsdateien findest du meist unter /etc/logrotate.conf und /etc/logrotate.d/. Die Hauptdatei definiert globale Regeln. Der Ordner logrotate.d enthält einzelne Regeln für Dienste wie nginx, apache, rsyslog oder custom Apps.

Wenn ich logrotate optimiere, starte ich immer mit diesen Fragen:

• Wie schnell wächst das Log?
• Wie lange müssen Logs aufbewahrt werden?
• Soll nach Zeit oder Größe rotiert werden?
• Darf komprimiert werden?
• Wie soll der Dienst nach der Rotation neu geladen werden?

Diese Antworten bestimmen die Konfiguration. Nicht umgekehrt.

Die wichtigsten logrotate-Optionen, die ich immer prüfe

Hier sind die Stellschrauben, die den größten Effekt haben:

• daily / weekly / monthly – Rotation nach Zeitintervall
• size – Rotation ab einer bestimmten Dateigröße
• rotate – Anzahl der alten Logdateien, die behalten werden
• compress – alte Logs komprimieren und Platz sparen
• delaycompress – Komprimierung erst ab der nächsten Rotation
• missingok – kein Fehler, wenn die Logdatei nicht existiert
• notifempty – leere Logs nicht rotieren
• create – neue Logdatei mit definierten Rechten anlegen
• postrotate / endscript – Dienst nach Rotation neu laden
• copytruncate – Datei kopieren und dann leeren, wenn der Dienst kein Reopen kann

Mein Rat: Nutze so wenig Sonderlogik wie möglich. Je einfacher die Regel, desto stabiler das System.

So setze ich logrotate praktisch auf

Ein typisches Beispiel für einen Dienst könnte so aussehen:

/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myuser adm
    postrotate
        systemctl reload myapp >/dev/null 2>&1 || true
    endscript
}

Was passiert hier?

• Die Logs werden täglich rotiert.
• 14 alte Versionen bleiben erhalten.
• Alte Logs werden komprimiert.
• Die neueste alte Datei bleibt erst mal unkomprimiert.
• Leere oder fehlende Logs verursachen keinen Fehler.
• Die neue Logdatei bekommt definierte Rechte.
• Der Dienst wird sauber neu geladen.

Genau so sollte gute Protokollverwaltung aussehen: automatisiert, kontrolliert, wartbar.

Rotation nach Zeit oder Größe?

Das ist eine der wichtigsten Entscheidungen. Ich nutze diese Regel:

• Nach Zeit, wenn das Log konstant relevant ist und du eine saubere historische Struktur willst.
• Nach Größe, wenn das Log stark schwankt oder bei Fehlern explodieren kann.

Beispiel: Ein Debug-Log kann in zehn Minuten mehrere Gigabyte groß werden. Dann reicht daily nicht. Dann brauchst du eher size 100M oder eine Kombination aus beiden, je nach Setup.

Die größten Fehler bei logrotate

Ich sehe diese Fehler ständig:

• Zu viele alte Logs – unnötiger Speicherverbrauch
• Zu wenig Logs – wichtige Daten verschwinden zu früh
• copytruncate ohne Not – kann zu Datenverlust führen
• Kein Reload des Dienstes – Logs schreiben weiter in alte Dateien
• Falsche Rechte – Dienste können neue Dateien nicht schreiben
• Unklare Aufbewahrungsregeln – Chaos bei Audits und Fehleranalysen

Der größte Fehler ist meistens nicht die Option selbst. Es ist der fehlende Plan.

Wann ich copytruncate verwende

copytruncate ist praktisch, aber nicht mein Favorit. Ich nutze es nur, wenn ein Dienst die Logdatei nicht neu öffnen kann. Dann kopiert logrotate die Datei und leert sie danach. Das ist bequem, aber nicht perfekt.

Problem: Während des Kopierens können Daten verloren gehen, wenn der Dienst weiter schreibt. Wenn der Dienst es kann, ist ein sauberer Reload oder Reopen besser.

Wie ich die Protokollverwaltung in Linux-Systemen schlank halte

Ich will keine Log-Hölle. Ich will ein System, das still im Hintergrund arbeitet. Dafür halte ich mich an diese Regeln:

• Nur rotieren, was gebraucht wird
• Retention passend zum Risiko wählen
• Komprimieren, wenn alte Logs selten gebraucht werden
• Rotation testen, bevor sie live geht
• Unterschiedliche Dienste getrennt konfigurieren
• Loggröße regelmäßig prüfen

Wenn du Monitoring hast, setze Warnungen auf Verzeichnisse wie /var/log. Warten, bis die Platte voll ist, ist keine Strategie.

logrotate testen und Fehler finden

Bevor du produktiv etwas änderst, teste die Konfiguration. Der wichtigste Befehl ist:

logrotate -d /etc/logrotate.conf

Das zeigt dir den Dry Run. Du siehst, was passieren würde, ohne wirklich zu rotieren.

Für einen echten Lauf kannst du zusätzlich mit Verbose-Ausgabe arbeiten:

logrotate -v /etc/logrotate.conf

Wenn etwas nicht funktioniert, prüfe zuerst:

• Dateirechte
• Pfade in der Konfiguration
• Postrotate-Skripte
• Dienstverhalten nach Reload
• Systemd-Journal oder klassische Logdateien

Nützliche Ressourcen

Wenn du tiefer einsteigen willst, sind diese offiziellen Ressourcen sinnvoll:

• logrotate Man Page
• Alternative logrotate Dokumentation
• Red Hat Artikel zu logrotate

Mein Fazit

Wenn du logrotate optimieren der protokollverwaltung in linux systemen wirklich ernst nimmst, denk nicht in Defaults. Denk in Last, Risiko und Wartbarkeit. Das Ziel ist nicht nur Platz sparen. Das Ziel ist ein System, das Logs sauber verwaltet, ohne dass du ständig eingreifen musst.

Meine einfache Regel: weniger Chaos, mehr Kontrolle. Wenn logrotate richtig eingerichtet ist, merkst du es kaum. Und genau dann funktioniert es gut. logrotate optimieren der protokollverwaltung in linux systemen ist am Ende kein Luxus, sondern Pflicht.