Linux para devs — ferramentas que salvam produção

Em algum momento, você vai estar diante de um app em produção que está "lento", "travando", ou "caindo sem motivo aparente". Aplicações modernas têm muitas camadas, e o problema raramente está onde você esperaria. Quem já passou por isso sabe a diferença entre dois cenários: você abre uma janela de terminal, executa cinco comandos, e em três minutos sabe exatamente o que está acontecendo; ou você passa duas horas chutando, vendo logs que não dizem nada, antes de chamar alguém que sabe. A diferença não é experiência mística — é conhecimento de um conjunto pequeno de ferramentas Linux e do que cada uma revela.

Este conceito não é tutorial completo de cada ferramenta — referências no final cobrem isso. É catálogo operacional: para cada sintoma, quais ferramentas usar e o que esperar delas. Se você internalizar esse mapa, as próximas crises serão muito mais curtas. E mesmo fora de crises, esses comandos viram cotidianos — entender o que está acontecendo no servidor é parte do trabalho de quem opera o que constrói.

O conjunto essencial

top e htop — visão geral em tempo real

A primeira coisa a olhar quando algo está estranho. Mostra processos ordenados por consumo (CPU ou memória), uso total do sistema, load average, threads. htop é a versão moderna com cores, hierarquia visual de processos, e teclas para filtrar/ordenar interativamente.

O que procurar:

• Load average — três números no canto superior. Em Linux, é uma média de processos rodando ou esperando I/O nos últimos 1, 5 e 15 minutos. Load 4 numa máquina de 4 cores significa "100% utilização"; load 8 significa fila se acumulando. Atenção: load alto pode ser CPU (ruim) ou I/O bloqueando (também ruim, mas razão diferente).
• %CPU vs %MEM: identifique processos que estão consumindo muito de cada. Atenção: %CPU pode passar de 100% (multi-thread/multi-core).
• Estado do processo (S = sleeping, R = running, D = uninterruptible sleep, Z = zombie). D em particular indica processo bloqueado em I/O — não pode ser morto até o I/O terminar.

ps — snapshot de processos

Diferente de top, ps dá um snapshot. Útil para scripts e investigação focada. ps aux é o comando que todo mundo decora: lista todos os processos com detalhes. ps -ef tem layout um pouco diferente. ps --tree mostra hierarquia pai-filho — útil para entender quem criou quem.

Combinações comuns:

# Top 10 por CPU
ps aux --sort=-%cpu | head

# Top 10 por memória
ps aux --sort=-%mem | head

# Encontrar processo por nome
ps -ef | grep -i nginx

# Threads de um processo
ps -L -p <pid>

ss — estado de sockets

Substituiu netstat (que ainda existe mas é considerado legado). Mostra todas as conexões TCP/UDP, suas estados, processos donos. Indispensável para qualquer problema de rede.

# Todos os sockets TCP estabelecidos com PIDs
ss -tnp

# Sockets em LISTEN (servidores)
ss -tlnp

# Resumo geral de estados
ss -s

# Filtros: conexões para porta 80
ss -tn dport = :80

Útil para descobrir: que processo está ouvindo em que porta? quantos sockets em TIME_WAIT estão acumulando? quais hosts a máquina está conversando agora? quais conexões estão em CLOSE_WAIT (sintoma de cleanup ruim)?

lsof — list open files

Em Linux, "tudo é arquivo" — incluindo sockets de rede, pipes, dispositivos. lsof lista tudo o que está aberto. Para um processo específico:

# Tudo o que o processo <pid> tem aberto
lsof -p <pid>

# Quem está ouvindo na porta 80
lsof -i :80

# Quem tem o arquivo /var/log/app.log aberto
lsof /var/log/app.log

# Procurar leak de FD
lsof -p <pid> | wc -l   # crescente ao longo do tempo = leak

strace — system calls em tempo real

Já mencionado no conceito 03. strace -p <pid> mostra cada syscall que um processo está fazendo. Diagnóstico definitivo para "o que esse processo está tentando fazer?". Caro (desacelera processo), use com critério em produção.

# Tudo
strace -p <pid>

# Só syscalls de arquivo
strace -e trace=openat,read,write -p <pid>

# Só rede
strace -e trace=network -p <pid>

# Com timestamps relativos
strace -tt -p <pid>

# Iniciar com o programa (mais útil em dev)
strace -e trace=openat ./meu_programa

tcpdump — captura de pacotes

Para problemas de rede que ferramentas de mais alto nível não esclarecem. Captura pacotes da interface, mostra ou salva para análise posterior (Wireshark abre arquivos pcap).

# Capturar tráfego HTTP
sudo tcpdump -i eth0 -nn 'port 80'

# Capturar e salvar para Wireshark
sudo tcpdump -i any -w captura.pcap 'host 192.168.1.50'

# Mostrar conteúdo (texto não-binário)
sudo tcpdump -i any -A 'port 80'

Em containers Kubernetes, capturar o tráfego de um pod específico envolve entrar no namespace de rede dele — ferramentas como kubectl debug ou nsenter ajudam.

journalctl — logs do systemd

Em sistemas com systemd (Ubuntu, Debian, RHEL, Fedora modernos), todos os logs centralizam em journald. journalctl é a ferramenta para consultar.

# Logs de uma unidade
journalctl -u nginx.service

# Tail contínuo
journalctl -u nginx.service -f

# Desde determinada hora
journalctl -u nginx.service --since "2 hours ago"

# Apenas erros
journalctl -u nginx.service -p err

# Logs do kernel (incluindo OOM kills)
journalctl -k

dmesg — buffer do kernel

Mensagens do kernel: hardware, OOM kills, drivers, problemas de filesystem. Quando o sistema operacional tem algo a dizer, é aqui. dmesg -T adiciona timestamps; dmesg -w faz tail.

OOM kills (Out Of Memory) aparecem aqui antes de em qualquer outro lugar:

$ dmesg | grep -i 'killed process'
[12345.678] Out of memory: Killed process 1234 (java) total-vm:8GB...

vmstat, iostat, mpstat — performance

Trio para diagnosticar onde está o gargalo do sistema:

• vmstat 1: amostra a cada 1s — CPU (us/sy/id/wa), memória, swap, I/O, contexts switches, interrupts. Coluna wa alto = I/O bound; us alto = CPU bound; cs muito alto = thrashing.
• iostat -x 1: I/O por dispositivo. Coluna %util próximo de 100 = disco saturado. await alto = latência de I/O ruim.
• mpstat -P ALL 1: por core. Mostra desbalanço — uma CPU em 100% e outras ociosas é sintoma de single-thread bottleneck ou scheduling ruim.

perf — profiling de produção

Profiling no nível do sistema operacional. Pode atachar a processos vivos sem instrumentação prévia. Para diagnosticar "este processo está em 100% CPU mas eu não sei fazendo o quê":

# Sample por 30 segundos
sudo perf record -F 99 -p <pid> -g -- sleep 30

# Ver report
sudo perf report

# Flame graph (com Brendan Gregg's tools)
sudo perf script | flamegraph.pl > flame.svg

Brendan Gregg, em Systems Performance, codificou um catálogo de uso de perf que vale conhecer. Flame graphs em particular são a ferramenta visual mais informativa para análise de hot paths.

O método USE de Brendan Gregg

Quando você não sabe por onde começar, o método USE oferece um checklist sistemático. Para cada recurso (CPU, memória, disco, rede), verifique três coisas:

• Utilization: quanto está ocupado? (%)
• Saturation: quanto trabalho está em fila esperando?
• Errors: tem erros?

Para CPU: top (utilization), load average (saturation), dmesg (errors). Para memória: free -h (utilization), swap (saturation), dmesg | grep oom (errors). Para disco: iostat -x (todos os três). Para rede: ss -s, nstat, contadores de erro de interface em ip -s link.

A elegância do método é que ele força você a olhar tudo, em ordem, em vez de pular para a primeira hipótese. Em incidentes, a primeira hipótese costuma estar errada — porque é viesada pelo que você acabou de tocar ("commitei agora então é meu código"). USE é antiviés.

Padrões de diagnóstico — sintoma → ferramenta

Tabela mental para você acessar quando o pager apita:

• "Servidor lento": começa com top/htop para ver o que consome. Se CPU alto, perf top ou perf record. Se I/O alto, iostat + iotop. Se memória, free + top ordenado por mem.
• "App não responde": strace -p <pid> para ver se está fazendo algo, em quê travado. ss -tnp | grep <pid> para conexões em estados estranhos.
• "App caiu": journalctl -u app.service --since "10 min ago" para ver últimos logs. dmesg | grep -i kill para OOM. Se há core dumps, coredumpctl.
• "Conectividade intermitente": mtr destino.com para ver perda em hops; tcpdump filtrado para o tráfego suspeito. ss -i mostra retransmissões.
• "DNS estranho": dig +trace dominio para ver hierarquia. cat /etc/resolv.conf para resolvers configurados. Em containers, isso pode ser CoreDNS — verifique pods kube-system.
• "Disco cheio": df -h mostra uso por partição. du -sh /var/* | sort -h mostra o que ocupa diretório. ncdu é a versão interativa.

Ferramentas modernas e BPF

Os comandos clássicos têm complementos modernos baseados em eBPF (extended Berkeley Packet Filter), tecnologia Linux que permite executar pequenos programas sandboxed dentro do kernel. A coleção bcc-tools e o framework bpftrace dão acesso a observabilidade de baixo nível com overhead muito menor que ferramentas antigas:

• execsnoop: cada execução de programa, em tempo real.
• opensnoop: cada arquivo aberto. Substituto leve de strace para esse caso.
• tcpconnect, tcpaccept: conexões TCP novas.
• biolatency: latência de I/O por dispositivo.
• cachestat: cache hits/misses do page cache.

eBPF é o futuro de observabilidade Linux. Cilium, Pixie, Falco, Hubble — muitas ferramentas modernas se baseiam nele. Hoje você não precisa escrever programas BPF na mão; apenas saber que essa camada existe e que ferramentas tipo bcc dão acesso fácil.

Editor de fluxo de texto — sed, awk, jq

Logs e dados estruturados aparecem em todo lugar. Saber massagear texto na linha de comando economiza muito tempo:

• grep: básico, mas use -A, -B para contexto, -r para recursivo, -E para regex estendido.
• awk: para processar colunas. awk '{print $5}' pega a 5ª coluna. awk '$5 > 100 {print}' filtra.
• sed: edição de stream. sed 's/foo/bar/g' substitui.
• jq: para JSON. Dado que muitos logs modernos são JSON, jq é canivete suíço. jq '.user.email', jq 'select(.level == "error")'.
• cut, sort, uniq, wc: clássicos que combinados resolvem 80% dos casos.

Pipeline canônico para "top 10 IPs em log Nginx":

cat access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Como praticar

Não decore comandos — use-os. A familiaridade vem de aplicar em situações reais. Três exercícios:

1. Investigue um app que você não conhece. Suba qualquer coisa (Nginx, Postgres, um app teu). Use o método USE para descrevê-lo completamente: quanto consome de CPU/mem/disk/net, que portas escuta, que processos filhos tem, quais arquivos tem aberto. Não tem objetivo — é treino.
2. Provoque um problema e diagnostique. Suba um servidor que vaza FDs em loop. Use lsof e watch -n 1 'lsof -p PID | wc -l' para ver o número crescer. Quando o servidor cair, identifique a causa nos logs.
3. Capture e analise tráfego. Use tcpdump para capturar o tráfego de uma curl contra um servidor seu. Abra no Wireshark. Identifique handshake TCP, handshake TLS, request HTTP, response. Cada parte deveria ser identificável visualmente.