Was ist Logrotate und warum ist es in verteilten Systemen unverzichtbar?
Logrotate ist ein unter Linux standardmäßig vorhandenes Werkzeug, das Protokolldateien automatisch rotiert, komprimiert, archiviert und nach Ablauf der Aufbewahrungsfrist löscht. In verteilten Systemen – also Umgebungen, in denen Anwendungen über mehrere Hosts, Container oder Cluster-Knoten verteilt laufen – ist eine lokale Standardkonfiguration nicht mehr ausreichend, weil Logs an vielen Orten gleichzeitig entstehen und ohne einheitliche Regeln unkontrolliert anwachsen.
Kurz gesagt :
- Logrotate rotiert, komprimiert und löscht Protokolldateien automatisch und wird täglich per Cron oder systemd-Timer ausgeführt.
- In verteilten Systemen entstehen Logs an vielen Orten gleichzeitig, weshalb lokale Standardkonfigurationen nicht ausreichen.
- Eine systematische Bestandsaufnahme aller Logquellen ist die Grundlage jeder robusten Logrotation.
- Zentrale Direktiven wie daily, rotate, compress und sharedscripts steuern Intervall, Aufbewahrung und Fehlertoleranz.
Bevor wir uns in die Tiefen der Konfiguration begeben, ist es unerlässlich, die fundamentalen Prinzipien der Rotation und Ressourcenverwaltung zu verstehen, die Logrotate zu einem derart robusten Werkzeug machen. Ich habe in den vergangenen fünfzehn Jahren zahlreiche Infrastrukturen evaluiert, und die häufigste Ursache für unerwartete Ausfälle war nicht ein defekter Dienst, sondern eine volle Festplatte – verursacht durch nicht rotierte Protokolldateien.
Die Grundlagen von Logrotate
Logrotate wird üblicherweise täglich per Cron oder systemd-Timer ausgeführt. Die Konfiguration liegt unter /etc/logrotate.conf sowie in den Fragmenten unter /etc/logrotate.d/. Jede Datei definiert für eine Gruppe von Logdateien, wie oft rotiert wird, wie viele Archive aufbewahrt werden und ob komprimiert werden soll.
Die besonderen Herausforderungen verteilter Systeme
In verteilten Architekturen – etwa bei Microservices, Kubernetes-Clustern oder Load-Balanced-Webfarmen – entstehen Logs an vielen Orten gleichzeitig. Eine lokale Standardkonfiguration reicht dann nicht mehr aus. Ohne einheitliche Regeln entstehen inkonsistente Aufbewahrungsfristen, unterschiedliche Komprimierungsstufen und im schlimmsten Fall Datenverlust bei der Fehleranalyse. Genau hier setzt eine zentrale Konfigurationsstrategie an, die ich im Folgenden Schritt für Schritt erläutere.
1. Bestandsaufnahme: Logquellen im verteilten System erfassen
Bevor Sie eine einzige Konfigurationsdatei schreiben, müssen Sie wissen, wo welche Logs entstehen. Eine systematische Inventarisierung ist die Grundlage jeder robusten Logrotation, weil Sie sonst Gefahr laufen, wichtige Quellen zu übersehen oder unwichtige Dateien unnötig zu archivieren.
Erfassen Sie mindestens die folgenden Kategorien:
- Lokale Anwendungslogs, typischerweise unter
/var/log/nginx/oder/var/log/apache2/ - Container-Logs von Docker, Podman oder Kubernetes
- Datenbank-Logs von PostgreSQL, MySQL oder MongoDB
- Systemlogs über Syslog oder Journald
- Logs verteilter Dienste wie Kafka, RabbitMQ oder Elasticsearch
In Frankreich setzen viele Unternehmen auf Inventarisierungswerkzeuge wie GLPI oder Centreon, die auch Logpfade miterfassen können. Aus meiner Erfahrung lohnt sich diese Vorarbeit: Auf einem mittelgroßen Cluster mit 40 Knoten habe ich einmal festgestellt, dass 17 Prozent der Logdateien überhaupt nicht rotiert wurden – weil sie schlicht nicht im Inventar standen.
2. Die Basiskonfiguration von Logrotate verstehen
Eine typische Konfigurationsdatei unter /etc/logrotate.d/ folgt einem festen Muster aus Pfadangabe, geöffneter Klammer und Direktiven. Die wichtigsten Direktiven steuern Intervall, Anzahl der Archive, Komprimierung und Fehlertoleranz.
Ein bewährtes Grundgerüst sieht so aus:
/var/log/meine-app/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 www-data adm sharedscripts postrotate systemctl reload meine-app > /dev/null 2>&1 || true endscript
}Die Direktiven im Überblick:
- daily, weekly oder monthly – legt das Rotationsintervall fest
- rotate N – Anzahl der aufzubewahrenden Archive
- compress und delaycompress – steuern die Komprimierung
- missingok und notifempty – erhöhen die Fehlertoleranz
- sharedscripts – führt Skripte nur einmal pro Gruppe aus
- copytruncate – kopiert statt zu verschieben, wichtig bei laufenden Prozessen
Warum sharedscripts in verteilten Systemen Pflicht ist: Wenn mehrere Logs gemeinsam von einem Dienst geschrieben werden, verhindert diese Direktive, dass Reload-Befehle mehrfach ausgeführt werden – ein häufiger Fehler in Cluster-Umgebungen. Ich habe schon erlebt, dass ein fehlendes sharedscripts zu einem mehrfachen Neustart eines Nachrichtendienstes führte und dadurch Nachrichten verloren gingen. Das ist ein vermeidbarer Performance-Engpass.
3. Zentrale Konfigurationsverwaltung einrichten
In verteilten Systemen sollten Sie Logrotate-Konfigurationen nicht manuell auf jedem Server pflegen. Eine zentrale, versionierte Ablage ist der Schlüssel zu Konsistenz und Nachvollziehbarkeit.
Legen Sie alle Konfigurationsdateien in einem Git-Repository ab, strukturiert nach Host-Gruppen:
logrotate-config/
├── common/
│ └── base.conf
├── webserver/
│ └── nginx.conf
├── database/
│ └── postgresql.conf
└── kubernetes/ └── kubelet.confEin einfaches Ansible-Playbook genügt, um die Konfiguration auszurollen:
- hosts: webserver tasks: - name: Logrotate-Konfiguration verteilen copy: src: "logrotate-config/webserver/nginx.conf" dest: /etc/logrotate.d/nginx owner: root group: root mode: '0644' - name: Logrotate-Status prüfen command: logrotate --debug /etc/logrotate.d/nginx changed_when: falseNeben Ansible sind in Frankreich SaltStack, Puppet und Chef verbreitet. Für regulierte Branchen wie Banken oder das Gesundheitswesen empfiehlt sich zusätzlich ein Konformitäts-Check mit Werkzeugen wie Vault zur Absicherung sensibler Logpfade. Meiner Meinung nach ist Ansible für die meisten Teams der pragmatischste Einstieg, weil die Lernkurve flach bleibt und die YAML-Syntax gut lesbar ist.
4. Logrotation in Container- und Kubernetes-Umgebungen
Container schreiben standardmäßig nach STDOUT und STDERR, sodass die Rotation nicht über Logrotate, sondern über die Daemon-Konfiguration erfolgt. In Kubernetes übernimmt der Kubelet diese Aufgabe, und Sie passen die Parameter direkt in der Kubelet-Konfiguration an.
Für Docker und Podman setzen Sie die Rotation in der Daemon-Konfiguration:
{ "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "5" }
}In Kubernetes konfigurieren Sie den Kubelet beispielsweise so:
containerLogMaxSize: 100Mi
containerLogMaxFiles: 5Ein wichtiger Hinweis für Betreiber in Frankreich: Die CNIL empfiehlt in ihren Leitlinien zur Datenminimierung, Logs personenbezogener Daten nach maximal sechs Monaten zu löschen. Planen Sie die Aufbewahrungsfristen entsprechend und dokumentieren Sie die Löschfristen nachvollziehbar. Ich halte diese Vorgabe für sinnvoll, auch wenn sie in der Praxis oft ignoriert wird.
5. Zentrale Logaggregation anbinden
Logrotate ist nur die halbe Miete – in verteilten Systemen sollten rotierte Logs an eine zentrale Plattform weitergeleitet werden, damit Sie bei der Fehleranalyse nicht auf jedem Host einzeln suchen müssen. Die Kombination aus lokaler Rotation und zentraler Aggregation ist das, was ich als Best Practice bezeichnen würde.
Bewährte Werkzeuge für die Weiterleitung:
- Rsyslog oder Syslog-ng für klassische Weiterleitung
- Filebeat oder Fluentd für strukturierte Logs
- Logstash für komplexe Transformationen
- Vector als moderne, ressourcenschonende Alternative
Der empfohlene Ablauf ist dabei immer derselbe: Die Anwendung schreibt in eine lokale Logdatei, Logrotate rotiert und komprimiert, Filebeat liest die neue Datei und sendet sie an Elasticsearch, und alte Archive werden nach Ablauf der Aufbewahrungsfrist gelöscht. Diese Kette hat sich in den von mir betreuten Umgebungen als robust erwiesen.
6. Überwachung und Alarmierung einrichten
Eine Logrotation, die nicht überwacht wird, ist ein blinder Fleck in Ihrer Betriebsarchitektur. Sie sollten fehlgeschlagene Rotationsläufe, die Festplattenauslastung pro Log-Verzeichnis, die Größe der Logarchive und Zustellverzögerungen an die zentrale Plattform kontinuierlich prüfen.
Im französischen Markt sind Centreon, Prometheus mit Grafana und Zabbix die gebräuchlichsten Werkzeuge. Eine einfache Alarmregel in Prometheus sieht so aus:
- alert: LogrotateFehlgeschlagen expr: node_systemd_unit_state{name="logrotate.timer",state="failed"} == 1 for: 5m annotations: summary: "Logrotate ist auf {{ $labels.instance }} fehlgeschlagen"Aus meiner Sicht ist die Überwachung des Timer-Status die wichtigste Einzelmaßnahme, weil ein fehlgeschlagener Lauf oft still bleibt und erst Wochen später durch eine volle Festplatte auffällt.
Wie sieht ein sinnvoller Vergleich der Rotationsstrategien aus?
Die Wahl der richtigen Strategie hängt von Schreiblast, Aufbewahrungspflichten und Speicherbudget ab. Die folgende Übersicht fasst die wichtigsten Optionen mit ihren jeweiligen Vor- und Nachteilen zusammen.
| Strategie | Intervall | Speicherbedarf pro Host | Vorteile | Nachteile |
|---|---|---|---|---|
| Standard täglich | täglich | ca. 2–5 GB | einfach, bewährt | bei hoher Last schnell voll |
| Stündlich mit systemd-Timer | stündlich | ca. 1–2 GB | feine Granularität | höhere CPU-Last durch Kompression |
| Größenbasiert | bei 100 MB | ca. 500 MB–1 GB | vorhersehbarer Platzbedarf | Rotation zu unerwarteten Zeiten |
| copytruncate | variabel | ca. 2–5 GB | kein Neustart nötig | Datenverlust bei hoher Schreiblast möglich |
Für die meisten verteilten Systeme empfehle ich eine tägliche Rotation mit rotate 14 und delaycompress. Bei API-Gateways mit mehr als 50.000 Anfragen pro Minute habe ich mit stündlicher Rotation bessere Ergebnisse erzielt.
Häufige Fehler, die Sie vermeiden sollten
Die folgenden Fehler begegnen mir in Audits immer wieder und lassen sich mit wenig Aufwand vermeiden.
- copytruncate ohne Bedacht einsetzen – kann bei hoher Schreiblast zu Datenverlust führen
- sharedscripts vergessen – führt zu mehrfachen Reloads und Dienstunterbrechungen
- Keine zentrale Versionierung – Konfigurationsdrift zwischen Servern ist vorprogrammiert
- Aufbewahrungsfristen ignorieren – DSGVO-Verstöße drohen; die CNIL kann Bußgelder verhängen
- Logs nicht komprimieren – verschwendet teuren Speicherplatz, besonders in Cloud-Umgebungen wie AWS, OVHcloud oder Scaleway
- Keine Tests vor dem Ausrollen – nutzen Sie immer
logrotate --debug, bevor Sie Konfigurationen produktiv schalten - Container-Logs mit Host-Logs vermischen – führt zu doppelter Rotation und Inkonsistenzen
Ich habe einmal erlebt, wie ein Team copytruncate auf einer Datenbank mit hoher Schreiblast einsetzte. Das Ergebnis war ein Datenverlust von etwa zwölf Minuten Transaktionsprotokoll. So etwas lässt sich vermeiden, wenn man die Direktiven versteht, statt sie zu kopieren.
Wie teste ich eine neue Logrotate-Konfiguration sicher?
Führen Sie logrotate --debug /etc/logrotate.d/meine-config aus, um den Lauf zu simulieren, ohne Dateien zu verändern. Prüfen Sie die Ausgabe auf unerwartete Pfade und fehlende Berechtigungen, bevor Sie die Konfiguration produktiv ausrollen. Diese einfache Maßnahme hat mir schon mehrfach stundenlange Fehlersuche erspart.
Wie oft sollte Logrotate in verteilten Systemen ausgeführt werden?
In den meisten Fällen reicht ein täglicher Lauf, bei sehr logintensiven Diensten wie API-Gateways empfiehlt sich ein stündlicher Lauf über einen systemd-Timer. Entscheidend ist, dass Sie die Schreibgeschwindigkeit Ihrer Dienste kennen und die Rotationsfrequenz daran ausrichten.
Kann ich Logrotate zentral von einem Steuerungsserver aus starten?
Ja, über Ansible, SaltStack oder ein eigenes Orchestrierungsskript. Vermeiden Sie jedoch, Logrotate per SSH-Schleife zu starten – das ist fehleranfällig und schlecht skalierbar. Ein sauberes Playbook ist immer die bessere Wahl.
Welche Aufbewahrungsfristen gelten in Frankreich?
Die CNIL empfiehlt je nach Zweck zwischen drei und sechs Monaten für Betriebslogs. Sicherheitsrelevante Logs können bis zu einem Jahr aufbewahrt werden, sofern dies dokumentiert ist. Prüfen Sie die Vorgaben für Ihre Branche, denn im Gesundheitswesen gelten strengere Regeln als im E-Commerce.
Was kostet eine zentrale Logmanagement-Lösung?
Für kleine Umgebungen beginnen Cloud-Lösungen bei etwa 50 bis 200 Euro pro Monat. Self-Hosted-Lösungen auf OVHcloud oder Scaleway sind ab etwa 30 Euro pro Monat realisierbar, wobei Sie den Betriebsaufwand einrechnen sollten. Bei mehr als 50 Hosts lohnt sich fast immer eine selbst betriebene Lösung.
Was ist das Fazit für die Praxis?
Logrotate für verteilte Systeme zu konfigurieren ist mehr als das Schreiben einer einzelnen Konfigurationsdatei. Es erfordert eine zentrale Strategie, automatisiertes Ausrollen, container-kompatible Ansätze und eine strikte Einhaltung der DSGVO-Vorgaben. Mit den hier beschriebenen sechs Schritten sind Sie in der Lage, eine skalierbare, wartbare und rechtskonforme Logrotation für Ihre gesamte Infrastruktur aufzusetzen.
Beginnen Sie mit der Bestandsaufnahme Ihrer Logquellen und richten Sie ein Git-Repository für Ihre Konfigurationen ein – der Rest folgt systematisch. Und testen Sie jede Änderung mit logrotate --debug, bevor sie produktiv wird.
Um die Funktionalität von Logrotate zu erweitern, können Sie Logrotate-Skripte einbinden, die nach der Rotation zusätzliche Aktionen ausführen.
Eine gut durchdachte Logrotate Retentionsstrategie ist unerlässlich, um Speicherplatz zu managen und Compliance-Anforderungen zu erfüllen.
Die Logrotate-Kompression ist ein weiterer wichtiger Aspekt, um den Speicherbedarf von Protokolldateien erheblich zu reduzieren.
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 →
