← Docker: executar e diagnosticar contentores
06 / 12 · 40 MIN

Diagnóstico e recuperação

Usa estado, logs e recursos para recuperar o serviço com evidência.

Conceito e mecanismo

O diagnóstico começa pela instância correta e pelo intervalo da falha. Recolhe estado, comando efetivo, horários e alteração recente antes de substituir o contentor. docker inspect permite observar configuração e estado; docker logs depende do destino dos logs e do driver configurado. Uma saída vazia não demonstra ausência de erros se a aplicação escreve num ficheiro interno. O código 137 é compatível com terminação por SIGKILL, mas não prova sozinho falta de memória. Relaciona-o com OOMKilled, eventos e métricas no mesmo intervalo. Se alguém forçou a paragem, a explicação pode ser diferente de um limite de memória atingido. Conserva essa distinção no registo de incidente.

Aplicação guiada

Num exercício original, um worker sem limites compete com outras aplicações. Dimensiona memória e CPU com observações e capacidade do anfitrião, sem assumir que o isolamento cria recursos reservados. CPU shares traduz prioridade relativa sob contenção, não uma reserva fixa de processadores. Quando memory é 512 MiB e memory-swap é 768 MiB, o limite combinado deixa até 256 MiB para swap, dependendo do suporte e disponibilidade. Um restart pode restaurar serviço sem eliminar a causa; regista recorrência e valida processamento, ligações e backlog. Na passagem para a equipa seguinte, inclui identidade da imagem, configuração efetiva, estado persistente, sinais observados e limites da conclusão. Um processo running é apenas parte da evidência de recuperação.

NA PRÁTICA

137 mais OOMKilled=true e crescimento de memória apoia investigar memória; 137 isolado não fecha o diagnóstico.

Armadilhas comuns

Exit code como causa única; logs vazios como ausência de erro; restart como resolução permanente.

Tópicos relacionados: Processos e imagens · Build e distribuição · Rede e acesso

Leva esta ideia contigo

Recupera a função do serviço e conserva evidência suficiente para explicar a falha.

Criar conta

Referência: Memory and CPU constraints · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped

Docker® é uma marca registada de Docker, Inc. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por Docker. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.