Porque é que as verificações de integridade dos contentores carregam um servidor doméstico inativo?

As verificações de saúde dos contentores carregam um servidor doméstico inativo porque são trabalhos agendados: cada sonda inicia um comando ou ligação e pede ao serviço para responder.

Uma verificação leve a cada minuto é insignificante. Uma stack com muitos contentores, intervalos curtos, sondas baseadas em shell, consultas a bases de dados, pesquisas DNS e horários sincronizados pode criar despertares contínuos da CPU, leituras de armazenamento, entradas de registos e tráfego de rede mesmo quando nenhum utilizador está ativo.

Uma Aplicação Inativa Continua a Ser Solicitada a Provar que Está Saudável

Um contentor pode ter um processo em execução enquanto a aplicação está bloqueada ou incapaz de servir pedidos. As verificações de saúde fecham essa lacuna de visibilidade executando um teste repetidamente. Um guia prático de verificação de saúde Docker mostra como uma sonda pode verificar condições HTTP, de base de dados e do sistema em vez de apenas verificar se o processo existe.

Esse teste útil não é gratuito. Uma sonda exec cria um processo dentro do contentor. Uma sonda HTTP abre uma ligação e passa pelo framework da aplicação. Um endpoint mais profundo pode adquirir uma ligação à base de dados, ler armazenamento, verificar credenciais ou chamar outro serviço.

O Tipo de Sonda Determina Quais Recursos São Despertados

Uma sonda TCP verifica que um socket aceita uma ligação, mas diz pouco sobre a correção da aplicação. HTTP pode exercitar o encaminhamento e o código da aplicação. As sondas exec podem iniciar um shell, interpretador ou binário cliente. Uma comparação de sondas de saúde explica porque as verificações de vivacidade, prontidão e arranque respondem a diferentes questões operacionais.

Num servidor pequeno, um shell mais uma utilidade de rede podem custar mais do que o endpoint que testam. Uma consulta a base de dados também impede que a base de dados e o armazenamento subjacente fiquem completamente silenciosos. A sonda correta é a mais superficial que pode suportar a ação tomada após a falha.

Intervalos Curtos Multiplicam-se na Stack de Contentores

Um intervalo de dez segundos significa 360 verificações por hora para um contentor. Multiplique isso por uma dúzia de serviços e o pequeno custo de cada verificação torna-se uma carga de fundo regular. Um caso reportado de verificações de saúde a aumentar a carga em contentores inativos mostra porque aumentar um intervalo demasiado curto pode reduzir a atividade constante da CPU.

Tempos limite e tentativas multiplicam ainda mais as verificações falhadas. Se uma dependência ficar lenta, cada sonda pode permanecer ativa até ao tempo limite enquanto chegam novas verificações. O sistema então gasta mais recursos a provar que está com problemas, o que pode atrasar a dependência e prolongar o incidente.

Verificações Sincronizadas Criam Picos Periódicos de Carga

Contentores iniciados em conjunto frequentemente herdam o mesmo intervalo e fase. As suas sondas podem disparar quase ao mesmo tempo, criando uma pequena manada estrondosa contra DNS, um proxy reverso ou uma base de dados. A carga média mantém-se baixa enquanto picos curtos interrompem pedidos interativos ou impedem que HDDs entrem em modo de espera.

O padrão geral da manada estrondosa explica porque pedidos concentrados são piores do que o mesmo número distribuído ao longo do tempo. Atrasos aleatórios no início, intervalos diferentes ou monitorização central podem reduzir o alinhamento de fases.

As Verificações de Saúde Devem Corresponder à Ação de Recuperação

Uma falha de vivacidade pode reiniciar um serviço, por isso a verificação deve evitar declarar a aplicação como morta porque uma dependência opcional está lenta. A prontidão pode ser mais rigorosa porque controla se o tráfego deve chegar. Uma verificação de arranque dá tempo de inicialização sem relaxar a vivacidade para sempre.

Um guia de temporização de verificação de saúde liga intervalo, tempo limite, tentativas e período de início ao estado resultante. Um artigo sobre dependências de arranque em servidores domésticos acrescenta o limite relacionado: a ordem de arranque por si só não prova que a base de dados, rede ou montagem está pronta.

Perguntas Frequentes

Deveriam as verificações de saúde ser desativadas num servidor doméstico inativo?

Não por defeito. Elas fornecem deteção útil de falhas. Reduza a profundidade e frequência desnecessárias e depois meça se as sondas restantes afetam materialmente o consumo de energia, ruído ou tempo de resposta.

É suficiente uma resposta HTTP 200 para provar que um contentor está saudável?

Prova apenas o que esse endpoint testa. Um endpoint superficial pode não detetar uma base de dados avariada; um endpoint profundo pode reiniciar uma aplicação saudável porque uma dependência opcional está lenta.

Porque é que os HDDs despertam quando os contentores estão inativos?

Os manipuladores de saúde podem escrever registos de acesso, consultar bases de dados, ler configurações ou atualizar métricas armazenadas no pool de HDD. O pedido da sonda é pequeno, mas os seus efeitos secundários tocam no armazenamento.