Log Rotation: cómo funciona, estrategias de rotación y configuración para proyectos móviles

Qué es Log Rotation

Log Rotation es el proceso de cambiar periódicamente el archivo de registro activo por uno nuevo, archivando, comprimiendo o eliminando el anterior. Sin rotación, un solo archivo de registro crece indefinidamente hasta llenar toda la partición del disco, lo que provoca fallos en la aplicación y pérdida de datos.

Escenario típico: una aplicación escribe registros en el archivo app.log. Cuando app.log alcanza 100 MB, el sistema lo renombra a app.log.1, lo comprime a app.log.1.gz y crea un nuevo app.log vacío. En el siguiente llenado, app.log.1 pasa a ser app.log.2, app.log.1.gz pasa a app.log.2.gz y el antiguo app.log.2.gz se elimina. Este mecanismo se llama rotación con keep count — el número de copias de archivo es fijo.

Según Splunk (2023), la configuración incorrecta de rotación es la causa del 40% de los incidentes relacionados con el agotamiento del espacio en disco en servidores de aplicaciones. Para dispositivos móviles, la rotación es aún más crítica porque el usuario no puede ni debe gestionar los registros manualmente.

Estrategias de rotación de registros

Log Rotation admite tres estrategias básicas que se pueden combinar. La elección de la estrategia depende del tipo de aplicación: los sistemas servidores suelen usar rotación por tiempo, los móviles por tamaño y los sistemas embebidos por cantidad de archivos.

Rotación por tamaño — la más común

La rotación por tamaño garantiza que ningún archivo de registro supere un límite determinado. El límite se elige según el espacio disponible en disco y la frecuencia de registro. Para un servidor, el límite típico es de 100–500 MB por archivo, para un dispositivo móvil — de 1–10 MB. Si la aplicación registra de forma agresiva, el límite debe reducirse, de lo contrario la rotación ocurrirá cada pocos minutos.

Rotación por tiempo — para cumplimiento normativo

La rotación por tiempo es independiente del volumen de registros — el archivo se cambia estrictamente según un horario. Es conveniente para sistemas donde los registros deben almacenarse un número fijo de días: rotación diaria con keep count = 30 significa 30 días de almacenamiento. La desventaja — un solo archivo puede crecer hasta un gigabyte por día bajo carga intensiva.

logrotate en Linux: configuración y ejemplos

logrotate es la utilidad estándar de Linux para la rotación automática de registros. Se ejecuta mediante cron y procesa archivos de configuración de /etc/logrotate.d/. Cada servicio (nginx, postgresql, aplicación) crea su propia configuración especificando las rutas de los registros, la estrategia de rotación y las acciones posteriores a la rotación.

# /etc/logrotate.d/myapp — rotación de registros de la aplicación
/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
}

Esta configuración rota los registros diariamente, conserva 7 copias de archivo, comprime los archivos antiguos con gzip (excepto el último — delaycompress), no genera error si faltan registros (missingok), no rota archivos vacíos (notifempty) y recrea el archivo con permisos 0640. Después de la rotación, envía una señal HUP al proceso de la aplicación mediante un script postrotate.

Parámetros de logrotate

size — rotación al alcanzar un tamaño (size 100M). rotate — número de copias de archivo (rotate 7). compress — compresión gzip. dateext — añade la fecha al nombre del archivo en lugar de un número secuencial. sharedscripts — ejecuta postrotate una vez para todos los archivos, no para cada uno individualmente. maxage — elimina archivos más antiguos de N días.

Log Rotation en aplicaciones móviles

En dispositivos móviles, Log Rotation es crítica porque el usuario no gestiona el sistema de archivos y no espera que la aplicación ocupe gigabytes con registros. iOS y Android tienen mecanismos integrados: os_log en iOS usa un búfer circular de tamaño fijo (rotación por sobrescritura), Android Logcat tiene un búfer limitado en el kernel.

Para registros de archivo personalizados en iOS se usa CocoaLumberjack con la clase DDFileLogger, que admite rotación por tamaño y por tiempo. En Android — Logback o implementaciones personalizadas mediante RollingFileAppender. Ambas herramientas permiten establecer el tamaño máximo de archivo y la cantidad de archivos.

// CocoaLumberjack — rotación de archivos en iOS
import CocoaLumberjack

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

iOS: os_log no requiere rotación — los mensajes se sobrescriben en el búfer circular. Pero si la aplicación escribe registros de archivo personalizados (para depuración o envío al servidor), la rotación debe configurarse manualmente. CocoaLumberjack es la opción estándar para equipos iOS — comprime automáticamente los archivos a .gz y elimina los antiguos al superar el límite.

Por qué la rotación es importante en Android

Android no restringe a las aplicaciones la escritura de registros en su propio directorio. Si un desarrollador escribe registros de depuración en un archivo sin rotación, en un mes de uso activo pueden ocupar de 500 MB a 1 GB. El usuario descubrirá el problema cuando el sistema muestre una advertencia de espacio insuficiente y eliminará la aplicación. Logback con RollingFileAppender resuelve este problema: un límite de 5 MB con 3 archivos garantiza que los registros nunca superen los 20 MB.

Ejemplos de implementación de rotación en iOS y Android

A continuación se muestran ejemplos de configuración de rotación de registros en ambas plataformas. En iOS se usa CocoaLumberjack, en Android — Logback con configuración XML.

// Logback en Android — configuración de rotación en logback.xml
// Tamaño de archivo 5MB, 3 copias de archivo
@file:Suppress("unused")

// En 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 en iOS admite no solo la rotación por tamaño sino también la eliminación de registros antiguos por fecha mediante logFileManager.maximumLogFiles. Si se establece maximumLogFiles = 0, el límite se elimina — los registros se acumularán indefinidamente, lo cual es peligroso para producción.

// Rotación personalizada con verificación de volumen 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 {
            // Eliminar el archivo más antiguo
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Monitoreo y alertas en la rotación

Log Rotation no solo es archivado automático sino también un indicador de salud del sistema. Si los registros rotan con demasiada frecuencia (cada pocos minutos), es una señal de registro excesivo o de un bucle de registro de errores. Configure alertas sobre la frecuencia de rotación: más de 10 rotaciones por hora es motivo de revisión.

Los sistemas de monitoreo (Prometheus, Grafana, Datadog) pueden rastrear métricas de rotación mediante exportadores del sistema de archivos. Prometheus node_exporter proporciona métricas de tamaño de archivos y tiempo de modificación. En dispositivos móviles, el monitoreo de rotación suele estar integrado en el SDK: CocoaLumberjack registra el evento de rotación mediante DDLog, y Logback envía el estado a través de un appender.

Alertas: si hay más archivos de los esperados (el recuento de rotación superó el límite) o el volumen total de registros superó la cuota — el sistema debe notificar al administrador. Para servidores, el umbral estándar es el 80% del tamaño de la partición; para dispositivos móviles — una alerta cuando se superan los 50 MB por aplicación.