APRENDER. PRATICAR. EVOLUIR.Seguir uma falha até ao pedido seguinte
O grupo passive usa A como primário, B como backup, max_fails=1 e fail_timeout=1s. A começa por devolver 503 e a configuração permite retry nessa condição. O primeiro pedido percorre A e B, terminando com 200; o seguinte vai diretamente para B. O resultado final positivo não elimina a primeira tentativa nem a exclusão temporária. Correlaciona os eventos do backend com upstream_addr e upstream_status no access log. Os grupos de upstream são separados para que a falha de um exercício não contamine o estado de outro.
Esperar não é verificar recuperação
O script altera o backend fictício para voltar a responder com sucesso e espera 2,2 segundos sem enviar pedidos. Não surgem eventos novos nesse intervalo. A espera ultrapassa o fail_timeout configurado, mas não executa um health check ativo. Só o pedido seguinte demonstra reentrada de A e resposta 200. Num incidente real, o fim do período não prova que a causa desapareceu. Se a aplicação continuar avariada, a nova tentativa pode falhar novamente. A recuperação precisa de prova da instância selecionada e do contrato funcional, não apenas de um temporizador terminado.
Testar as exceções de contagem
Dois grupos mostram por que não se deve memorizar uma regra universal de exclusão. Em noaccount, max_fails=0 desativa a contagem: dois pedidos percorrem A com 503 e B com 200. Os retries continuam ativos. Em single, existe apenas A; apesar de max_fails=1 e fail_timeout=60s, dois pedidos chegam a A e recebem 503, em conformidade com a exceção documentada de grupo único. Lê número de membros, opções e edição antes de diagnosticar uma configuração real. Zero, down, ausência de alternativas e retry são conceitos diferentes.
Separar retry e falha contabilizada
O grupo notfound permite retry em http_404. A devolve 404 e B devolve 200, em dois pedidos consecutivos. A volta a ser tentado porque 404 não conta como tentativa malsucedida para exclusão passiva, embora permita passagem ao próximo servidor quando configurado. Não uses a lista de retries como se fosse idêntica à lista de eventos contabilizados. O comportamento é específico de NGINX e das opções executadas. Para uma análise de APS, documenta condição, tentativas, resultado final e elegibilidade posterior, preservando os dois níveis de evidência.
Dar ao check o contrato correto
O backend de saúde é didático: responde 200 ao Host default.fund.test e 503 ao Host app.fund.test. As duas rotas do proxy diferem nesse cabeçalho. O ensaio mostra que uma resposta genérica pode ocultar falha do serviço pretendido, sem executar o módulo de checks ativos. Num portal real, define Host, caminho, estado e eventual conteúdo esperado de acordo com o contrato de prontidão. Mantém o check barato e interpreta dependências partilhadas. Repetir mais vezes um check do virtual host errado só aumenta o número de amostras irrelevantes.
Entregar provas e trabalho pendente ao RUN
Usa a grelha abaixo para simular uma reunião de passagem a RUN em inglês. Uma pessoa apresenta os resultados por pedido; outra verifica se sucesso foi servido pelo primário recuperado ou pelo backup. Acrescenta limites de concorrência, âmbito dos workers, critério de prontidão e ações quando todos os destinos ficam indisponíveis. O laboratório não executa cloud, Kubernetes, HAProxy ou carga de produção. Essas implementações precisam de provas próprias. Regista responsáveis e critérios de fecho para as lacunas. O workshop é proposto para estudo; não houve realização humana nem revisão independente especializada.
PROPOSED LOAD-BALANCING HANDOVER
Scope: NGINX version/build, workers, shared state, keepalive configuration.
Selection: method, weights, eligible targets, active-connection evidence.
Admission: max_conns scope, exhaustion response, remaining headroom.
Passive health: counted conditions, max_fails, fail_timeout, exceptions.
Readiness: Host, path, status/content contract and check cost.
Request evidence: final status, ordered upstream attempts, backend events.
Recovery: selected instance, functional result, repeat-failure handling.
Change: stop criteria, recovery action, owner and communication.
Outstanding: representative workload, multi-worker limits and real platform.
Statement: Bounded concurrency and passive-state checks passed;
representative capacity still needs validation.
No human workshop has been performed.
Exercício: um relatório mostra 200 finais enquanto A falha repetidamente. Reconstrói as tentativas, identifica max_fails=0 e escreve uma atualização de incidente que conserve sucesso do cliente e falha do primário.
Armadilhas comuns
Tratar espera como reparação, max_fails=0 como ausência de retries, 404 como falha contabilizada ou check genérico como prova da aplicação.
Tópicos relacionados: Algoritmos, afinidade e estado · Health checks e prontidão · Capacidade e falhas em cascata
A elegibilidade resulta de regras concretas. O fecho operacional exige identificar o destino, observar a recuperação e validar o contrato que o utilizador realmente usa.
Referência: NGINX retries and upstream headers · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior