journalctl explicado com exemplos: encontrar erros de um app Linux
Publicado em 2026-10-26 por frfrand
Buscar logs de serviços por unidade, prioridade e data com journalctl
Quando um app cai às três da manhã, a pergunta não é «qual comando reinicia tudo?». É «o que aconteceu logo antes?». journalctl permite consultar logs de serviços com filtros de tempo, unidade e prioridade.
Te mostro onde está o problema, como verificá-lo sem chutar e o que faria em um aplicativo que realmente tem usuários. Não é preciso decorar um manual inteiro para resolver uma falha específica.
O que significa journalctl na prática
O journal do systemd armazena eventos de aplicativos e serviços compatíveis. Pode ser filtrado por unidade (-u), inicialização (-b), prioridade (-p) e janelas temporais. A retenção depende da configuração e do espaço disponível.
Uma observação antes de acessar o servidor: se o projeto já está em produção, salve o estado que encontrou e verifique em qual usuário e máquina você vai executar os comandos. Trabalhar como root sem necessidade e mudar várias coisas de uma vez dificulta encontrar a causa de um erro.
Comandos úteis para começar
sudo journalctl -u miapp -n 100 --no-pager
sudo journalctl -u miapp --since '2026-10-26 09:00' --until '2026-10-26 10:00'
sudo journalctl -b -p err --no-pager
sudo journalctl -u miapp -f
sudo journalctl --disk-usageOs caminhos, nomes de unidades e domínios são exemplos. Adapte-os ao seu serviço. Se um comando exigir permissões de administrador, revise o que muda e por quê. As consultas de diagnóstico devem vir antes das modificações.
Passo a passo, com verificações
- Identifique o nome real da unidade que executa a aplicação.
- Busque a hora da falha e limite com
--sincee--until. - Siga primeiro o erro mais antigo da cadeia, não o último sintoma.
- Se houver vários serviços, compare os timestamps do Nginx, API e worker.
- Defina a retenção e evite registrar senhas ou dados pessoais.
Após cada passo, verifique um resultado observável: um status, um arquivo, uma resposta HTTP ou uma entrada de log. Se encontrar uma mensagem inesperada, salve-a para investigar em vez de ocultá-la com reinícios repetidos.
Exemplo real: uma aplicação que precisa ser mantida
Uma reserva retorna 500 apenas quando o usuário adiciona uma nota longa. Os logs mostram um erro de validação antes de qualquer conexão com o PostgreSQL: o problema não era o VPS nem o proxy.
Ao final, teste o caminho completo: acessar pelo domínio, chamar a API, gravar um dado de teste e verificar se a informação permanece após um reinício controlado. Um servidor que «arranca» nem sempre é uma aplicação que funciona.
Erros que vale a pena evitar
Se a aplicação armazena seus logs apenas em um arquivo próprio, o journalctl talvez não mostre todas as informações. Confirme onde são gravados stdout, stderr e logs estruturados.
Também é importante que as credenciais não terminem no histórico do terminal, logs, arquivos compartilhados ou capturas. Para usuários e serviços, use permissões mínimas e documente quem pode revogar o acesso.
Como o ArduMaker se encaixa neste cenário
No ArduMaker, a consulta de logs por VPS e processo ajuda a investigar sem reiniciar às cegas. Use essa evidência para criar incidentes com etapas de reprodução claras.
O ArduMaker pode ajudar você a administrar os VPSs, implantar repositórios e trabalhar com serviços, bancos de dados e domínios na mesma plataforma. Não substitui o que acabamos de explicar sobre o Linux: precisamente por isso convém entender o diagnóstico e ter uma forma de repeti-lo.
Quando convém automatizá-lo
Se a tarefa se repete, documente primeiro o procedimento manual e suas verificações. Depois considere um script ou uma tarefa agendada com erros visíveis, logs e permissões limitadas. Não automatize um comando que você ainda não sabe recuperar quando dá errado.
Perguntas frequentes
Posso testar sem afetar clientes? Em muitos casos, sim: um VPS de staging ou um serviço de teste separado permite validar a configuração antes de alterar a produção.
Como saber se ficou certo? Veja os logs e uma operação funcional, não apenas se o comando terminou com código zero.
Quando preciso de mais recursos? Quando as métricas indicarem saturação de CPU, RAM, disco ou conexões. Uma falha de configuração raramente se resolve contratando mais memória.
Referências
Em uma frase: primeiro entenda o erro, depois mude uma coisa concreta e verifique seu efeito. Essa disciplina economiza muitas horas de suporte.