Log Rotation: Funktionsweise, Rotationsstrategien und Konfiguration fürMobile Projekte

Was ist Log Rotation

Log Rotation ist der Prozess des periodischen Wechselns der aktiven Logdatei zu einer neuen, bei gleichzeitiger Archivierung, Komprimierung oder Löschung der alten. Ohne Rotation wächst eine einzelne Logdatei unbegrenzt, bis sie die gesamte Festplattenpartition füllt, was zu Anwendungsausfällen und Datenverlust führt.

Typisches Szenario: Eine Anwendung schreibt Logs in die Datei app.log. Wenn app.log 100 MB erreicht, benennt das System sie in app.log.1 um, komprimiert sie in app.log.1.gz und erstellt eine neue leere app.log. Beim nächsten Füllen wird app.log.1 zu app.log.2, app.log.1.gz wird zu app.log.2.gz und die alte app.log.2.gz wird gelöscht. Dieser Mechanismus heißt Rotation mit Keep Count — die Anzahl der Archivkopien ist festgelegt.

Laut Splunk (2023) ist eine falsche Rotationskonfiguration die Ursache für 40% der Vorfälle im Zusammenhang mit der Erschöpfung des Speicherplatzes auf Anwendungsservern. Für mobile Geräte ist die Rotation noch kritischer, da der Benutzer Logs nicht manuell verwalten kann und soll.

Log-Rotationsstrategien

Log Rotation unterstützt drei grundlegende Strategien, die kombiniert werden können. Die Wahl der Strategie hängt vom Anwendungstyp ab: Serversysteme verwenden häufiger zeitbasierte Rotation, mobile — größenbasierte, eingebettete — dateianzahlbasierte.

Größenbasierte Rotation — die häufigste

Die größenbasierte Rotation stellt sicher, dass keine Logdatei ein festgelegtes Limit überschreitet. Das Limit wird basierend auf dem verfügbaren Speicherplatz und der Protokollierungshäufigkeit gewählt. Für einen Server beträgt das typische Limit 100–500 MB pro Datei, für ein mobiles Gerät 1–10 MB. Wenn die Anwendung aggressiv protokolliert, sollte das Limit gesenkt werden, sonst erfolgt die Rotation alle paar Minuten.

Zeitbasierte Rotation — für Compliance

Die zeitbasierte Rotation ist unabhängig vom Logvolumen — die Datei wird streng nach Zeitplan gewechselt. Praktisch für Systeme, in denen Logs für eine festgelegte Anzahl von Tagen aufbewahrt werden müssen: tägliche Rotation mit Keep Count = 30 bedeutet 30 Tage Aufbewahrung. Der Nachteil — eine einzelne Datei kann bei starker Last auf ein Gigabyte pro Tag anwachsen.

logrotate unter Linux: Konfiguration und Beispiele

logrotate ist das Standard-Linux-Dienstprogramm zur automatischen Logrotation. Es wird über cron ausgeführt und verarbeitet Konfigurationsdateien aus /etc/logrotate.d/. Jeder Dienst (nginx, postgresql, Anwendung) erstellt seine eigene Konfiguration mit Angabe der Logpfade, der Rotationsstrategie und der Aktionen nach der Rotation.

# /etc/logrotate.d/myapp — Logrotation der Anwendung
/var/log/myapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data www-data
    postrotate
        kill -HUP $(cat /var/run/myapp.pid)
    endscript
}

Diese Konfiguration rotiert Logs täglich, behält 7 Archivkopien, komprimiert alte Dateien mit gzip (außer der letzten — delaycompress), gibt keinen Fehler aus, wenn Logs fehlen (missingok), rotiert keine leeren Dateien (notifempty) und erstellt die Datei mit Berechtigungen 0640 neu. Nach der Rotation sendet sie ein HUP-Signal an den Anwendungsprozess über ein postrotate-Skript.

logrotate-Parameter

size — Rotation bei Erreichen einer Größe (size 100M). rotate — Anzahl der Archivkopien (rotate 7). compress — gzip-Komprimierung. dateext — fügt dem Dateinamen das Datum anstelle einer Sequenznummer hinzu. sharedscripts — führt postrotate einmal für alle Dateien aus, nicht für jede einzeln. maxage — löscht Archive, die älter als N Tage sind.

Log Rotation in mobilen Anwendungen

Auf mobilen Geräten ist Log Rotation kritisch, da der Benutzer das Dateisystem nicht verwaltet und nicht erwartet, dass die Anwendung Gigabyte mit Logs belegt. iOS und Android haben integrierte Mechanismen: os_log auf iOS verwendet einen Ringpuffer fester Größe (Rotation durch Überschreiben), Android Logcat hat einen begrenzten Puffer im Kernel.

Für benutzerdefinierte Dateilogs auf iOS wird CocoaLumberjack mit der Klasse DDFileLogger verwendet, die größen- und zeitbasierte Rotation unterstützt. Auf Android — Logback oder benutzerdefinierte Implementierungen über RollingFileAppender. Beide Tools ermöglichen die Festlegung der maximalen Dateigröße und der Anzahl der Archivkopien.

// CocoaLumberjack — Dateirotation auf iOS
import CocoaLumberjack

let fileLogger = DDFileLogger()
fileLogger.maximumFileSize = 1024 * 1024 // 1 MB
fileLogger.logFileManager.maximumNumberOfLogFiles = 5
DDLog.add(fileLogger)

iOS: os_log benötigt keine Rotation — Nachrichten werden im Ringpuffer überschrieben. Wenn die Anwendung jedoch benutzerdefinierte Dateilogs schreibt (zum Debuggen oder zum Senden an den Server), muss die Rotation manuell konfiguriert werden. CocoaLumberjack ist die Standardwahl für iOS-Teams — es komprimiert Archive automatisch in .gz und löscht alte Dateien bei Überschreitung des Limits.

Warum Rotation auf Android wichtig ist

Android schränkt Anwendungen nicht beim Schreiben von Logs in ihr eigenes Verzeichnis ein. Wenn ein Entwickler Debug-Logs ohne Rotation in eine Datei schreibt, können sie bei aktiver Nutzung innerhalb eines Monats 500 MB bis 1 GB belegen. Der Benutzer entdeckt das Problem, wenn das System eine Speicherwarnung anzeigt, und löscht die App. Logback mit RollingFileAppender löst dieses Problem: ein Limit von 5 MB mit 3 Archiven garantiert, dass Logs nie 20 MB überschreiten.

Beispiele für die Rotationsimplementierung auf iOS und Android

Nachfolgend finden Sie Beispiele für die Konfiguration der Logrotation auf beiden Plattformen. Auf iOS wird CocoaLumberjack verwendet, auf Android — Logback mit XML-Konfiguration.

// Logback auf Android — Rotationskonfiguration in logback.xml
// Dateigröße 5MB, 3 Archivkopien
@file:Suppress("unused")

// In logback.xml:
// <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
//   <file>${DATA_DIR}/logs/app.log</file>
//   <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
//     <fileNamePattern>app.%i.log.gz</fileNamePattern>
//     <minIndex>1</minIndex>
//     <maxIndex>3</maxIndex>
//   </rollingPolicy>
//   <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
//     <maxFileSize>5MB</maxFileSize>
//   </triggeringPolicy>
// </appender>

CocoaLumberjack auf iOS unterstützt nicht nur die größenbasierte Rotation, sondern auch das Löschen alter Logs nach Datum mit logFileManager.maximumLogFiles. Wird maximumLogFiles = 0 gesetzt, wird die Beschränkung aufgehoben — Logs sammeln sich unbegrenzt an, was für die Produktion gefährlich ist.

// Benutzerdefinierte Rotation mit Prüfung des Gesamtvolumens
class SizeAwareLogger {
    let maxTotalSize: Int64 = 20 * 1024 * 1024

    func enforceQuota(at logDirectory: URL) {
        let files = (try? FileManager.default
            .contentsOfDirectory(
                at: logDirectory,
                includingPropertiesForKeys: [.fileSize]
            )) ?? []
        let total = files.reduce(0) {
            $0 + (try? $1.resourceValues(forKeys: [.fileSize])
                .fileSize).map(Int64.init) ?? 0
        }
        if total > maxTotalSize {
            // Älteste Datei löschen
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Überwachung und Warnmeldungen bei Rotation

Log Rotation ist nicht nur automatische Archivierung, sondern auch ein Indikator für die Systemgesundheit. Wenn Logs zu häufig rotiert werden (alle paar Minuten), ist dies ein Zeichen für übermäßige Protokollierung oder eine Fehlerprotokollschleife. Richten Sie Warnmeldungen zur Rotationshäufigkeit ein: mehr als 10 Rotationen pro Stunde sind ein Grund zur Überprüfung.

Überwachungssysteme (Prometheus, Grafana, Datadog) können Rotationsmetriken über Dateisystem-Exporteure verfolgen. Prometheus node_exporter liefert Metriken zur Dateigröße und Änderungszeit. Auf mobilen Geräten ist die Rotationsüberwachung normalerweise im SDK integriert: CocoaLumberjack protokolliert das Rotationsereignis über DDLog, und Logback sendet den Status über einen Appender.

Warnmeldungen: Wenn mehr Archive als erwartet vorhanden sind (der Rotationszähler hat das Limit überschritten) oder das gesamte Logvolumen das Kontingent überschritten hat, sollte das System den Administrator benachrichtigen. Für Server beträgt die Standardschwelle 80% der Partitionsgröße, für mobile Geräte — eine Warnung bei Überschreitung von 50 MB pro Anwendung.