Logs Consumindo Disco? Como Controlar e Limpar o Linux

Introdução

Um dos problemas mais comuns e frustrantes para administradores de sistemas é encontrar o sistema de arquivos 100% cheio. Certamente, quando isso acontece, os serviços param de responder e os bancos de dados podem corromper. Na maioria das vezes, o culpado oculto são os logs consumindo disco.

Embora os registros de eventos sejam vitais para a resolução de problemas, eles podem se tornar inimigos da estabilidade se não forem limitados. Portanto, neste artigo, exploraremos profundamente como o Linux gerencia esses dados. Além disso, veremos como você pode configurar políticas de retenção rigorosas para manter seu servidor saudável.

Logs crescendo rapidamente podem indicar problemas maiores no sistema. Para entender o cenário completo, veja o guia de performance de servidores Linux

Parte 1: O Sistema Moderno – Entendendo o Systemd Journal

Antigamente, quase todos os logs eram arquivos de texto simples em /var/log. Hoje, a maioria das distribuições modernas (Ubuntu, Debian, CentOS, Fedora) utiliza o systemd-journald.

Antigamente, quase todos os logs eram arquivos de texto simples. Atualmente, contudo, a maioria das distribuições modernas utiliza o systemd-journald.

1.1 Por que o Journald cresce tanto?

O Journal armazena dados em formato binário, o que permite buscas muito mais rápidas. No entanto, por padrão, ele pode ocupar até 10% do tamanho da sua partição. Dessa forma, se você tem um disco de 100GB, o sistema pode permitir Gigabytes de logs consumindo disco antes de iniciar qualquer limpeza automática.

1.2 Comandos de Limpeza Imediata

Caso você esteja em uma emergência, não tente deletar os arquivos manualmente. Em vez disso, use as ferramentas nativas para liberar espaço com segurança:

Por tamanho: sudo journalctl --vacuum-size=200M
Por tempo: sudo journalctl --vacuum-time=3d

Com o intuito de resolver o problema definitivamente, você deve editar o arquivo de configuração do daemon em /etc/systemd/journald.conf.

1.3 Configuração Permanente do Journald

Para resolver o problema de logs consumindo disco definitivamente, você deve editar o arquivo de configuração do daemon.

Abra o arquivo: sudo nano /etc/systemd/journald.conf
Descomente e altere as seguintes variáveis:
- SystemMaxUse=500M (Limite total no disco)
- SystemMaxFileSize=50M (Tamanho máximo de cada arquivo individual de log)
- MaxRetentionSec=1month (Tempo máximo de retenção)

Após salvar, aplique as mudanças: sudo systemctl restart systemd-journald

O acúmulo de logs pode afetar diretamente o desempenho do servidor. Confira como melhorar a performance de servidores Linux.

Parte 2: O Papel Crucial do Logrotate

Enquanto o Journal cuida do sistema, aplicações como Nginx e MySQL escrevem em arquivos de texto plano. Nesse sentido, quem evita que esses arquivos fiquem gigantes é o Logrotate.

2.1 Como o Logrotate funciona na prática?

O Logrotate é um utilitário executado periodicamente para rotacionar os arquivos. Ou seja, ele renomeia o log atual, cria um novo e compacta os antigos. Consequentemente, se o seu Logrotate estiver mal configurado, você terá arquivos de texto massivos gerando logs consumindo disco.

2.2 Anatomia de uma configuração de sucesso

As configurações ficam em /etc/logrotate.d/. Um exemplo de configuração ideal para economizar espaço seria:

Plaintext

/var/log/nginx/*.log {
    daily
    missingok
    rotate 7
    compress
    delaycompress
    notifempty
    create 0640 www-data adm
}

daily: Rotaciona todo dia.
rotate 7: Mantém apenas 7 dias. O oitavo dia é deletado.
compress: Usa gzip para reduzir o tamanho em até 90%.
notifempty: Não rotaciona se o arquivo estiver vazio, poupando processamento.

Parte 3: Investigação Avançada – Onde estão os logs?

Muitas vezes, você sabe que há logs consumindo disco, mas não sabe quais. Em servidores com múltiplos sites ou aplicações, a estrutura de pastas pode ser vasta.

O crescimento excessivo de logs pode estar ligado a falhas ou configurações incorretas. Veja a estratégia de otimização de servidores Linux.

3.1 Usando o NCDU para Visualização Rápida

O ncdu (NCurses Disk Usage) é a melhor ferramenta para um SysAdmin. Ele permite navegar pelas pastas e ver em tempo real o que está pesando.

Instalação: sudo apt install ncdu ou sudo dnf install ncdu
Execução: sudo ncdu /var/log

Com ele, você pode identificar rapidamente se o problema está no /var/log/apache2, no /var/log/mysql ou em logs de sistemas de terceiros.

3.2 O Comando Find para Logs Antigos

Se você tem muitos arquivos pequenos que somados estão causando logs consumindo disco, o comando find é seu bisturi:

Bash

# Encontra arquivos de log maiores que 100MB criados há mais de 30 dias
sudo find /var/log -type f -name "*.log" -size +100M -mtime +30

3.3 Arquivos Deletados, mas Espaço Ocupado (O Fantasma)

Este é um erro clássico: você deleta um arquivo de log gigante com rm, mas o comando df -h continua mostrando o disco cheio. Por que? No Linux, se um processo (como o Nginx) ainda estiver com o arquivo aberto, o espaço só é liberado quando o processo morre ou é reiniciado.

Para encontrar esses “arquivos fantasmas”: sudo lsof +L1

Se vir um log na lista, reinicie o serviço correspondente: sudo systemctl restart nginx

Parte 4: Docker e a Explosão de Logs em Containers

Além dos serviços tradicionais, o uso de containers trouxe novos desafios. Isso ocorre porque o Docker captura toda a saída padrão e a armazena em arquivos JSON no host. Se não houver um limite definido, esses arquivos crescerão indefinidamente.

Por esse motivo, é fundamental configurar o max-size no arquivo daemon.json. Afinal, prevenir o crescimento desordenado é muito mais eficiente do que limpar o disco após um travamento do sistema.

4.1 O Perigo do JSON-File padrão

Sem configuração, esses arquivos crescem até o infinito. Eles ficam escondidos em: /var/lib/docker/containers/<ID-DO-CONTAINER>/<ID>-json.log

4.2 Configurando Limites no Docker (Daemon.json)

Para evitar que containers causem logs consumindo disco, você deve configurar o driver de log globalmente. Edite ou crie o arquivo /etc/docker/daemon.json:

JSON

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Isso garante que cada container tenha no máximo 3 arquivos de log de 10MB cada. (Requer reiniciar o Docker: sudo systemctl restart docker)

Parte 5: Aplicações Web e Banco de Dados (PHP, MariaDB, MySQL)

Muitas vezes o culpado não é o sistema, mas a aplicação.

5.1 Logs de Erros de PHP-FPM

Aplicações WordPress ou frameworks mal otimizados podem gerar milhares de avisos por minuto. Se o seu php-error.log está com logs consumindo disco, verifique o arquivo php.ini:

display_errors = Off
log_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT (Filtre o que é realmente necessário).

5.2 MariaDB/MySQL: O Log Binário (binlog)

O log binário é essencial para replicação, mas pode devorar o disco. No my.cnf, controle a retenção:

Disco cheio impacta toda a aplicação. Veja como melhorar a performance do servidor Linux.

Parte 6: Automação e Monitoramento Preventivo

Não basta saber limpar; um administrador de sistemas eficiente configura o servidor para que ele se autogestione ou, no mínimo, avise antes do desastre ocorrer. Ter logs consumindo disco em excesso é um problema que pode ser antecipado com scripts simples.

6.1 Script Bash de Alerta de Disco

Você pode criar um script cron que verifica o uso da partição /var/log e envia um alerta (via e-mail ou Telegram) se ultrapassar um limite.

#!/bin/bash
# Script para monitorar logs consumindo disco
THRESHOLD=80
EMAIL="admin@seu-dominio.com"
DISK_USAGE=$(df /var | grep / | awk '{ print $5 }' | sed 's/%//g')

if [ [ $DISK_USAGE -gt $THRESHOLD ] ]; then
    echo "Alerta: O uso de disco na partição de logs atingiu ${DISK_USAGE}%" | mail -s "Uso de Disco Crítico" $EMAIL
fi

#!/bin/bash
# Script para monitorar logs consumindo disco
THRESHOLD=80
EMAIL="admin@seu-dominio.com"
DISK_USAGE=$(df /var | grep / | awk '{ print $5 }' | sed 's/%//g')

if [ [ $DISK_USAGE -gt $THRESHOLD ] ]; then
    echo "Alerta: O uso de disco na partição de logs atingiu ${DISK_USAGE}%" | mail -s "Uso de Disco Crítico" $EMAIL
fi

6.2 O uso de Quotas de Disco

Em ambientes multi-usuário, você pode aplicar quotas de disco na pasta /var/log. Embora seja uma medida extrema, ela impede que um único serviço derrube o sistema inteiro ao gerar logs consumindo disco de forma desenfreada.

O crescimento de logs deve ser analisado junto com outras métricas. Veja também:

Parte 7: Arquitetura de Log Centralizado (A Solução Definitiva)

Se você gerencia múltiplos servidores, a melhor estratégia para evitar logs consumindo disco localmente é enviá-los para um servidor de logs dedicado (Syslog Server) ou uma stack ELK (Elasticsearch, Logstash, Kibana).

7.1 Configurando o Rsyslog para Envio Remoto

O rsyslog já vem instalado na maioria das distros. Para enviar logs para um servidor central e limpar o disco local mais rápido:

Edite o arquivo /etc/rsyslog.conf.
Adicione a linha para o servidor remoto:
*.* @192.168.1.50:514 (Para UDP)
ou
*.* @@192.168.1.50:514 (Para TCP).
Após garantir que os logs estão no servidor central, você pode reduzir a retenção local no Logrotate para apenas 1 ou 2 dias.

Parte 8: Erros Comuns ao Lidar com Logs no Linux

Muitos profissionais cometem falhas básicas ao tentar resolver o problema de logs consumindo disco. Evite estes cenários:

Deletar o diretório de log: Nunca use rm -rf /var/log/apache2. Muitos serviços não conseguem recriar a pasta com as permissões corretas (como www-data) e param de iniciar após um reboot.
Ignorar o Log de Auditoria: O auditd pode gerar logs massivos em sistemas com muitas chamadas de arquivo. Verifique /var/log/audit/audit.log.
Logs de Debug ativos em Produção: Verifique se o seu CMS (WordPress, Magento, Laravel) não ficou com o modo DEBUG ativado. Isso é a causa principal de logs consumindo disco em servidores de hospedagem.

Parte 9: Checklist de Manutenção (Resumo para o SysAdmin)

Para manter seu servidor saudável e longe de problemas com logs consumindo disco, siga este checklist mensal:

[ ] Testar a rotação de logs para garantir que a compressão está ativa.

[ ] Executar journalctl --vacuum-size=500M.

[ ] Verificar se há arquivos .gz antigos no /var/log que podem ser movidos para um storage externo.

[ ] Validar a configuração do daemon.json do Docker.

[ ] Analisar o crescimento do banco de dados e seus logs binários.

Conclusão

Gerenciar logs consumindo disco é uma arte técnica que separa os administradores juniores dos seniores. Ao dominar o journalctl, o logrotate e as configurações específicas de aplicações como Docker e MySQL, você garante que seu servidor Linux permaneça online, rápido e, acima de tudo, com espaço disponível para o que realmente importa: os seus dados e aplicações.

Para evitar problemas recorrentes, é essencial otimizar o sistema como um todo. Consulte o guia de como otimizar servidores Linux.

FAQ

Por que os logs ocupam tanto espaço?

Porque, por padrão, muitos serviços registram cada evento. Sem limites configurados, esses arquivos crescem indefinidamente até lotar a partição /var.

Como ver o tamanho da pasta de logs?

Use o comando du -sh /var/log para ver o resumo do espaço ocupado.

É seguro deletar logs manualmente?

Não é recomendado usar rm. O ideal é usar ferramentas como journalctl --vacuum ou truncate para não travar processos ativos.

O que fazer quando o comando df -h mostra disco cheio, mas o du -sh não encontra os arquivos?

Provavelmente, você está lidando com arquivos deletados que ainda estão abertos por algum processo. Nesse caso, o Linux mantém o espaço reservado até que o serviço seja reiniciado. Para resolver, utilize o comando lsof +L1 para identificar o processo e, em seguida, reinicie o serviço correspondente para liberar o espaço físico.

Qual a diferença entre os logs no /var/log e o journalctl?

Embora ambos armazenem registros do sistema, eles funcionam de formas distintas. O /var/log geralmente contém arquivos de texto legíveis gerenciados pelo rsyslog e logrotate. Por outro lado, o journalctl acessa logs binários gerenciados pelo systemd. Portanto, para uma limpeza completa, é essencial configurar ambos os sistemas corretamente.

É seguro utilizar o comando truncate em arquivos de log ativos?

Certamente, o uso do truncate -s 0 /var/log/arquivo.log é a maneira mais segura de esvaziar um log sem interromper o serviço. Isso ocorre porque, ao contrário do comando rm, o truncate não remove o descritor de arquivo que o processo está usando. Consequentemente, o serviço continua escrevendo no arquivo normalmente, mas agora a partir do zero.

Como limitar os logs do Docker para que não lotem o HD?

Visto que o Docker não limita o tamanho dos logs por padrão, você deve configurar o driver de log no arquivo /etc/docker/daemon.json. Basta definir o max-size (ex: 10m) e o max-file (ex: 3). Dessa forma, você garante que cada container nunca ultrapasse um limite fixo de armazenamento.