Erro 503 Serviço indisponível com TARGET_CONNECT_TIMEOUT (alvos de peering de VPC e Internet)

Está a ver a documentação do Apigee e do Apigee Hybrid.
Não existe um equivalente na documentação do Apigee Edge para este tópico.

Sintoma

Este problema aparece como erros "503 – Serviço indisponível" na monitorização da API, depuração ou noutras ferramentas. O motivo "TARGET_CONNECT_TIMEOUT" indica um limite de tempo de ligação entre a instância do Apigee e o destino da Internet ou um destino acessível com o intercâmbio da VPC.

Não deve confundir este erro com outros erros de limite de tempo excedido, como o erro 504 Gateway Timeout.

Mensagem de erro

Este é o erro típico na sessão de depuração ou no payload da resposta. Tenha em atenção 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

Tenha em atenção que estas causas são específicas de destinos de Internet ou destinos acessíveis com o VPC Peering. Consulte as opções de rede do Apigee. Se o destino for o PSC (anexo do ponto final), consulte o manual de procedimentos do PSC.

Causa	Descrição
Erro de configuração de rotas	Os encaminhamentos de destino não são exportados para a interligação com a instância do Apigee.
Problema de conetividade no destino	O destino nem sempre consegue aceitar uma ligação TCP.
Lista de autorizações de IPs no destino com alguns ou todos os IPs NAT do Apigee não adicionados	Nem todos os IPs NAT do Apigee estão na lista de autorizações no destino.
Esgotamento da porta IP NAT	Não existem portas NAT suficientes para o tráfego.
O valor connect.timeout.millis está definido como demasiado baixo	A definição de limite de tempo de ligação é demasiado baixa no lado do Apigee.

Passos de diagnóstico comuns

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

• Duração total do pedido. Normalmente, demora três segundos (predefinição connect.timeout.millis) até ocorrer um limite de tempo da ligação. Se notar uma duração inferior, verifique a configuração do ponto final de destino.
• Nome do anfitrião de destino e endereço IP. A apresentação do endereço IP errado pode indicar um problema relacionado com o DNS. Também pode notar uma correlação entre diferentes IPs de destino e o problema.
• Frequência. São necessárias abordagens diferentes consoante o problema seja intermitente ou persistente.

Causa: erro de configuração do trajeto

Diagnóstico

Se o problema persistir, mesmo que tenha começado recentemente, pode ser causado por uma configuração incorreta do trajeto.

Isto pode afetar alvos internos (encaminhados na VPC com peering) e externos (Internet).

1. Primeiro, identifique o endereço IP do destino resolvido a partir da instância do Apigee. Um dos métodos consiste em usar uma sessão de depuração. Na depuração, navegue para AnalyticsPublisher (ou AX na depuração clássica):
   
   

   Procure o valor target.ip no lado direito do ecrã.

   Neste exemplo, o IP é 10.2.0.1. Uma vez que este intervalo é privado, requer a implementação de determinadas medidas de encaminhamento para garantir que o Apigee consegue alcançar o destino.

   Tenha em atenção que, se o destino estiver na Internet, tem de seguir este passo se os VPC Service Controls estiverem ativados para o Apigee, uma vez que isso impede a conetividade à Internet.

2. Tenha em atenção a região onde a instância do Apigee afetada está implementada. Na IU do Apigee na consola do Google Cloud, clique em Instâncias. No campo Localização, pode encontrar a região exata da instância.
   
   
   
3. No projeto com intercâmbio com o Apigee, navegue para a secção Rede VPC -> Intercâmbio de redes VPC na IU. Tenha em atenção que, se estiver a usar a VPC partilhada, tem de executar esses passos no projeto anfitrião em vez do projeto do Apigee.
   
   
4. Clique em servicenetworking-googleapis-com, selecione o separador ROTAS EXPORTADAS e filtre pela região obtida no passo 2.
   
   Este exemplo mostra o encaminhamento 10.2.0.0/24 exportado e inclui o IP de destino de exemplo 10.2.0.1. Se não vir um percurso correspondente ao seu destino, esse é o motivo do problema.
   
   Nota: se o destino for externo, normalmente, os encaminhamentos não estão presentes nos encaminhamentos exportados e os pedidos do Apigee são encaminhados diretamente para a Internet. Isto pode nem sempre ser o caso, por isso, certifique-se de que esclarece a topologia de rede pretendida. Por exemplo, se os VPC Service Controls estiverem ativados, também tem de exportar rotas predefinidas ou outras para alcançar destinos externos.
   
   

Resolução

Reveja a arquitetura da sua rede e certifique-se de que as rotas são exportadas para a interligação de VPCs com o Apigee. É provável que a rota em falta seja estática ou dinâmica. A falta de rotas dinâmicas necessárias indica um problema com a funcionalidade correspondente, por exemplo, o Cloud Interconnect.

Tenha em atenção que o intercâmbio transitivo não é suportado. Por outras palavras, se a rede da VPC N1 estiver ligada à N2 e à N3, mas a N2 e a N3 não estiverem diretamente ligadas, a rede da VPC N2 não pode comunicar com a rede da VPC N3 através do intercâmbio das redes da VPC.

Pode ler os padrões de rede de saída para mais informações.

Causa: problema de conetividade no destino

Diagnóstico

O destino pode não estar acessível a partir da VPC ou não conseguir aceitar uma ligação. Estão disponíveis duas opções para diagnosticar o problema.

Teste de conetividade (endereços IP de destino privados)

Se o destino estiver numa rede privada, pode usar a funcionalidade Teste de conetividade para diagnosticar causas comuns.

1. Identifique o endereço IP do destino resolvido a partir da instância do Apigee. Um dos métodos consiste em usar uma sessão de depuração.
   
   Na depuração, navegue para AnalyticsPublisher (ou AX na depuração clássica). Procure o valor target.ip no lado direito do ecrã.
   
   Neste exemplo, o IP é 10.2.0.1. Este é um endereço IP privado, o que significa que podemos usar o teste de conetividade.
   
   
2. Tome nota do endereço IP da instância do Apigee que não consegue estabelecer ligação ao destino. Em Instances (Instâncias) na consola do Apigee, encontre o endereço IP da instância do Apigee no campo IP Address (Endereço IP).
   
   
3. Aceda a Testes de conetividade e clique em Criar teste de conetividade. Indique estes detalhes:
   1. Endereço IP de origem: use o IP da instância do Apigee obtido no passo 2 acima. Tenha em atenção que este não é o IP de origem exato usado pelo Apigee para enviar um pedido para o destino, mas é suficiente para o teste, uma vez que está na mesma sub-rede.
   2. Este é um endereço IP usado no Google Cloud: deixe a caixa desmarcada, a menos que o endereço esteja em qualquer um dos seus projetos do Google Cloud. Se verificar este valor, também tem de indicar o projeto e a rede.
   3. Introduza o endereço de destino (passo 1) e a porta como o endereço IP de destino e a porta de destino, respetivamente.
   
4. Clique em Criar e aguarde que o teste conclua a primeira execução.
5. Na lista de testes de conetividade, clique em Ver para ver os resultados da execução.
6. Se o resultado for "Inacessível", significa que tem um problema com a configuração. A ferramenta deve direcionar para a documentação sobre os estados dos testes de conetividade para continuar. Se o estado for "Acessível", isso exclui muitos problemas de configuração. No entanto, isto não garante que o alvo seja alcançável. Não houve uma tentativa real de estabelecer uma ligação TCP com o destino. Apenas o diagnóstico seguinte ajuda a testar isso.
   
   

Teste de conetividade de VM (todos os destinos)

1. Na mesma VPC que está em peering com o Apigee, crie uma instância de VM no Linux.
2. Faça testes de conetividade a partir da VM, de preferência no momento em que o problema é reproduzível a partir do Apigee. Pode usar o telnet, o curl e outras utilidades para estabelecer uma ligação. Este exemplo de curl é executado num ciclo com um limite de tempo de três segundos. Se o curl não conseguir estabelecer uma ligação TCP em três segundos, falha.

   for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done

3. Verifique o resultado completo e procure este erro:

   * Closing connection 0
    curl: (28) Connection timed out after 3005 milliseconds

   A presença deste erro confirma que o problema é reproduzível fora do Apigee.

   Tenha em atenção que, se vir outros erros, como erros relacionados com TLS, códigos de estado inválidos, etc., Não confirmam o limite de tempo da ligação e não estão relacionados com este problema.

4. Se o destino exigir a adição de IPs à lista de autorizações, pode não conseguir testá-lo a partir de uma VM, a menos que adicione também o IP de origem da instância de VM à lista de autorizações.

Resolução

Se identificou um problema com base nos testes de conetividade, avance com os passos de resolução documentados.

Se o limite de tempo for reproduzido a partir de uma VM, não existem orientações definitivas sobre como resolver o problema no lado de destino. Assim que o tempo limite de ligação for reproduzível fora do Apigee, investigue o problema mais a fundo a partir da VPC. Tente testar a conetividade o mais próximo possível do alvo.

Se o destino estiver atrás de uma ligação VPN, também pode testá-lo a partir da rede local.

Se o destino estiver na Internet, pode tentar reproduzir o problema fora da Google Cloud Console.

Se o problema ocorrer nas horas de ponta, o destino pode ficar sobrecarregado com ligações.

Se precisar de apresentar um registo de apoio técnico do Google Cloud nessa fase, já não tem de selecionar o componente do Apigee, uma vez que o problema é agora reproduzível diretamente a partir da VPC.

Causa: lista de autorizações de IPs no destino com alguns ou todos os IPs de NAT do Apigee não adicionados

Diagnóstico

Isto refere-se a destinos externos (a Internet) que têm a lista de autorizações de IPs ativada. Certifique-se de que todos os IPs NAT do Apigee são adicionados no lado do destino afetado. Se não existir uma lista de autorizações no destino, pode ignorar esta secção.

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

Se o problema persistir (todas as chamadas estão a falhar), certifique-se de que os IPs NAT estão ativados no Apigee e obtenha-os através destes passos:

Liste os IPs NAT para uma instância:

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

Uma resposta de exemplo:

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

Se não receber endereços no resultado, significa que os IPs NAT não foram adicionados no lado do Apigee. Se obtiver endereços, mas nenhum deles estiver ATIVO, significa que nenhum dos endereços usados permite o acesso à Internet, o que também é um problema.

Se tiver, pelo menos, um endereço ATIVO, este pode ser incluído na lista de autorizações no destino. Por conseguinte, não existe nenhuma configuração incorreta no lado do Apigee. Nesse caso, o endereço pode estar em falta na lista de autorizações no destino.

Se o problema for intermitente, isso pode indicar que apenas um subconjunto de IPs NAT foi adicionado à lista de autorizações no destino. Para identificar isso:

1. Crie um novo proxy inverso onde o destino afetado é especificado no TargetEndpoint. Também pode reutilizar o proxy existente e avançar para o passo seguinte:
   
   
2. Adicione uma política ServiceCallout ao Request PreFlow. O ServiceCallout deve chamar "https://icanhazip.com", "https://mocktarget.apigee.net/ip" ou qualquer outro ponto final público que devolva o endereço IP do autor da chamada na resposta. Armazene a resposta na variável "response" para que o conteúdo seja visível na depuração. Segue-se um exemplo de configuração da 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 pode armazenar a resposta numa variável personalizada, mas tem de ler o ".content" dessa variável com a política AssignMessage para a revelar na ferramenta de depuração.

   Certifique-se de que o destino está configurado exatamente da mesma forma que no proxy afetado.

   Nota: o pedido ServiceCallout e o pedido Target devem ocorrer numa única transação. Isto destina-se a garantir que o mesmo servidor processa um pedido, de modo que o IP NAT do pedido afetado corresponda ao IP NAT obtido a partir do ServiceCallout.
3. Execute uma sessão de depuração e clique no passo ServiceCallout:
   
   
4. No canto inferior direito, deve ver uma secção Conteúdo da resposta que contém o IP NAT (no corpo) da instância do Apigee que está a fazer o pedido. Em alternativa, se armazenar a resposta ServiceCallout num local diferente, deve vê-la aí.
   
   Tenha em atenção que, mais tarde no fluxo, o proxy chama o destino e o conteúdo da resposta é substituído pelo erro ou por uma resposta do destino.
5. Tente correlacionar os IPs NAT com o problema. Se reparar que apenas determinados IPs falham, isto é um sinal de que alguns, mas não todos, os IPs estão na lista de autorizações no destino.
6. Se não vir uma correlação entre os IPs NAT e os erros, por exemplo, se o mesmo IP falhar num pedido, mas não no outro, é provável que não se trate de um problema de lista de autorizações. Pode ser um esgotamento de NAT. Consulte Causa: esgotamento da porta IP de NAT.

Resolução

Certifique-se de que tem endereços IP NAT aprovisionados e ativados e certifique-se de que todos eles são adicionados no lado de destino.

Causa: esgotamento da porta IP da NAT

Diagnóstico

Nota: esta causa não é comum e é relevante se o problema não for reproduzível a partir da sua VPC ou de qualquer outro local fora do Apigee. Se não tiver realizado esse teste, siga as instruções na secção Problema de conetividade no destino acima para receber orientações. Esta secção também não é relevante se não estiver a usar IPs NAT.

Se o problema for reproduzível apenas a partir do Apigee e os IPs NAT forem aprovisionados para a sua organização, e vir que acontece para diferentes destinos ao mesmo tempo, pode estar a ficar sem portas de origem NAT:

1. Indique o período do problema. Por exemplo: diariamente entre as 17:58 e as 18:08.
2. Confirme se outro alvo é afetado pelo problema no mesmo período. Esse outro destino tem de estar acessível através da Internet e não pode estar alojado na mesma localização que o destino afetado original.
3. Estabeleça se os erros só ocorrem acima de um determinado volume de tráfego em TPS. Para tal, tome nota do período do problema e navegue para o painel de controlo de desempenho do proxy.
4. Experimente correlacionar o período de tempo do erro com o aumento das transações médias por segundo (tps).

Neste exemplo, o tps aumenta para 1000 às 17:58. Partindo do princípio de que, neste exemplo, as 17:58 são exatamente quando o problema ocorre e o problema afeta dois ou mais alvos não relacionados, isso é um sinal de um problema com o esgotamento de NAT.

Resolução

Volte a calcular os requisitos de IP NAT através das instruções em Calcular os requisitos de IP NAT estático.

Também pode adicionar mais IPs NAT e ver se isso resolve o problema. Tenha em atenção que a adição de mais IPs pode exigir que os adicione à lista de autorizações em todos os alvos primeiro.

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

Diagnóstico

Pode ter configurado incorretamente o valor do limite de tempo no proxy.

Para verificar, navegue até ao proxy afetado e inspecione o TargetEndpoint em questão. Tenha em atenção a propriedade "connect.timeout.millis" e o respetivo valor. No exemplo aqui, o valor é 50, que corresponde a 50 milissegundos e, normalmente, é demasiado baixo para garantir o estabelecimento de uma ligação TCP. Se vir um valor inferior a 1000, é provável que seja a causa do problema. Se não vir a propriedade "connect.timeout.millis", o valor predefinido está definido e a causa não está confirmada.

Resolução

Corrija o valor connect.timeout.millis, certificando-se de que tem em atenção que as unidades de tempo estão em milissegundos. O valor predefinido é 3000, que corresponde a 3000 milissegundos. Para mais informações, consulte a referência das propriedades dos pontos finais.

Contacte o apoio técnico para receber mais assistência

Se o problema persistir depois de seguir as instruções acima, recolha as seguintes informações de diagnóstico para o apoio técnico do Google Cloud:

1. ID do projeto e nome da organização Apigee
2. Nomes dos proxies e o ambiente
3. Intervalo de tempo do problema
4. Frequência do problema
5. Nome do anfitrião de destino
6. Sessão de depuração com o problema
7. Resultado das verificações realizadas para as possíveis causas acima. Por exemplo, o resultado do comando curl de uma VM