Projeto guiado: diagnosticando um servidor remoto

Esta última lição não ensina comando novo nenhum — ela junta praticamente tudo que você viu nas 15 lições anteriores num cenário só, do jeito que aconteceria de verdade: alguém te avisa que "o site caiu", e a única ferramenta que você tem em mãos é o terminal.

O cenário

Você recebe uma mensagem: "o site parou de responder". Não tem mais informação que isso. O servidor onde a aplicação roda é uma VPS Linux, e seu único acesso é remoto. Vamos investigar passo a passo, exatamente na ordem que faz sentido investigar — de fora pra dentro.

Passo 1 — conectando no servidor

O primeiro passo é sempre entrar no servidor. Isso é a lição 12 em ação:

ssh deploy@203.0.113.42

Prompt mudou pra deploy@servidor — você está dentro do servidor agora. Todo comando daqui pra frente roda lá, não na sua máquina.

Passo 2 — navegando até a pasta do projeto

Isso é a lição 2: pwd pra saber onde você está, cd pra chegar até a aplicação.

pwd

cd /var/www/meu-site
ls -la

Existe uma pasta logs — é o próximo lugar óbvio pra olhar.

Passo 3 — lendo o log de erro

Isso combina a lição 4 (less) com a lição 7 (grep). Um log de produção pode ter milhares de linhas — não dá pra ler tudo com cat.

grep -n "ERROR" logs/app.log | tail -5

grep -n "ERROR" filtra só as linhas de erro, mostrando o número da linha; tail -5 (que ainda não vimos, mas segue a mesma lógica de pipe da lição 6) pega só as 5 últimas — as mais recentes. A pista mais forte aqui: porta 3000 já em uso, impedindo o serviço de reiniciar. Isso sugere que existe um processo travado, ainda ocupando a porta que o serviço precisa.

Passo 4 — checando se o processo está rodando

Hora da lição 8. Vamos confirmar a suspeita: existe algum processo preso, segurando a porta 3000.

ps aux | grep node

Dois processos node server.js rodando ao mesmo tempo — isso não deveria acontecer. O segundo (PID 4390) está consumindo 95% de CPU, um sinal claro de que travou num loop e nunca terminou de sair, sem liberar a porta 3000 pro processo novo conseguir subir.

kill 4390

Um kill normal primeiro, do jeito educado — dando a chance do processo se encerrar corretamente antes de forçar. Se depois de alguns segundos o ps aux mostrar que ele ainda está lá, aí sim o próximo passo seria kill -9 4390.

Passo 5 — editando a configuração

Enquanto investigava, você percebeu no config.yml que a URL do banco estava apontando pro endereço errado — provavelmente a causa raiz do Connection refused visto no log. Hora do nano, lição 4:

nano config.yml

database_url: postgres://app:senha@db.interno:5432/producao
porta: 3000

Depois de corrigir a linha do database_url: Ctrl+O salva, Enter confirma o nome, Ctrl+X sai.

Passo 6 — reiniciando o serviço

Com o processo travado encerrado e a configuração corrigida, é hora de subir o serviço de novo. Como isso pode demorar e você quer continuar usando o terminal pra acompanhar, rodar em background (lição 8) faz sentido:

node server.js &

grep -n "ERROR" logs/app.log | tail -3

Nenhum erro novo depois do restart — sinal de que a correção funcionou. Uma última conferência com ps aux | grep node confirma que agora existe só um processo rodando, saudável, sem consumo anormal de CPU.

O que esse cenário mostrou

ssh                → entrar no servidor remoto
cd / ls -la         → chegar até a pasta certa e ver o que existe ali
grep -n / tail       → filtrar o log gigante até achar as linhas relevantes
ps aux               → confirmar o que está rodando de fato, e identificar o processo travado
kill                 → encerrar o processo problemático, do jeito educado primeiro
nano                 → corrigir a configuração com o erro raiz identificado
comando & / jobs      → reiniciar o serviço em background e acompanhar

Nenhum passo dessa investigação usou uma ferramenta gráfica, um dashboard ou um clique sequer — cada decisão veio de ler a saída de um comando e decidir o próximo com base nela. É exatamente essa leitura de saída, comando após comando, que esta trilha inteira tentou construir.