Log Rotation: cum funcționează, strategii de rotație și configurare pentru proiecte mobile

Ce este Log Rotation

Log Rotation este procesul de schimbare periodică a fișierului activ de log cu unul nou, cu arhivarea, comprimarea sau ștergerea celui vechi. Fără rotație, un singur fișier de log crește la nesfârșit până umple întreaga partiție de disc, ceea ce duce la defectarea aplicației și pierderea datelor.

Scenariu tipic: aplicația scrie loguri în fișierul app.log. Când app.log atinge 100 MB, sistemul îl redenumește în app.log.1, îl comprimă în app.log.1.gz și creează un nou app.log gol. La următoarea umplere, app.log.1 devine app.log.2, app.log.1.gz devine app.log.2.gz, iar app.log.2.gz vechi este șters. Acest mecanism se numește rotație cu keep count — numărul copiilor de arhivă este fix.

Conform Splunk (2023), configurarea incorectă a rotației este cauza a 40% din incidentele legate de umplerea discului pe serverele de aplicații. Pentru dispozitivele mobile, rotația este și mai critică, deoarece utilizatorul nu poate și nu trebuie să gestioneze manual logurile.

Strategii de rotație a logurilor

Log Rotation suportă trei strategii de bază care pot fi combinate. Alegerea strategiei depinde de tipul aplicației: sistemele server folosesc mai des rotația după timp, aplicațiile mobile — după dimensiune, sistemele încorporate — după numărul de fișiere.

Rotația după dimensiune — cea mai comună

Rotația după dimensiune garantează că niciun fișier de log nu depășește limita stabilită. Limita se alege în funcție de spațiul disponibil pe disc și frecvența logării. Pentru un server, limita tipică este 100–500 MB per fișier, pentru un dispozitiv mobil — 1–10 MB. Dacă aplicația loghează agresiv, limita trebuie redusă, altfel rotația va avea loc la fiecare câteva minute.

Rotația după timp — pentru conformitate

Rotația după timp este independentă de volumul logurilor — fișierul se schimbă strict conform programului. Utilă pentru sistemele unde logurile trebuie păstrate un număr fix de zile: rotația zilnică cu keep count = 30 înseamnă 30 de zile de păstrare. Dezavantajul — un fișier poate crește până la un gigabyte pe zi la sarcină intensivă.

logrotate în Linux: configurare și exemple

logrotate este unealta standard Linux pentru rotația automată a logurilor. Este rulată prin cron și procesează fișierele de configurare din /etc/logrotate.d/. Fiecare serviciu (nginx, postgresql, aplicație) își creează propriul config cu căile către loguri, strategia de rotație și acțiunile post-rotație.

# /etc/logrotate.d/myapp — rotația logurilor aplicației
/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
}

Acest config rotește logurile zilnic, păstrează 7 copii de arhivă, comprimă fișierele vechi cu gzip (cu excepția ultimului — delaycompress), nu generează eroare dacă logurile lipsesc (missingok), nu rotește fișierele goale (notifempty) și recrează fișierul cu permisiunile 0640. După rotație, trimite semnalul HUP procesului aplicației prin scriptul postrotate.

Parametri logrotate

size — rotație la atingerea dimensiunii (size 100M). rotate — numărul copiilor de arhivă (rotate 7). compress — comprimare gzip. dateext — adăugarea datei în numele fișierului în loc de număr ordinal. sharedscripts — executarea postrotate o singură dată pentru toate fișierele, nu pentru fiecare separat. maxage — ștergerea arhivelor mai vechi de N zile.

Log Rotation în aplicațiile mobile

Pe dispozitivele mobile, Log Rotation este critică deoarece utilizatorul nu gestionează sistemul de fișiere și nu se așteaptă ca aplicația să ocupe gigabytes cu loguri. iOS și Android au mecanisme încorporate: os_log pe iOS folosește un buffer circular de dimensiune fixă (rotație prin suprascriere), Android Logcat are un buffer limitat în nucleu.

Pentru loguri de fișier personalizate pe iOS se folosește CocoaLumberjack cu clasa DDFileLogger, care suportă rotația după dimensiune și timp. Pe Android — Logback sau implementări proprii prin RollingFileAppender. Ambele unelte permit setarea dimensiunii maxime a fișierului și a numărului de arhive.

// CocoaLumberjack — rotație fișiere pe iOS
import CocoaLumberjack

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

iOS: os_log nu necesită rotație — mesajele sunt suprascrise în bufferul circular. Dar dacă aplicația scrie loguri de fișier personalizate (de exemplu, pentru depanare sau trimitere la server), rotația trebuie configurată manual. CocoaLumberjack este alegerea standard pentru echipele iOS, comprimă automat arhivele în .gz și șterge fișierele vechi la depășirea limitei.

De ce rotația este importantă pe Android

Android nu limitează aplicația în scrierea logurilor în propriul director. Dacă dezvoltatorul scrie loguri de debug într-un fișier fără rotație, într-o lună de utilizare activă acestea pot ocupa 500 MB — 1 GB. Utilizatorul va descoperi problema când sistemul afișează avertismentul de spațiu insuficient și va șterge aplicația. Logback cu RollingFileAppender rezolvă această problemă: limita de 5 MB cu 3 arhive garantează că logurile nu vor ocupa niciodată mai mult de 20 MB.

Exemple de implementare a rotației pe iOS și Android

Mai jos sunt exemple de configurare a rotației logurilor pe ambele platforme. Pe iOS se folosește CocoaLumberjack, pe Android — Logback cu configurare prin XML.

// Logback pe Android — configurare rotație în logback.xml
// Dimensiune fișier 5MB, 3 copii de arhivă
@file:Suppress("unused")

// În 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 pe iOS suportă nu doar rotația după dimensiune, ci și ștergerea logurilor vechi după dată cu logFileManager.maximumLogFiles. Dacă setați maximumLogFiles = 0, limitarea este eliminată — logurile se vor acumula la nesfârșit, ceea ce este periculos pentru producție.

// Rotație personalizată cu verificare a volumului total
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 {
            // Ștergem cel mai vechi fișier
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Monitorizare și alerte la rotație

Log Rotation nu este doar arhivare automată, ci și un indicator al sănătății sistemului. Dacă logurile se rotesc prea des (la fiecare câteva minute), acesta este un semnal de logare excesivă sau de eroare în bucla de logare a erorilor (error log loop). Configurați alerte pe frecvența rotației: mai mult de 10 rotații pe oră — motiv de verificare.

Sistemele de monitorizare (Prometheus, Grafana, Datadog) pot urmări metricile de rotație prin exportatori de sistem de fișiere. Prometheus node_exporter furnizează metrici de dimensiune a fișierelor și timp de modificare. Pe dispozitivele mobile, monitorizarea rotației este de obicei încorporată în SDK: CocoaLumberjack înregistrează evenimentul de rotație prin DDLog, iar Logback trimite starea prin appender.

Alerte: dacă arhivele sunt mai multe decât era de așteptat (rotate count a depășit limita) sau volumul total al logurilor a depășit cota — sistemul trebuie să notifice administratorul. Pentru servere, pragul standard este 80% din dimensiunea partiției, pentru dispozitivele mobile — alertă la depășirea a 50 MB per aplicație.