Guia completo para limpar logs do Docker: 5 formas de evitar que o json.log ocupe todo o disco

Resumo rápido: contenha o problema antes de corrigi-lo de vez

Quando os logs do Docker ocuparem o disco, a ordem mais eficaz é:
primeiro, use truncate para conter o problema e liberar espaço; depois, configure a rotação com max-size + max-file; por fim, recrie os contêineres para que a configuração entre em vigor.
Se você apenas limpar, o problema voltará. Se apenas configurar, os contêineres antigos continuarão crescendo.

Às 3h17 da madrugada, a vibração do celular me arrancou de um sono leve.

Na tela piscava um alerta vermelho e incômodo: “Uso de disco do servidor de produção em 100%; todos os serviços pararam de responder”. Meu coração gelou naquele instante. Era uma plataforma de e-commerce com centenas de milhares de usuários, e cada minuto de indisponibilidade representava perda de dinheiro de verdade.

Entrei imediatamente no servidor por SSH. O df -h confirmou que a partição raiz estava cheia. Depois de uma rodada de verificações, encontrei o culpado no diretório /var/lib/docker/containers/: o arquivo xxx-json.log de um único contêiner tinha incríveis 82 GB!

Para ser sincero, fiquei sem entender nada. O contêiner estava funcionando normalmente; como o log tinha crescido tanto?

Depois descobri que esse não era um caso isolado. Por padrão, o Docker não limita o tamanho dos arquivos de log. Toda a saída de stdout e stderr é gravada no arquivo json.log, que cresce, cresce e continua crescendo até ocupar todo o disco.

Se os logs do Docker também estão tirando você do sério, não se preocupe. Este artigo mostra como fazer uma limpeza emergencial dos arquivos grandes, configurar a rotação para evitar que o problema volte e escolher o driver de log adequado para o seu caso. Reuni aqui os erros que já cometi para ajudar você a evitá-los.

Por que os logs do Docker ocupam todo o disco

Como o Docker armazena os logs

Primeiro, vamos entender como o Docker processa os logs.

Quando seu contêiner envia conteúdo para stdout e stderr por meio de console.log(), System.out.println() ou qualquer outro método, o Docker grava tudo em um arquivo de log no formato JSON. Esse arquivo fica em /var/lib/docker/containers/<container-id>/<container-id>-json.log.

Parece normal, certo? O problema é que o Docker não faz rotação de logs por padrão.

O que isso significa? O arquivo continua crescendo sem parar e nunca é dividido automaticamente nem tem seus registros antigos excluídos. Se o contêiner gerar 1 GB por dia, serão 7 GB em uma semana e 30 GB em um mês. Se a aplicação for especialmente tagarela — por exemplo, com o nível de log definido como DEBUG —, o crescimento pode ser assustadoramente rápido.

Fiz uma conta: se uma aplicação web de tráfego médio gerar 100 registros por segundo, com uma média de 100 bytes por registro, em um dia teremos:

100 registros/segundo × 86400 segundos × 100 bytes ≈ 864 MB/dia ≈ 25 GB/mês

Com dez contêineres desse tipo, um disco de 100 GB pode ficar cheio em menos de um mês. E essa ainda é uma estimativa conservadora.

Cenários em que o problema aparece com mais frequência

Pela minha experiência e pela de colegas próximos, estas são as situações mais perigosas:

1. Nível de log excessivamente detalhado

Durante o desenvolvimento, é comum definir o nível como INFO ou até DEBUG para facilitar a depuração e depois esquecer de alterá-lo ao implantar em produção. O resultado é que cada requisição HTTP gera uma pilha de informações de depuração e o log cresce sem controle.

O caso mais exagerado que já vi foi o de um serviço Node.js com o registro do corpo das requisições ativado. Sempre que um usuário enviava uma imagem, todo o texto em base64 era gravado. Uma única requisição produzia vários MB de log. Em menos de três dias, o disco de 200 GB ficou cheio.

2. Erros em loop no programa

Isso é ainda mais grave. Se um bug fizer sua aplicação entrar em loop infinito, gerando exceções e stack traces continuamente, a velocidade de crescimento do log pode ser desesperadora.

Em uma ocasião, um de nossos microsserviços teve um problema na configuração do pool de conexões com o banco de dados. Ele tentava se reconectar centenas de vezes por segundo e imprimia o stack trace completo em cada tentativa. Em três horas, o log de um contêiner saltou de 2 GB para 120 GB e derrubou o disco.

3. Contêineres de produção executados por longos períodos

Se o contêiner fica em execução contínua por meses ou até anos em produção e não tem rotação configurada, o volume acumulado de logs pode ser enorme.

Certa vez, assumi um projeto com um contêiner Nginx que estava em execução havia oito meses. Seu arquivo de log já tinha 150 GB. Sempre que alguém usava docker logs, era preciso esperar muito tempo porque o Docker tinha de ler aquele arquivo gigantesco.

4. Aplicações de alto tráfego

Aplicações com muitos acessos naturalmente geram mais logs. Mesmo que um site com milhões de pageviews diárias registre apenas uma linha por requisição, o volume acumulado será astronômico.

O ponto principal é que muita gente só percebe o problema quando o disco fica cheio de madrugada e o sistema cai. Só então descobre o tamanho da armadilha dos logs do Docker.

Limpeza emergencial: libere espaço em disco imediatamente

Muito bem: o disco já está cheio, o serviço caiu e seu chefe está marcando você sem parar no grupo. Não entre em pânico. Primeiro libere espaço; depois cuide do restante.

Etapa 1: encontre o culpado

Primeiro você precisa descobrir quais arquivos de log são os maiores. Execute este comando:

find /var/lib/docker/ -name "*.log" -exec ls -sh {} \; | sort -h -r | head -20

Ele lista os vinte maiores arquivos de log, em ordem decrescente de tamanho. A saída será parecida com esta:

82G /var/lib/docker/containers/a1b2c3d4.../a1b2c3d4...-json.log
35G /var/lib/docker/containers/e5f6g7h8.../e5f6g7h8...-json.log
12G /var/lib/docker/containers/i9j0k1l2.../i9j0k1l2...-json.log
...

Encontre os maiores e anote o container ID, aquela sequência longa de caracteres.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Para descobrir onde fica o log de um contêiner específico, use:

docker inspect --format='{{.LogPath}}' <container_name_or_id>

Por exemplo:

docker inspect --format='{{.LogPath}}' nginx
# Saída: /var/lib/docker/containers/abc123.../abc123...-json.log

Etapa 2: esvazie o log com segurança

Atenção: nunca exclua o arquivo de log diretamente com rm!

Eu também cometi esse erro no começo: executei rm -f xxx-json.log e o Docker ficou completamente perdido. O processo do Docker mantém um descritor aberto para esse arquivo. Depois da exclusão, ele continua gravando como se o arquivo ainda estivesse ali, mas, na prática, o espaço em disco não é liberado.

O procedimento correto é esvaziar o conteúdo sem excluir o arquivo.

Método 1: esvaziar com o comando cat

cat /dev/null > $(docker inspect --format='{{.LogPath}}' <container_id>)

Esse comando grava conteúdo vazio no arquivo. O arquivo continua existindo, mas passa a ter tamanho zero. O processo do Docker não percebe a mudança e segue funcionando normalmente.

Para esvaziar o log do contêiner nginx, por exemplo:

cat /dev/null > $(docker inspect --format='{{.LogPath}}' nginx)

Método 2: usar o comando truncate (recomendado)

truncate -s 0 $(docker inspect --format='{{.LogPath}}' <container_id>)

O truncate é mais direto e foi criado especificamente para truncar arquivos. A opção -s 0 define o tamanho como zero byte.

Para esvaziar o log do contêiner nginx:

truncate -s 0 $(docker inspect --format='{{.LogPath}}' nginx)

Método 3: esvaziar os logs de todos os contêineres em lote

Se todos os seus logs estiverem muito grandes e você quiser esvaziá-los de uma só vez, use:

sudo sh -c 'truncate -s 0 /var/lib/docker/containers/*/*-json.log'

Atenção: esse comando apaga o conteúdo de todos os logs de todos os contêineres. Use com cuidado. Antes de executar, confirme que você não precisa preservar nenhum log histórico.

Eu normalmente recorro a ele apenas em emergências. No dia a dia, prefiro limpar um por um para não perder registros importantes por engano.

Verifique o resultado

Depois da limpeza, execute df -h para conferir o espaço em disco:

df -h /var/lib/docker/

A taxa de uso deve cair de forma perceptível. Se isso não acontecer, talvez algum contêiner ainda esteja gravando logs sem parar. Nesse caso, primeiro resolva o problema da aplicação, como desativar logs DEBUG ou corrigir um erro em loop.

Quando limpei aquele arquivo de 82 GB, o uso do disco caiu imediatamente de 100% para 60% e os serviços voltaram a funcionar. Mas eu sabia que aquilo apenas tratava o sintoma. Para resolver de vez, era necessário configurar a rotação.

A solução definitiva: configure a rotação de logs

A limpeza emergencial só resolve a urgência. Para eliminar o problema, você precisa fazer o Docker gerenciar automaticamente o tamanho dos logs e impedir o crescimento ilimitado.

Configuração global: altere o daemon.json

O método mais simples e comum é definir os parâmetros de rotação no arquivo global de configuração do Docker.

Local do arquivo: /etc/docker/daemon.json

Se ele não existir, crie-o. Em seguida, adicione este conteúdo:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}

Veja o que cada parâmetro faz:

• max-size: tamanho máximo de cada arquivo de log. Ao atingir esse limite, ocorre a rotação e um novo arquivo é criado
• max-file: quantidade máxima de arquivos de log mantidos. Ao ultrapassar esse número, o mais antigo é excluído
• compress: define se os logs antigos serão compactados depois da rotação para economizar espaço

Com essa configuração, cada contêiner ocupa no máximo 10 MB × 3 = 30 MB de espaço para logs, sem considerar a compactação.

Valores recomendados para produção:

Com base na minha experiência e nas práticas comuns do setor, uma configuração de produção pode ser:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3",
    "compress": "true"
  }
}

O max-size: "100m" reserva mais espaço para os logs, o que ajuda na investigação de problemas. O max-file: "3" mantém três arquivos, equivalentes aos 300 MB mais recentes de histórico.

Você também pode ajustar os valores de acordo com o caso:

• Aplicações com pouco volume de logs: max-size: "10m", max-file: "3"
• Aplicações com volume médio: max-size: "50m", max-file: "3"
• Aplicações com grande volume: max-size: "100m", max-file: "5"

Aviso importante: todos os valores precisam estar entre aspas porque o Docker exige strings. Escrever "max-size": 10m sem aspas no valor causa erro.

Reinicie o Docker para aplicar a configuração

Depois de alterar o daemon.json, é preciso reiniciar o serviço do Docker:

sudo systemctl restart docker

Após a reinicialização, o Docker carrega a nova configuração. Mas há um detalhe muito importante: ela só vale para contêineres criados depois da mudança. Os contêineres que já estão em execução não são afetados.

O que fazer? Recriar os contêineres.

Se o contêiner foi iniciado com docker run:

docker stop <container_name>
docker rm <container_name>
docker run [parâmetros originais] <image>

Se você usa docker-compose:

docker-compose down
docker-compose up -d

O down interrompe e remove os contêineres; o up -d os recria com a nova configuração. A partir daí, os novos contêineres passam a usar a rotação de logs.

Configuração para um único contêiner

Às vezes, você não quer alterar a configuração global, apenas limitar o log de um contêiner especialmente tagarela. Nesse caso, informe os parâmetros ao iniciá-lo.

Com docker run:

docker run -d \
  --name my-app \
  --log-driver json-file \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  nginx:latest

Com docker-compose.yml:

version: '3.8'
services:
  web:
    image: nginx:latest
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
        compress: "true"

A vantagem dessa abordagem é a flexibilidade: cada contêiner pode ter uma estratégia diferente. Por exemplo:

• O contêiner Nginx pode manter mais logs: max-size: "50m", max-file: "5"
• Um contêiner de tarefa agendada menos importante pode usar: max-size: "5m", max-file: "2"

Verifique se a configuração entrou em vigor

Como confirmar que a configuração realmente foi aplicada? Use docker inspect para consultar a configuração de log do contêiner:

docker inspect <container_name> | grep -A 10 LogConfig

A saída será parecida com esta:

"LogConfig": {
    "Type": "json-file",
    "Config": {
        "max-file": "3",
        "max-size": "10m",
        "compress": "true"
    }
}

Se aparecer um objeto vazio, {}, o contêiner ainda está usando a configuração padrão, sem limite de crescimento. Nesse caso, você precisa recriá-lo.

Depois de configurar tudo, escrevi um pequeno script para verificar os logs de todos os contêineres e garantir que nenhum ficasse de fora. Desde então, nunca mais tive o disco lotado por esse motivo.

Guia para escolher o driver de log

Até aqui, falamos do driver padrão json-file. Mas o Docker oferece vários drivers de log, cada um com usos diferentes.

Você talvez esteja se perguntando: qual deles devo usar?

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

json-file (driver padrão)

É a opção padrão do Docker.

Vantagens:

• Compatível com o comando docker logs, o que facilita a investigação de problemas
• Configuração simples: basta adicionar max-size e max-file
• Armazenamento local com acesso rápido

Desvantagens:

• Não faz rotação por padrão e pode ocupar todo o disco — o principal problema tratado neste artigo
• Os logs ficam no host e são perdidos quando o contêiner é excluído

Quando usar: na maioria dos cenários. Com a rotação bem configurada, esse driver costuma ser suficiente.

Configuração recomendada:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3",
    "compress": "true"
  }
}

Driver local (recomendado)

Se você usa o Docker 18.09 ou uma versão mais recente, recomendo mais esta opção.

Vantagens:

• Rotação automática: já limita o tamanho dos logs por padrão, sem configuração manual
• Formato de arquivo mais eficiente e desempenho melhor que o json-file
• Também é compatível com o comando docker logs

Desvantagens:

• Exige Docker 18.09+
• O formato do log é binário e não pode ser lido diretamente com cat, embora isso geralmente não seja necessário

Quando usar: muito recomendado em produção. Exige menos manutenção e tem bom desempenho.

Como configurar:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

Hoje uso esse driver em todos os projetos novos. Ele realmente dá menos trabalho que o json-file.

Driver journald

Se o servidor usa systemd, como Ubuntu 16.04+ ou CentOS 7+, vale a pena considerar esse driver.

Vantagens:

• Integra-se aos logs do sistema e permite gerenciamento unificado
• Faz rotação automática e não ocupa todo o disco
• Oferece logs estruturados com metadados, como ID e nome do contêiner
• É compatível com os comandos docker logs e journalctl

Desvantagens:

• Só funciona em sistemas com systemd
• Pode haver uma curva de aprendizado para quem não conhece o journald

Quando usar: se sua operação já se baseia em systemd e journald, esse driver mantém tudo consistente.

Como configurar:

{
  "log-driver": "journald"
}

Para consultar os logs do contêiner com journalctl:

journalctl -u docker.service -f CONTAINER_NAME=my-app

Driver syslog

Esse driver é usado principalmente para enviar logs a um servidor syslog.

Vantagens:

• Pode enviar dados a um servidor syslog remoto para gerenciamento centralizado
• É compatível com TCP e UDP; TCP é mais confiável
• Integra-se facilmente a uma infraestrutura syslog existente

Desvantagens:

• Não é compatível com o comando docker logs, o que dificulta bastante a investigação de problemas
• Pode haver latência de rede
• Exige configuração e manutenção de um servidor syslog

Quando usar: em clusters de grande escala que já contam com um sistema syslog centralizado e maduro.

Como configurar:

{
  "log-driver": "syslog",
  "log-opts": {
    "syslog-address": "tcp://192.168.1.100:514",
    "syslog-facility": "daemon",
    "tag": "{{.Name}}/{{.ID}}"
  }
}

Para ser sincero, não costumo recomendar syslog sem uma necessidade específica. Perder o docker logs realmente atrapalha a investigação de problemas.

Minha recomendação

Escolha de acordo com o seu cenário:

Na minha prática, uso o driver local em projetos pequenos. Nos grandes, uso json-file em conjunto com Loki para centralizar os logs e mantenho localmente algumas centenas de MB para investigações emergenciais.

Independentemente do driver escolhido, lembre-se de um princípio: sempre limite o tamanho dos logs locais. Se eles puderem crescer sem controle, cedo ou tarde ocuparão todo o disco.

Boas práticas e recomendações operacionais

Depois de resolver o problema imediato, vamos falar sobre a operação no longo prazo.

Checklist de configuração para produção

Se você é responsável por um ambiente de produção, recomendo revisar esta lista:

1. Configuração global de logs

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

Ou use json-file:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3",
    "compress": "true"
  }
}

2. Verifique a configuração de todos os contêineres

Crie um script para confirmar que a rotação foi aplicada a todos eles:

#!/bin/bash
for container in $(docker ps -q); do
  name=$(docker inspect --format='{{.Name}}' $container | sed 's/\///')
  logconfig=$(docker inspect --format='{{json .HostConfig.LogConfig}}' $container)
  echo "Contêiner: $name"
  echo "Configuração de log: $logconfig"
  echo "---"
done

Execute uma vez e confirme que nenhum contêiner ficou de fora.

3. Configure monitoramento e alertas

Não espere o disco lotar para descobrir o problema. Configure alertas com antecedência:

• Uso de disco > 80%: aviso
• Uso de disco > 90%: alerta crítico
• Tamanho do diretório /var/lib/docker/containers/ acima do limite: aviso

Uso Prometheus + Grafana + Alertmanager, com uma configuração bem simples:

- alert: HighDiskUsage
  expr: (node_filesystem_size_bytes - node_filesystem_free_bytes) / node_filesystem_size_bytes > 0.8
  for: 5m
  annotations:
    summary: "Uso de disco acima de 80%"

4. Faça inspeções periódicas

Execute semanal ou mensalmente um script de verificação para descobrir quais contêineres têm os logs que mais crescem:

# Consultar o tamanho total do diretório do Docker
du -sh /var/lib/docker/

# Consultar o tamanho do diretório de logs
du -sh /var/lib/docker/containers/

# Encontrar os maiores arquivos de log
find /var/lib/docker/containers/ -name "*-json.log" -exec du -h {} \; | sort -h -r | head -10

Ao encontrar qualquer anomalia, resolva-a rapidamente.

Recomendações de otimização na aplicação

O gerenciamento de logs do Docker pertence à camada de infraestrutura, mas a aplicação também precisa colaborar.

1. Ajuste o nível de log

Não use DEBUG ou INFO em produção: eles geram detalhes demais. Minha recomendação é:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

• Produção: WARN ou ERROR
• Teste: INFO
• Desenvolvimento: DEBUG

Isso pode reduzir o volume de logs em pelo menos 80%.

2. Use um sistema dedicado de logs

Se sua aplicação gera muitos logs, não espere que o Docker dê conta sozinho. O ideal é:

• A aplicação enviar os dados diretamente para ELK (Elasticsearch + Logstash + Kibana)
• Ou usar Loki + Grafana, uma alternativa mais leve
• Ou usar o serviço de logs de um provedor de nuvem, como Alibaba Cloud SLS ou Tencent Cloud CLS

Mantenha no Docker apenas um pequeno volume dos registros mais recentes para investigações emergenciais.

3. Use logs estruturados

Gere logs estruturados no formato JSON para facilitar a análise:

// Prática ruim
console.log("Login do usuário realizado, ID do usuário: " + userId);

// Prática recomendada
console.log(JSON.stringify({
  level: "info",
  event: "user_login",
  userId: userId,
  timestamp: new Date().toISOString()
}));

Logs estruturados são mais fáceis de pesquisar e analisar.

4. Faça amostragem dos logs

Se algum tipo de registro tiver volume excessivo, como um log para cada requisição HTTP, considere usar amostragem:

// Registra apenas 10% das requisições
if (Math.random() < 0.1) {
  console.log("Detalhes da requisição HTTP...");
}

Outra opção é registrar detalhes apenas quando houver erro:

if (error) {
  console.log("Informações detalhadas da requisição: ", requestDetails);
}

Perguntas frequentes

P1: reiniciar o Docker depois de configurar o daemon.json afeta os contêineres em execução?

R: Não. Reiniciar o Docker não interrompe os contêineres, que continuam executando. No entanto, a configuração só é aplicada aos novos contêineres; os existentes precisam ser recriados.

P2: esvaziar o arquivo de log afeta a execução da aplicação?

R: Não. O processo do Docker mantém o descritor do arquivo aberto. Depois que você o trunca, o Docker continua gravando normalmente e a aplicação não percebe a mudança.

P3: se eu usar log-driver=journald, ainda preciso configurar max-size?

R: Não. O journald gerencia o próprio tamanho dos logs e tem seu próprio mecanismo de rotação.

P4: já configurei a rotação. Por que os logs ainda estão tão grandes?

R: Verifique dois pontos:

1. O contêiner foi recriado? O daemon.json só vale para novos contêineres
2. A aplicação está gerando linhas individuais gigantescas? A rotação considera o tamanho do arquivo, não o número de linhas

P5: posso excluir diretamente arquivos antigos em /var/lib/docker/containers/?

R: Você pode excluir os arquivos antigos que já passaram pela rotação, como xxx-json.log.1.gz. Não exclua o xxx-json.log atual; use truncate para esvaziá-lo.

Resumo dos cuidados importantes

Para finalizar, guarde estes pontos para evitar armadilhas:

1. A configuração do daemon.json só vale para novos contêineres; os existentes precisam ser recriados
2. Os valores dos parâmetros devem estar entre aspas, como "max-size": "10m", e não "max-size": 10m
3. truncate é seguro; rm é perigoso: use truncate para esvaziar os logs, não exclua os arquivos
4. Nem todos os drivers oferecem suporte a docker logs: syslog não oferece, enquanto json-file e journald oferecem
5. Reinicie o Docker depois de alterar o daemon.json com systemctl restart docker
6. Revise a configuração de logs regularmente para evitar que novos contêineres sejam implantados sem limites

Depois de tudo isso, o ponto central é simples: configure com antecedência, verifique regularmente e não espere o disco lotar para agir.

Conclusão

Voltando ao alerta das 3h da madrugada que mencionei no início.

Naquele dia, passei meia hora limpando os logs, duas horas configurando a rotação e o monitoramento e depois recriei todos os contêineres. Só terminei às 6h da manhã.

Mas o incidente me ensinou uma lição: o gerenciamento dos logs do Docker não pode ser ignorado. É como uma bomba-relógio invisível no dia a dia, mas capaz de causar um grande problema quando explode.

Estes são os pontos principais do artigo:

Em uma emergência: use truncate para esvaziar os arquivos de log grandes, liberar espaço imediatamente e restabelecer os serviços.

Para prevenir: configure a rotação no daemon.json com max-size + max-file, escolha um driver adequado — recomendo local ou json-file — e recrie todos os contêineres para aplicar a configuração.

Na operação de longo prazo: configure alertas de uso de disco, revise as configurações regularmente e otimize a geração de logs da aplicação.

Se você usa Docker hoje, seja em desenvolvimento ou em produção, recomendo verificar agora mesmo:

1. Execute find /var/lib/docker/ -name "*.log" -exec ls -sh {} \; | sort -h -r | head -10 para procurar arquivos de log muito grandes
2. Verifique se /etc/docker/daemon.json tem a rotação configurada
3. Use docker inspect para confirmar que todos os contêineres estão sujeitos aos limites de log

Não espere um alerta acordar você de madrugada para perceber o problema.

Se este artigo ajudou, compartilhe com outras pessoas que possam enfrentar a mesma armadilha. Assim, todo mundo perde menos tempo com problemas e ganha mais horas de sono.

Próximas leituras

• Diagnóstico de encerramento inesperado de contêineres Docker: Exit Code 137/1
• Guia de limites de recursos do Docker: CPU, memória e estabilidade
• Guia para consultar e analisar logs do Docker