Estás consultando la documentación de Apigee y Apigee hybrid.
No hay documentación equivalente de
Apigee Edge para este tema.
Síntoma
Este problema se muestra como errores "503 - Servicio no disponible" en Monitorización de APIs, Depuración u otras herramientas. El motivo "TARGET_CONNECT_TIMEOUT" indica que se ha agotado el tiempo de espera de la conexión entre la instancia de Apigee y el destino de Internet o un destino accesible con el emparejamiento de VPCs.
Este error no debe confundirse con otros errores de tiempo de espera, como el error 504 Gateway Timeout.
Mensaje de error
Este es el error habitual en la sesión de depuración o en 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 emparejamiento de VPC. Consulta las opciones de red de Apigee. Si el destino es PSC (Endpoint Attachment), consulta el manual de procedimientos de PSC.
| Causa | Descripción |
|---|---|
| Configuración incorrecta de las rutas | Las rutas de destino no se exportan al peering con la instancia de Apigee. |
| Problema de conectividad en el destino | El destino no siempre puede aceptar una conexión TCP. |
| Se ha añadido a la lista de permitidas de IPs de destino algunas o todas las IPs de NAT de Apigee | No todas las IPs NAT de Apigee están en la lista de permitidas en el destino. |
| Agotamiento de puertos de IP de NAT | No se han asignado suficientes puertos NAT para el tráfico. |
| El valor de connect.timeout.millis es demasiado bajo | El tiempo de espera de la conexión es demasiado bajo en Apigee. |
Pasos de diagnóstico habituales
Depuración es una herramienta esencial para registrar y evaluar los siguientes detalles sobre el problema:
- Duración total de la solicitud. Normalmente, se tarda tres segundos (valor predeterminado de connect.timeout.millis) en que se agote el tiempo de espera de una conexión. Si observas una duración inferior, comprueba la configuración del endpoint de destino.
- Nombre de host de destino y dirección IP. Si se muestra una dirección IP incorrecta, puede que haya un problema relacionado con el DNS. También puede observar una correlación entre diferentes IPs de destino y el problema.
- Frecuencia. Se necesitan enfoques diferentes en función de si el problema es intermitente o persistente.
Causa: configuración incorrecta de la ruta
Diagnóstico
Si el problema persiste, aunque haya empezado hace poco, puede deberse a un error de configuración de la ruta.
Esto podría afectar tanto a los destinos internos (enrutados en la VPC emparejada) como a los externos (Internet).
-
Primero, identifique 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, vaya a AnalyticsPublisher (o AX en la depuración clásica):
Busca el valor target.ip en la parte derecha de la pantalla.
En este ejemplo, la IP es 10.2.0.1. Como este intervalo es privado, se deben implementar ciertas medidas de enrutamiento para que Apigee pueda acceder al destino.
Ten en cuenta que, si el destino está en Internet, debes seguir este paso si Controles de Servicio de VPC está habilitado en Apigee, ya que impide la conectividad a Internet.
- Anota la región en la que se ha desplegado la instancia de Apigee afectada. En la interfaz de Apigee en la consola de Cloud, haz clic en Instancias. En el campo Ubicación, puede
encontrar la región exacta de la instancia.
- En el proyecto emparejado con Apigee, vaya a la sección Red de VPC -> Emparejamiento entre redes de VPC de la interfaz de usuario. Ten en cuenta que, si utilizas una VPC compartida, debes seguir esos pasos en el proyecto host en lugar de en el proyecto de Apigee.
- Haz clic en servicenetworking-googleapis-com, selecciona la pestaña RUTAS EXPORTADAS y filtra por la región obtenida en el paso 2.
En este ejemplo se muestra la ruta 10.2.0.0/24 exportada y se incluye la IP de destino de ejemplo 10.2.0.1. Si no ves ninguna ruta que corresponda a tu objetivo, ese es el motivo del problema.
Resolución
Revisa tu arquitectura de red y asegúrate de que las rutas se exporten al emparejamiento de VPC con Apigee. Lo más probable es que la ruta que falta sea estática o dinámica. La falta de rutas dinámicas necesarias indica que hay un problema con la función correspondiente, como Cloud Interconnect.
Ten en cuenta que el emparejamiento transitivo no está disponible. Es decir, si la red de VPC N1 está emparejada con N2 y N3, pero N2 y N3 no están conectadas directamente, la red de VPC N2 no puede comunicarse con la red de VPC N3 a través de emparejamiento entre redes de VPC.
Para obtener más información, consulte Patrones de red con límites.
Causa: problema de conectividad en el destino
Diagnóstico
Puede que no se pueda acceder al destino desde la VPC o que no pueda aceptar una conexión. Hay 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 habituales.
- 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, vaya a AnalyticsPublisher (o AX en Depuración clásica). Busca el valor target.ip en la parte derecha de la pantalla.
En este ejemplo, la IP es 10.2.0.1. Se trata de 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 destino.
En Instancias de 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 estos detalles:
- Dirección IP de origen: usa la IP de la instancia de Apigee obtenida en el paso 2 de arriba. Ten en cuenta que 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: no marques esta opción a menos que la dirección esté en alguno de tus proyectos de Google Cloud. Si comprueba este valor, también debe proporcionar el proyecto y la red.
- Introduce la dirección de destino (paso 1) y el puerto como Dirección IP de destino y 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 "Unreachable" (No se puede acceder), significa que hay un problema con la configuración. La herramienta debería dirigirte a la
documentación sobre los estados de las pruebas de conectividad
para continuar. Si el estado es "Accesible", se descartan muchos problemas de configuración.
Sin embargo, no se garantiza que se pueda acceder al destino. No se ha intentado establecer una conexión TCP con el destino. Solo el siguiente diagnóstico te ayudará a comprobarlo.
Prueba de conectividad de VM (todos los destinos)
- En la misma VPC que está emparejada con Apigee, crea una instancia de VM en Linux.
- Realiza pruebas de conectividad desde la VM, preferiblemente en el momento en que se pueda reproducir el problema 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 - Consulta 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., No confirman el tiempo de espera de la conexión y no están relacionados con este problema.
- Si el destino requiere que se incluyan IPs en una lista de permitidas, es posible que no puedas probarlo desde una VM a menos que también incluyas en la lista de permitidas la IP de origen de la instancia de VM.
Resolución
Si has identificado un problema en función de las pruebas de conectividad, sigue los pasos de resolución documentados.
Si el tiempo de espera se reproduce desde una VM, no hay instrucciones definitivas sobre cómo resolver el problema en el destino. Una vez que se pueda reproducir el tiempo de espera de conexión fuera de Apigee, investiga 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 VPN, también puedes probarlo desde la red local.
Si el destino está en Internet, puedes intentar reproducir el problema fuera de la consola de Google Cloud.
Si el problema se produce en horas punta, es posible que el destino esté saturado de conexiones.
Si necesitas abrir un caso de asistencia de Google Cloud en esa fase, ya no tienes que seleccionar el componente de Apigee, ya que el problema ahora se puede reproducir directamente desde la VPC.
Causa: la lista de IPs permitidas en el destino no incluye algunas o todas las IPs de NAT de Apigee
Diagnóstico
Esto afecta a los destinos externos (Internet) que tienen habilitada la lista de permitidas de IPs. Asegúrese de que todas las IPs NAT de Apigee se hayan añadido en el lado del destino afectado. Si no hay ninguna lista de permitidos en el destino, puedes saltarte 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 pueda encontrar una correlación entre determinadas IPs de NAT y los errores.
Si el problema persiste (todas las llamadas fallan), asegúrate de que las IPs de NAT están habilitadas en Apigee y obténlas siguiendo estos pasos:
Lista de IPs de 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 ACTIVA, se puede incluir en la lista de permitidas en el destino, por lo que no hay ningún error de configuración en Apigee. En ese caso, puede que falte la dirección en la lista de permitidas del destino.
Si el problema es intermitente, puede indicar que solo se ha incluido en la lista de 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 destino afectado en TargetEndpoint. También puedes reutilizar el proxy que ya tengas y pasar al siguiente paso:
- Añade una política ServiceCallout al Request PreFlow. ServiceCallout debe llamar a "https://icanhazip.com", "https://mocktarget.apigee.net/ip" o cualquier otro endpoint público que devuelva la dirección IP de la persona que llama en la respuesta. Almacena la respuesta en la variable "response" para que el contenido se vea en Depuración. Este es un ejemplo de configuración de la 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>También puede almacenar la respuesta en una variable personalizada, pero tendría que leer el ".content" de esa variable con la política AssignMessage para que se muestre en la herramienta Depuración.
Asegúrate de que el destino esté configurado exactamente igual 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ía ver una sección Contenido de la respuesta que contiene la IP de NAT (en el cuerpo) de la instancia de Apigee que realiza la solicitud.
Si almacenas la respuesta de ServiceCallout en otro lugar, deberías verla ahí.
Ten en cuenta que, más adelante en el flujo, el proxy llamará al destino y el contenido de la respuesta se sobrescribirá con el error o con una respuesta del destino. - Intenta correlacionar las IPs de NAT con el problema. Si observa que solo fallan determinadas IPs, esto indica que algunas IPs, pero no todas, están incluidas en la lista de permitidos del destino.
- Si no ves ninguna correlación entre las IPs de NAT y los errores (por ejemplo, si la misma IP falla en una solicitud, pero no en otra), lo más probable es que no se trate de un problema de lista de permitidos. Puede que se trate de un agotamiento de NAT. Consulta Causa: agotamiento del puerto de la IP de NAT.
Resolución
Asegúrate de que tengas IPs NAT aprovisionadas y activadas y de que todas ellas se hayan añadido en el lado de destino.
Causa: agotamiento de puertos IP de NAT
Diagnóstico
Si el problema solo se puede reproducir desde Apigee y se han aprovisionado IPs de NAT para tu organización, y observas que ocurre con diferentes destinos al mismo tiempo, es posible que te estés quedando sin puertos de origen de NAT:
- Anota el periodo en el que se ha producido el problema. Por ejemplo, todos los días entre las 17:58 y las 18:08.
- Confirma si el problema afecta a otro objetivo en el mismo periodo. El otro destino debe ser accesible 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 se producen por encima de un determinado volumen de tráfico en TPS. Para ello, anota el periodo del problema y ve al panel Rendimiento del proxy.
- Intenta correlacionar el periodo del error con el aumento de las transacciones medias por segundo (tps).
En este ejemplo, las tps aumentan a 1000 a las 17:58. Supongamos que, en este ejemplo, las 17:58 es exactamente cuando se produce el problema y que este afecta a dos o más destinos no relacionados. Esto indica que hay un problema de agotamiento de NAT.
Resolución
Vuelve a calcular tus requisitos de IPs de NAT siguiendo las instrucciones de Calcular los requisitos de IPs de NAT estáticas.
También puedes añadir más IPs NAT y comprobar si así se soluciona el problema. Ten en cuenta que, para añadir más IPs, es posible que primero tengas que incluirlas en la lista de permitidas de todos los destinos.
Causa: el valor de connect.timeout.millis es demasiado bajo
Diagnóstico
Es posible que haya configurado incorrectamente el valor de tiempo de espera en el proxy.
Para comprobarlo, vaya al proxy afectado e inspeccione el TargetEndpoint en cuestión. Anote la propiedad "connect.timeout.millis" y su valor. En este ejemplo, el valor es 50, que equivale a 50 milisegundos. Por lo general, es demasiado bajo para garantizar el establecimiento de una conexión TCP. Si ves un valor inferior a 1000, es probable que sea la causa del problema. Si no ve la propiedad "connect.timeout.millis", se habrá definido el valor predeterminado y no se habrá confirmado la causa.
Resolución
Corrige el valor de connect.timeout.millis y ten en cuenta que las unidades de tiempo son milisegundos. El valor predeterminado es 3000, que equivale a 3000 milisegundos. Para obtener más información, consulta la referencia de propiedades de Endpoints.
Contactar con el equipo de Asistencia para obtener más ayuda
Si el problema persiste después de seguir las instrucciones anteriores, recoge la siguiente información de diagnóstico para el equipo de Asistencia de Google Cloud:
- ID del proyecto y nombre de la organización de Apigee
- Nombre(s) del proxy y el entorno
- Intervalo de tiempo del problema
- Frecuencia del problema
- Nombre de host de destino
- Sesión de depuración con el problema
- Resultado de las comprobaciones realizadas para las posibles causas anteriores. Por ejemplo, el resultado del comando
curlde una máquina virtual