Erro de serviço indisponível do peering de VPC 503 com TARGET_CONNECT_TIMEOUT

Esta é a documentação da Apigee e da Apigee híbrida.
Não há documentação equivalente do Apigee Edge para esse tópico.

Sintoma

Esse problema aparece como erros "503 - Serviço indisponível" no Monitoramento de APIs, Depuração ou em outras ferramentas. O motivo "TARGET_CONNECT_TIMEOUT" indica um tempo limite de conexão entre a instância da Apigee e o destino ao usar o peering de VPC.

O erro não deve ser confundido com outros erros de tempo limite, como 504 Gateway Timeout.

Mensagem de erro

Esse é o erro típico na sessão de depuração ou no payload de resposta. Observe o motivo: TARGET_CONNECT_TIMEOUT.

{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}

Causas possíveis

Essas causas são específicas da Apigee configurada com o peering de VPC. Consulte Opções de rede da Apigee. Se o destino for PSC (anexo de endpoint), consulte o playbook do PSC.

Causa	Descrição
Configuração incorreta de rotas	As rotas de destino não são exportadas para o peering com a instância da Apigee.
Problema de conectividade no destino	O destino nem sempre aceita uma conexão TCP.
Lista de permissões de IP no destino com alguns ou todos os IPs NAT da Apigee não adicionados	Nem todos os IPs NAT da Apigee estão na lista de permissões no destino.
Esgotamento da porta IP NAT	Não há portas NAT suficientes acomodadas para o tráfego.
connect.timeout.millis está definido como muito baixo	A configuração de tempo limite da conexão é muito baixa no lado da Apigee.

Etapas comuns do diagnóstico

A depuração é uma ferramenta essencial para capturar e avaliar os seguintes detalhes sobre o problema:

Duração total da solicitação. Geralmente, leva três segundos (padrão connect.timeout.millis) até que o tempo limite de conexão seja atingido. Se você perceber uma duração menor, verifique a configuração do endpoint de destino.
Nome do host de destino e endereço IP. O endereço IP errado exibido pode indicar um problema relacionado ao DNS. Talvez você também note uma correlação entre diferentes IPs de destino e o problema.
Frequência. Diferentes abordagens são necessárias dependendo se o problema é intermitente ou persistente.

Causa: configuração incorreta da rota

Diagnóstico

Se o problema for persistente, mesmo que tenha começado recentemente, ele pode ser causado por uma configuração incorreta da rota.

Isso pode afetar destinos internos (roteados dentro da VPC com peering) e externos (Internet).

Primeiro, identifique o endereço IP do destino resolvido a partir da instância da Apigee. Um dos métodos é usar uma sessão de Depuração. Em "Depuração", acesse AnalyticsPublisher (ou AX na depuração clássica):

Procure o valor de target.ip no lado direito da tela.

Neste exemplo, o IP é 10.2.0.1. Como esse intervalo é particular, ele exige que certas medidas de roteamento sejam implementadas para garantir que a Apigee possa alcançar o destino.

Se o destino estiver na Internet, será necessário seguir esta etapa se o VPC Service Controls estiver ativado para a Apigee, porque isso impede a conectividade de Internet.
Observe a região em que a instância afetada da Apigee está implantada. Na IU da Apigee no console do Cloud, clique em Instâncias. No campo Local, é possível encontrar a região exata da instância.
No projeto que está em peering com a Apigee, navegue até a seção Rede VPC -> Peering de rede VPC na interface. Se você estiver usando a VPC compartilhada, essas etapas precisarão ser executadas no projeto host, e não no projeto da Apigee.
Clique em servicenetworking-googleapis-com, selecione a guia servicenetworking-googleapis-com e filtre pela região recebida na Etapa 2.

Neste exemplo, mostramos a rota 10.2.0.0/24 como exportada e inclui o IP de destino 10.2.0.1. Se você não vir uma rota correspondente ao destino, essa é a causa do problema.
Observação: se o destino for externo, as rotas normalmente não estão presentes nas Rotas exportadas e as solicitações da Apigee são roteadas diretamente para a Internet. Como nem sempre esse é o caso, é importante esclarecer a topologia de rede desejada. Por exemplo, se o VPC Service Controls estiver ativado, também será necessário exportar rotas padrão ou outras para alcançar destinos externos.

Resolução

Revise sua arquitetura de rede e verifique se as rotas são exportadas para o peering de VPC com a Apigee. É provável que a rota ausente seja estática ou dinâmica. A falta de rotas dinâmicas necessárias indica um problema com o recurso correspondente, por exemplo, o Cloud Interconnect.

Observação: não há suporte ao peering transitivo. Ou seja, se a rede VPC N1 estabelecer peering com a N2 e a N3, mas a N2 e a N3 não tiverem uma conexão direta, a rede VPC N2 não poderá se comunicar com a rede VPC N3 por meio do Peering de redes VPC.

Consulte os padrões de rede de sentido sul para mais informações.

Causa: problema de conectividade no destino

Diagnóstico

O destino pode não estar acessível pela VPC ou não aceitar uma conexão. Há duas opções disponíveis para diagnosticar o problema.

Teste de conectividade (endereços IP de destino particular)

Se o destino estiver em uma rede privada, use o recurso Teste de conectividade para diagnosticar causas comuns.

Identifique o endereço IP do destino resolvido com base na instância da Apigee. Um dos métodos é usar uma sessão de Depuração.

Em "Debug", acesse AnalyticsPublisher (ou AX na depuração clássica). Procure o valor de target.ip no lado direito da tela.

Neste exemplo, o IP é 10.2.0.1. Esse é um endereço IP particular, o que significa que podemos usar o teste de conectividade.
Anote o endereço IP da instância da Apigee que não consegue se conectar ao destino. Em Instâncias no console da Apigee, encontre o endereço IP da instância da Apigee no campo Endereço IP.
Acesse Testes de conectividade e clique em Criar teste de conectividade. Informe estes detalhes:
1. Endereço IP de origem: use o IP da instância da Apigee conseguido na Etapa 2 acima. Esse não é o IP de origem exato usado pela Apigee para enviar uma solicitação ao destino, mas é suficiente para o teste, já que está na mesma sub-rede.
2. This is an IP address used in Google Cloud: deixe a opção desmarcada, a menos que o endereço esteja em algum dos seus projetos do Google Cloud. Se estiver verificando esse valor, forneça também o projeto e a rede.
3. Coloque o endereço de destino (Etapa 1) e a porta como o Endereço IP de destino e a Porta de destino respectivamente.
Clique em Criar e aguarde o teste terminar a primeira execução.
Na lista de testes de conectividade, clique em View para conferir os resultados da execução.
Se o resultado for "Inacessível", significa que você tem um problema com a configuração. A ferramenta direcionará você para a documentação de estados dos testes de conectividade para continuar. Se o status for "Acessível", isso eliminará muitos problemas de configuração. No entanto, isso não garante que a meta esteja acessível. Não houve uma tentativa real de estabelecer uma conexão TCP com o destino. Apenas o próximo diagnóstico abaixo ajudará a testar isso.

Teste de conectividade da VM (todos os destinos)

Na mesma VPC que faz peering com a Apigee, crie uma instância de VM no Linux.
Execute testes de conectividade da VM, de preferência no momento em que o problema puder ser reproduzido na Apigee. É possível usar telnet, curl e outros utilitários para estabelecer uma conexão. Este exemplo de curl é executado em um loop com um tempo limite de três segundos. Se o curl não conseguir estabelecer uma conexão TCP em três segundos, ele falhará.
```
for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done
```
Verifique a saída completa e procure este erro:
```
* Closing connection 0
 curl: (28) Connection timed out after 3005 milliseconds
```
A presença desse erro confirma que o problema pode ser reproduzido fora da Apigee.

Se você encontrar outros erros, como erros relacionados a TLS, códigos de status incorretos e outros, eles não confirmam o tempo limite da conexão e não estão relacionados ao problema.
Se o destino exigir uma lista de permissões de IP, talvez não seja possível testá-lo em uma VM, a menos que você também coloque o IP de origem da instância de VM na lista de permissões.

Resolução

Se você identificou um problema com base nos Testes de conectividade, prossiga com as etapas de resolução documentadas.

Se o tempo limite for reproduzido em uma VM, não haverá orientação definida sobre como resolver o problema no lado do destino. Quando o tempo limite da conexão puder ser reproduzido fora da Apigee, busque o problema mais adiante na VPC. Teste a conectividade o mais próximo possível do destino.

Se o destino estiver atrás de uma conexão VPN, você também poderá testá-lo a partir da rede local.

Se o destino estiver na Internet, tente reproduzir o problema fora do console do Google Cloud.

Se o problema ocorrer em horários de pico, o destino pode ficar sobrecarregado com conexões.

Se você precisar criar um caso de suporte do Google Cloud nessa etapa, não será mais necessário selecionar o componente da Apigee, já que o problema agora pode ser reproduzido diretamente pela VPC.

Causa: lista de permissões de IP no destino com alguns ou todos os IPs NAT da Apigee não adicionados

Diagnóstico

Isso diz respeito a destinos externos (a Internet) que têm a lista de permissões de IP ativada. Verifique se todos os IPs NAT da Apigee foram adicionados no lado do destino afetado. Se não houver lista de permissões no destino, pule esta seção.

O problema é mais fácil de detectar se os erros forem intermitentes, porque, nesse caso, você pode encontrar uma correlação entre IPs NAT específicos e os erros.

Se o problema for persistente (todas as chamadas estão falhando), verifique se os IPs NAT estão ativados na Apigee e busque-os com estas etapas:

Liste os IPs NAT de uma instância:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

Um exemplo de resposta:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

Se você não receber nenhum endereço na saída, os IPs NAT não serão adicionados no lado da Apigee. Se você receber endereços, mas nenhum deles estiver ACTIVE, nenhum dos endereços usados permitirá acesso à Internet, o que também é um problema.

Se você tiver pelo menos um endereço ATIVO, ele poderá ser incluído na lista de permissões no destino. Portanto, não há configuração incorreta do lado da Apigee. Nesse caso, o endereço pode estar ausente da lista de permissões no destino.

Se o problema for intermitente, isso pode indicar que apenas um subconjunto de IPs NAT foi colocado na lista de permissões no destino. Para identificar isso:

Crie um novo proxy reverso em que o destino afetado é especificado no TargetEndpoint. Também é possível reutilizar o proxy atual e passar para a próxima etapa:
Adicione uma política ServiceCall ao pré-fluxo de solicitação. Serviço deve chamar "https://icanhazip.com", "https://mocktarget.apigee.net/ip" ou qualquer outro endpoint público que retorne o endereço IP do autor da chamada na resposta. Armazene a resposta na variável "response" para que o conteúdo fique visível no Debug. Este é um exemplo de configuração de política ServiceCallout:
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
    <DisplayName>Service Callout-1</DisplayName>
    <Properties/>
    <Request clearPayload="true" variable="myRequest">
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>response</Response>
    <HTTPTargetConnection>
        <Properties/>
        <URL>https://icanhazip.com</URL>
    </HTTPTargetConnection>
</ServiceCallout>
```
Também é possível armazenar a resposta em uma variável personalizada, mas você precisaria ler o ".content" dessa variável com a políticaAssignMessage para revelá-lo na ferramenta de depuração.

Verifique se o destino está configurado exatamente da mesma maneira que no proxy afetado.

Observação: a solicitação ServiceCall e a solicitação Target precisam acontecer em uma única transação. Isso garante que o mesmo servidor processe uma solicitação para que o IP NAT da solicitação afetada corresponda ao IP NAT recebido da ServiceCallout.
Execute uma sessão de depuração e clique na etapa "ServiceCallout":
No canto inferior direito, você verá uma seção Conteúdo de resposta que contém o IP NAT (no corpo) da instância da Apigee que fez a solicitação. Como alternativa, se você armazenar a resposta ServiceCall em um lugar diferente, ela vai aparecer nesse local.

Mais adiante no fluxo, o proxy chamará o destino e o Conteúdo de resposta será substituído pelo erro ou uma resposta do destino.
Tente correlacionar os IPs NAT com o problema. Se você perceber que apenas IPs específicos falham, isso é um sinal de que alguns, mas não todos, IPs estão na lista de permissões no destino.
Se você não vir uma correlação entre os IPs NAT e os erros, por exemplo, se o mesmo IP falhar em uma solicitação, mas não na outra, é provável que o problema não seja de lista de permissões. Isso pode ser um esgotamento de NAT. Consulte Causa: esgotamento da porta IP NAT.

Resolução

Verifique se você tem IPs NAT provisionados e ativados e se todos eles foram adicionados no lado do destino.

Causa: esgotamento da porta IP NAT

Diagnóstico

Se o problema só for reproduzível da Apigee e IPs NAT forem provisionados para sua organização e você perceber que ele está acontecendo para destinos diferentes ao mesmo tempo, é possível que você esteja executando fora das portas de origem NAT:

Anote o período do problema. Por exemplo: diariamente entre 17h58 e 18h08.
Confirme se algum outro destino foi afetado pelo problema no mesmo período. Esse outro destino precisa estar acessível pela Internet e não pode estar hospedado no mesmo local do destino afetado original.
Estabelecer se erros só acontecem acima de um determinado volume de tráfego no TPS. Para fazer isso, observe o período do problema e navegue até o painel de desempenho do proxy.
Tente correlacionar a janela de tempo de erro com o aumento na média de transações por segundo (tps).

Nesse exemplo, o tps aumenta para 1.000 às 17h58. Supondo que, neste exemplo, às 17h58 é o momento exato em que o problema acontece e ele afeta dois ou mais destinos não relacionados, isso é um sinal de um problema com o esgotamento do NAT.

Resolução

Recalcule os requisitos de IP NAT usando as instruções em Como calcular os requisitos de IP NAT estático.

Você também pode adicionar mais IPs NAT e verificar se isso resolve o problema. Adicionar mais IPs pode exigir que eles sejam incluídos na lista de permissões em todos os destinos primeiro.

Causa: o valor de connect.timeout.millis está definido como muito baixo

Diagnóstico

O valor de tempo limite no proxy pode ter sido configurado incorretamente.

Para verificar, navegue até o proxy afetado e inspecione o TargetEndpoint em questão. Observe a propriedade "connect.timeout.millis" e o valor dela. Neste exemplo, o valor é 50, que é 50 milissegundos e geralmente é muito baixo para garantir o estabelecimento de uma conexão TCP. Um valor abaixo de 1.000 provavelmente é a causa do problema. Se a propriedade "connect.timeout.millis" não for exibida, o valor padrão será definido, e a causa não será confirmada.

Proxy com tempo limite

Resolução

Corrija o valor de connect.timeout.millis, lembrando que as unidades de tempo estão em milissegundos. O valor padrão é 3.000, ou seja, 3.000 milissegundos. Para mais informações, consulte a Referência de propriedades do Endpoints.

Entrar em contato com o Suporte para receber mais assistência

Se o problema persistir depois que você seguir as instruções acima, colete as seguintes informações de diagnóstico para o suporte do Google Cloud:

ID do projeto e nome da organização da Apigee
Nomes dos proxies e o ambiente
Prazo do problema
Frequência do problema
Destino (nome do host)
Depurar a sessão com o problema
Resultado das verificações realizadas para as possíveis causas acima. Por exemplo, a saída do comando curl de uma VM