Log Rotation : fonctionnement, stratégies de rotation et configuration pour les projets mobiles

Qu'est-ce que Log Rotation

Log Rotation est le processus de changement périodique du fichier journal actif vers un nouveau, avec archivage, compression ou suppression de l'ancien fichier simultanément. Sans rotation, un seul fichier journal croît indéfiniment jusqu'à remplir toute la partition disque, entraînant une défaillance de l'application et une perte de données.

Scénario typique : une application écrit des logs dans le fichier app.log. Lorsque app.log atteint 100 Mo, le système le renomme en app.log.1, le compresse en app.log.1.gz et crée un nouveau app.log vide. Au prochain remplissage, app.log.1 devient app.log.2, app.log.1.gz devient app.log.2.gz et l'ancien app.log.2.gz est supprimé. Ce mécanisme s'appelle la rotation avec keep count — le nombre de copies d'archive est fixe.

Selon Splunk (2023), une configuration incorrecte de la rotation est la cause de 40% des incidents liés à l'épuisement de l'espace disque sur les serveurs d'applications. Pour les appareils mobiles, la rotation est encore plus critique car l'utilisateur ne peut pas et ne doit pas gérer les logs manuellement.

Stratégies de rotation des logs

Log Rotation prend en charge trois stratégies de base qui peuvent être combinées. Le choix de la stratégie dépend du type d'application : les systèmes serveurs utilisent plus souvent la rotation par temps, les mobiles — par taille, les systèmes embarqués — par nombre de fichiers.

Rotation par taille — la plus courante

La rotation par taille garantit qu'aucun fichier journal ne dépasse une limite définie. La limite est choisie en fonction de l'espace disque disponible et de la fréquence de journalisation. Pour un serveur, la limite typique est de 100–500 Mo par fichier, pour un appareil mobile — de 1–10 Mo. Si l'application journalise de manière agressive, la limite doit être réduite, sinon la rotation se produira toutes les quelques minutes.

Rotation par temps — pour la conformité

La rotation par temps est indépendante du volume de logs — le fichier est changé strictement selon un calendrier. Pratique pour les systèmes où les logs doivent être conservés pendant un nombre fixe de jours : rotation quotidienne avec keep count = 30 signifie 30 jours de conservation. L'inconvénient — un seul fichier peut atteindre un gigaoctet par jour sous charge intensive.

logrotate sous Linux : configuration et exemples

logrotate est l'utilitaire standard Linux pour la rotation automatique des logs. Il s'exécute via cron et traite les fichiers de configuration de /etc/logrotate.d/. Chaque service (nginx, postgresql, application) crée sa propre configuration spécifiant les chemins des logs, la stratégie de rotation et les actions post-rotation.

# /etc/logrotate.d/myapp — rotation des logs de l'application
/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
}

Cette configuration effectue une rotation quotidienne des logs, conserve 7 copies d'archive, compresse les anciens fichiers avec gzip (sauf le dernier — delaycompress), ne génère pas d'erreur si les logs sont absents (missingok), ne tourne pas les fichiers vides (notifempty) et recrée le fichier avec les permissions 0640. Après la rotation, elle envoie un signal HUP au processus de l'application via un script postrotate.

Paramètres de logrotate

size — rotation à l'atteinte d'une taille (size 100M). rotate — nombre de copies d'archive (rotate 7). compress — compression gzip. dateext — ajoute la date au nom du fichier au lieu d'un numéro séquentiel. sharedscripts — exécute postrotate une fois pour tous les fichiers, pas pour chacun individuellement. maxage — supprime les archives plus anciennes que N jours.

Log Rotation dans les applications mobiles

Sur les appareils mobiles, Log Rotation est critique car l'utilisateur ne gère pas le système de fichiers et ne s'attend pas à ce que l'application occupe des gigaoctets avec des logs. iOS et Android ont des mécanismes intégrés : os_log sur iOS utilise un tampon circulaire de taille fixe (rotation par écrasement), Android Logcat a un tampon limité dans le noyau.

Pour les logs de fichiers personnalisés sur iOS, on utilise CocoaLumberjack avec la classe DDFileLogger, qui prend en charge la rotation par taille et par temps. Sur Android — Logback ou des implémentations personnalisées via RollingFileAppender. Les deux outils permettent de définir la taille maximale du fichier et le nombre d'archives.

// CocoaLumberjack — rotation de fichiers sur iOS
import CocoaLumberjack

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

iOS : os_log ne nécessite pas de rotation — les messages sont écrasés dans le tampon circulaire. Mais si l'application écrit des logs de fichiers personnalisés (pour le débogage ou l'envoi au serveur), la rotation doit être configurée manuellement. CocoaLumberjack est le choix standard pour les équipes iOS — il compresse automatiquement les archives en .gz et supprime les anciens fichiers lorsque la limite est dépassée.

Pourquoi la rotation est importante sur Android

Android ne limite pas les applications dans l'écriture de logs dans leur propre répertoire. Si un développeur écrit des logs de débogage dans un fichier sans rotation, en un mois d'utilisation active, ils peuvent occuper de 500 Mo à 1 Go. L'utilisateur découvrira le problème lorsque le système affichera un avertissement d'espace insuffisant et supprimera l'application. Logback avec RollingFileAppender résout ce problème : une limite de 5 Mo avec 3 archives garantit que les logs ne dépassent jamais 20 Mo.

Exemples d'implémentation de rotation sur iOS et Android

Voici des exemples de configuration de rotation des logs sur les deux plateformes. Sur iOS, on utilise CocoaLumberjack, sur Android — Logback avec configuration XML.

// Logback sur Android — configuration de rotation dans logback.xml
// Taille du fichier 5 Mo, 3 copies d'archive
@file:Suppress("unused")

// Dans 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 sur iOS prend non seulement en charge la rotation par taille, mais aussi la suppression des anciens logs par date avec logFileManager.maximumLogFiles. Si maximumLogFiles = 0 est défini, la limite est supprimée — les logs s'accumuleront indéfiniment, ce qui est dangereux pour la production.

// Rotation personnalisée avec vérification du volume 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 {
            // Supprimer le fichier le plus ancien
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Surveillance et alertes lors de la rotation

Log Rotation n'est pas seulement un archivage automatique mais aussi un indicateur de santé du système. Si les logs tournent trop fréquemment (toutes les quelques minutes), cela signale une journalisation excessive ou une boucle de journalisation d'erreurs. Configurez des alertes sur la fréquence de rotation : plus de 10 rotations par heure justifie une vérification.

Les systèmes de surveillance (Prometheus, Grafana, Datadog) peuvent suivre les métriques de rotation via des exportateurs du système de fichiers. Prometheus node_exporter fournit des métriques de taille de fichier et de temps de modification. Sur les appareils mobiles, la surveillance de rotation est généralement intégrée au SDK : CocoaLumberjack enregistre l'événement de rotation via DDLog, et Logback envoie le statut via un appender.

Alertes : s'il y a plus d'archives que prévu (le compteur de rotation a dépassé la limite) ou si le volume total des logs a dépassé le quota — le système doit notifier l'administrateur. Pour les serveurs, le seuil standard est de 80% de la taille de la partition ; pour les appareils mobiles — une alerte lorsque 50 Mo par application sont dépassés.