Logs de container e como não perdê-los

Quando um serviço cai, o log é a única fonte da verdade. Por padrão, o Docker o grava em um arquivo ao lado do contêiner e não impõe limite de tamanho: uma aplicação tagarela pode encher o disco inteiro em uma semana.

Como ler

docker logs -f --tail 100 <container>
docker compose logs -f app
docker compose logs --since 30m --timestamps app
docker logs <container> 2>&1 | grep -i error | tail -50

Vale lembrar: o Docker mostra o que a aplicação escreve na saída padrão e na saída de erro. Se ela gravar em um arquivo próprio dentro do contêiner, docker logs não mostrará nada — é preciso procurar o log lá dentro ou redirecionar a saída.

docker compose exec app ls -la /var/log

Limite o tamanho agora mesmo

A configuração global para todos os contêineres fica em /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "20m", "max-file": "3" }
}

sudo systemctl restart docker

A configuração vale para os contêineres criados após a reinicialização. Os que estão em execução precisam ser recriados. Para um único serviço, o mesmo vale no Compose:

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "20m"
        max-file: "3"

O resultado: no máximo 60 MB por serviço em vez de crescimento ilimitado.

Confira o tamanho atual antes que ele te surpreenda: sudo du -sh /var/lib/docker/containers/*/*-json.log | sort -h | tail. Não dá para reduzir um arquivo em uso com rm — o espaço não é liberado enquanto o Docker mantém o descritor. O jeito certo: recriar o contêiner ou sudo truncate -s 0 <file>.

Faça os logs sobreviverem ao contêiner

O arquivo de log é apagado junto com o contêiner. Se o histórico importa, entregue-o ao journal do sistema:

logging:
  driver: journald
  options:
    tag: "myapp"

journalctl -t myapp -n 200 --since today
journalctl -t myapp -p err --since "2 days ago"

O journald rotaciona os registros por conta própria e é limitado pela configuração SystemMaxUse em /etc/systemd/journald.conf. Para ver quanto espaço ele ocupa: journalctl --disk-usage.

Para vários serviços ao mesmo tempo, é mais prático coletar tudo em um só lugar — por exemplo, com um contêiner coletor dedicado que armazena os registros em arquivos por dia. Mas comece pelo journald: ele já está lá e não custa nada.

O que procurar ao depurar uma queda

1. As últimas 200 linhas antes da queda: docker logs --tail 200 <container>.
2. Código de saída: docker inspect -f '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>. Código 137 e true em OOMKilled significam que o kernel matou o processo por falta de memória — veja limites de recursos.
3. O log do sistema da máquina: sudo dmesg -T | tail -50 mostrará mortes por falta de memória e erros de disco.

Erros comuns

• O disco encheu de logs e todos os serviços caíram. Limitar o tamanho é obrigatório logo após instalar o Docker.
• Procurar o log de um contêiner já excluído. Depois de docker compose down ele se foi. Colete os registros no journald com antecedência.
• Segredos no log. As aplicações adoram imprimir strings de conexão com senhas. Qualquer pessoa com acesso à máquina pode ler o log.
• Procurar o erro no console de texto. Ele é sempre 80×24 e linhas longas são cortadas. Para ler logs, o SSH ou o console “Screen” é mais prático.