Checklist de Diagnóstico por Sintoma em Servidores Linux

By HelpSysAdminMonitoramento e Troubleshooting (Diagnóstico)

Diagnóstico por sintoma em servidores Linux. Em ambientes de produção, o sintoma quase nunca aponta diretamente para a causa real do problema. Servidores lentos, sites fora do ar ou bancos de dados travando são apenas manifestações visíveis de gargalos mais profundos.

Este artigo apresenta um checklist técnico de diagnóstico por sintoma, focado em servidores Linux, pensado para sysadmins, SREs e profissionais de infraestrutura que precisam reduzir o MTTR (Mean Time To Repair) e evitar decisões baseadas em achismo.

Servidor lento ou com alta latência

Sintomas comuns

  • Lentidão geral
  • SSH demorando para responder
  • Comandos simples travando

Checklist inicial

  • uptime → load average maior que o número de CPUs?
  • top ou htop → processos consumindo CPU ou memória
  • vmstat 1 → swap ativa (si/so > 0)

CPU

  • mpstat -P ALL 1
  • %wa alto indica espera por disco
  • %sy alto pode indicar overhead de kernel, firewall ou rede

Memória

  • free -h
  • Uso excessivo de swap
  • Verificar OOM Killer:dmesg | grep-i oom

Disco

  • iostat -xz 1
  • await alto ou %util próximo de 100%

Site fora do ar (HTTP 502, 503 ou 504)

Diagnóstico rápido

  • Serviços ativos?systemctl status nginx apache2 php-fpm
  • Portas escutando?ss -lntp

Interpretação dos erros

  • 502 Bad Gateway → backend indisponível (PHP-FPM, app)
  • 503 Service Unavailable → saturação de workers
  • 504 Gateway Timeout → backend lento ou travado

Logs essenciais

  • Nginx: /var/log/nginx/error.log
  • Apache: /var/log/apache2/error.log
  • PHP-FPM: error.log e slow.log

PHP-FPM lento ou travando

Pontos críticos

  • pm.max_children atingido
  • Processos presos por requisições longas
  • Dependência externa lenta (API, banco, filesystem)

Comandos úteis

ps-ylC php-fpm –sort:rss

Ativar slowlog ajuda a identificar scripts problemáticos.

Banco de dados lento (MySQL / MariaDB)

Sintomas

  • Site responde, mas carrega lentamente
  • CPU aparentemente ociosa

Checklist

  • SHOW PROCESSLIST;
  • Queries em estado Locked ou Sending data
  • SHOW ENGINE INNODB STATUS\G

Sistema

  • Swap ativa durante carga
  • Gargalo de I/O identificado via iostat

Disco cheio ou espaço desaparecendo

Verificações

  • df -h
  • df -i (inodes)
  • Identificar maiores diretórios:du -xh / | sort-h | tail

Causas comuns incluem logs sem rotação e backups acumulados.

Inodes esgotados

Sintoma clássico

  • Espaço livre disponível
  • Erros ao criar arquivos

Diagnóstico

  • df -i
  • Diretórios com milhões de arquivos pequenos
  • Sessões PHP, uploads ou maildirs

Problemas de rede ou conexões caindo

Checklist

  • ss -s → sockets ativos
  • Muitos TIME_WAIT?
  • Firewall bloqueando conexões
  • Interface de rede:ip -s link

OOM Killer finalizando processos

Confirmação

dmesg | grep-i oom

Análise

  • Qual processo foi morto?
  • Swap insuficiente?
  • Limites de memória mal configurados (cgroups, systemd)

Servidor cai sob pico de tráfego

Pontos comuns

  • Limite baixo de arquivos abertos (ulimit -n)
  • fs.file-max insuficiente
  • PHP-FPM ou banco saturados
  • Cache inexistente ou mal configurado

Boas práticas de diagnóstico

  • Nunca reinicie sem coletar dados
  • Métrica antes de ação
  • Logs são provas, não opinião

Sintoma não é causa. Diagnóstico estruturado evita retrabalho.

Conclusão

Um checklist de diagnóstico por sintoma transforma incidentes caóticos em processos previsíveis. Com dados corretos, decisões se tornam técnicas — não emocionais.

Esse método é essencial para operações profissionais, especialmente em ambientes com WordPress, Nginx, PHP-FPM, MariaDB e alta concorrência.