Log Rotation: como funciona, estratégias de rotação e configuração para projetos móveis

O que é Log Rotation

Log Rotation é o processo de trocar periodicamente o arquivo de log ativo por um novo, arquivando, compactando ou excluindo o antigo simultaneamente. Sem rotação, um único arquivo de log cresce indefinidamente até preencher toda a partição do disco, levando à falha do aplicativo e perda de dados.

Cenário típico: um aplicativo escreve logs no arquivo app.log. Quando app.log atinge 100 MB, o sistema o renomeia para app.log.1, compacta para app.log.1.gz e cria um novo app.log vazio. No próximo preenchimento, app.log.1 se torna app.log.2, app.log.1.gz se torna app.log.2.gz e o antigo app.log.2.gz é excluído. Esse mecanismo é chamado de rotação com keep count — o número de cópias de arquivo é fixo.

De acordo com Splunk (2023), a configuração incorreta de rotação é a causa de 40% dos incidentes relacionados ao esgotamento do espaço em disco em servidores de aplicativos. Para dispositivos móveis, a rotação é ainda mais crítica porque o usuário não pode e não deve gerenciar logs manualmente.

Estratégias de rotação de logs

Log Rotation suporta três estratégias básicas que podem ser combinadas. A escolha da estratégia depende do tipo de aplicativo: sistemas servidores geralmente usam rotação por tempo, móveis — por tamanho, embarcados — por quantidade de arquivos.

Rotação por tamanho — a mais comum

A rotação por tamanho garante que nenhum arquivo de log exceda um limite definido. O limite é escolhido com base no espaço disponível em disco e na frequência de registro. Para um servidor, o limite típico é de 100–500 MB por arquivo, para um dispositivo móvel — de 1–10 MB. Se o aplicativo registra de forma agressiva, o limite deve ser reduzido, caso contrário a rotação ocorrerá a cada poucos minutos.

Rotação por tempo — para conformidade

A rotação por tempo é independente do volume de logs — o arquivo é trocado estritamente de acordo com um cronograma. Conveniente para sistemas onde os logs devem ser armazenados por um número fixo de dias: rotação diária com keep count = 30 significa 30 dias de armazenamento. A desvantagem — um único arquivo pode crescer até um gigabyte por dia sob carga intensiva.

logrotate no Linux: configuração e exemplos

logrotate é o utilitário padrão do Linux para rotação automática de logs. Ele é executado via cron e processa arquivos de configuração de /etc/logrotate.d/. Cada serviço (nginx, postgresql, aplicativo) cria sua própria configuração especificando os caminhos dos logs, a estratégia de rotação e as ações pós-rotação.

# /etc/logrotate.d/myapp — rotação de logs do aplicativo
/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 configuração rotaciona os logs diariamente, mantém 7 cópias de arquivo, compacta os arquivos antigos com gzip (exceto o último — delaycompress), não emite erro se os logs estiverem ausentes (missingok), não rotaciona arquivos vazios (notifempty) e recria o arquivo com permissões 0640. Após a rotação, envia um sinal HUP para o processo do aplicativo através de um script postrotate.

Parâmetros do logrotate

size — rotação ao atingir um tamanho (size 100M). rotate — número de cópias de arquivo (rotate 7). compress — compressão gzip. dateext — adiciona a data ao nome do arquivo em vez de um número sequencial. sharedscripts — executa postrotate uma vez para todos os arquivos, não para cada um individualmente. maxage — exclui arquivos mais antigos que N dias.

Log Rotation em aplicativos móveis

Em dispositivos móveis, Log Rotation é crítica porque o usuário não gerencia o sistema de arquivos e não espera que o aplicativo ocupe gigabytes com logs. iOS e Android têm mecanismos integrados: os_log no iOS usa um buffer circular de tamanho fixo (rotação por sobrescrita), o Android Logcat tem um buffer limitado no kernel.

Para logs de arquivo personalizados no iOS, usa-se CocoaLumberjack com a classe DDFileLogger, que suporta rotação por tamanho e por tempo. No Android — Logback ou implementações personalizadas via RollingFileAppender. Ambas as ferramentas permitem definir o tamanho máximo do arquivo e o número de arquivos.

// CocoaLumberjack — rotação de arquivos no iOS
import CocoaLumberjack

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

iOS: os_log não requer rotação — as mensagens são sobrescritas no buffer circular. Mas se o aplicativo escreve logs de arquivo personalizados (para depuração ou envio ao servidor), a rotação deve ser configurada manualmente. CocoaLumberjack é a escolha padrão para equipes iOS — ele compacta automaticamente os arquivos para .gz e exclui os antigos ao exceder o limite.

Por que a rotação é importante no Android

Android não restringe os aplicativos de escrever logs em seu próprio diretório. Se um desenvolvedor escreve logs de depuração em um arquivo sem rotação, em um mês de uso ativo eles podem ocupar de 500 MB a 1 GB. O usuário descobrirá o problema quando o sistema mostrar um aviso de espaço insuficiente e excluirá o aplicativo. Logback com RollingFileAppender resolve esse problema: um limite de 5 MB com 3 arquivos garante que os logs nunca excedam 20 MB.

Exemplos de implementação de rotação no iOS e Android

Abaixo estão exemplos de configuração de rotação de logs em ambas as plataformas. No iOS usa-se CocoaLumberjack, no Android — Logback com configuração XML.

// Logback no Android — configuração de rotação em logback.xml
// Tamanho do arquivo 5MB, 3 cópias de arquivo
@file:Suppress("unused")

// Em 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 no iOS suporta não apenas rotação por tamanho, mas também exclusão de logs antigos por data usando logFileManager.maximumLogFiles. Se maximumLogFiles = 0 for definido, o limite é removido — os logs se acumularão indefinidamente, o que é perigoso para produção.

// Rotação personalizada com verificação de 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 {
            // Excluir o arquivo mais antigo
            files.sorted { $0.path < $1.path }.first.map {
                try? FileManager.default.removeItem(at: $0)
            }
        }
    }
}

Monitoramento e alertas na rotação

Log Rotation não é apenas arquivamento automático, mas também um indicador de saúde do sistema. Se os logs rotacionam com muita frequência (a cada poucos minutos), isso sinaliza registro excessivo ou um loop de registro de erros. Configure alertas sobre a frequência de rotação: mais de 10 rotações por hora é motivo para verificação.

Sistemas de monitoramento (Prometheus, Grafana, Datadog) podem rastrear métricas de rotação através de exportadores do sistema de arquivos. Prometheus node_exporter fornece métricas de tamanho de arquivos e tempo de modificação. Em dispositivos móveis, o monitoramento de rotação geralmente está integrado ao SDK: CocoaLumberjack registra o evento de rotação via DDLog, e Logback envia o status através de um appender.

Alertas: se houver mais arquivos do que o esperado (a contagem de rotação excedeu o limite) ou o volume total de logs excedeu a cota — o sistema deve notificar o administrador. Para servidores, o limite padrão é 80% do tamanho da partição; para dispositivos móveis — um alerta quando 50 MB por aplicativo são excedidos.