Como Usar o journalctl - Guia de Investigação de Logs no Linux

2025-12-16 Tempo de leitura: Cerca de 10 min Dificuldade: Intermediário+

O Que Você Vai Aprender

• Você supera a confusão "onde estão os logs?" no Ubuntu.
• Você usa o journalctl para encontrar rapidamente a causa de uma falha de serviço.
• Você aplica os padrões práticos: "ver apenas recentes", "filtrar por tempo", "acompanhar enquanto reproduz".
• Você confirma OOM e erros de kernel a partir do log do kernel.

0. O Que é o journalctl? (Mínimo)

Conclusão: journalctl lê os logs do journald do systemd onde eventos de inicialização e OOM aparecem.

No Ubuntu, logs de serviços podem não estar em arquivos (/var/log/~) mas coletados no journald (journal). journalctl é o comando para ler esse "log agregado".

Antes de tudo, os termos.

1. Primeiro, Identifique o Nome do Serviço (Muitos Travam Aqui)

Conclusão: Identifique o nome exato do serviço primeiro; systemctl status revela com segurança.

Exemplos:

• nginx -> nginx
• apache -> apache2
• ssh -> ssh
• php-fpm -> php8.1-fpm, etc. (varia por ambiente)

Verifique o status primeiro para confirmar o nome:

$ sudo systemctl status nginx

O nome do serviço aparece nesta saída.

2. Ver "Apenas Recentes" (Mais Usado por Iniciantes)

Conclusão: Execute journalctl -u <service> -n 200 para logs recentes; 200 linhas é um bom início.

O -u significa "apenas os logs deste serviço (unidade)". O -n 200 significa "apenas as últimas 200 linhas".

2-1. Últimas 200 Linhas (Serviço Específico)

$ sudo journalctl -u nginx -n 200

Dec 15 13:02:11 web01 systemd[1]: Starting A high performance web server and a reverse proxy server...
Dec 15 13:02:11 web01 systemd[1]: Started A high performance web server and a reverse proxy server.
Dec 15 13:41:55 web01 nginx[1234]: 2025/12/15 13:41:55 [error] 1234#1234: *12 open() "/var/www/html/missing.html" failed (2: No such file or directory)

Cada linha traz: data e hora, hostname, nome do processo com o PID e a mensagem.

Para Apache:

$ sudo journalctl -u apache2 -n 200

2-2. Mais Curto (Últimas 50 Linhas)

$ sudo journalctl -u nginx -n 50

3. "Acompanhar Enquanto Reproduz" é o Mais Poderoso (-f)

Conclusão: Use journalctl -u <service> -f e reproduza em outra aba para encontrar causas rapidamente.

Este é o caminho mais rápido até a causa.

$ sudo journalctl -u nginx -f

O -f (follow) continua acrescentando na tela cada nova linha de log que chega. Pressione Ctrl+C para sair. Você está apenas lendo, então sair não afeta o serviço.

Reproduza com curl ou navegador em outra aba -> observe o log. Isso geralmente revela a causa imediatamente.

4. Filtrar por Tempo (Torna a Investigação Muito Mais Rápida)

Conclusão: Filtre por tempo com --since/--until quando souber quando o problema começou.

Se você sabe "quando quebrou", sempre filtre por tempo.

4-1. Última Hora

$ sudo journalctl -u nginx --since "1 hour ago"

4-2. Apenas Hoje

$ sudo journalctl -u nginx --since "today"

4-3. Faixa de Tempo Específica

$ sudo journalctl -u nginx --since "2025-12-15 13:00" --until "2025-12-15 14:00"

5. Encontrar Apenas Linhas de Erro (Filtrar por Prioridade com -p)

Conclusão: Filtre por prioridade com -p err primeiro e, se faltar, acrescente o grep por texto.

5-1. Filtrar por prioridade (o jeito próprio do journalctl)

O journalctl registra uma prioridade para cada linha de log. Esse dado é separado do texto da mensagem, então o -p filtra de forma mecânica.

$ sudo journalctl -u nginx -p err --since "today"

Os oito níveis, do mais grave ao menos grave, são emerg / alert / crit / err / warning / notice / info / debug. O -p err mostra apenas linhas de err para cima. Ele pega até linhas de erro que nunca escrevem a palavra "error".

5-2. Filtrar por texto (junto com o grep)

Quando o -p ainda deixa muita coisa, restrinja por texto.

$ sudo journalctl -u nginx --since "today" | grep -iE "error|fail|fatal|panic|denied|refused|timeout"

O grep -i ignora maiúsculas e minúsculas, e o -E habilita a sintaxe | (ou).

6. Problemas no Nível do SO: OOM / Logs do Kernel (Frequentemente Decisivo)

Conclusão: Crashes de apps podem esconder problemas de OOM ou kernel; verifique com journalctl -k.

Quando apps travam, processos morrem, 502s aumentam... OOM Killer (falta de memória) ou problemas de kernel podem estar por trás.

O OOM Killer é o mecanismo do Linux que encerra à força um processo quando a memória acaba. "OOM" vem de Out Of Memory (falta de memória), e o log do próprio app pode não mostrar nada.

6-1. Logs do Kernel (-k)

$ sudo journalctl -k -n 200

6-2. Encontrar Apenas OOM

$ sudo journalctl -k | grep -i oom | tail -n 50
$ sudo journalctl -k | grep -i "killed process" | tail -n 50

7. Investigando "Falha na Inicialização" (Comum)

Conclusão: Em falhas de inicialização, leia systemctl status e journal juntos; -b limita o escopo.

Quando o serviço não inicia, verifique status e journal juntos:

7-1. status (Resumo)

$ sudo systemctl status nginx

7-2. Logs Recentes de Inicialização (Serviço Específico)

$ sudo journalctl -u nginx -n 200

7-3. Apenas Boot Atual (-b)

Logs "desde o boot atual" apenas:

$ sudo journalctl -u nginx -b -n 200

8. Erros Comuns e Soluções

Conclusão: Sem logs, muitos logs ou grep vazio são típicos; adicione sudo, filtre, leia logs brutos.

8-1. "Nenhum Log Aparecendo"

• O serviço não envia saída para o journald (apenas logs em arquivo)
• Permissões insuficientes para leitura

Soluções:

• Adicione sudo
• Para Nginx/Apache, verifique também /var/log/nginx/ ou /var/log/apache2/

8-2. "Muitos Logs Para Pesquisar"

Soluções:

• Use --since para filtro de tempo
• Use -n para limite de linhas
• Use -u para filtro de unidade
• Reproduza + -f (mais rápido)

8-3. "grep Não Encontra Nada" Mas Ainda Está Quebrado

Soluções:

• Condições do grep muito restritas - primeiro verifique logs brutos com -n 200
• Verifique linhas de erro na saída do status

9. Quando os Logs Somem Após um Reboot

Conclusão: Alguns servidores não guardam o journal entre reboots; journalctl -b -1 mostra isso.

"Os logs sumiram depois do reboot" costuma se resumir a onde o journald guarda os dados. O journald grava em /run/log/journal (na memória, apagado no reboot) ou em /var/log/journal (em disco, mantido entre reboots).

Comece verificando se a inicialização anterior ainda pode ser lida.

$ sudo journalctl -b -1 -n 20

Se a inicialização anterior aparecer, os logs são persistidos. Se a resposta indicar que essa inicialização não foi encontrada, aquele servidor não guarda o journal entre reboots.

$ sudo journalctl -u nginx -n 2000 > ~/nginx-journal-$(date +%Y%m%d).log

10. Checklist de Investigação

Conclusão: Estado, recorte, fuso horário, log do kernel e preservação encerram a investigação.

• [ ] Você conferiu o estado atual com systemctl status <service>
• [ ] Você recortou com -u e limitou o intervalo com -n ou --since
• [ ] Você confirmou o fuso horário com timedatectl e o alinhou com o horário do incidente
• [ ] Você checou journalctl -k em busca de OOM e erros de kernel
• [ ] Você gravou em arquivo os logs necessários

# 1) Verifique o status primeiro
sudo systemctl status <service>

# 2) Logs recentes
sudo journalctl -u <service> -n 200

# 3) Acompanhar enquanto reproduz (mais poderoso)
sudo journalctl -u <service> -f

# 4) Apenas hoje
sudo journalctl -u <service> --since "today"

# 5) Nivel do SO (OOM, etc.)
sudo journalctl -k | grep -i oom | tail -n 50
sudo journalctl -k | tail -n 200