Troubleshooting Linux em Produção: O Guia de Sobrevivência dos Primeiros 60 Segundos

São 02h14 da manhã. O canal de incidentes do Slack acorda com alertas vermelhos do Zabbix ou Grafana. O servidor de banco ou aplicação parou de responder, o Load Average está em 48 e o suporte já está sugerindo a pior solução possível: “Dá um reboot forçado pra ver se volta”.

Dar reboot sem investigar é como jogar água em um painel elétrico: você pode até reiniciar o sistema, mas destrói as evidências na memória e o servidor voltará a cair 15 minutos depois.

Em servidores Linux corporativos, você tem uma janela crítica de 60 segundos para diagnosticar se o gargalo está em CPU, Disco (I/O), Memória ou Rede.

Neste guia prático, dissecamos a esteira de triagem rápida que todo SysAdmin e SRE precisa dominar antes de tomar qualquer decisão drástica em produção.

⚡ Triagem Rápida em 60 Segundos (TL;DR)

Execute estes comandos na ordem abaixo para isolar o culpado em menos de um minuto:

🧭 Os 4 Grandes Assassinos de Performance no Linux

Todo servidor Linux que entra em colapso está sofrendo por um destes quatro pilares. Veja como identificá-los em cards objetivos:

🛠️ O Protocolo de Execução Passo a Passo

Abra o terminal com acesso root e siga os passos cirúrgicos:

Passo 1: Entenda o Load Average com Relação aos Cores

Execute:

uptime && nproc

Se o seu servidor tem 4 cores (nproc retorna 4) e o Load Average está em 4.0, sua CPU está a 100% da capacidade saudável. Se o Load estiver em 16.0, significa que há uma fila média de 12 processos esperando CPU ou presos em I/O.

Passo 2: Verifique se o OOM Killer foi Acionado

Muitas vezes o serviço cai misteriosamente (como MySQL ou Node.js) sem registrar erro no próprio log porque foi sumariamente fuzilado pelo Kernel:

dmesg -T | grep -E -i 'oom|kill|out of memory' | tail -n 15

Se encontrar linhas como Out of memory: Killed process 1420 (mysqld), você já sabe que o problema foi insuficiência de RAM física ou vazamento de memória.

Passo 3: Avalie o Tráfego de Disco e Processos Bloqueados com o vmstat

O vmstat é a ferramenta mais rápida para identificar I/O Wait:

vmstat 1 5

• Coluna r (Run queue): Processos aguardando CPU. Se for muito maior que o número de núcleos, a CPU é o gargalo.
• Coluna b (Blocked): Processos em espera ininterrupta de disco (D state). Se b estiver maior que 2, o seu gargalo é o storage.
• Coluna wa (Wait I/O): Porcentagem de tempo de CPU gasta aguardando leitura/escrita de disco.

Passo 4: Descubra Exatamente Qual PID Está Destruindo o Disco

Se o vmstat acusou I/O alto, use o pidstat para pegar o processo em flagrante:

pidstat -d 1 5

A coluna kB_rd/s e kB_wr/s mostrará exatamente quanto cada comando está gravando em tempo real. Você saberá na hora se é uma query de banco sem índice ou um log descontrolado.

Passo 5: Inspecione a Tabela de Conexões TCP

Descubra se o servidor web está sofrendo ataque de esgotamento de conexões (SYN Flood) ou se há conexões zumbis travadas:

ss -ant | awk '{print $1}' | sort | uniq -c | sort -n

Isso mostrará a contagem por estado (ESTAB, SYN-RECV, TIME-WAIT, CLOSE-WAIT). Um excesso de conexões em CLOSE-WAIT indica que a aplicação não está fechando os sockets após responder.

🚫 4 Erros Fatais que Destroem a Produção no Momento de Crise

1. Dar kill -9 em bancos de dados relacionais: Matar o processo do MySQL, PostgreSQL ou Oracle com SIGKILL impede que o banco feche seus arquivos de log de transação e tabelas temporárias, gerando corrupção severa no restart. Use sempre systemctl stop ou kill -15 (SIGTERM).
2. Desativar a memória Swap por completo: Existe o mito de que “desativar o swap deixa o servidor mais rápido”. Sem Swap, qualquer pico momentâneo de alocação de memória acionará o OOM Killer imediatamente. O correto é manter swap e regular o vm.swappiness=10.
3. Não verificar o espaço em disco e Inodes: O disco pode estar com 90% livre em gigabytes, mas sem espaço para novos arquivos porque esgotou a tabela de Inodes (causado por milhões de arquivos pequenos de sessão). Sempre verifique com:

“bash
df -h && df -i
`

1. Ignorar o Journal do Systemd: Ficar procurando arquivos em /var/log antigos quando o erro em tempo real está gravado com precisão de milissegundos no journal:

`bash
journalctl -p err..emerg -b --no-pager -n 50
`

Dica do Especialista Hora Nerd: Crie um alias no seu .bashrc ou use nossa seção de Cheatsheets para salvar o comando triage contendo a sequência de inspeção em um único atalho de terminal.

O que fazer quando o servidor está tão travado que nem o SSH aceita novas conexões?
Se o SSH não responder por exaustão de descritores ou CPU a 100%, utilize a interface out-of-band (Console IPMI, iLO, DRAC ou console VNC do provedor de nuvem). Em último caso, use as teclas mágicas de emergência do Kernel (Magic SysRq keys): Alt + SysRq + R-E-I-S-U-B` para sincronizar os discos e reiniciar de forma segura sem corromper o sistema de arquivos.

Qual a diferença real entre Load Average e Uso de CPU?
O uso de CPU mede apenas a porcentagem de tempo em que os processadores estão executando instruções ativas. Já o Load Average mede a demanda total do sistema: processos usando a CPU + processos prontos esperando a CPU + processos em espera bloqueada de disco (I/O Wait). É por isso que um servidor pode ter 10% de uso de CPU e Load Average de 50 (quando o disco está travado).

Eleve suas habilidades de infraestrutura corporativa acompanhando nossa trilha de DevOps e Servidores e confira os guias práticos do Blog do Hora Nerd.

✓

Guilherme Nascimento

Especialista & Fundador

Especialista em Infraestrutura, Cloud/DevOps e Cibersegurança | +10 anos de experiência prática

Profissional com mais de uma década atuando no campo de batalha da tecnologia corporativa. Especialista em arquiteturas resilientes, automação com Docker/Kubernetes, Hardening de Active Directory, Linux avançado e observabilidade SRE. Criador do ecossistema Hora Nerd, dedicado a desmistificar a tecnologia para profissionais e estudantes.

Cloud & DevOps Active Directory Hardening Linux SysAdmin Docker & CI/CD Observabilidade SRE

Conectar no LinkedIn GitHub