Como Usar o journalctl - Guia de Investigacao de Logs no Linux

Como Usar o journalctl - Guia de Investigacao de Logs no Linux
Tempo de leitura: Cerca de 10 min Dificuldade: Intermediate

O Que Voce Vai Aprender

  • Superar a confusao "onde estao os logs?" no Ubuntu
  • Usar journalctl para encontrar rapidamente causas de falha de servicos
  • Dominar padroes praticos: "ver apenas recentes", "filtrar por tempo", "acompanhar enquanto reproduz"

Resumo Rapido

Para investigacao de incidentes, geralmente comece com estes:

  1. Verificar se o servico morreu: systemctl status <service>
  2. Logs recentes: journalctl -u <service> -n 200
  3. Acompanhar enquanto reproduz: journalctl -u <service> -f
  4. Problemas no nivel do SO (OOM, etc.): journalctl -k | grep -i oom

Pre-requisitos

  • SO: Ubuntu
  • Publico: Iniciantes em servidores
  • Ambiente systemd (maioria dos servidores Ubuntu)
  • Acesso sudo (alguns logs podem nao ser visiveis sem ele)

0. O Que e o journalctl? (Minimo)

Conclusao: journalctl le os logs do journald do systemd onde eventos de inicializacao e OOM aparecem.

No Ubuntu, logs de servicos podem nao estar em arquivos (/var/log/~) mas coletados no journald (journal). journalctl e o comando para ler esse "log agregado".

Nginx/Apache tambem tem logs em arquivo, mas "falha na inicializacao do servico", "erro de configuracao", "morto por OOM" frequentemente aparecem no journal.

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

Conclusao: Identifique o nome exato do servico primeiro; systemctl status revela com seguranca.

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 servico aparece nesta saida.

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

Conclusao: Execute journalctl -u <service> -n 200 para logs recentes; 200 linhas e um bom inicio.

2-1. Ultimas 200 Linhas (Servico Especifico)

$ sudo journalctl -u nginx -n 200

Para Apache:

$ sudo journalctl -u apache2 -n 200

2-2. Mais Curto (Ultimas 50 Linhas)

$ sudo journalctl -u nginx -n 50

Comece com 200 linhas. Poucas demais e "o erro principal nao aparece" acontece frequentemente.

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

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

Este e o caminho mais rapido ate a causa.

$ sudo journalctl -u nginx -f

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

4. Filtrar por Tempo (Torna a Investigacao Muito Mais Rapida)

Conclusao: Filtre por tempo com --since/--until quando souber quando o problema comecou.

Se voce sabe "quando quebrou", sempre filtre por tempo.

4-1. Ultima Hora

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

4-2. Apenas Hoje

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

4-3. Faixa de Tempo Especifica

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

5. Encontrar Apenas Linhas de Erro (Alta Prioridade)

Conclusao: Quando os logs sao barulhentos, use grep -iE para error, fail e palavras similares primeiro.

Quando os logs sao muitos, primeiro filtre por "strings semelhantes a erro":

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

grep nao e perfeito mas e otimo para investigacao inicial.

6. Problemas no Nivel do SO: OOM / Logs do Kernel (Frequentemente Decisivo)

Conclusao: 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 memoria) ou problemas de kernel podem estar por tras.

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 Inicializacao" (Comum)

Conclusao: Em falhas de inicializacao, leia systemctl status e journal juntos; -b limita o escopo.

Quando o servico nao inicia, verifique status e journal juntos:

7-1. status (Resumo)

$ sudo systemctl status nginx

7-2. Logs Recentes de Inicializacao (Servico Especifico)

$ 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

-b significa "desde o boot atual".

8. Erros Comuns e Solucoes

Conclusao: Sem logs, muitos logs ou grep vazio sao tipicos; adicione sudo, filtre, leia logs brutos.

8-1. "Nenhum Log Aparecendo"

  • O servico nao envia saida para o journald (apenas logs em arquivo)
  • Permissoes insuficientes para leitura

Solucoes:

  • Adicione sudo
  • Para Nginx/Apache, verifique tambem /var/log/nginx/ ou /var/log/apache2/

8-2. "Muitos Logs Para Pesquisar"

Solucoes:

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

8-3. "grep Nao Encontra Nada" Mas Ainda Esta Quebrado

Solucoes:

  • Condicoes do grep muito restritas - primeiro verifique logs brutos com -n 200
  • Verifique linhas de erro na saida do status

Coisas a Evitar

  • Reiniciar spam e limpar logs - Logs desaparecem e a causa fica invisivel. Primeiro journalctl -u <service> -n 200.
  • Ler tudo sem filtro de tempo - Perde tempo. --since sozinho melhora dramaticamente a produtividade.
  • Verificar apenas logs do app, ignorar SO - Problemas de OOM e kernel nao aparecem nos logs do app. Sempre use journalctl -k.

Template Copiar e Colar

# 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

Proximas Leituras