Como impedir que os registos do Docker encham o disco de arranque do anfitrião?

Pare o produtor imediato de registos, identifique o destino de registos ativo, aplique uma rotação limitada e corrija o erro ou o ciclo de reinício que está a causar a inundação.

Num NAS ou servidor doméstico baseado em Docker, a unidade de arranque pode ficar cheia mesmo quando os ficheiros multimédia e as bases de dados estão noutro conjunto de armazenamento, porque o stdout e o stderr dos contentores, os dados do journal do systemd e os ficheiros nativos das aplicações podem continuar a permanecer no sistema de ficheiros do sistema. A sequência segura consiste em preservar provas recentes suficientes, parar o crescimento descontrolado, classificar a camada de registo que ocupa o espaço, configurar a retenção para os serviços existentes e futuros e verificar se a aplicação subjacente deixou de emitir o mesmo volume.

Localize o Armazenamento de Registos Que Está Efetivamente a Crescer

Verifique o espaço livre no sistema de ficheiros da unidade de arranque e compare depois o tamanho da raiz de dados do Docker, dos ficheiros de registo de cada contentor, do journal do sistema e dos diretórios de registos das aplicações montados a partir do anfitrião. Registe os caminhos maiores antes de apagar ou truncar qualquer conteúdo.

Um caso de espaço em disco do Docker revelou que os resumos normais do Docker não mostravam o principal consumidor, porque o ficheiro de registo predefinido crescia separadamente. A prova decisiva foi um registo de contentor em crescimento contínuo no caminho de armazenamento local do Docker.

Inspecione o controlador de registos e o caminho de registo configurados para cada contentor em execução e associe o ficheiro maior ao nome do contentor e às mensagens recentes. Se nenhum registo de contentor explicar a utilização, continue com o journald e as pastas nativas das aplicações, em vez de presumir que todos os problemas de disco relacionados com o Docker pertencem ao json-file.

Pare o Contentor Ruidoso Antes da Limpeza de Emergência

Quando a unidade de arranque estiver quase cheia, pause ou pare o contentor que apresenta o crescimento mais rápido. Guarde uma quantidade limitada das linhas finais do registo, a contagem de reinícios, o estado de saída, a versão da imagem, o ambiente, os pontos de montagem e o primeiro erro repetido antes de libertar espaço.

Os administradores descobrem frequentemente que os registos JSON dos contentores podem consumir o espaço restante em disco quando não está configurado qualquer limite de tamanho. Uma longa discussão no Stack Overflow identifica o crescimento ilimitado dos registos JSON como um risco de capacidade separado dos dados de imagens e volumes.

Não apague cegamente um ficheiro de registo ativo enquanto o Docker ainda o tiver aberto e nunca remova diretórios arbitrários da árvore de metadados do Docker. Utilize o procedimento de rotação ou truncamento suportado pela plataforma apenas depois de parar o produtor e confirme que os blocos recuperados estão visíveis antes de reiniciar qualquer serviço afetado.

Aplique uma Rotação Limitada a Cada Serviço de Longa Duração

Defina um controlador de registos explícito e limites de rotação finitos na configuração do serviço Compose ou do contentor. Para o controlador JSON comum, os controlos importantes são um tamanho máximo de ficheiro e um número limitado de ficheiros retidos.

Uma discussão da comunidade Docker explica que opções como max-size e max-file limitam a quantidade de histórico local que um contentor retém. O requisito operacional é uma política de rotação finita, e não um único ficheiro em crescimento indefinido.

Escolha os limites com base na rapidez com que um incidente tem de ser diagnosticado e na quantidade de espaço em disco de arranque que o anfitrião pode reservar em segurança. Recrie o serviço para que o contentor em execução receba a nova configuração de registos, inspecione depois as definições efetivas e faça um pequeno teste controlado para confirmar que os ficheiros rodam conforme esperado.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Defina Predefinições para Futuros Contentores Sem Presumir Que Alteram os Existentes

Configure uma predefinição ao nível do daemon ou da plataforma para os contentores recém-criados, de modo que uma definição de serviço omitida não faça regressar silenciosamente o registo local ilimitado. Mantenha os serviços críticos livres para utilizarem uma substituição mais restrita quando as suas necessidades de diagnóstico forem diferentes.

Alterar uma predefinição de registo do Docker não reescreve retroativamente a configuração no anfitrião de todos os contentores existentes. As mesmas orientações da comunidade distinguem as predefinições do daemon das definições de criação por contentor, pelo que os serviços antigos têm de ser inspecionados e recriados deliberadamente.

Aplique a alteração primeiro a um serviço não crítico. Confirme que a obtenção de registos, a monitorização, os alertas e os fluxos de trabalho de suporte continuam a funcionar e, em seguida, recrie os restantes serviços em lotes controlados, sem remover os respetivos volumes persistentes.

Corrija o Evento Que Produz a Inundação de Registos

Os limites de rotação reduzem os danos, mas não corrigem um contentor que reinicia a cada poucos segundos, tenta repetidamente aceder a uma base de dados inacessível, regista cada verificação de estado, recebe um ataque ou uma inundação de pedidos ou ficou no modo de depuração após a resolução de um problema.

Um utilizador do Docker associou um registo JSON de aproximadamente 80 GB a uma saída de depuração excessiva, demonstrando como a saída ao nível de depuração pode sobrecarregar uma unidade de arranque, mesmo quando a rotação é a medida de proteção imediata.

Agrupe as mensagens repetidas por frequência e pelo primeiro carimbo temporal e corrija depois o erro de origem mais antigo. O guia ZimaSpace sobre como encontrar uma dependência num ciclo de reinício é o passo de diagnóstico seguinte quando falhas de ligação, montagem, segredo ou prontidão geram a tempestade de registos.

Acompanhe Separadamente os Registos do Docker, do Journald e Nativos das Aplicações

Um contentor pode enviar o stdout para o Docker e, simultaneamente, escrever os seus próprios ficheiros numa montagem bind, enquanto o próprio serviço Docker pode enviar eventos do daemon para o journald. Cada destino tem um responsável de retenção diferente e pode encher o mesmo sistema de ficheiros de arranque de forma independente.

Operadores de servidores domésticos relataram que os diretórios de registos das aplicações crescem apesar da expectativa de que a rotação ao nível do Docker os contenha. Um caso da comunidade TrueNAS realça a necessidade de identificar qual camada de registo é responsável pela retenção antes de ajustar os limites.

Registe uma linha de base pós-correção para a utilização do disco de arranque, os maiores ficheiros de registo, o tamanho do journal, as contagens de reinício dos contentores e o crescimento diário. A reparação só está concluída quando todos os destinos ativos têm uma política limitada, o serviço ruidoso permanece estável com a sua carga de trabalho normal e um reinício deliberado não recria ficheiros ilimitados.