Log Rotation: hur det fungerar, rotationsstrategier och konfiguration för mobilprojekt

Vad är Log Rotation

Log Rotation är processen att periodiskt byta ut den aktiva loggfilen mot en ny med samtidig arkivering, komprimering eller borttagning av den gamla. Utan rotation växer en enda loggfil oändligt tills den fyller hela diskpartitionen, vilket leder till applikationskrasch och dataförlust.

Typiskt scenario: applikationen skriver loggar till filen app.log. När app.log når 100 MB byter systemet namn på den till app.log.1, komprimerar den till app.log.1.gz och skapar en ny tom app.log. Vid nästa fyllning blir app.log.1 till app.log.2, app.log.1.gz blir app.log.2.gz och gamla app.log.2.gz raderas. Denna mekanism kallas rotation med keep count — antalet arkivkopior är fast.

Enligt Splunk (2023) är felaktig rotationskonfiguration orsaken till 40% av incidenter relaterade till full disk på applikationsservrar. För mobila enheter är rotation ännu mer kritisk eftersom användaren inte kan och inte bör hantera loggar manuellt.

Rotationsstrategier för loggar

Log Rotation stöder tre grundläggande strategier som kan kombineras. Valet av strategi beror på applikationstyp: serversystem använder oftare tidsbaserad rotation, mobilapplikationer — storleksbaserad, inbyggda system — baserat på antal filer.

Rotation efter storlek — den vanligaste

Rotation efter storlek garanterar att ingen loggfil överskrider den inställda gränsen. Gränsen väljs baserat på tillgängligt diskutrymme och loggningsfrekvens. För en server är den typiska gränsen 100–500 MB per fil, för en mobil enhet 1–10 MB. Om applikationen loggar aggressivt måste gränsen sänkas, annars sker rotation varannan minut.

Rotation efter tid — för efterlevnad

Rotation efter tid är oberoende av loggvolymen — filen byts strikt enligt schema. Praktiskt för system där loggar måste sparas ett fast antal dagar: daglig rotation med keep count = 30 innebär 30 dagars lagring. Nackdel — en fil kan växa till en gigabyte per dag under intensiv belastning.

logrotate i Linux: konfiguration och exempel

logrotate är standard Linux-verktyget för automatisk loggrotation. Det körs via cron och bearbetar konfigurationsfiler från /etc/logrotate.d/. Varje tjänst (nginx, postgresql, applikation) skapar sin egen konfig med sökvägar till loggar, rotationsstrategi och åtgärder efter rotation.

# /etc/logrotate.d/myapp — rotation av applikationsloggar
/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
}

Denna konfig roterar loggar dagligen, behåller 7 arkivkopior, komprimerar gamla filer med gzip (förutom den sista — delaycompress), ger inget fel om loggar saknas (missingok), roterar inte tomma filer (notifempty) och återskapar filen med behörigheten 0640. Efter rotation skickar den HUP-signal till applikationsprocessen via postrotate-skript.

Parametrar för logrotate

size — rotation när storlek nås (size 100M). rotate — antal arkivkopior (rotate 7). compress — gzip-komprimering. dateext — lägg till datum i filnamn istället för löpnummer. sharedscripts — kör postrotate en gång för alla filer, inte för varje separat. maxage — ta bort arkiv äldre än N dagar.

Log Rotation i mobilapplikationer

På mobila enheter är Log Rotation kritisk eftersom användaren inte hanterar filsystemet och inte förväntar sig att applikationen tar upp gigabyte med loggar. iOS och Android har inbyggda mekanismer: os_log på iOS använder en cirkulär buffert med fast storlek (rotation genom överskrivning), Android Logcat har en begränsad buffert i kärnan.

För anpassade filloggar på iOS används CocoaLumberjack med klassen DDFileLogger, som stöder rotation efter storlek och tid. På Android — Logback eller egna implementationer via RollingFileAppender. Båda verktygen tillåter inställning av maximal filstorlek och antal arkiv.

// CocoaLumberjack — filrotation på iOS
import CocoaLumberjack

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

iOS: os_log kräver inte rotation — meddelanden skrivs över i den cirkulära bufferten. Men om applikationen skriver anpassade filloggar (t.ex. för felsökning eller sändning till server), måste rotation konfigureras manuellt. CocoaLumberjack är standardvalet för iOS-team, det komprimerar automatiskt arkiv till .gz och tar bort gamla filer när gränsen överskrids.

Varför rotation är viktigt på Android

Android begränsar inte applikationen i att skriva loggar till sin egen katalog. Om utvecklaren skriver debug-loggar till en fil utan rotation kan de inom en månads aktiv användning ta upp 500 MB — 1 GB. Användaren upptäcker problemet när systemet visar en varning om brist på utrymme och tar bort applikationen. Logback med RollingFileAppender löser detta problem: en gräns på 5 MB med 3 arkiv garanterar att loggar aldrig tar upp mer än 20 MB.

Exempel på rotationsimplementation på iOS och Android

Nedan finns exempel på konfiguration av loggrotation på båda plattformarna. På iOS används CocoaLumberjack, på Android — Logback med konfiguration via XML.

// Logback på Android — rotationskonfiguration i logback.xml
// Filstorlek 5MB, 3 arkivkopior
@file:Suppress("unused")

// I 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 på iOS stöder inte bara rotation efter storlek, utan även borttagning av gamla loggar efter datum med logFileManager.maximumLogFiles. Om du ställer in maximumLogFiles = 0 tas begränsningen bort — loggar samlas oändligt, vilket är farligt för produktion.

// Anpassad rotation med kontroll av total volym
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 {
            // Vi tar bort den äldsta filen
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Övervakning och aviseringar vid rotation

Log Rotation är inte bara automatisk arkivering, utan också en indikator på systemets hälsa. Om loggar roterar för ofta (varannan minut) är detta en signal om överdriven loggning eller fel i cyklisk felloggning (error log loop). Konfigurera aviseringar på rotationsfrekvens: mer än 10 rotationer i timmen — anledning att kontrollera.

Övervakningssystem (Prometheus, Grafana, Datadog) kan spåra rotationsmetricer via filsystemsexportörer. Prometheus node_exporter tillhandahåller metricer för filstorlek och ändringstid. På mobila enheter är rotationsövervakning vanligtvis inbyggd i SDK: CocoaLumberjack loggar rotationshändelsen via DDLog, och Logback skickar status via appender.

Aviseringar: om arkiv är fler än förväntat (rotate count har överskridit gränsen) eller den totala loggvolymen har överskridit kvoten — bör systemet meddela administratören. För servrar är standardtröskeln 80% av partitionens storlek, för mobila enheter — avisering vid överskridande av 50 MB per applikation.