Linux e linha de comando
Processos, permissões, sinais e as ferramentas para investigar um servidor em produção.
As decisões aqui são práticas: quais ferramentas usar para cada pergunta, como investigar quando as ferramentas não estão disponíveis, como configurar limites e permissões, e como evitar que logs e arquivos temporários derrubem o servidor.
Uma ferramenta para cada pergunta
| Pergunta | Ferramenta | O que ela mostra |
|---|---|---|
| Quem está usando a CPU e a memória? | top, htop | Processos ordenados por uso, carga do sistema |
| Que processos existem e há quanto tempo? | ps aux, ps -o pid,stat,etime,cmd | Estado, tempo de execução, linha de comando |
| Quanta memória existe e está livre? | free -h, /proc/meminfo | Memória total, usada, em cache e disponível |
| O disco está cheio? | df -h, df -i | Espaço e inodes por sistema de arquivos |
| O que está ocupando o disco? | du -sh /caminho/* | Tamanho de cada pasta |
| Que conexões existem? | ss -tnp | Conexões TCP, estado e processo dono |
| Que arquivos o processo tem abertos? | ls -l /proc/<pid>/fd, lsof -p <pid> | Arquivos, conexões e pipes abertos |
| O que o processo está fazendo agora? | strace -p <pid> | As chamadas ao sistema em tempo real |
| O sistema matou algum processo? | dmesg, journalctl -k | Mensagens do núcleo, inclusive o OOM killer |
| O que o serviço registrou? | journalctl -u servico, docker logs, kubectl logs | Os logs da aplicação |
Um método para não se perder
Diante de um servidor lento, a tentação é olhar os logs da aplicação e mais nada. Um roteiro simples, que percorre cada recurso, encontra a causa mais rápido. Para CPU, memória, disco e rede, pergunte três coisas:
| Utilização | Saturação | Erros | |
|---|---|---|---|
| CPU | top: quanto está ocupada | Carga maior que o número de CPUs; tempo freado em containers | Raramente |
| Memória | free: quanto está em uso | Uso de swap; reinícios por falta de memória | dmesg: processos mortos pelo OOM killer |
| Disco | df: quanto está cheio | iostat: fila de espera do disco | No space left on device nos logs |
| Rede | Tráfego da interface | Conexões acumuladas em ss | Conexões recusadas ou esgotadas |
| Descritores | ls /proc/<pid>/fd | wc -l | Perto do limite de ulimit -n | Too many open files |
Esse roteiro se chama método USE (utilization, saturation, errors), e cobre a maior parte dos problemas de sistema em poucos minutos.
Investigar quando a imagem não tem ferramentas
Imagens mínimas, como as distroless recomendadas no tópico de containers, não têm shell nem ferramentas. As saídas:
| Situação | Como investigar |
|---|---|
| Docker | docker exec só funciona se houver shell. Sem shell, use um container de depuração que compartilha o espaço de processos: docker run -it --pid=container:<nome> --network=container:<nome> nicolaka/netshoot |
| Kubernetes | kubectl debug -it <pod> --image=busybox --target=<container> cria um container efêmero no mesmo pod, com acesso aos processos |
| Na máquina hospedeira | O processo do container aparece no ps do host; /proc/<pid> e strace -p <pid> funcionam de fora, com permissão |
O strace precisa da capacidade SYS_PTRACE. Em containers, ela não vem por padrão; o container de depuração precisa recebê-la (--cap-add SYS_PTRACE).
Limites de descritores
| Onde | Como configurar |
|---|---|
| Sessão do shell | ulimit -n 65536, até o limite máximo permitido |
| Serviço do systemd | LimitNOFILE=65536 na unidade do serviço |
| Container Docker | --ulimit nofile=65536:65536 |
| Kubernetes | Herdado do runtime de containers do nó |
Aumentar o limite resolve servidores que precisam de muitas conexões de verdade. Não resolve vazamento: um código que nunca fecha arquivos chega a qualquer limite, só demora mais. No teste do nível Conceito, o mesmo limite de 100 bastou para 500 aberturas quando o código fechava cada arquivo.
Permissões em containers
| Problema | Solução |
|---|---|
| A aplicação precisa gravar numa pasta da imagem | Criar a pasta no Dockerfile e dar a posse ao usuário da aplicação: RUN mkdir /app/dados && chown app:app /app/dados |
| Um volume montado pertence ao root | No Kubernetes, securityContext.fsGroup faz o volume pertencer ao grupo da aplicação; no Docker, ajustar a posse do diretório no host |
| A aplicação precisa da porta 80 ou 443 | Escutar numa porta acima de 1024 e mapear para a 80 no container ou no balanceador |
Logs e disco
| Prática | Por quê |
|---|---|
| Em containers, logs na saída padrão | O runtime coleta, e a aplicação não gerencia arquivos |
| Rotação no runtime do container | O Docker guarda os logs sem limite por padrão; configure max-size e max-file no driver json-file |
Fora de containers, logrotate ou o journald | Rotação e compressão automáticas |
| Alerta de disco acima de 80% | Tempo para agir antes do No space left on device |
| Arquivos temporários com limpeza | Uploads e relatórios temporários apagados ao terminar, e uma limpeza periódica para os que sobrarem |
Um detalhe que engana: apagar um arquivo de log grande que ainda está aberto pela aplicação não libera o espaço. O arquivo só deixa de existir quando o último processo o fecha. lsof +L1 lista arquivos apagados que ainda estão abertos; reiniciar o processo, ou truncar o arquivo com : > arquivo.log, libera o espaço.
Resumo da decisão
- Investigue por recurso: CPU, memória, disco, rede e descritores, com utilização, saturação e erros.
- Imagens mínimas pedem containers de depuração, e não ferramentas instaladas na imagem de produção.
- Vazamento de descritores se corrige no código; o limite só se aumenta para carga legítima.
- Permissões ajustadas ao usuário da aplicação, nunca com
777ou root. - Logs com rotação e alerta de disco.
O próximo nível mostra uma investigação real com essas ferramentas, o fechamento correto de recursos nas cinco linguagens e os comandos para cada problema deste tópico.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Roteiro de investigação de um servidor lento
Quero um roteiro para investigar um servidor Linux lento ou que parou de responder. Pergunte se é uma máquina virtual, um container Docker ou um pod no Kubernetes. Explique o método USE (utilização, saturação e erros) e monte comigo um roteiro para CPU, memória, disco, rede e descritores de arquivo, com o comando exato de cada verificação e o que indica problema na saída. Depois me apresente três incidentes simulados, um por vez, mostrando a saída dos comandos, e peça que eu identifique a causa. Corrija o meu raciocínio a cada passo.
Investigar containers sem ferramentas
Minhas imagens de produção são mínimas, sem shell e sem ferramentas. Quero saber como investigar problemas nelas. Pergunte se uso Docker ou Kubernetes. Explique: 1. Por que não instalar ferramentas na imagem de produção. 2. Como usar um container de depuração que compartilha os processos e a rede do container investigado. 3. No Kubernetes, como usar kubectl debug com containers efêmeros. 4. Como acessar o processo a partir da máquina hospedeira. 5. Que permissões o container de depuração precisa para usar strace. Termine com os comandos prontos para o meu ambiente.
Logs, disco e limites do servidor
Quero configurar o servidor ou os containers para que logs e arquivos não encham o disco, e para que os limites de recursos sejam adequados. Pergunte onde a aplicação roda e como os logs são coletados hoje. Explique, para o meu caso: 1. Rotação de logs: no Docker, no journald ou com logrotate. 2. Alertas de disco e de inodes. 3. Limpeza de arquivos temporários. 4. O limite de descritores de arquivo: como conferir e como ajustar. 5. Como encontrar arquivos apagados que ainda ocupam espaço.