O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Resolver problemas com balanceadores de carga de aplicativo externos

Neste guia, descrevemos como solucionar problemas de configuração de balanceadores de carga de aplicativos externos. Antes de investigar os problemas, conheça as páginas a seguir.:

Os back-ends têm modos de balanceamento incompatíveis

Ao criar um balanceador de carga, talvez você veja o erro:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Isso acontece quando você tenta usar o mesmo back-end em dois balanceadores de carga diferentes, e os back-ends não têm modos de balanceamento compatíveis.

Para ver mais informações, consulte os seguintes tópicos:

Resolver problemas gerais de conectividade

Erros 5XX inexplicáveis

Um erro "HTTP 5XX" pode ser retornado por um GFE de primeira camada, um GFE de segunda camada ou um back-end, dependendo de onde a condição de erro ocorre.

Nesta seção, descrevemos como resolver problemas de erros 5XX que podem ocorrer em diferentes estágios do processo de distribuição de solicitações para balanceadores de carga de aplicativo externos baseados no GFE.

Identificar a origem dos erros "5XX" usando o Cloud Logging

Para condições de erro causadas por um problema de comunicação entre o proxy do balanceador de carga e os back-ends, o balanceador de carga gera um código de resposta de erro HTTP (5XX) e retorna esse código de resposta de erro para o cliente. Nem todos os erros HTTP 5XX são gerados pelo balanceador de carga. Por exemplo, se um back-end envia uma resposta HTTP 5XX para o balanceador de carga, o balanceador de carga redireciona essa resposta para o cliente.

Para determinar se uma resposta HTTP 5XX foi redirecionada de um back-end ou se foi gerada pelo proxy do balanceador de carga, verifique o campo statusDetails no Cloud Logging.

Se statusDetails for response_sent_by_backend, o balanceador de carga retransmitiu a resposta 5XX do back-end. Resolva o problema nos back-ends.
Se statusDetails for qualquer outra mensagem de falha, a resposta 5XX será gerada pelo balanceador de carga.

As mudanças de configuração no balanceador de carga de aplicativo externo global, como a adição ou remoção de um serviço de back-end, podem resultar em um breve período em que você recebe respostas HTTP 502 com statusDetails como failed_to_pick_backend. Isso é normal durante a propagação de mudanças de configuração para GFEs no mundo todo.

Antes de começar a solucionar problemas, verifique a integridade do back-end

Antes de resolver problemas de erros 5XX, verifique se os back-ends estão íntegros e se as verificações de integridade estão sendo aprovadas. Se os back-ends não estiverem íntegros, o GFE de segunda camada não poderá encaminhar solicitações para eles, o que pode causar erros 5XX, mesmo que tudo esteja configurado corretamente.

Verifique se há uma regra de firewall configurada para permitir verificações de integridade. Na ausência de um, as verificações de integridade falham, e os registros do balanceador de carga podem mostrar um statusDetails de failed_to_pick_backend.
Confira se o tráfego de verificação de integridade atinge as VMs de back-end. Para fazer isso, ative a geração de registros de verificação de integridade e pesquise entradas de registro bem-sucedidas. Para novos balanceadores de carga, talvez você não veja entradas de registro de verificação de integridade bem-sucedidas imediatamente. Isso pode ocorrer porque o estado de integridade inicial do back-end ainda não mudou de UNHEALTHY para um estado diferente. Você verá entradas de registro de verificação de integridade bem-sucedidas somente depois que a sondagem de verificação de integridade receber uma resposta HTTP 200 OK do back-end.

Se as verificações de integridade estiverem falhando, resolva os problemas do aplicativo de back-end e das regras de firewall. Se as verificações de integridade forem aprovadas, mas você ainda estiver recebendo erros 5XX, verifique o campo statusDetails no Cloud Logging para identificar a origem do erro, conforme descrito na seção a seguir.

Resolver erros com base em `statusDetails`

Se os erros HTTP 5XX persistirem, use o campo statusDetails no Cloud Logging para identificar a causa e resolver o problema.

O balanceador de carga de aplicativo externo global e o balanceador de carga de aplicativo externo regional geram códigos de status HTTP significativos, como HTTP 503 Serviço indisponível e HTTP 504 Tempo limite do gateway.
O balanceador de carga de aplicativo clássico sempre usa o código de status HTTP 502 Bad Gateway para todos os erros gerados pelo balanceador de carga.

statusDetails	Possível causa e solução
`failed_to_pick_backend` `failed_to_pick_backend_by_hash`	Causa: o GFE de segunda camada não conseguiu selecionar um back-end íntegro para encaminhar a solicitação. Esse erro pode ocorrer por um dos seguintes motivos: Todas as regiões estão com a capacidade máxima ou acima dela. O balanceador de carga não consegue encontrar nenhum back-end disponível com base no hash calculado. O balanceador de carga não consegue encontrar back-ends que correspondam às configurações de serviço. Solução: Siga as etapas descritas em Verificar a integridade do back-end para confirmar se os back-ends estão íntegros. Verifique se as verificações de integridade estão configuradas corretamente com a porta, o caminho e o protocolo certos. Verifique se as regras de firewall de back-end permitem o tráfego de verificação de integridade das sondagens de verificação de integridade `35.191.0.0/16`. Se você tiver alguns grupos de instâncias de back-end não íntegros, observe que o failover ou o transbordamento é restrito a um número limitado de grupos de instâncias alternativos. Se você observar `failed_to_pick_backend` ou `failed_to_pick_backend_by_hash`, mesmo que tenha grupos de instâncias íntegros, drene os grupos de instâncias não íntegros definindo a capacidade deles como zero. Isso força o balanceador de carga a encaminhar o tráfego para os grupos de instâncias íntegros.
`failed_to_connect_to_backend`	Causa: o GFE de segunda camada não conseguiu estabelecer uma conexão com uma instância de back-end (não foi possível receber um SYN-ACK). Esse erro também pode ser causado por um erro interno do GFE que o impede de se conectar ao back-end ou por uma interrupção regional ou de rede (como um corte de fibra) que impede que os GFEs de primeira camada se comuniquem com os GFEs de segunda camada. Solução: Verifique se as regras de firewall nas VMs de back-end ou na rede VPC permitem o tráfego para os back-ends de intervalos do GFE de segunda camada `35.191.0.0/16`. Verifique se o aplicativo nas instâncias de back-end está em execução e detectando na porta configurada no serviço de back-end. Verifique as métricas da instância de back-end (CPU, memória, conexões) para identificar sinais de esgotamento de recursos.
`backend_connection_closed_before_data_sent_to_client`	Causa: a conexão entre o GFE de segunda camada e o back-end foi fechada inesperadamente antes que a resposta pudesse ser enviada ao cliente. Esse problema pode ser causado pelo servidor da Web de back-end ou por um dispositivo intermediário. Isso também pode ocorrer quando você usa o GKE se os pods estiverem reduzindo a escala vertical ou sendo encerrados, e os back-ends do balanceador de carga forem do tipo NEGs. Solução: Defina o tempo limite do sinal de atividade HTTP no servidor da Web de back-end (como Apache ou Nginx) para ser maior que o tempo limite de 600 segundos do balanceador de carga. O valor recomendado é de 620 segundos. Se você usa o GKE, isso ocorre quando os pods estão reduzindo a escala vertical ou sendo encerrados, e os back-ends do balanceador de carga são NEGs. Para resolver isso, aumente `terminationGracePeriodSeconds` no pod ou na configuração de implantação para permitir que as conexões atuais sejam fechadas corretamente. O valor ideal é: `T_grace > T_preStop + T_drain + T_buffer` Em que: `T_preStop` é a duração do sono do hook `preStop` do contêiner, que normalmente é de 120 segundos para permitir que o endpoint seja removido do NEG. `T_drain` é o tempo limite de diminuição da conexão do serviço de back-end, que normalmente é de 60 segundos. `T_buffer` é um buffer adicional de 30 a 45 segundos para permitir que o pod seja encerrado com segurança. Para configurações padrão, o valor recomendado é de pelo menos 210 segundos (3,5 minutos). Verifique se há erros nos registros do aplicativo de back-end que possam causar o fechamento da conexão. Verifique as métricas da instância de back-end (CPU, memória, conexões) para identificar sinais de esgotamento de recursos.
`backend_timeout`	Causa: o GFE de segunda camada estabeleceu uma conexão com o back-end, mas o back-end não enviou uma resposta dentro do tempo limite do serviço de back-end configurado. Solução: Se o aplicativo precisar de mais tempo para processar solicitações, aumente o tempo limite do serviço de back-end. Verifique se há problemas de desempenho nas instâncias de back-end (CPU, E/S, atrasos no aplicativo) que possam impedir uma resposta em tempo hábil. Se os back-ends estiverem sobrecarregados, considere escalonar os recursos de back-end ou otimizar o aplicativo.
`retriable_error`	Causa: esse erro 503 pode ocorrer se as ferramentas de infraestrutura como código (como o Terraform) atualizarem as regras do balanceador de carga de uma forma que remova temporariamente as regras do mapa de URL antes de adicioná-las novamente ou devido a problemas temporários de rede ou configuração interna do Google durante lançamentos ou envios de configuração. Solução: Se você estiver usando a automação, verifique se ela realiza atualizações no local em vez de atualizações de exclusão e criação para regras de mapa de URL. Se você encontrar esse erro durante ou após uma alteração de configuração, ele pode ser temporário. Aguarde alguns minutos para que a configuração seja propagada globalmente.

Como resolver erros HTTP `408`

Com o tráfego HTTP, o tempo máximo para o cliente concluir o envio da solicitação é igual ao tempo limite do serviço de back-end. Se você vir respostas HTTP 408 com o jsonPayload.statusDetail client_timed_out, significa que não houve progresso suficiente enquanto a solicitação do cliente foi colocada em proxy ou a resposta do back-end foi colocada em proxy. Se o problema for causado por clientes com problemas de desempenho, a solução é aumentar o tempo limite do serviço de back-end.

Tráfego com carga balanceada não tem endereço de origem do cliente original

O endereço IP de origem dos pacotes, como visto pelos back-ends, não é o endereço IP externo do balanceador de carga. Os balanceadores de carga baseados em proxy, como os de aplicativos externos, usam duas conexões TCP para transmitir o tráfego do cliente para os back-ends:

Conexão 1, do cliente original para o balanceador de carga (GFE ou sub-rede somente proxy)
Conexão 2, do balanceador de carga (GFE ou sub-rede somente proxy) para a VM ou o endpoint de back-end

Os endereços IP de origem e destino para cada conexão são diferentes com base no tipo de balanceador de carga de aplicativo externo que você está usando. Para detalhes, consulte Endereços IP de origem para pacotes de cliente .

Erro de permissão ao tentar visualizar um objeto em meu bucket do Cloud Storage

Para veicular objetos pelo balanceamento de carga, os objetos do Cloud Storage precisam ser publicamente acessíveis. Não se esqueça de atualizar as permissões dos objetos veiculados para que a leitura pública seja possível.

URL não exibe o objeto do Cloud Storage esperado

O objeto do Cloud Storage a ser veiculado é determinado com base no mapa de URL e no URL solicitado. Quando o caminho da solicitação aponta para um bucket de back-ends no mapa de URL, esse objeto é definido pelo acréscimo do caminho completo da solicitação ao bucket do Cloud Storage especificado no mapa.

Por exemplo, se você mapear /static/* para gs://[EXAMPLE_BUCKET], a solicitação para https://<GCLB IP or Host>/static/path/to/content.jpg tentará veicular gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Se esse objeto não existir, em vez dele, você receberá a seguinte mensagem de erro:


NoSuchKey
The specified key does not exist.

A compressão não funciona

O balanceador de carga de aplicativo externo não compacta nem descompacta as respostas, mas pode veicular as respostas geradas pelo serviço de back-end que foram compactadas usando ferramentas como gzip ou DEFLATE.

Se as respostas veiculadas pelo balanceador de carga não estiverem compactadas, mas deveriam estar, verifique se o software servidor da Web em execução nas instâncias está configurado para compactar as respostas. Por padrão, alguns softwares servidores da Web desativam automaticamente a compactação de solicitações que incluem um cabeçalho Via, que indica que a solicitação foi encaminhada por um proxy. Como é um proxy, o balanceador de carga de aplicativo externo adiciona um cabeçalho Via a cada solicitação, conforme exigido pela especificação HTTP. Para ativar a compactação, talvez seja necessário substituir a configuração padrão do seu servidor da Web para que ele compacte as respostas mesmo se a solicitação tiver um cabeçalho Via.

Para configurar back-ends do nginx (em inglês) para veicular respostas compactadas encaminhadas por meio de um balanceador de carga de aplicativo externo:

defina a diretiva gzip_proxied (em inglês) de forma adequada (por exemplo, a any);
defina a diretiva gzip_vary como on.

Para configurar back-ends do Apache para veicular respostas compactadas encaminhadas por meio de um balanceador de carga de aplicativo externo:

use o filtro DEFLATE (em inglês);
Adicione Vary Accept-Encoding ao cabeçalho de resposta usando o módulo mod_headers.

Solução de problemas de back-ends não íntegros

Solução de problemas com HTTP/2 para back-ends

Verifique se a instância de back-end está íntegra e aceita o protocolo HTTP/2. Para isso, teste a conectividade com a instância de back-end usando HTTP/2. Confira se a VM usa pacotes de criptografia compatíveis com a especificação HTTP/2. Por exemplo, determinados pacotes de criptografia do TLS 1.2 não são permitidos pelo HTTP/2. Consulte a Lista negra de pacotes de criptografia do TLS 1.2 (em inglês).

Depois de verificar que a VM usa o protocolo HTTP/2, confira se a configuração do firewall permite a passagem do verificador de integridade e do balanceador de carga.

Se não houver problemas com a configuração do firewall, verifique se o balanceador de carga está configurado para se comunicar com a porta correta na VM.

Solucionar problemas de queda de conexão para clientes que operam atrás de um NAT de nível de operadora

Quando um cliente se conecta a um balanceador de carga de aplicativo externo por um dispositivo com estado intermediário, como um NAT de nível de operadora (CGNAT, na sigla em inglês), o CGNAT rastreia cada conexão TCP ativa em uma tabela de estado. Muitos CGNATs aplicam um tempo limite de inatividade curto, menor que o tempo limite do sinal de atividade HTTP do cliente do balanceador de carga (610 segundos por padrão) e o tempo limite de conexão inativa no pool de conexões HTTP do cliente.

Se uma conexão permanecer inativa por mais tempo do que o tempo limite de inatividade do CGNAT, o CGNAT removerá silenciosamente a entrada de conexão da tabela de estado sem enviar um pacote TCP FIN ou RST para nenhum dos endpoints. Como o cliente e o balanceador de carga ainda consideram a conexão aberta, a próxima solicitação HTTP que o cliente enviar por essa conexão será descartada ou rejeitada pelo CGNAT, fazendo com que a solicitação falhe.

Para evitar quedas de conexão silenciosas para clientes que operam atrás de CGNATs ou outros dispositivos com estado, siga um destes procedimentos:

Reduza o tempo limite de conexão inativa no pool de conexões do cliente HTTP para um valor menor que o tempo limite de inatividade do CGNAT e o tempo limite de sinal de atividade HTTP do cliente do balanceador de carga para que o cliente feche as conexões inativas normalmente antes que o estado do NAT expire.
Configure keepalives no nível do aplicativo (como frames HTTP/2 PING periódicos) em um intervalo menor que o tempo limite de inatividade do CGNAT (mas pelo menos 30 segundos entre frames PING em conexões inativas para evitar a limitação de taxa). Embora os frames PING do HTTP/2 não redefinam o tempo limite de keepalive HTTP do cliente do balanceador de carga quando não há streams ativos, eles mantêm o mapeamento NAT intermediário ativo para que a conexão permaneça válida ou possa ser encerrada de maneira adequada.
Reduza o intervalo de sinal de atividade TCP do sistema operacional do lado do cliente (por exemplo, net.ipv4.tcp_keepalive_time no Linux) para um valor menor que o tempo limite de inatividade do CGNAT, para que as sondagens TCP de saída periódicas evitem que o mapeamento NAT expire. As sondagens de sinal de atividade TCP são processadas na camada de transporte e não redefinem o tempo limite do sinal de atividade HTTP do cliente do balanceador de carga.

Solucionar problemas de back-end externo e NEG da Internet

Antes de investigar os problemas, conheça as páginas a seguir.:

O tráfego não alcança os endpoints

Depois de configurar um serviço, o novo endpoint se torna acessível por meio do balanceador de carga de aplicativo externo quando:

o endpoint estiver anexado à Internet NEG;
for possível resolver o FQDN associado no DNS (se você estiver usando o tipo de endpoint FQDN);
o endpoint for acessível pela Internet.

Se o tráfego não alcançar o endpoint, o que resulta em um código de erro 502, consulte o registro TXT do DNS _cloud-eoips.googleusercontent.com usando ferramentas como dig ou nslookup. Observe os CIDRs (após ip4:) e verifique se esses intervalos são permitidos pelo firewall ou pela lista de controle de acesso (ACL, na sigla em inglês).

Depois de configurar um back-end externo, as solicitações para back-end externo falharam com um erro 5xx

Verifique a Geração de registros.
Verifique se o grupo de endpoints da rede está configurado com o IP:Porta ou FQDN:Porta corretos para o backend externo
Se estiver usando o FQDN, certifique-se de que ele pode ser resolvido por meio do DNS público do Google. É possível verificar se o FQDN pode ser resolvido por meio do DNS público do Google usando estas etapas ou a interface da Web diretamente.
Se estiver acessando o balanceador de carga somente no IP externo e seu servidor da Web de origem estiver esperando um nome de host, verifique se você está enviando um cabeçalho HTTP Host válido para seu back-end configurando um cabeçalho de solicitação personalizado.
Se estiver se comunicando com um back-end por HTTPS ou HTTP2 (conforme definido no campo protocol do serviço de back-end) configurado como um endpoint de back-end externo INTERNET_FQDN_PORT, certifique-se de que a origem apresenta um certificado TLS (SSL) e que o FQDN configurado corresponde a um SAN (nome alternativo do assunto) da lista de SANs dos certificados. Um certificado válido é aquele que foi assinado por uma autoridade de certificação pública e que não expirou.
Ao usar endpoints de back-end externos INTERNET_FQDN_PORT, os certificados autoassinados não são aceitos pelo balanceador de carga e são rejeitados.
Ao usar HTTPS ou HTTP/2 com endpoints do tipo INTERNET_IP_PORT, nenhuma validação de certificado SSL ou verificação de SAN é realizada. Isso significa que é possível usar certificados autoassinados. Ao usar SSL, recomendamos usar endpoints INTERNET_FQDN_PORT para garantir que os certificados de servidor e os SANs sejam validados.

Resolver problemas de injeção do gateway da tag do Google

O gateway da tag do Google não está injetando tags corretamente ou está causando erros.

Para resolver esse problema, use a Análise de registros do console do Google Cloud para analisar os registros gerados pelo balanceador de carga. Os problemas do gateway da tag do Google não afetam o código de resposta HTTP geral ou o statusDetails da solicitação da página da Web. A resposta HTTP será enviada sem modificações, mesmo que a injeção da tag do Google falhe. Para identificar erros de gateway, verifique o grpcStatus da execução do plug-in no payload JSON do balanceador de carga.

Verifique se o Cloud Logging está ativado nos serviços de back-end que veiculam o conteúdo do site para os domínios em que o gateway da tag do Google está ativo. Configure isso no console do Google Cloud acessando Balanceamento de carga > Editar > Configuração de back-end. Para mais informações, consulte Como ativar a geração de registros em um serviço de back-end atual. Uma taxa de amostragem de registro maior que 0.0 precisa ser definida para esse serviço de back-end.

No console do Google Cloud , acesse a página Análise de registros e selecione o projeto correto.

Acessar a Análise de registros
Ajuste o período para cobrir o momento em que você suspeita que os problemas ocorreram. Para mais informações, consulte Usar o seletor de período.
Para ver os registros de solicitações processadas pelo plug-in de injeção de gateway da tag do Google, use esta consulta:
```
resource.type="http_load_balancer" logName="projects/PROJECT_ID/logs/requests"  \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway"
```
Substitua PROJECT_ID pelo ID do projeto.
Identifique possíveis erros examinando o campo jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. Mostra o status da extensão do gateway da tag do Google.
- OK: a extensão concluiu o processamento sem um erro de gRPC.
- Qualquer valor diferente de OK (por exemplo, INTERNAL, UNAVAILABLE, DEADLINE_EXCEEDED): indica um erro na execução da extensão do gateway da tag do Google.

Para encontrar registros em que a extensão de gateway da tag do Google informou um erro, use a seguinte consulta:

resource.type="http_load_balancer" logName="projects/PROJECT_IDlogs/requests" \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway" NOT jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus="OK"

Quando a consulta anterior retornar resultados, examine toda a entrada de registro para correlacionar o status da extensão com o resultado da solicitação:
- Falha na extensão do gateway da tag do Google: um grpcStatus diferente de OK (especialmente no evento RESPONSE_BODY) significa que o processo de injeção de tag encontrou um erro. O código gRPC específico fornece pistas (por exemplo, DEADLINE_EXCEEDED indica um tempo limite).
- Impacto na solicitação do usuário: se o grpcStatus da extensão de gateway da tag do Google não for OK, verifique o httpRequest.status e o jsonPayload.statusDetails na mesma entrada de registro. Por exemplo, um grpcStatus que não seja OK combinado com httpRequest.status: 500 e jsonPayload.statusDetails: service_extensions_error sugere que a falha na extensão do gateway da tag do Google fez com que o usuário recebesse um erro de servidor.
- Frequência do problema: analisar os carimbos de data/hora e a frequência desses registros de erro ajuda a determinar se os problemas de injeção do gateway da tag do Google são contínuos, intermitentes ou estão relacionados a eventos específicos.

Se você tiver problemas durante a configuração que não podem ser resolvidos com a documentação, entre em contato com o suporte do Google Ads.

Resolver problemas com balanceadores de carga de aplicativo externos Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.