Logs e debugging de containers em produção

Quando algo dá errado em produção, você não tem um debugger anexado nem um terminal aberto olhando o processo — o que você tem são logs, um punhado de comandos do próprio Docker e, na pior das hipóteses, um container que nem chegou a subir. Saber usar essas ferramentas rápido é a diferença entre resolver em 2 minutos e ficar 1 hora tateando no escuro.

docker logs -f — acompanhando saída em tempo real

docker logs -f api
docker logs --tail 100 api    # só as últimas 100 linhas, sem o histórico inteiro

-f ("follow") mantém o terminal acompanhando a saída conforme ela é gerada — o equivalente a um tail -f de um arquivo de log, mas puxando direto do container. Funciona mesmo depois que o container já crashou (sem o -f), porque o Docker guarda a saída já produzida.

docker exec -it — entrando num container que já está rodando

docker exec -it api sh

Isso abre uma sessão interativa dentro do container já em execução — útil pra inspecionar um arquivo, checar uma variável de ambiente ou testar um comando pontual sem reconstruir nada. Não é lugar pra editar código: qualquer mudança feita ali dentro desaparece na próxima vez que o container for recriado, porque o sistema de arquivos do container não é a fonte de verdade — a imagem é.

docker stats — uso de recursos em tempo real

docker stats

Primeiro lugar pra olhar quando um serviço está lento ou reiniciando sozinho: se MEM USAGE está colado no limite, é candidato a estar sendo morto pelo OOM killer (lição de limites de recursos); se CPU % está constantemente em 100%+, o serviço está gargalado em processamento, não em memória.

Container que crashou vs container que nunca subiu

São dois problemas diferentes e pedem investigação diferente:

Crashou depois de rodar   O processo iniciou, rodou por um tempo, e morreu. "docker logs" tem
                          conteúdo útil: erro de aplicação, exceção não tratada, OOM.

Nunca chegou a subir      O container sai quase instantaneamente. Geralmente é o comando do
                          CMD/ENTRYPOINT com erro de sintaxe, um arquivo esperado que não existe
                          na imagem, ou uma variável de ambiente obrigatória faltando. "docker logs"
                          pode estar vazio ou ter só um erro de shell — o app nunca chegou a rodar
                          de verdade.

docker ps -a

docker ps -a (com o -a, mostra containers parados também) já entrega o código de saída — o próximo passo é sempre docker logs daquele container específico pra ver a mensagem de erro real.

Exit codes comuns

0     Sucesso — o processo terminou normalmente, sem erro
1     Erro genérico da aplicação — depende do que o processo reportou
137   SIGKILL (128 + 9) — geralmente o OOM killer matando o processo por estourar memória
139   Segmentation fault — o processo acessou memória inválida e travou
143   SIGTERM (128 + 15) — o processo recebeu um pedido de parada graciosa (ex.: "docker stop")