Erro Sem Upstream Saudável – Guia Completo para Entender, Corrigir e Prevenir

Quando você vê um erro “Sem Upstream Saudável” de aplicações web, APIs ou serviços, isso geralmente sinaliza que seu balanceador de carga ou gateway esgotou seu pool de servidores backend saudáveis para passar solicitações.

Isso quer dizer que o “diretor de tráfego” não tem alvos válidos, e como tal, as solicitações de seus usuários não irão a lugar nenhum, o que significa uma conexão falhada, uma interrupção e clientes insatisfeitos.

Isso pode acontecer em praticamente qualquer tipo de configuração, como proxies reversos Nginx, clusters Kubernetes, contêineres Docker ou virtualizados como VMware vCenter, etc.

Agora, a causa raiz real variará com base na sua configuração, mas, em geral, aqui está o que deu errado: seus serviços upstream estavam ou fora do ar, oscilando com verificações de saúde, ou sendo bloqueados por alguma má configuração.

O que significa o erro “Sem Upstream Saudável”?

Um upstream, no contexto de arquiteturas balanceadas por carga ou malha de serviços, representa os servidores ou serviços backend que lidam com solicitações vindas de clientes.

O balanceador de carga ou gateway (por exemplo, Nginx, Envoy, API Gateway) toma a decisão sobre qual servidor upstream precisa assumir a responsabilidade por uma solicitação.

Se nenhuma das verificações de saúde configuradas passar em qualquer upstream, ou se você não conseguir alcançar nenhum deles, você receberá o erro Sem Upstream Saudável.

Cenários típicos onde isso aparece

• Falha na verificação de saúde devido a resposta lenta ou configuração incorreta.

• Os serviços backend não estão acessíveis devido a problemas de conectividade de rede.

• Se uma regra de roteamento estiver configurada incorretamente, o tráfego vai para alvos errados.

Exemplos em diferentes sistemas

• Nginx: [erro] sem upstreams ativos ao conectar ao upstream

• Kubernetes: 0/3 nós estão disponíveis: 3 nó(s) tinham taints que o pod não tolerou

• Docker: serviço “app” não está saudável

Causas Comuns em Todas as Plataformas

Embora a razão exata varie dependendo do ambiente, as causas mais comuns incluem:

2. Falhas ou desligamentos do serviço backend: O serviço para ou falha, e não há mais instâncias em execução.

3. Configurações de verificação de saúde incorretas: Se falhar, o balanceador de carga considera servidores saudáveis como “fora do ar”, removendo-os do pool.

4. Problemas de resolução de DNS: O nome de domínio do backend não pode ser resolvido para um endereço IP.

5. Desajuste de porta: A configuração das definições de upstream sobre uma porta incorreta que o serviço backend escuta.

6. Políticas de rede e firewalls: O balanceador de carga não pode se comunicar com o backend, pois está bloqueado por regras de segurança.

7. Expiração de certificado: Em configurações SSL/TLS, certificados expirados podem interromper conexões seguras.

8. Agendamento de pod ou taints de nó no Kubernetes: Condições de nó incompatíveis podem fazer com que os pods não sejam executados.

Como Diagnosticar o Erro

A fase inicial para resolver o erro Sem upstream saudável será determinar onde está falhando, seja no balanceador de carga, na rede ou no serviço backend.

Passo 1: Verificar Disponibilidade do Backend

• Para serviços Linux: systemctl status

• Para verificações de porta de rede: netstat -tulpn | grep

Passo 2: Testar Conectividade de Rede

• Do balanceador de carga para o backend:

# Exemplo (substitua os espaços reservados antes de executar):
curl -v :/

• Testar resolução de DNS: dig backend.example.com

Passo 3 – Revisar Logs

• Nginx: /var/log/nginx/error.log

• Kubernetes: kubectl describe pod

• Docker: docker logs

• vCenter: Logs de certificado e serviço

Passo 4 – Verificar Verificações de Saúde

• Certifique-se de que seu /health endpoint retorna um status 200 OK apropriado ou similar.

• Certifique-se de que o caminho e o método são o que o balanceador de carga está configurado para verificar.

Correções Específicas da Plataforma

A. Nginx

Se o Nginx mostrar sem upstreams ativos, listas geralmente são um sinal de um problema relacionado às suas definições de backend ou falha na verificação de saúde.

Lista de Verificação para Corrigir Nginx:

2. Confirme se os IPs/nome de host do backend estão corretos.

3. Verifique se os serviços backend estão em execução e acessíveis.

4. Ajuste as configurações de verificação de saúde:

upstream backend {
    server backend1.example.com:8080 max_fails=3 fail_timeout=30s;
    server backend2.example.com:8080 backup;
}

2. Opcionalmente, adicione verificações de saúde ativas (requer Nginx Plus ou um módulo):

check interval=3000 rise=2 fall=5 timeout=1000 type=http;
check_http_send "HEAD / HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;

B. Kubernetes

No balanceamento de carga do Kubernetes, você quer sondas de prontidão e mapeamento de serviço para pod.

Correções Comuns:

2. Certifique-se de que os pods estão em execução: kubectl get pods

3. Verifique as configurações da sonda de prontidão:

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

2. Verifique se os seletores de serviço correspondem aos rótulos do pod.

3. Inspecione as políticas de rede para tráfego bloqueado.

C. Docker

No Docker e Docker Compose, se as verificações de saúde para um contêiner estão passando, quando marcado como saudável.

Passos de Correção:

2. Revise o status de saúde do contêiner: docker inspect

Implemente ou corrija uma verificação de saúde em docker-compose.yml:

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost/health"]
  interval: 30s
  timeout: 10s
  retries: 3

2. Certifique-se de que seu serviço realmente serve o endpoint /health.

D. VMware vCenter

Frequentemente, a razão pode ser devido a certificados SSL expirados. Isso é mais relevante para usuários do vCenter. Veja como você verifica se os certificados estão expirados ou não:

• Inicialmente, inicie o vCenter Appliance.

• Execute este comando: for store in $(/usr/lib/vmware-vmafd/bin/vecs-cli store list | grep -v TRUSTED_ROOT_CRLS); do echo “[*] Store :” $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list –store $store –text | grep -ie “Alias” -ie “Not After”;done;

• Agora, veja se os certificados Machine_SSL e Solution User estão expirados. Se estiverem, substitua-os.

• Você também pode executar o vCenter Windows ou PowerShell para isso: $VCInstallHome = [System.Environment]::ExpandEnvironmentVariables(“%VMWARE_CIS_HOME%”);foreach ($STORE in & “$VCInstallHome\vmafdd\vecs-cli” store list){Write-host STORE: $STORE;& “$VCInstallHome\vmafdd\vecs-cli” entry list –store $STORE –text | findstr /C:”Alias” /C:”Not After”}

Ações de Recuperação Imediata

Se você precisar de uma restauração rápida enquanto trabalha na causa raiz:

• Tente reiniciar o serviço no backend, o que fornece serviços temporários na versão atualizada do Serviço Backend.

• Atualize DNS ou endereços IP se houver um problema de resolução.

• Adicione um servidor de backup ao bloco upstream como um manipulador temporário.

• Desative temporariamente as verificações de saúde ruins (não é uma solução permanente).

Prevenindo Erros Sem Upstream Saudável

A prevenção é sobre resiliência e visibilidade:

2. Melhores Práticas de Verificação de Saúde

• Cada serviço pode oferecer endpoints /health
• Se o serviço estiver ativo, ele apenas responde com um simples 200 OK.
• Esses limites de tempo + limite de tentativas devem realmente representar um desempenho real.

4. Redundância

• Use várias instâncias backend.
• Esteja sempre pronto para ativar pelo menos um servidor de backup a mais.

6. Monitoramento & Alertas

• Prometheus + Grafana, Datadog ou New Relic que podem alertá-lo antes da falha total do upstream.
• Monitore latência, taxas de erro e contagens de conexão.

8. Higiene de Configuração

• Mantenha os registros DNS atualizados.
• Documente portas de serviço e caminhos de verificação de saúde.
• Use disjuntores para evitar falhas em cascata.

10. Regras de Segurança & Rede

• Revise regularmente as regras de firewall e políticas de rede do Kubernetes
• Mantenha os certificados SSL atualizados.

Perguntas Frequentes

Posso corrigir isso sem acesso ao servidor?

Não, você precisa ser um administrador de sistema ou desenvolvedor para corrigir problemas de backend ou configuração, se houver algum.

É sempre um problema de backend?

Nem sempre, exceto quando é uma configuração de balanceador de carga ou DNS.

Quanto tempo leva para corrigir?

Máquinas de configuração menores podem ser corrigidas em minutos; problemas de rede ou escalonamento podem levar horas.

Isso afeta o desempenho mesmo antes da falha total?

Sim, falhas parciais do upstream podem levar a aumentos de latência e taxa de erro mesmo antes da interrupção total.

Quais ferramentas de monitoramento são as melhores?

Prometheus + Grafana, Datadog, New Relic e monitoramento nativo em nuvem são todos ótimos.

Considerações Finais

O erro Sem Upstream Saudável, parece ser mais do que apenas um bug vago; isso é um indicador de que o sistema que lida com solicitações para sua infraestrutura backend não tem acesso a esses backends.

Uma mensagem de erro para o usuário final e um item de ação para o Admin. Não importa se você está executando Nginx, Kubernetes, Docker e VMware; os princípios permanecem os mesmos. Monitore, verifique a configuração, confirme o acesso à rede e valide a saúde do serviço.

Através de uma combinação de correções rápidas e soluções de longo prazo, você pode reduzir significativamente a chance de que esse erro impacte seus serviços.