Como e onde os logs são armazenados em um servidor

Publicado em 2026-09-12 por frfrand

Dónde busca cada cosa, qué cambió con journald, por qué un log sin rotación llena el disco, y los comandos que resuelven la mayoría de las búsquedas.

Quando algo falha, a resposta quase sempre já está escrita em algum lugar. O problema é saber em qual.

Dois sistemas convivendo

Em um Linux moderno, existem dois locais para os registros, e vale a pena entender a diferença.

journald (do systemd) armazena em um formato binário indexado, com metadados: de qual serviço vem cada linha, qual usuário, qual processo, com qual prioridade. É consultado com journalctl.

Os arquivos de texto em /var/log continuam existindo. Muitos serviços (nginx, por exemplo) escrevem seus próprios arquivos diretamente, e em muitas distribuições o rsyslog copia parte do journal para arquivos por compatibilidade.

Essa duplicação explica uma confusão frequente: a mesma mensagem pode aparecer nos dois lados.

Os comandos que vale a pena memorizar

Para um serviço:

journalctl -u miapp -f # ao vivo journalctl -u miapp --since "1 hour ago" journalctl -u miapp -n 200 # as últimas 200 linhas

Para erros do sistema:

journalctl -p err -S today

A opção -p filtra por prioridade, com a escala clássica do syslog: 0 emergência, 3 erro, 4 aviso, 6 informativo. Filtrar por err remove o ruído e mostra o que importa.

E para os arquivos de texto:

tail -f /var/log/nginx/error.log grep -i "timeout" /var/log/nginx/error.log | tail -50

Um atalho que economiza tempo

Se o nginx retornar 502, o problema quase nunca está no nginx: significa que sua aplicação não respondeu. O erro está no log da sua aplicação, não no do nginx.

Um 504 é diferente: sua aplicação respondeu, mas demorou mais do que o nginx esperava.

Saber essa diferença economiza muitas buscas no arquivo errado.

A rotação, e por que o disco enche

Um log cresce indefinidamente se ninguém o cortar. A rotação se encarrega disso: renomeia o arquivo, inicia um novo, comprime os antigos e exclui os que excedem a retenção.

Para arquivos de texto, quem faz isso é o logrotate, com sua configuração em /etc/logrotate.d/. Cada serviço deixa seu arquivo lá.

Para o journal, o limite se configura em /etc/systemd/journald.conf:

SystemMaxUse=500M

Sem esse limite, o journal pode crescer até ocupar um percentual considerável do disco.

E o comando que você vai querer no dia em que o disco encher:

journalctl --disk-usage journalctl --vacuum-time=7d # apaga o anterior a 7 dias

Dois detalhes que mordem

Um log rotado enquanto um processo o tem aberto. Se a rotação renomear o arquivo e o processo continuar escrevendo no descritor antigo, o espaço não é liberado e as novas linhas vão para um arquivo sem nome. Por isso a configuração de rotação inclui avisar o processo para reabrir seus arquivos. Quando você vê que o disco não é liberado após a rotação, costuma ser isso.

Os logs de aplicações em contêineres não vão para o journal por padrão: o motor de contêineres os captura. Se não configurar rotação lá, esses arquivos crescem sem controle. É uma causa muito frequente de discos cheios em servidores com Docker.

O que convém registrar

Mais não é melhor. Um log com tudo é tão inútil quanto um vazio, porque ninguém lê.

Três costumes que fazem os logs servirem:

• Um identificador por requisição, que apareça em todas as linhas relacionadas. Permite reconstruir o que aconteceu em um caso concreto.
• Formato estruturado (JSON) se for processá-los com ferramentas. Texto simples se for lê-los a olho nu.
• Nunca dados sensíveis. Senhas, tokens e dados pessoais não vão ao log. É uma das formas mais comuns de vazamento, e acontece quase sempre por uma sessão de depuração que ficou ligada.

No ArduMaker, os logs de cada serviço e de cada implantação são vistos no painel, com seu histórico, sem precisar entrar por SSH para buscá-los.