Como identificar abuso de CPU, memória, disco e rede analisando logs do Linux

O abuso de recursos no servidor Linux é o pesadelo de qualquer administrador de sistemas. Esse tema é ouro para quem cuida de infraestrutura em produção — porque quando o gráfico do painel de monitoramento estoura e fica vermelho, o estrago já começou, os clientes já estão reclamando e você já entrou no “modo apagar incêndio”.

A grande diferença entre um SysAdmin reativo e um SysAdmin proativo está na capacidade de ler os sinais antes do colapso. O kernel do Linux, os servidores web e os bancos de dados são sistemas extremamente “faladores”. Eles documentam cada engasgo, cada limite alcançado e cada erro em seus logs.

Neste guia definitivo, vamos aprofundar na arte do troubleshooting avançado. A ideia aqui é aprender a identificar o abuso de recursos de CPU, memória, disco e rede, cruzando logs do Linux, Nginx, PHP-FPM e MariaDB/MySQL, com um foco estritamente preditivo.

1️⃣ Abuso de CPU: Quando o servidor “não tá fazendo nada”, mas está lento

Um dos cenários mais confusos na administração de servidores é quando o comando top mostra uma porcentagem alta de CPU ociosa (idle), mas o load average (carga do sistema) está nas alturas e os sites demoram segundos para responder. O abuso de CPU raramente é apenas um processo em 100%; geralmente, é uma fila de processos aguardando tempo de processador ou bloqueados por outros recursos.

🔍 Sinais Clássicos de Abuso no Processamento

• Load average desconexo da CPU: Um servidor com 8 cores apresentando load de 40.00, mas com 60% de CPU idle.
• Aumento drástico de Steal Time (%st): Em ambientes virtualizados (VPS/Cloud), indica que o hypervisor está sobrecarregado e roubando ciclos de processamento da sua máquina.
• Processos em estado D ou R: Processos em estado R (Running) estão ativamente usando a CPU. Processos em estado D (Uninterruptible Sleep) estão aguardando I/O (disco ou rede) e não podem ser mortos, elevando o load average artificialmente.

📁 Logs e Ferramentas de Diagnóstico

Kernel Linux (dmesg e journalctl) O kernel avisa quando a CPU está travando por muito tempo em uma única tarefa. Utilize o journalctl para buscar travamentos:

Shell

journalctl -k | grep -i stall
journalctl -k | grep -i "soft lockup"

Fique atento a mensagens como: BUG: soft lockup - CPU#2 stuck for 22s! ou rcu_sched detected stalls on CPUs/tasks. Isso indica que a CPU ficou presa no kernel space, muitas vezes devido a drivers problemáticos, bugs de hypervisor ou I/O extremamente lento que bloqueou interrupções de hardware.

Nginx: Encontrando os culpados no Access Log O servidor web é a porta de entrada. Se a CPU está alta, alguém está pedindo para ela trabalhar. O log de acesso do Nginx é sua melhor ferramenta para descobrir quem e o quê.

Shell

# Descobrir quais URLs estão recebendo mais requisições (possível flood/abuso)
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20

Se você encontrar uma explosão de requests em endpoints específicos (como /xmlrpc.php, /wp-login.php ou rotas de API pesadas), você encontrou a fonte do abuso de recursos. Outro sinal claro são muitos retornos HTTP 200 rápidos gerados por bots, ou códigos HTTP 499, que ocorrem quando o cliente desiste e fecha a conexão porque o servidor (preso na CPU) demorou demais para responder.

PHP-FPM: Onde a CPU realmente ferve No ecossistema web, o Nginx apenas entrega os arquivos; quem mastiga os dados e queima a CPU é o PHP-FPM.

Shell

tail -f /var/log/php-fpm/www-error.log

Red flags absolutas:

• server reached pm.max_children: O PHP-FPM não tem mais workers disponíveis. Todas as novas requisições ficarão em fila no Nginx.
• slow script detected: Se você ativou o slowlog do PHP-FPM (altamente recomendado), ele mostrará exatamente qual linha de código em qual arquivo de qual plugin está demorando segundos para executar.

📌 Mitigação Rápida: O padrão comum de abuso aqui são poucos endpoints causando alta carga por loops mal otimizados. Implementar caching agressivo no Nginx (FastCGI Cache) ou object caching (Redis) evita que a requisição chegue ao PHP, poupando a CPU instantaneamente.

2️⃣ Abuso de Memória: O inimigo silencioso e o OOM Killer

Diferente da CPU, que causa lentidão quando abusada, o abuso de memória causa a morte de processos. O Linux utiliza a RAM disponível para caching de disco agressivamente. A memória “livre” real quase sempre será baixa, mas isso é normal. O perigo real ocorre quando os aplicativos exigem mais memória física do que o sistema possui, forçando o uso do Swap e, eventualmente, acionando o ceifador do kernel: o Out of Memory (OOM) Killer.

🔍 Sinais Clássicos de Gargalo de RAM

• Uso ativo de Swap: Ter Swap alocado é uma boa prática; ver o sistema lendo e escrevendo no Swap constantemente (Swapping/Thrashing) destrói a performance.
• Processos morrendo “do nada”: O banco de dados ou o servidor web reiniciam misteriosamente sem que ninguém tenha dado o comando.
• Lentidão progressiva: O servidor inicia rápido e vai ficando lento ao longo de dias ou semanas.

📁 Logs Decisivos para Análise de Memória

Kernel / OOM Killer Quando a RAM acaba, o kernel não trava o sistema; ele sacrifica um processo para salvar o resto. Ele calcula um “badness score” e mata o maior ofensor.

Shell

journalctl -k | grep -i -A 5 "out of memory"
journalctl -k | grep -i killed

Você verá uma saída detalhada e, no final, a sentença: Killed process 31245 (php-fpm) total-vm:458732kB, anon-rss:124500kB...

Muitos sysadmins acham que isso é um bug do aplicativo. Não é. Isso não é bug, é o kernel te salvando de um kernel panic total. O aplicativo pediu mais RAM do que existia.

O Problema Crônico do PHP-FPM e Memory Leaks Aplicações web complexas frequentemente sofrem de vazamento de memória (memory leak). O worker do PHP processa uma requisição, mas não libera 100% da RAM que utilizou. Após processar 500 requisições, aquele único worker inflou de 30MB para 250MB. Multiplique isso por 50 workers e seu servidor de 8GB de RAM colapsa.

👉 Indicador claro: Crescimento contínuo de memória por worker no top ou htop, culminando na morte do processo pelo OOM Killer.

📌 Dica Prática de Tuning: Nunca deixe o PHP-FPM rodar processos infinitamente. Configure a reciclagem automática no /etc/php-fpm.d/www.conf: pm.max_requests = 500 Isso obriga o worker a se suicidar educadamente e renascer após 500 requisições, devolvendo toda a memória vazada para o sistema operacional e prevenindo o abuso de recursos no servidor Linux.

3️⃣ Abuso de Disco (I/O): Quando o gargalo não aparece no CPU

Com a popularização dos SSDs NVMe, gargalos de I/O (Input/Output) tornaram-se menos frequentes, mas quando ocorrem, são devastadores. Um disco lento causa um “efeito dominó”: o banco de dados não consegue gravar, o PHP fica esperando o banco, o Nginx fica esperando o PHP, e o load average decola enquanto a CPU permanece ociosa.

🔍 Sinais Clássicos de Abuso de I/O

• I/O Wait (%wa) alto no top: Se o valor de wa passar de 5% a 10% constantemente, seu disco é o gargalo.
• MySQL/MariaDB “travando”: Consultas simples demoram vários segundos.
• Serviços de Backup destruindo a performance: O servidor congela no horário do cron de backup.

📁 Onde Olhar e Como Diagnosticar

Kernel / IO Subsystem Erros no nível do bloco de armazenamento são críticos.

journalctl -k | grep -i error | grep -i -E "blk|buffer|sd|nvme"

Mensagens como blk_update_request: I/O error, dev sda, sector 123456 ou buffer I/O error on dev vda1 são sinais vermelhos imediatos.

🚨 O que isso indica:

• O disco físico (SSD/HDD) está falhando e atingiu o limite de vida útil.
• O array RAID está degradado ou mal configurado.
• Em ambientes Cloud/VPS, indica um ambiente hiper-compartilhado saturado (noisy neighbor ou overselling extremo do provedor).

Nginx: Uploads Massivos ou Logs Excessivos Um volume absurdo de acessos significa que o Nginx está escrevendo furiosamente no arquivo access.log. Em discos lentos, apenas o ato de registrar o tráfego pode causar abuso de recursos.

# Descobrindo IPs fazendo requisições muito pesadas (possíveis uploads grandes)
awk '{print $10 " " $1}' /var/log/nginx/access.log | sort -nr | head -n 10

Banco de Dados (MariaDB / MySQL) O banco de dados é o rei do I/O. Verifique o log de erros do MySQL:

tail -n 100 /var/log/mysql/error.log

Procure por avisos relacionados ao mecanismo InnoDB:

• InnoDB: page_cleaner: 1000ms intended loop took 4500ms.
• InnoDB: Write latency ou reclamações sobre fsync() demorando demais.

📌 Mitigação Rápida: O abuso de recursos no disco devido ao banco de dados geralmente se resolve com tuning de memória. Aumente o innodb_buffer_pool_size para que o MariaDB guarde os dados mais acessados na RAM, reduzindo a necessidade de ler o disco físico. Otimize as tabelas e garanta que as consultas possuam índices adequados.

4️⃣ Abuso de Rede: O ataque que parece “tráfego normal”

Problemas de rede nem sempre são grandes ataques DDoS volumétricos (Layer 3/4) que derrubam o link do datacenter. O abuso de recursos mais perigoso é o ataque de Camada 7 (Aplicação) ou conexões zumbis que exaurem as tabelas de roteamento do kernel. Eles parecem tráfego normal, mas são projetados para drenar sockets e memória.

🔍 Sinais Clássicos de Exaustão de Rede

• Muitas conexões abertas e não fechadas: O servidor atinge o limite de file descriptors ou sockets TCP.
• Erros Nginx: Códigos 499 (Cliente fechou a conexão), 444 (Conexão fechada sem resposta) ou 502/504 gerados por falha de comunicação interna no loopback.
• Estados TCP inflados: Um número massivo de conexões em estado TIME_WAIT ou SYN_RECV.

📁 Logs e Comandos que Entregam o Abuso

Análise do Access Log (A Camada 7) Ataques de força bruta, scrapers roubando conteúdo ou botnets geram um padrão distinto.

# Contando acessos por IP para identificar floods
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 15

# Identificando User-Agents agressivos ou vazios
awk '{print $12}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 15

Se você vê meia dúzia de IPs com dezenas de milhares de requests, ou User-Agents como python-requests, curl ou nomes genéricos mascarados acessando agressivamente, você está sob um ataque focado, gerando abuso de recursos no servidor Linux.

Kernel (Netfilter e Conntrack) Se você utiliza um firewall no Linux (iptables, nftables, firewalld, ufw), o módulo nf_conntrack rastreia o estado de cada conexão de rede.

journalctl -k | grep -i conntrack

Se você vir a mensagem: nf_conntrack: table full, dropping packet

Isso é uma queda anunciada. O kernel não consegue mais registrar novas conexões e simplesmente começa a descartar pacotes de usuários legítimos. O servidor parece online, mas ninguém consegue acessar.

📌 Ajuste Fino de Sysctl: Para mitigar isso imediatamente, aumente os limites no arquivo /etc/sysctl.conf:

net.nf_conntrack_max = 262144
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.core.somaxconn = 65535

Aplique com sysctl -p. Além disso, integrar ferramentas como CrowdSec ou Fail2Ban para analisar os logs do Nginx e bloquear os IPs agressores no firewall dinamicamente é essencial para não depender apenas do tuning do kernel.

5️⃣ O “God Mode”: O poder real está no cruzamento dos logs

O erro número um de administradores iniciantes é analisar logs de forma isolada. Eles olham para o MySQL, veem o uso de CPU alto e começam a alterar dezenas de parâmetros no my.cnf. Eles não percebem que o problema não era o banco.

Exemplo Clássico do Efeito Dominó (O Abuso em Cadeia):

1. O Gatilho: Uma agência de marketing dispara um e-mail em massa e o tráfego do site multiplica por 10x repentinamente.
2. Nginx: O access.log registra milhares de requisições simultâneas válidas.
3. PHP-FPM: O log de erro registra server reached pm.max_children. Todos os workers estão ocupados calculando o conteúdo dinâmico da página inicial para cada visitante.
4. MariaDB: As consultas se acumulam. O slow query log mostra consultas normais demorando 5 segundos, pois a fila de I/O do disco encheu.
5. Kernel: A RAM lota com workers do PHP-FPM presos esperando o banco. O sistema começa a usar Swap. O dmesg mostra o kernel reclamando de lentidão de I/O.
6. O Fim: O OOM Killer desperta e mata o MariaDB (journalctl | grep killed), pois era o processo consumindo mais memória no momento crítico.

👉 A Conclusão Correta: Não é “falta de servidor” ou “MySQL configurado errado”. É um claro abuso de recursos gerado por um gargalo mal dimensionado. A solução não é dar mais CPU para o banco, mas sim implementar um Microcache no Nginx (FastCGI Cache) para servir o site estaticamente para o pico de tráfego, protegendo o PHP e o Banco de Dados do impacto.

6️⃣ Checklist Mental de Diagnóstico Antes do Servidor Cair

Quando os alertas começarem a soar, não reinicie os serviços cegamente. Reiniciar apenas esconde o problema por algumas horas. Faça estas perguntas cruzando as informações:

1. 🔁 Padrão Temporal: O mesmo pico aparece todo dia no mesmo horário? (Verifique as cronjobs, tarefas de backup, varreduras de antivírus ou rotinas de exportação).
2. 📍 Foco da Carga: Um único endpoint ou domínio (em ambientes de hospedagem compartilhada como DirectAdmin/cPanel) concentra toda a carga? (Isole o usuário, verifique plugins desatualizados).
3. 🧠 Curva de Degradação: O problema cresce lentamente ao longo de dias (memory leak, acumulação de inodes no disco) ou explode repentinamente de um minuto para o outro (ataque DDoS, flood de requisições, picos de tráfego viral)?
4. ⚠️ A Voz do Sistema: O kernel já está reclamando no dmesg? (Se o kernel fala, escute. Avisos de soft lockup, erros de I/O e exaustão de tabela conntrack são pré-requisitos para uma queda sistêmica).

7️⃣ Próximo Nível: Transformar Logs em Alerta Preditivo

O caminho natural para um SysAdmin Sênior depois de dominar a leitura manual de logs para evitar o abuso de recursos no servidor Linux é a automação. Ficar rodando grep e awk de madrugada não é qualidade de vida.

Você precisa extrair padrões dos logs e alertar por tendência, não apenas quando o limite já foi estourado.

• Centralização e Parsing: Ferramentas como Promtail integrado ao Loki, ou a stack ELK (Elasticsearch, Logstash, Kibana) permitem ingerir gigabytes de logs do Nginx, Kernel e PHP e criar dashboards visuais.
• Monitoramento Ativo: Utilize agentes avançados (como Zabbix Agent ou Netdata) não apenas para medir CPU, mas para contar quantas vezes a palavra “Error” apareceu no log do banco de dados nos últimos 5 minutos, disparando um gatilho antes da CPU travar.
• Respostas Automatizadas: Integre a detecção de anomalias no log do Nginx diretamente com o WAF ou firewall, isolando atacantes sem interação humana.

Dominar os logs não é apenas sobre consertar o que quebrou; é sobre projetar uma infraestrutura que seja resiliente, previsível e à prova de falhas na camada de aplicação e sistema operacional.

FAQ