Estás viendo la documentación de Apigee y Apigee hybrid.
No hay documentación de Apigee Edge equivalente para este tema.
Síntoma
Este problema aparece como errores “503 - Service Unavailable” en Supervisión de API, Depuración o en otras herramientas. El motivo "TARGET_CONNECT_TIMEOUT" indica un tiempo de espera de conexión entre la instancia de Apigee y el destino de Internet o un destino al que se puede acceder con el intercambio de tráfico de VPC.
No se debe confundir el error con otros errores de tiempo de espera, como el error 504 de tiempo de espera de la puerta de enlace.
Mensaje de error
Este es el error típico de la sesión de depuración o de la carga útil de la respuesta. Ten en cuenta el motivo:
TARGET_CONNECT_TIMEOUT.
{"fault":{"faultstring":"The Service is temporarily unavailable",
"detail":{"errorcode":"messaging.adaptors.http.flow.ServiceUnavailable",
"reason":"TARGET_CONNECT_TIMEOUT"}}}Causas posibles
Ten en cuenta que estas causas son específicas de los destinos de Internet o de los destinos a los que se puede acceder con el intercambio de tráfico entre VPC. Consulta Opciones de red de Apigee. Si el destino es PSC (adjunto de extremo), consulta la guía de PSC en su lugar.
| Causa | Descripción |
|---|---|
| Configuración incorrecta de las rutas | Las rutas de destino no se exportan al intercambio de tráfico con la instancia de Apigee. |
| Problema de conectividad en el destino | El destino no siempre puede aceptar una conexión TCP. |
| Lista de entidades permitidas de IP en el destino con algunas o todas las IPs de NAT de Apigee no agregadas | No todas las IPs de NAT de Apigee están en la lista de entidades permitidas en el destino. |
| Agotamiento de puertos de IP de NAT | No hay suficientes puertos NAT para el tráfico. |
| El valor de connect.timeout.millis es demasiado bajo | El parámetro de configuración de tiempo de espera de la conexión es demasiado bajo en Apigee. |
Pasos comunes de diagnóstico
La depuración es una herramienta esencial para capturar y evaluar los siguientes detalles sobre el problema:
- Es la duración total de la solicitud. Por lo general, tarda tres segundos (connect.timeout.millis predeterminado) hasta que se agote el tiempo de espera de la conexión. Si observas una duración menor, verifica la configuración del extremo de destino.
- Nombre de host de destino y dirección IP Si se muestra una dirección IP incorrecta, es posible que haya un problema relacionado con el DNS. También es posible que notes una correlación entre las diferentes IP de destino y el problema.
- Frecuencia. Se necesitan diferentes enfoques según si el problema es intermitente o persistente.
Causa: Configuración incorrecta de la ruta
Diagnóstico
Si el problema persiste, incluso si comenzó recientemente, es posible que se deba a una configuración incorrecta de la ruta.
Esto podría afectar a los destinos internos (enrutados dentro de una VPC vinculada) y externos (Internet).
-
Primero, identifica la dirección IP del destino resuelta desde la instancia de Apigee. Uno de los métodos es usar una sesión de depuración. En Depuración, navega a AnalyticsPublisher (o AX en la depuración clásica):
Busca el valor target.ip en el lado derecho de la pantalla.
En este ejemplo, la IP es 10.2.0.1. Dado que este rango es privado, requiere que se implementen ciertas medidas de enrutamiento para garantizar que Apigee pueda llegar al objetivo.
Ten en cuenta que, si el destino está en Internet, debes seguir este paso si los Controles del servicio de VPC están habilitados para Apigee, ya que eso impide la conectividad a Internet.
- Toma nota de la región en la que se implementa la instancia de Apigee afectada. En la
IU de Apigee en la consola de Cloud, haz clic en Instancias. En el campo Ubicación, puedes
encontrar la región exacta de la instancia.
- En el proyecto que está vinculado con Apigee, navega a la sección Red de VPC -> Intercambio de tráfico entre redes de VPC en la IU. Ten en cuenta que, si usas VPC compartida, esos pasos deben realizarse en el proyecto host en lugar del proyecto de Apigee.
- Haz clic en servicenetworking-googleapis-com, selecciona la pestaña EXPORTED ROUTES y filtra por la región que obtuviste en el paso 2.
En este ejemplo, se muestra la ruta 10.2.0.0/24 como exportada y se incluye la IP de destino de ejemplo 10.2.0.1. Si no ves una ruta que corresponda a tu objetivo, esa es la causa del problema.
Solución
Revisa la arquitectura de tu red y asegúrate de que las rutas se exporten al intercambio de tráfico entre VPC con Apigee. Es probable que la ruta que falta sea estática o dinámica. La falta de rutas dinámicas necesarias indica un problema con la función correspondiente, por ejemplo, Cloud Interconnect.
Ten en cuenta que no se admite el intercambio de tráfico transitivo. En otras palabras, si la red de VPC N1 intercambia tráfico con las redes N2 y N3, pero estas no están conectadas directamente, la red de VPC N2 no se podrá comunicar con la N3 mediante el intercambio de tráfico entre redes de VPC.
Para obtener más información, puedes leer Patrones de herramientas de redes descendentes.
Causa: Problema de conectividad en el destino
Diagnóstico
Es posible que no se pueda acceder al destino desde la VPC o que no pueda aceptar una conexión. Existen dos opciones disponibles para diagnosticar el problema.
Prueba de conectividad (direcciones IP de destino privadas)
Si el destino está en una red privada, puedes usar la función Prueba de conectividad para diagnosticar las causas comunes.
- Identifica la dirección IP del destino resuelta desde la instancia de Apigee. Uno de los métodos es usar una sesión de depuración.
En Depuración, navega a AnalyticsPublisher (o AX en la depuración clásica). Busca el valor target.ip en el lado derecho de la pantalla.
En este ejemplo, la IP es 10.2.0.1. Esta es una dirección IP privada, lo que significa que podemos usar la prueba de conectividad.
- Anota la dirección IP de la instancia de Apigee que no puede conectarse al objetivo.
En Instancias, en la consola de Apigee, busca la dirección IP de la instancia de Apigee en el campo Dirección IP.
- Ve a Pruebas de conectividad y haz clic en Crear prueba de conectividad. Proporciona los siguientes detalles:
- Dirección IP de origen: Usa la IP de la instancia de Apigee que obtuviste en el paso 2 anterior. Ten en cuenta que esta no es la IP de origen exacta que usa Apigee para enviar una solicitud al destino, pero es suficiente para la prueba, ya que está en la misma subred.
- Esta es una dirección IP que se usa en Google Cloud: Deja desmarcada, a menos que la dirección esté en cualquiera de tus proyectos de Google Cloud. Si verificas este valor, también proporciona el proyecto y la red.
- Coloca la dirección de destino (paso 1) y el puerto como la dirección IP de destino y el puerto de destino, respectivamente.
- Haz clic en Crear y espera a que la prueba termine la primera ejecución.
- En la lista de pruebas de conectividad, haz clic en Ver para ver los resultados de la ejecución.
-
Si el resultado es "No se puede acceder", significa que tienes un problema con la configuración. La herramienta debería dirigirte a la documentación de estados de las pruebas de conectividad para continuar. Si el estado es "Se puede comunicar", se descartan muchos problemas de configuración.
Sin embargo, esto no garantiza que se pueda acceder al destino. No se realizó un intento real de establecer una conexión TCP con el destino. Solo el siguiente diagnóstico que se indica a continuación te ayudará a probarlo.
Prueba de conectividad de la VM de
(todos los destinos)
- En la misma VPC que está vinculada con Apigee, crea una instancia de VM en Linux.
- Realiza pruebas de conectividad desde la VM, preferiblemente en el momento en que el problema se pueda reproducir desde Apigee. Puedes usar telnet, curl y otras utilidades para establecer una conexión. Este ejemplo de curl se ejecuta en un bucle con un tiempo de espera de tres segundos. Si curl no puede establecer una conexión TCP en tres segundos, falla.
for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done - Verifica el resultado completo y busca este error:
* Closing connection 0 curl: (28) Connection timed out after 3005 milliseconds
La presencia de este error confirma que el problema se puede reproducir fuera de Apigee.
Ten en cuenta que, si ves otros errores, como errores relacionados con TLS, códigos de estado incorrectos, etcétera, no confirman el tiempo de espera de la conexión y no están relacionados con este problema.
- Si el objetivo requiere una lista de IP permitidas, es posible que no puedas probarlo desde una VM, a menos que también incluyas la IP de origen de la instancia de VM en la lista de entidades permitidas.
Solución
Si identificaste un problema en función de las pruebas de conectividad, continúa con los pasos de resolución documentados.
Si el tiempo de espera se reproduce desde una VM, no hay una guía definitiva para resolver el problema en el lado de destino. Una vez que se pueda reproducir el tiempo de espera de conexión fuera de Apigee, profundiza en el problema desde la VPC. Intenta probar la conectividad lo más cerca posible del objetivo.
Si el destino está detrás de una conexión de VPN, es posible que también puedas probarlo desde la red local.
Si el destino está en Internet, intenta reproducir el problema fuera de la consola de Google Cloud.
Si el problema ocurre en horas pico, es posible que el destino esté sobrecargado de conexiones.
Si necesitas generar un caso de asistencia de Google Cloud en esa etapa, ya no necesitas seleccionar el componente de Apigee, ya que el problema ahora se puede reproducir directamente desde la VPC.
Causa: Lista de entidades permitidas de IP en el destino con algunas o todas las IPs de NAT de Apigee no agregadas
Diagnóstico
Esto se aplica a los destinos externos (Internet) que tienen habilitada la lista de entidades permitidas de IP. Asegúrate de que todas las IPs de NAT de Apigee se agreguen en el destino afectado. Si no hay una lista de entidades permitidas en el destino, puedes omitir esta sección.
El problema es más fácil de detectar si los errores son intermitentes, ya que, en ese caso, es posible que puedas encontrar una correlación entre las IP de NAT en particular y los errores.
Si el problema es persistente (todas las llamadas fallan), asegúrate de que las IP de NAT estén habilitadas en Apigee y recupéralas mediante estos pasos:
Obtén una lista de las IP NAT de una instancia:
curl -H "Authorization: Bearer $TOKEN" \ "https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"
{
"natAddresses": [
{
"name": "nat-1",
"ipAddress": "35.203.160.18",
"state": "ACTIVE"
},
{
"name": "nat-2",
"ipAddress": "35.230.14.174",
"state": "RESERVED"
}
]
}Si tienes al menos una dirección con estado ACTIVE, se puede incluir en la lista de entidades permitidas en el destino, por lo que no hay una configuración incorrecta del lado de Apigee. En ese caso, es posible que falte la dirección en la lista de entidades permitidas del destino.
Si el problema es intermitente, es posible que solo se haya incluido en la lista de entidades permitidas un subconjunto de IPs de NAT en el destino. Para identificarlo, sigue estos pasos:
- Crea un nuevo proxy inverso en el que se especifique el objetivo afectado en TargetEndpoint. También puedes volver a usar el proxy existente y pasar al siguiente paso:
- Agrega una política de ServiceCallout al flujo previo de solicitud. ServiceCallout debe llamar a "https://icanhazip.com", "https://mocktarget.apigee.net/ip" o cualquier otro extremo público que devuelva la dirección IP del emisor en la respuesta. Almacena la respuesta en la variable "response" para que el contenido sea visible en Debug. Este es un ejemplo de configuración de la política de 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>También puedes almacenar la respuesta en una variable personalizada, pero deberás leer el ".content" de esa variable con la política de AssignMessage para revelarla en la herramienta de depuración.
Asegúrate de que el objetivo esté configurado de la misma manera que en el proxy afectado.
- Ejecuta una sesión de depuración y haz clic en el paso ServiceCallout:
- En la esquina inferior derecha, deberías ver una sección Response content que
contiene la IP de NAT (en el cuerpo) de la instancia de Apigee que realiza la solicitud.
Como alternativa, si almacenas la respuesta de ServiceCallout en otro lugar, deberías verla allí.
Ten en cuenta que, más adelante en el flujo, el proxy llamará al destino y el contenido de la respuesta se reemplazará con el error o una respuesta del destino. - Intenta correlacionar las IP de NAT con el problema. Si notas que solo fallan IPs específicas, esto es un indicador de que algunas IPs, pero no todas, están en la lista de entidades permitidas del destino.
- Si no ves una correlación entre las IP de NAT y los errores, por ejemplo, si la misma IP falla en una solicitud, pero no en la otra, es probable que no se trate de un problema de lista de entidades permitidas. Es posible que se trate de un agotamiento de NAT. Consulta Causa: Agotamiento del puerto IP de NAT.
Solución
Asegúrate de tener IPs de NAT aprovisionadas y activadas, y de que todas se agreguen en el extremo de destino.
Causa: Agotamiento del puerto de IP de NAT
Diagnóstico
Si el problema solo se puede reproducir desde Apigee y se aprovisionaron IP de NAT para tu organización, y ves que ocurre en diferentes destinos al mismo tiempo, es posible que se te estén acabando los puertos de origen de NAT:
- Anota el período en el que ocurrió el problema. Por ejemplo: todos los días de 5:58 p.m. a 6:08 p.m.
- Confirma si algún otro objetivo se ve afectado por el problema en el mismo período. Se debe poder acceder a ese otro destino a través de Internet y no debe estar alojado en la misma ubicación que el destino afectado original.
- Determina si los errores solo ocurren por encima de un volumen de tráfico determinado en TPS. Para ello, toma nota del período del problema y navega al panel Rendimiento del proxy.
- Intenta correlacionar el periodo de tiempo de error con el aumento en el promedio de transacciones por segundo (tps).
En este ejemplo, las tps aumentan a 1,000 a las 5:58 p.m. Suponiendo que, en este ejemplo, el problema ocurre exactamente a las 5:58 p.m. y afecta a dos o más destinos no relacionados, es un indicador de un problema con el agotamiento de NAT.
Solución
Vuelve a calcular los requisitos de IP de NAT con las instrucciones que se indican en Calcula los requisitos de IP NAT estáticas.
También puedes agregar más IP de NAT para ver si se resuelve el problema. Ten en cuenta que, para agregar más IPs, es posible que primero debas incluirlas en la lista de entidades permitidas en todos los destinos.
Causa: El valor de connect.timeout.millis es demasiado bajo.
Diagnóstico
Es posible que hayas configurado de forma incorrecta el valor de tiempo de espera en el proxy.
Para verificarlo, navega al proxy afectado y, luego, inspecciona el TargetEndpoint en cuestión. Ten en cuenta la propiedad "connect.timeout.millis" y su valor. En este ejemplo, el valor es 50, que es 50 milisegundos y, por lo general, es demasiado bajo para garantizar que se establezca una conexión TCP. Si ves un valor inferior a 1,000, es probable que esa sea la causa del problema. Si no ves la propiedad "connect.timeout.millis", significa que se estableció el valor predeterminado y no se confirmó la causa.
Solución
Corrige el valor de connect.timeout.millis y asegúrate de tener en cuenta que las unidades de tiempo están en milisegundos. El valor predeterminado es 3000, que equivale a 3,000 milisegundos. Para obtener más información, consulta la referencia de propiedades de Endpoints.
Comunícate con el equipo de Asistencia para obtener más ayuda
Si el problema persiste después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico para Asistencia de Google Cloud:
- ID del proyecto y nombre de la organización de Apigee
- Nombres de proxy y el entorno
- Período del problema.
- Frecuencia del problema
- Nombre de host de destino
- Sesión de depuración con el problema.
- Resultado de las verificaciones realizadas para las posibles causas anteriores. Por ejemplo, el resultado del comando
curlde una VM