Log Rotation: hoe het werkt, rotatiestrategieën en configuratie voor mobiele projecten

Wat is Log Rotation

Log Rotation is het proces van periodieke vervanging van het actieve logbestand door een nieuw met gelijktijdige archivering, compressie of verwijdering van het oude. Zonder rotatie groeit één logbestand oneindig door totdat het de hele schijfpartitie vult, wat leidt tot applicatiecrashes en gegevensverlies.

Typisch scenario: de applicatie schrijft logs naar het bestand app.log. Wanneer app.log 100 MB bereikt, hernoemt het systeem het naar app.log.1, comprimeert het naar app.log.1.gz en maakt een nieuwe lege app.log aan. Bij de volgende vulling wordt app.log.1 app.log.2, app.log.1.gz wordt app.log.2.gz en oude app.log.2.gz wordt verwijderd. Dit mechanisme heet rotatie met keep count — het aantal archiefkopieën is vast.

Volgens Splunk (2023) is onjuiste rotatieconfiguratie de oorzaak van 40% van de incidenten met betrekking tot schijfvolheid op applicatieservers. Voor mobiele apparaten is rotatie nog kritischer, omdat de gebruiker logs niet handmatig kan en mag beheren.

Rotatiestrategieën voor logs

Log Rotation ondersteunt drie basisstrategieën die gecombineerd kunnen worden. De keuze van strategie hangt af van het type applicatie: serversystemen gebruiken vaker rotatie op tijd, mobiele applicaties — op grootte, ingebedde systemen — op aantal bestanden.

Rotatie op grootte — de meest voorkomende

Rotatie op grootte garandeert dat geen enkel logbestand de ingestelde limiet overschrijdt. De limiet wordt gekozen op basis van beschikbare schijfruimte en logfrequentie. Voor een server is de typische limiet 100–500 MB per bestand, voor een mobiel apparaat 1–10 MB. Als de applicatie agressief logt, moet de limiet worden verlaagd, anders vindt rotatie om de paar minuten plaats.

Rotatie op tijd — voor compliance

Rotatie op tijd is onafhankelijk van het logvolume — het bestand wordt strikt volgens schema gewisseld. Handig voor systemen waar logs een vast aantal dagen moeten worden bewaard: dagelijkse rotatie met keep count = 30 betekent 30 dagen opslag. Nadeel — één bestand kan bij intensieve belasting tot een gigabyte per dag groeien.

logrotate in Linux: configuratie en voorbeelden

logrotate is het standaard Linux-hulpprogramma voor automatische logrotatie. Het wordt gestart via cron en verwerkt configuratiebestanden uit /etc/logrotate.d/. Elke service (nginx, postgresql, applicatie) maakt zijn eigen config met paden naar logs, rotatiestrategie en acties na rotatie.

# /etc/logrotate.d/myapp — rotatie van applicatielogs
/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
}

Deze config roteert logs dagelijks, bewaart 7 archiefkopieën, comprimeert oude bestanden met gzip (behalve de laatste — delaycompress), geeft geen fout als logs ontbreken (missingok), roteert geen lege bestanden (notifempty) en hermaakt het bestand met rechten 0640. Na rotatie stuurt het een HUP-signaal naar het applicatieproces via een postrotate-script.

Parameters van logrotate

size — rotatie bij bereiken van de grootte (size 100M). rotate — aantal archiefkopieën (rotate 7). compress — gzip-compressie. dateext — toevoegen van datum aan bestandsnaam in plaats van volgnummer. sharedscripts — eenmalige uitvoering van postrotate voor alle bestanden, niet voor elk afzonderlijk. maxage — verwijdering van archieven ouder dan N dagen.

Log Rotation in mobiele applicaties

Op mobiele apparaten is Log Rotation cruciaal omdat de gebruiker het bestandssysteem niet beheert en niet verwacht dat de applicatie gigabytes aan logs in beslag neemt. iOS en Android hebben ingebouwde mechanismen: os_log op iOS gebruikt een circulaire buffer met vaste grootte (rotatie door overschrijven), Android Logcat heeft een beperkte buffer in de kernel.

Voor aangepaste bestandlogs op iOS wordt CocoaLumberjack met de klasse DDFileLogger gebruikt, die rotatie op grootte en tijd ondersteunt. Op Android — Logback of eigen implementaties via RollingFileAppender. Beide tools maken het mogelijk om de maximale bestandsgrootte en het aantal archieven in te stellen.

// CocoaLumberjack — bestandsrotatie op iOS
import CocoaLumberjack

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

iOS: os_log vereist geen rotatie — berichten worden overschreven in de circulaire buffer. Maar als de applicatie aangepaste bestandlogs schrijft (bijvoorbeeld voor debugging of verzending naar de server), moet rotatie handmatig worden geconfigureerd. CocoaLumberjack is de standaardkeuze voor iOS-teams, het comprimeert automatisch archieven naar .gz en verwijdert oude bestanden bij overschrijding van de limiet.

Waarom rotatie belangrijk is op Android

Android beperkt de applicatie niet in het schrijven van logs naar de eigen directory. Als een ontwikkelaar debug-logs zonder rotatie naar een bestand schrijft, kunnen deze binnen een maand actief gebruik 500 MB — 1 GB in beslag nemen. De gebruiker ontdekt het probleem wanneer het systeem een waarschuwing voor onvoldoende ruimte toont en verwijdert de applicatie. Logback met RollingFileAppender lost dit probleem op: een limiet van 5 MB met 3 archieven garandeert dat logs nooit meer dan 20 MB in beslag nemen.

Voorbeelden van rotatie-implementatie op iOS en Android

Hieronder staan voorbeelden van het configureren van logrotatie op beide platforms. Op iOS wordt CocoaLumberjack gebruikt, op Android — Logback met configuratie via XML.

// Logback op Android — rotatieconfiguratie in logback.xml
// Bestandsgrootte 5MB, 3 archiefkopieën
@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 op iOS ondersteunt niet alleen rotatie op grootte, maar ook het verwijderen van oude logs op datum via logFileManager.maximumLogFiles. Als u maximumLogFiles = 0 instelt, wordt de beperking opgeheven — logs worden oneindig verzameld, wat gevaarlijk is voor productie.

// Aangepaste rotatie met controle van totaal volume
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 {
            // We verwijderen het oudste bestand
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Monitoring en alerts bij rotatie

Log Rotation is niet alleen automatische archivering, maar ook een indicator van de systeemgezondheid. Als logs te vaak roteren (elke paar minuten), is dit een signaal van overmatig loggen of een fout in de cyclische foutlogging (error log loop). Stel alerts in op rotatiefrequentie: meer dan 10 rotaties per uur — reden voor onderzoek.

Monitoringsystemen (Prometheus, Grafana, Datadog) kunnen rotatiemetrics volgen via bestandssystemexporteurs. Prometheus node_exporter biedt metrics van bestandsgrootte en wijzigingstijd. Op mobiele apparaten is rotatiemonitoring meestal ingebouwd in de SDK: CocoaLumberjack logt de rotatiegebeurtenis via DDLog, en Logback stuurt status via appender.

Alerts: als er meer archieven zijn dan verwacht (rotate count heeft de limiet overschreden) of het totale logvolume het quotum heeft overschreden — moet het systeem de beheerder waarschuwen. Voor servers is de standaarddrempel 80% van de partitiegrootte, voor mobiele apparaten — alert bij overschrijding van 50 MB per applicatie.