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.:

Visão geral do balanceador de carga de aplicativo externo
Geração de registros e monitoramento do balanceador de carga de aplicativo global e clássico
Geração de registros e monitoramento do balanceador de carga de aplicativo externo regional

Resolver problemas comuns com o Network Analyzer

O Network Analyzer monitora automaticamente as configurações da rede VPC e detecta configurações incorretas e não ideais. Ele identifica falhas de rede, fornece informações sobre a causa raiz e sugere possíveis soluções. Para saber mais sobre os diferentes cenários de configuração incorreta que são detectados automaticamente pelo Network Analyzer, consulte Insights do balanceador de carga na documentação do Network Analyzer.

O Network Analyzer está disponível no console do Google Cloud como parte do Network Intelligence Center.

Acessar o Network Analyzer

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.

Esta seção descreve como solucionar 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 seus back-ends.
Se statusDetails for qualquer outra mensagem de falha, a resposta 5XX será gerada pelo balanceador de carga.

Alterações na configuração do 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 resolver 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 todo o resto 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 acontecer 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 problemas no aplicativo de back-end e nas regras de firewall. Se as verificações de integridade estiverem sendo aprovadas, mas você ainda estiver vendo 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 Service Unavailable e HTTP 504 Gateway Timeout.
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 rotear a solicitação. Esse erro pode ocorrer por um dos seguintes motivos: Todas as regiões estão na capacidade ou acima dela. O balanceador de carga não consegue encontrar um 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. 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 estouro está restrito a um número limitado de grupos de instâncias alternativas. Se você observar `failed_to_pick_backend` ou `failed_to_pick_backend_by_hash`, apesar de ter grupos de instâncias íntegros, esvazie 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 impede a conexão com o 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 suas VMs de back-end ou na rede VPC permitem o tráfego para os back-ends dos intervalos 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) em busca de 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 acontecer quando você usa o GKE se os pods estiverem sendo reduzidos ou encerrados e os back-ends do balanceador de carga forem do tipo NEGs. Solução: Defina o tempo limite de 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 acontece quando os pods estão sendo reduzidos ou encerrados e os back-ends do balanceador de carga são NEGs. Para resolver isso, considere aumentar `terminationGracePeriodSeconds` na configuração do pod ou do deployment para permitir que as conexões atuais sejam fechadas de maneira normal. O valor ideal é: `T_grace > T_preStop + T_drain + T_buffer` Em que: `T_preStop` é a duração da suspensão do hook `preStop` do contêiner, que geralmente é 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 geralmente é de 60 segundos. `T_buffer` é um buffer adicional de 30 a 45 segundos para permitir que o pod seja desligado com segurança. Para configurações padrão, o valor recomendado é de pelo menos 210 segundos (3,5 minutos). Verifique os registros de aplicativos de back-end em busca de erros que possam causar o fechamento da conexão. Verifique as métricas da instância de back-end (CPU, memória, conexões) em busca de sinais de esgotamento de recursos.
`backend_timeout`	Causa:o GFE de segunda camada estabeleceu uma conexão com o back-end, mas ele 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 de aplicativos) que possam impedir uma resposta oportuna. 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 ferramentas de infraestrutura como código (como o Terraform) atualizarem as regras do balanceador de carga de forma que remova temporariamente as regras do mapa de URL antes de adicioná-las novamente ou devido a problemas transitórios internos de configuração ou rede do Google durante lançamentos ou envios de configuração. Solução: Se você estiver usando a automação, verifique se ela faz atualizações no local em vez de atualizações de exclusão e criação para regras de mapa de URL. Se esse erro aparecer durante ou após uma mudança 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 da 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.

Resolver problemas do gRPC

Se você estiver usando streaming gRPC bidirecional e o cliente se conectar a um balanceador de carga de aplicativo externo global, o servidor de back-end poderá ficar travado se um cliente realizar um fechamento parcial imediato (enviar uma flag END_STREAM imediatamente após a criação do stream sem enviar dados). Isso ocorre devido a um conflito entre a otimização do HTTP/2 e as especificações de enquadramento do gRPC.

O balanceador de carga de aplicativo externo global otimiza o tráfego HTTP/2 mesclando o frame HEADERS e o frame DATA vazio (com END_STREAM) do cliente em um único frame HEADERS com END_STREAM antes de encaminhá-lo ao back-end. Essa é a otimização padrão do HTTP/2 de acordo com a RFC 7540. O balanceador de carga realiza essa fusão de frames quando eles chegam quase simultaneamente (atraso de 0 ms).

Algumas implementações de servidor gRPC (como grpc-go) não aceitam o recebimento da flag END_STREAM em um frame HEADERS, fazendo com que o back-end espere indefinidamente. A especificação gRPC sobre HTTP/2 exige estritamente que o fim do stream (EOS) seja indicado pela flag END_STREAM no último frame DATA recebido.

Para evitar esse problema de travamento do servidor de back-end e de permanência da conexão aberta até que seja encerrada à força pelo cliente ao enviar um RST_STREAM, você pode aplicar uma das seguintes soluções alternativas:

Introduza um pequeno atraso (por exemplo, 10 ms ou mais) no lado do cliente antes de fechar parcialmente o fluxo. Isso impede que o balanceador de carga mescle os frames, porque o frame HEADERS já teria sido encaminhado.
Verifique se o cliente envia pelo menos uma mensagem de dados antes de fechar parcialmente o fluxo.
Se possível, mude para um balanceador de carga de aplicativo externo regional, que não mescla o frame HEADERS e um frame DATA vazio, encaminhando-os separadamente.

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 externo do aplicativo 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.

As respostas do meu back-end externo não são armazenadas em cache pelo Cloud CDN

Verifique se:

você ativou o Cloud CDN no serviço de back-end que contém o NEG que aponta para seu back-end externo configurando enableCDN como verdadeiro.
As respostas exibidas pelo back-end externo atendem aos requisitos de armazenamento em cache do Cloud CDN. Por exemplo, você está enviando cabeçalhos de resposta Cache-Control: public, max-age=3600 a partir da origem.

Resolver problemas de NEG sem servidor

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

As solicitações falham com um erro 404

Verifique se o recurso subjacente sem servidor, como um serviço do App Engine, as funções do Cloud Run ou Cloud Run, ainda está em execução. Se o recurso sem servidor for excluído, mas o NEG sem servidor ainda existir, o balanceador de carga de aplicativo externo continuará tentando encaminhar solicitações para o serviço que não existe mais. Isso resulta em uma resposta 404.

Em geral, um balanceador de carga de aplicativo externo não consegue detectar se o recurso subjacente sem servidor está funcionando conforme o esperado. Isso significa que, se o serviço em uma região estiver retornando erros, mas a infraestrutura geral do Cloud Run, as funções do Cloud Run ou App Engine nessa região estiver funcionando normalmente, o balanceador de carga de aplicativo externo não direcionará o tráfego automaticamente para outras regiões. Faça testes detalhados das novas versões dos serviços antes de encaminhar o tráfego de usuários para eles.

Como lidar com incompatibilidades de máscara de URL

Se a aplicação da máscara de URL configurada a um URL de solicitação do usuário não resultar em um nome de serviço ou se resultar em um nome de serviço que não existe, o balanceador de carga poderá lidar com essas incompatibilidades de maneira diferente, dependendo da plataforma de computação sem servidor em uso.

Cloud Run: no caso de uma máscara de URL incompatível, o balanceador de carga retorna um erro HTTP 404 (não encontrado).

Funções do Cloud Run: no caso de uma máscara de URL incompatível, o balanceador de carga retorna um erro HTTP 404 (não encontrado).

gateway de API: no caso de uma máscara de URL incompatível, o balanceador de carga retorna um erro HTTP 404 (não encontrado).

App Engine: no caso de uma máscara de URL incompatível, o App Engine usa dispatch.yaml e a lógica de roteamento padrão do App Engine para determinar para qual serviço enviar a solicitação.

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 o Análise de registros do console Google Cloud para analisar os registros gerados pelo balanceador de carga. Os problemas de gateway da tag do Google não afetam o código de resposta HTTP geral nem o statusDetails da solicitação de página da Web. A resposta HTTP será enviada sem modificação, 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 atendem ao conteúdo do site nos domínios em que o gateway da tag do Google está ativo. Configure isso no console Google Cloud acessando Balanceamento de carga > Editar > Configuração de back-end. Para mais informações, consulte Ativar o registro em um serviço de back-end atual. Uma taxa de amostragem de geração de registros 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 abranger o período em que você suspeita que os problemas ocorreram. Para mais informações, consulte Usar o seletor de períodos.
Para conferir os registros de solicitações processadas pelo plug-in de injeção do 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 pela ID do seu projeto.
Identifique possíveis erros examinando o campo jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. Isso mostra o status da própria 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 do 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 gateway da tag do Google não for OK, verifique o httpRequest.status e jsonPayload.statusDetails na mesma entrada de registro. Por exemplo, um grpcStatus não 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 do servidor.
- Frequência do problema: analisar os carimbos de data/hora e a frequência desses registros de erros ajuda a determinar se os problemas de injeção do gateway da tag do Google são contínuos, intermitentes ou relacionados a eventos específicos.

Se você encontrar problemas durante a configuração que a documentação não consegue resolver, 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.