A aplicação engasga. O tempo de resposta dispara. O suporte começa a pipocar.
Pânico? Não. É hora de ativar o modo Sherlock Holmes. Felizmente, nosso sistema de escolha, o Linux, oferece o arsenal completo para investigar o mistério direto da fonte.
💡 Não vou falar de observabilidade complexa. O foco é o básico: Linux
🕵️ Chegando à cena do crime...
Primeira ferramenta: htop
Ele entrega tudo em tempo real. Meus focos:
-
CPU%: se tem processo fixado em 90–100%, já tenho um suspeito. -
MEM%: uso alto pode empurrar pro swap → queda de performance. -
PID: informação essencial pra próxima etapa.
🔎 Investigando suspeitos: ps
Se já tenho um alvo, sigo com:
ps aux | grep [nome_ou_PID]
Ou meu favorito:
ps aux --sort=-%cpu | head
Organiza por uso de CPU e me dá logo os 10 mais famintos.
🗂️ Procurando pistas nos bastidores: logs
Nem sempre o problema está no uso de recursos.
Pode ser erro interno, configuração, permissão…
Hora de usar o bom e velho tail:
tail -f /var/log/sua_aplicacao/error.log
⚠️ Caso real resolvido
Numa dessas investigações, encontrei um processo do SNGrep (análise SIP) devorando CPU.
Comando simples, solução direta para mandar o processo embora:
kill -9 [PID]
🛠️ Ferramentas simples, mas poderosas.
Top comments (0)