Como configurar logs rotativos em aplicações Linux

1. Introdução aos logs rotativos e sua importância

Aplicações Linux geram logs continuamente — acessos HTTP, erros de banco de dados, mensagens de depuração, auditoria de segurança. Sem um sistema de gerenciamento, esses arquivos crescem indefinidamente, consumindo espaço em disco e podendo causar falhas catastróficas quando a partição atinge 100% de uso. Um serviço web que escreve 50 MB de logs por dia, por exemplo, ocupará cerca de 1,5 GB em um mês; em um ano, mais de 18 GB.

A rotação de logs resolve esse problema automatizando três operações essenciais: compressão (reduz o tamanho dos arquivos antigos), exclusão (remove logs após um período definido) e retenção (mantém um número controlado de versões históricas). A ferramenta padrão no ecossistema Linux é o logrotate, presente em praticamente todas as distribuições. Alternativas nativas incluem o journald do systemd e soluções como newsyslog (FreeBSD) ou scripts customizados com cron, mas o logrotate continua sendo a opção mais flexível e amplamente adotada para logs de aplicações.

2. Instalação e configuração básica do logrotate

Na maioria das distribuições modernas (Ubuntu, Debian, CentOS, Fedora), o logrotate já vem instalado. Para verificar:

logrotate --version

Os arquivos de configuração residem em dois locais principais:

  • /etc/logrotate.conf — configuração global (padrões aplicados a todos os logs)
  • /etc/logrotate.d/ — diretório com configurações específicas por aplicação

A estrutura básica de um arquivo de configuração segue este formato:

/var/log/minhaapp/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
}

Exemplo prático: Vamos configurar rotação diária para uma aplicação hipotética que escreve logs em /var/log/minhaapp/. Crie o arquivo /etc/logrotate.d/minhaapp:

/var/log/minhaapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    postrotate
        systemctl reload minhaapp.service > /dev/null 2>&1 || true
    endscript
}

Este exemplo rotaciona diariamente, mantém 14 versões comprimidas (comprimindo apenas após um dia, usando delaycompress), não gera erro se o arquivo estiver ausente (missingok), não rotaciona logs vazios (notifempty), recria o arquivo com permissões adequadas (create) e executa um script pós-rotação para recarregar o serviço.

3. Diretivas essenciais para controle de rotação

As diretivas mais importantes do logrotate incluem:

  • rotate N: Número máximo de arquivos rotacionados mantidos. Após atingir esse limite, o mais antigo é excluído.
  • size TAMANHO: Rotaciona quando o arquivo atinge um tamanho específico (ex.: size 100M). Substitui a periodicidade quando definida.
  • daily/weekly/monthly: Define a frequência da rotação.
  • compress/delaycompress: compress compacta imediatamente; delaycompress adia a compactação para a próxima rotação (útil se a aplicação ainda estiver escrevendo no arquivo).
  • copytruncate: Copia o conteúdo do arquivo para um novo e trunca o original (sem fechar/reabrir o arquivo). Essencial para aplicações que não reabrem seus descritores de arquivo.
  • postrotate/prerotate: Scripts executados após/antes da rotação. Comuns para reiniciar serviços ou notificar sistemas de monitoramento.

4. Configuração avançada: logs de aplicações customizadas

Aplicações modernas — Node.js, Python (com logging padrão), Java — frequentemente mantêm descritores de arquivo abertos durante toda a execução. Se o logrotate renomear o arquivo (movendo app.log para app.log.1), a aplicação continuará escrevendo no nome antigo, e os logs serão perdidos. A solução é usar copytruncate:

/var/log/minhaapp/app.log {
    size 50M
    rotate 10
    copytruncate
    compress
    missingok
    notifempty
}

Exemplo completo com múltiplos arquivos curinga:

Suponha uma aplicação Python que escreve logs separados por módulo em /var/log/minhaapp/:

/var/log/minhaapp/*.log {
    size 100M
    rotate 5
    compress
    delaycompress
    copytruncate
    missingok
    notifempty
    dateext
    dateformat -%Y%m%d-%s
    postrotate
        # Notificar sistema de monitoramento
        curl -s -o /dev/null http://monitor.local/logrotate/minhaapp
    endscript
}

A diretiva dateext adiciona a data ao nome do arquivo rotacionado (ex.: app.log-20250328-1712344567.gz), facilitando a localização temporal.

5. Testando e depurando a configuração do logrotate

Antes de aplicar qualquer configuração em produção, teste rigorosamente:

Modo debug (simula sem executar ações):

logrotate -d /etc/logrotate.d/minhaapp

A saída mostra quais arquivos seriam rotacionados, quais diretivas seriam aplicadas e possíveis erros de sintaxe.

Rotação forçada (executa imediatamente):

logrotate -f /etc/logrotate.d/minhaapp

Verificação de logs do próprio logrotate:

cat /var/log/logrotate.log
# ou, se o logrotate for gerenciado pelo systemd:
journalctl -u logrotate.service --since "1 hour ago"

Se a rotação não ocorrer conforme esperado, verifique:
- Permissões do diretório e arquivos (o logrotate geralmente roda como root)
- Se o arquivo de log está vazio (notifempty impede rotação)
- Conflitos com outras configurações em /etc/logrotate.d/

6. Integração com systemd e serviços modernos

Em sistemas que usam systemd, o journald gerencia logs do sistema com suas próprias políticas de rotação. Configure em /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=500M
MaxRetentionSec=7day
RuntimeMaxUse=50M

Para aplicações que rodam como serviços systemd, mantenha o logrotate como ferramenta principal, mas integre com o ciclo de vida do serviço:

/var/log/minhaapp/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 0640 appuser appgroup
    postrotate
        /bin/systemctl kill -s HUP minhaapp.service > /dev/null 2>&1 || true
    endscript
}

Boas práticas: Cada aplicação deve ter seu próprio arquivo de configuração em /etc/logrotate.d/, com logs separados por diretório. Evite configurações genéricas que afetem logs de múltiplas aplicações — isso dificulta a depuração e pode causar efeitos colaterais indesejados.

7. Monitoramento e boas práticas de retenção

Definir políticas de retenção exige equilíbrio entre conformidade (regulamentações como GDPR ou PCI-DSS podem exigir retenção mínima) e economia de espaço. Recomendações práticas:

  • Baseado em espaço: Use size em vez de daily quando o volume de logs for imprevisível. Ex.: size 200M com rotate 7 garante no máximo 1,4 GB de logs.
  • Baseado em tempo: Para logs de auditoria, monthly com rotate 12 mantém um ano de histórico.
  • Alertas automáticos: Configure um script cron ou systemd timer que verifique a última rotação:
#!/bin/bash
# Verificar se logs foram rotacionados nas últimas 24h
if [ $(find /var/log/minhaapp/ -name "*.log" -mmin -1440 | wc -l) -eq 0 ]; then
    echo "ALERTA: Logs de minhaapp não rotacionados!" | mail -s "Logrotate falhou" admin@exemplo.com
fi

Boas práticas finais:
- Teste toda configuração em ambiente de staging antes de aplicar em produção
- Documente cada configuração com comentários no próprio arquivo (use #)
- Evite rotação muito frequente (horária ou a cada poucos minutos) — aumenta overhead de I/O
- Monitore o espaço em disco com ferramentas como df -h e du -sh /var/log/
- Considere usar logrotate --state /var/lib/logrotate/status para ver o estado atual de cada arquivo

Com essas configurações, suas aplicações Linux manterão logs gerenciáveis, seguros e em conformidade com políticas de retenção, evitando surpresas desagradáveis de disco cheio.

Referências