Tutoriais de VPS
Como ler os logs de uma VPS (2026): journalctl, systemctl, Nginx e logs de aplicação para localizar problemas
Quando a VPS dá problema, não basta reiniciar serviços. Este artigo segue a ordem de systemctl, journalctl, access/error log do Nginx, Docker logs e logs da aplicação para explicar com clareza como localizar problemas de porta, permissão, configuração, memória e falha de inicialização a partir dos logs.
Muitos problemas de VPS já estão escritos com clareza nos logs; só ninguém olha.
Vi um amigo cujo serviço Node não parava de falhar na inicialização. Ele executava repetidamente:
systemctl restart app
Reiniciou mais de dez vezes e nada. No fim, deu uma olhada nos logs e lá estava escrito claramente EADDRINUSE: address already in use: a porta estava ocupada por um processo antigo. O problema não era o servidor instável nem misticismo de código; era simplesmente não olhar os logs.
Por isso este artigo não trata de monitoramento complexo. Trata apenas da coisa mais prática: quando a VPS dá problema, onde olhar os logs primeiro, como lê-los e para que direção investigar ao ver certas palavras-chave.
Quando um serviço dá problema, o primeiro comando costuma ser:
systemctl status 服务名
Por exemplo:
systemctl status nginx
systemctl status docker
systemctl status mysql
systemctl status app
Preste atenção nestas linhas:
- Se
Active:está em running, failed ou activating - Se
Main PID:tem um processo - Se as últimas linhas do log têm erro
- Qual é o código de saída depois de
code=exited - Se há avisos como
permission denied,address already in use,cannot bind
systemctl status serve para julgar rapidamente o estado atual do serviço, mas mostra apenas um trecho pequeno do log. Para ver o log completo, use journalctl.
Se o serviço é gerenciado pelo systemd, o comando mais usado é:
journalctl -u 服务名 -n 100 --no-pager
Por exemplo:
journalctl -u nginx -n 100 --no-pager
journalctl -u docker -n 100 --no-pager
journalctl -u app -n 100 --no-pager
Para ver os logs em tempo real:
journalctl -u 服务名 -f
Para ver os logs a partir de um determinado momento:
journalctl -u 服务名 --since "1 hour ago"
journalctl -u 服务名 --since "2026-05-13 10:00:00"
Se o serviço acabou de falhar ao reiniciar, eu costumo olhar assim:
systemctl restart app
journalctl -u app -n 100 --no-pager
Não olhe só a última linha. Muitas causas reais estão uma dúzia de linhas acima, como falha ao ler o arquivo de configuração, variáveis de ambiente ausentes ou porta ocupada.
Alguns problemas não são de um único serviço, mas de inicialização, disco, memória, rede ou kernel.
Para ver os logs desde esta inicialização:
journalctl -b -n 200 --no-pager
Para ver os logs da inicialização anterior:
journalctl -b -1 -n 200 --no-pager
Se a VPS reinicia sem motivo ou os serviços caem de repente, você pode verificar:
last reboot
journalctl -b -1 -p warning --no-pager
Palavras-chave comuns:
Out of memory: memória insuficiente, encerrado por OOMKilled process: o sistema matou um processosegfault: o programa travouI/O error: problema de disco ou sistema de arquivosNo space left on device: disco cheiopermission denied: problema de permissão
Isso é muito mais útil do que "acho que o servidor está instável".
Os dois logs do Nginx mais consultados:
/var/log/nginx/access.log
/var/log/nginx/error.log
Para ver os erros em tempo real:
tail -f /var/log/nginx/error.log
Para ver os acessos recentes:
tail -n 100 /var/log/nginx/access.log
Se o navegador recebe 502, veja primeiro o error log. Causas comuns:
- Porta upstream errada
- Aplicação backend não iniciada
- Nginx sem permissão para acessar o socket
- PHP-FPM caído
- Timeout de conexão do proxy reverso
Se receber 404, veja o access log e o server block. Pode ser:
- O domínio caiu no server_name errado
- O caminho root está errado
- As regras de rewrite estão incorretas
- O arquivo estático não existe
Se for 403, geralmente é problema de permissão ou de índice de diretório.
Depois de alterar a configuração do Nginx, execute primeiro:
nginx -t
systemctl reload nginx
Não reinicie diretamente. nginx -t pode avisar de antemão se a configuração tem erro de sintaxe.
Quando um contêiner Docker cai, muita gente só olha:
docker ps
Mas a causa real geralmente está nos logs:
docker logs 容器名 --tail 100
docker logs -f 容器名
Se for docker compose:
docker compose ps
docker compose logs --tail 100 服务名
docker compose logs -f 服务名
Palavras-chave comuns:
permission denied: permissões erradas no diretório montadoconnection refused: serviço dependente não iniciado ou endereço erradono such file or directory: caminho do arquivo de configuração erradoaddress already in use: conflito de portaexit code 137: geralmente encerrado por falta de memória
Quando o contêiner reinicia sem parar, não altere apenas restart: always. Isso só faz o contêiner reiniciar sem parar; não resolve a causa raiz.
Cada aplicação tem um local de log diferente.
Locais comuns:
/var/log/应用名/
/opt/应用名/logs/
/home/用户名/app/logs/
pm2 logs
Se for Node + PM2:
pm2 status
pm2 logs --lines 100
Se for Python / Gunicorn:
journalctl -u gunicorn -n 100 --no-pager
Se for PHP-FPM:
journalctl -u php8.2-fpm -n 100 --no-pager
Quando não encontrar os logs, veja primeiro o arquivo de serviço:
systemctl cat 服务名
Normalmente dá para ver o comando de inicialização, o diretório de trabalho e o arquivo de variáveis de ambiente. Muitas causas de "o programa não inicia" são, na verdade, diretório de trabalho errado, variáveis de ambiente não carregadas ou caminho de configuração errado.
Aqui vai uma tabela de consulta rápida:
| Palavra-chave do log | Direção comum |
|---|---|
address already in use | Porta já em uso |
permission denied | Permissões de arquivo, de diretório, de porta |
connection refused | Serviço dependente não iniciado, porta inacessível |
no such file or directory | Caminho errado, arquivo inexistente |
No space left on device | Disco cheio, inodes cheios |
Out of memory / Killed process | Memória insuficiente, OOM kill |
bad gateway / upstream | Nginx não consegue chegar ao backend |
certificate / SSL | Problemas de certificado, domínio ou configuração HTTPS |
authentication failed | Problemas de senha, permissão ou usuário do banco de dados |
timeout | Rede lenta, dependências travadas, bloqueio do firewall |
Ao ver uma palavra-chave, não se apresse em copiar o erro inteiro e pesquisar. Primeiro avalie pelo cenário: é a fase de inicialização, a fase de acesso, a fase de conexão com o banco de dados ou a fase de proxy reverso?
Se você vai abrir um ticket ou pedir ajuda a alguém, os logs devem ser colados na medida certa.
Recomenda-se fornecer:
systemctl status 服务名
journalctl -u 服务名 -n 80 --no-pager
nginx -t
ss -lntp
Se for problema do site, acrescente também:
tail -n 80 /var/log/nginx/error.log
tail -n 50 /var/log/nginx/access.log
Não cole diretamente milhares de linhas de log. Os outros não conseguem terminar de ler e é fácil perder os pontos principais.
Mais importante ainda: antes de colar os logs, oculte:
- IP do servidor
- Senha do banco de dados
- API Key
- Token
- Cookie
- E-mail do usuário
- Caminho do painel administrativo
Os logs costumam conter informações sensíveis, especialmente stacks de erro da aplicação e cabeçalhos de requisição. Antes de publicar em fóruns ou grupos de chat, sempre revise.
Se um serviço em uma VPS dá problema, eu costumo seguir esta ordem:
systemctl status 服务名journalctl -u 服务名 -n 100 --no-pagerss -lntppara ver as portasdf -hpara ver o discofree -mpara ver a memória- Nginx error log / access log
- Os logs da própria aplicação
- Logs de Docker / PM2 / PHP-FPM
- Qual configuração foi alterada por último
- Depois decidir se reinicia, faz rollback ou altera a configuração
Isso é bem mais confiável do que "vamos tentar reiniciar". Reiniciar às vezes recupera temporariamente, mas também apaga a cena. Principalmente em problemas intermitentes, os logs são a evidência.
Ao encontrar um problema, pergunte-se primeiro:
- O status do serviço é running ou failed
- Há erros evidentes nas últimas 100 linhas de
journalctl -u - Há erros de porta ocupada, permissão, caminho, disco ou memória
- O error log do Nginx tem informações de upstream / 502 / 403 / 404
- Docker ou PM2 têm logs próprios
- A configuração, os certificados, as variáveis de ambiente ou as versões de dependências foram alterados recentemente
- Os logs foram ocultados antes de enviá-los a outra pessoa
O pior no diagnóstico de VPS é se guiar pela sensação. Os logs não necessariamente dão a resposta diretamente, mas dizem onde olhar em seguida. Olhe os logs primeiro e depois faça alterações: você evita muitos desvios.