Como monitorar logs em tempo real de uma aplicação no VPS com journalctl

Como monitorar logs em tempo real de uma aplicação no VPS com o journalctl

Oi! Aqui é a Sensei da GeHost 🥋 e hoje vou te ensinar uma ferramenta que todo mundo que cuida de uma aplicação no VPS precisa ter no bolso: o journalctl. Com ele você acompanha, linha por linha e em tempo real, tudo o que está acontecendo com o seu serviço — erros, reinicializações, avisos — sem precisar ficar caçando arquivo de log espalhado pelo servidor.

Vamos com calma, passo a passo. 😊

O que é o journalctl?

O journalctl é o comando que lê o journal do systemd — um "diário" central onde a maioria das distribuições Linux modernas (Ubuntu, Debian, CentOS/AlmaLinux etc.) guarda os logs do sistema e dos serviços que rodam nele. Se a sua aplicação está configurada como um serviço systemd (aquele arquivo .service), o journalctl é o jeito mais rápido e confiável de ver o que ela está "dizendo" em tempo real.

💡 Dica da Sensei: esse recurso depende de acesso ao terminal (SSH) do servidor. Se você não sabe se o seu plano inclui esse tipo de acesso, dá uma olhadinha no painel.gehost.com.br ou fala com o nosso suporte — a gente confirma certinho pra você.

Passo 1 — Conecte no seu servidor via SSH

Antes de tudo, você precisa estar logado no servidor. Abra o terminal (no Mac/Linux já vem pronto; no Windows pode usar o PowerShell ou um programa como o PuTTY) e conecte normalmente com os dados de acesso que você recebeu na entrega do seu servidor:

1. Abra o terminal.
2. Use o comando de conexão SSH com o usuário e o endereço do seu servidor (esses dados ficam no seu contrato/painel — nunca compartilhe com ninguém).
3. Digite a senha (ou use sua chave, se configurada) quando for solicitado.

Pronto, você já está "dentro" do servidor. 🎉

Passo 2 — Descubra o nome do serviço da sua aplicação

Pra pedir os logs de uma aplicação específica, o journalctl precisa saber o nome do serviço dela. Se você (ou quem configurou o servidor) já sabe o nome, ótimo. Se não souber, dá pra listar os serviços ativos com:

1. systemctl list-units --type=service
2. Procure na lista o nome que parece com o da sua aplicação (ex.: minhaapp.service, node-app.service, gunicorn.service etc.).

Passo 3 — Acompanhe os logs em tempo real

Aqui está o pulo do gato! O comando que "acompanha ao vivo", tipo uma transmissão, é:

1. journalctl -u nome-do-servico -f

Repare no -f (de follow) — é ele quem faz a tela ficar "ao vivo", mostrando cada nova linha de log assim que ela acontece. É perfeito pra quando você está testando algo e quer ver na hora se deu erro ou se funcionou.

Pra sair desse modo "ao vivo", é só apertar Ctrl + C.

Passo 4 — Filtre para achar o que interessa

Quando o log está gigante, filtrar é essencial. Aqui vão os filtros mais úteis do dia a dia:

• Ver só os erros: journalctl -u nome-do-servico -p err -f
• Ver as últimas N linhas antes de seguir ao vivo: journalctl -u nome-do-servico -n 100 -f
• Ver logs de um período específico: journalctl -u nome-do-servico --since "2026-07-20 08:00:00" --until "2026-07-20 09:00:00"
• Ver só o que aconteceu hoje: journalctl -u nome-do-servico --since today
• Ver os logs de todos os serviços do sistema (não só o seu): journalctl -f

💡 Dica da Sensei: combine os filtros! Por exemplo, journalctl -u nome-do-servico -p err --since "1 hour ago" mostra só os erros da última hora — ótimo pra investigar um problema que acabou de acontecer.

Passo 5 — Guarde ou compartilhe um trecho do log

Se você precisar mandar um pedaço do log pro nosso suporte analisar, o mais prático é salvar num arquivo de texto:

1. journalctl -u nome-do-servico -n 200 > log-da-aplicacao.txt
2. Isso salva as últimas 200 linhas num arquivo que você pode baixar do servidor e anexar no seu ticket.

Erros comuns (e como resolver)

• "journalctl: command not found" — normalmente aparece em distribuições muito antigas ou sem o systemd. Nesse caso, fale com o suporte pra confirmar como os logs são gerenciados no seu servidor.
• "Nenhum log encontrado" ou lista vazia — confira se o nome do serviço está certo (revise o Passo 2) ou se a aplicação realmente está rodando (systemctl status nome-do-servico).
• Permissão negada — alguns comandos podem exigir mais privilégio no sistema. Se acontecer, entre em contato com o suporte antes de tentar contornar isso sozinho.

Precisou de uma força?

Se em algum momento a coisa ficar mais técnica do que você se sente confortável em mexer — tudo bem, é pra isso que a gente está aqui! Abra um chamado no painel.gehost.com.br e nosso time te ajuda a interpretar os logs e resolver o que for preciso. 🙌

Prontinho — agora você já sabe acompanhar sua aplicação "ao vivo" como um verdadeiro sensei dos logs! 🥋✨