Log Rotation: jak działa, strategie rotacji i konfiguracja dla projektów mobilnych

Czym jest Log Rotation

Log Rotation — to proces okresowej zmiany aktywnego pliku loga na nowy z jednoczesną archiwizacją, kompresją lub usuwaniem starego. Bez rotacji jeden plik loga rośnie w nieskończoność, aż wypełni całą partycję dysku, co prowadzi do awarii aplikacji i utraty danych.

Typowy scenariusz: aplikacja zapisuje logi do pliku app.log. Gdy app.log osiąga 100 MB, system zmienia jego nazwę na app.log.1, kompresuje do app.log.1.gz i tworzy nowy pusty app.log. Przy następnym zapełnieniu app.log.1 staje się app.log.2, app.log.1.gz — app.log.2.gz, a stary app.log.2.gz jest usuwany. Ten mechanizm nazywa się rotacją z keep count — liczba kopii archiwalnych jest stała.

Według danych Splunk (2023), nieprawidłowa konfiguracja rotacji jest przyczyną 40% incydentów związanych z zapełnieniem dysku na serwerach aplikacji. Dla urządzeń mobilnych rotacja jest jeszcze bardziej krytyczna, ponieważ użytkownik nie może i nie powinien ręcznie zarządzać logami.

Strategie rotacji logów

Log Rotation obsługuje trzy podstawowe strategie, które można łączyć. Wybór strategii zależy od typu aplikacji: systemy serwerowe częściej używają rotacji według czasu, mobilne — według rozmiaru, wbudowane — według liczby plików.

Rotacja według rozmiaru — najpopularniejsza

Rotacja według rozmiaru gwarantuje, że żaden plik loga nie przekracza zadanego limitu. Limit wybiera się na podstawie dostępnej przestrzeni dyskowej i częstotliwości logowania. Dla serwera typowy limit to 100–500 MB na plik, dla urządzenia mobilnego — 1–10 MB. Jeśli aplikacja loguje agresywnie, limit należy obniżyć, w przeciwnym razie rotacja będzie występować co kilka minut.

Rotacja według czasu — dla zgodności

Rotacja według czasu jest niezależna od objętości logów — plik zmienia się ściśle według harmonogramu. Wygodna dla systemów, w których logi muszą być przechowywane przez stałą liczbę dni: codzienna rotacja z keep count = 30 oznacza 30 dni przechowywania. Wadą jest to, że jeden plik może urosnąć do gigabajta dziennie przy intensywnym obciążeniu.

logrotate w Linux: konfiguracja i przykłady

logrotate — standardowe narzędzie Linux do automatycznej rotacji logów. Uruchamiane jest przez cron i przetwarza pliki konfiguracyjne z /etc/logrotate.d/. Każda usługa (nginx, postgresql, aplikacja) tworzy własny konfig ze ścieżkami do logów, strategią rotacji i akcjami po rotacji.

# /etc/logrotate.d/myapp — rotacja logów aplikacji
/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
}

Ten konfig rotuje logi codziennie, przechowuje 7 kopii archiwalnych, kompresuje stare pliki gzip (z wyjątkiem ostatniego — delaycompress), nie zgłasza błędu jeśli logów nie ma (missingok), nie rotuje pustych plików (notifempty) i odtwarza plik z prawami 0640. Po rotacji wysyła sygnał HUP do procesu aplikacji przez skrypt postrotate.

Parametry logrotate

size — rotacja po osiągnięciu rozmiaru (size 100M). rotate — liczba kopii archiwalnych (rotate 7). compress — kompresja gzip. dateext — dodanie daty do nazwy pliku zamiast numeru porządkowego. sharedscripts — wykonanie postrotate raz dla wszystkich plików, a nie dla każdego osobno. maxage — usuwanie archiwów starszych niż N dni.

Log Rotation w aplikacjach mobilnych

Na urządzeniach mobilnych Log Rotation jest krytyczna, ponieważ użytkownik nie zarządza systemem plików i nie oczekuje, że aplikacja zajmie gigabajty logami. iOS i Android mają wbudowane mechanizmy: os_log na iOS używa bufora cyklicznego o stałym rozmiarze (rotacja przez nadpisywanie), Android Logcat ma ograniczony bufor w jądrze.

Do niestandardowych logów plikowych na iOS używa się CocoaLumberjack z klasą DDFileLogger, która obsługuje rotację według rozmiaru i czasu. Na Android — Logback lub własne implementacje przez RollingFileAppender. Oba narzędzia pozwalają ustawić maksymalny rozmiar pliku i liczbę archiwów.

// CocoaLumberjack — rotacja plikowa na iOS
import CocoaLumberjack

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

iOS: os_log nie wymaga rotacji — komunikaty są nadpisywane w buforze cyklicznym. Jeśli jednak aplikacja zapisuje niestandardowe logi plikowe (np. do debugowania lub wysyłki na serwer), rotację trzeba skonfigurować ręcznie. CocoaLumberjack to standardowy wybór dla zespołów iOS, automatycznie kompresuje archiwa do .gz i usuwa stare pliki po przekroczeniu limitu.

Dlaczego rotacja jest ważna na Android

Android nie ogranicza aplikacji w zapisie logów do własnego katalogu. Jeśli programista zapisuje debug-logi do pliku bez rotacji, w ciągu miesiąca aktywnego użytkowania mogą zająć 500 MB — 1 GB. Użytkownik odkryje problem, gdy system pokaże ostrzeżenie o braku miejsca i usunie aplikację. Logback z RollingFileAppender rozwiązuje ten problem: limit 5 MB z 3 archiwami gwarantuje, że logi nigdy nie zajmą więcej niż 20 MB.

Przykłady implementacji rotacji na iOS i Android

Poniżej znajdują się przykłady konfiguracji rotacji logów na obu platformach. Na iOS używany jest CocoaLumberjack, na Android — Logback z konfiguracją przez XML.

// Logback na Android — konfiguracja rotacji w logback.xml
// Rozmiar pliku 5MB, 3 kopie archiwalne
@file:Suppress("unused")

// W 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 na iOS obsługuje nie tylko rotację według rozmiaru, ale także usuwanie starych logów według daty za pomocą logFileManager.maximumLogFiles. Jeśli ustawisz maximumLogFiles = 0, ograniczenie zostanie zdjęte — logi będą gromadzić się w nieskończoność, co jest niebezpieczne w production.

// Niestandardowa rotacja z kontrolą całkowitej objętości
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 {
            // Usuwamy najstarszy plik
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Monitoring i alerty przy rotacji

Log Rotation to nie tylko automatyczna archiwizacja, ale także wskaźnik zdrowia systemu. Jeśli logi rotują zbyt często (co kilka minut), to sygnał o nadmiernym logowaniu lub o błędzie w cyklicznym logowaniu błędów (error log loop). Skonfiguruj alerty na częstotliwość rotacji: więcej niż 10 rotacji na godzinę — powód do sprawdzenia.

Systemy monitorujące (Prometheus, Grafana, Datadog) mogą śledzić metryki rotacji przez eksportery systemu plików. Prometheus node_exporter dostarcza metryki rozmiaru plików i czasu ich modyfikacji. Na urządzeniach mobilnych monitoring rotacji jest zwykle wbudowany w SDK: CocoaLumberjack loguje zdarzenie rotacji przez DDLog, a Logback wysyła status przez appender.

Alerty: jeśli archiwów jest więcej niż oczekiwano (rotate count przekroczył limit) lub łączna objętość logów przekroczyła limit — system powinien powiadomić administratora. Dla serwerów standardowy próg to 80% rozmiaru partycji, dla urządzeń mobilnych — alert po przekroczeniu 50 MB na aplikację.