Se usó la API de Cloud Translation para traducir esta página.

504 Tiempo de espera de la puerta de enlace: Se agotó el tiempo de espera del router

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

Síntoma

La aplicación cliente recibe un código de estado HTTP de 504 con el mensaje Gateway Timeout en respuesta a las llamadas a la API.

Esta respuesta de error indica que el cliente no recibió una respuesta oportuna de Apigee Edge o del servidor de backend durante la ejecución de una llamada a la API.

Mensaje de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 504 Gateway Time-out

Cuando llames a ese proxy con cURL o un navegador web, es posible que recibas el siguiente error:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

¿Qué causa los tiempos de espera?

La ruta de acceso típica para una solicitud a la API a través de la plataforma perimetral es Cliente > Router > Procesador de mensajes > Servidor de backend, como se muestra en la siguiente figura:

Todos los componentes del flujo del entorno de ejecución de Apigee Edge, incluidos los clientes, los routers, los procesadores de mensajes y los servidores de backend, se configuran con valores de tiempo de espera predeterminados adecuados para garantizar que las solicitudes a la API no tarden demasiado en completarse. Si alguno de los componentes del flujo no recibe la respuesta del componente ascendente dentro del período especificado en la configuración de tiempo de espera, el componente específico agotará el tiempo de espera y, por lo general, mostrará un error 504 Gateway Timeout.

En esta guía, se describe cómo solucionar un error 504 causado cuando se agota el tiempo de espera del router.

Tiempo de espera en el router

El tiempo de espera predeterminado que se configura en los routers en Apigee Edge es de 57 segundos. Esta es la cantidad máxima de tiempo que puede ejecutarse un proxy de API desde el momento en que se recibe la solicitud a la API en Edge hasta que se devuelve la respuesta, incluidas la respuesta de backend y todas las políticas que se ejecutan. El tiempo de espera predeterminado se puede anular en los routers o hosts virtuales como se explica en Configura el tiempo de espera de E/S en los routers.

Causas posibles

En Edge, las causas típicas del error 504 Gateway Timeout causado por el tiempo de espera del router son las siguientes:

Causa	Descripción	Instrucciones de solución de problemas aplicables para
Configuración incorrecta de tiempo de espera en el router	Esto sucede si el router se configuró con un tiempo de espera de E/S incorrecto.	Usuarios de la nube pública y privada de Edge

Pasos comunes de diagnóstico

Usa una de las siguientes herramientas o técnicas para diagnosticar este error:

Supervisión de API
Registros de acceso de NGINX

Supervisión de API

Para diagnosticar el error con la supervisión de la API, sigue estos pasos:

Navega a la página Analyze > API Monitoring > Investigate.
Filtra los errores 5xx y selecciona el período.
Traza el Código de estado en función del Tiempo.
Haz clic en la celda específica que muestra los errores 504 para ver más detalles y ver los registros sobre estos errores, como se muestra a continuación:

Ejemplo que muestra errores 504
En el panel derecho, haz clic en Ver registros.

En la ventana Registros de tráfico, ten en cuenta los siguientes detalles de algunos errores 504:
- Solicitud: Proporciona el método de solicitud y el URI que se usan para realizar las llamadas.
- Tiempo de respuesta:Indica el tiempo total transcurrido para la solicitud.
En el ejemplo anterior,
- Request apunta a GET /test-timeout.
- El tiempo de respuesta es de 57.001 segundos. Esto indica que se agotó el tiempo de espera del router antes de que Message Processor pudiera responder, ya que el valor está muy cerca del tiempo de espera de E/S predeterminado establecido en el router, que es de 57 segundos.
También puedes obtener todos los registros mediante la API GET logs de Monitoring de API. Por ejemplo, si consultas los registros de org, env, timeRange y status, podrás descargar todos los registros de las transacciones en las que se agotó el tiempo de espera del cliente.

Dado que la supervisión de API establece el proxy en - (sin definir) para estos errores 504, puedes usar la API (API de Logs) a fin de obtener el proxy asociado para el host virtual y la ruta de acceso.

For example :
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
Nota: Los siguientes campos mostrarán el valor de este error 504:
- Origen de la falla
- Código de falla
- Flujo de fallas
- Política de fallas
- Proxy de fallas
Message Processor completa estos campos y se establecerán con los valores adecuados solo si el router recibe una respuesta de Message Processor. En este caso, se agotó el tiempo de espera del router antes que Message Processor, ya que no respondió de manera oportuna. Esto obliga al router a establecer el código de estado en 504 y, como resultado, todos los campos mencionados anteriormente se muestran como -.
Revisa el Tiempo de respuesta para ver si hay errores 504 adicionales y verifica si el Tiempo de respuesta es coherente (valor de tiempo de espera de E/S establecido en el router que es de 57 segundos) en todos los errores 504.

Registros de acceso de NGINX

Para diagnosticar el error con los registros de acceso de NGINX, sigue estos pasos:

Verifica los registros de acceso de NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Busca para ver si hay errores 504 durante un período específico (si el problema ocurrió en el pasado) o si hay alguna solicitud que aún falla con 504.
Ten en cuenta la siguiente información para algunos errores 504:
- Tiempo de respuesta
- URI de solicitud
En este ejemplo, vemos la siguiente información:
- Tiempo de solicitud: 57.001 segundos. Esto indica que se agotó el tiempo de espera del router después de 57.001 segundos.
  
  Nota: Esto representa el campo request_time en los registros de NGINX. Se refiere al tiempo de procesamiento de la solicitud en segundos; el tiempo transcurrido entre los primeros bytes se leyeron del cliente y la escritura de registro después de que se enviaron los últimos bytes al cliente.
- Solicitud: GET /test-timeout
- Alias del host: myorg-test.apigee.net
Nota: En los siguientes campos, se mostrará el valor - para este error 504:
- Origen de la falla
- Código de falla
- Flujo de fallas
- Política de fallas
- Proxy de fallas
Message Processor completa estos campos y se establecerán con los valores adecuados solo si el router recibe una respuesta de Message Processor. En este caso, se agotó el tiempo de espera del router antes que Message Processor, ya que no respondió de manera oportuna. Esto obliga al router a establecer el código de estado en 504 y, como resultado, todos los campos mencionados anteriormente se muestran como -.
Comprueba si el tiempo de solicitud es el mismo que el tiempo de espera de E/S configurado en el router o host virtual. Si es así, significa que se agotó el tiempo de espera del router antes de que Message Processor no respondiera dentro de este período.

En el ejemplo de la entrada de registro de acceso de NGINX que se muestra arriba, el Tiempo de solicitud de 57.001 segundos es muy similar al tiempo de espera de E/S predeterminado establecido en el router. Esto indica claramente que se agotó el tiempo de espera del router antes de que el procesador de mensajes pudiera responder.
Usa la ruta base en el campo Request para determinar el proxy de API para el que se realizó la solicitud.

Causa: Configuración incorrecta de tiempo de espera en el router

Diagnóstico

Determina si los errores 504 se deben a que se agotó el tiempo de espera del router antes de que Message Processor pueda responder. Para ello, verifica si el Tiempo de respuesta en la supervisión de la API o el Tiempo de solicitud en el router (ambos campos representan la misma información, pero se llaman con nombres diferentes) es el mismo que el tiempo de espera de E/S configurado en el router o host virtual y los campos Fuente de errores, Proxy fallido y Código de error en - mediante la supervisión de la API o los registros comunes de acceso de NGINX, como se explica.
Comprueba si el valor del tiempo de espera de E/S configurado en el router o el host virtual específico es inferior en comparación con el configurado en Message Processor o el proxy de API específico.

Para hacerlo, sigue los pasos que se indican en esta sección.

Verifica el tiempo de espera de E/S en hosts virtuales

IU de Edge

Para verificar el tiempo de espera del host virtual con la IU de Edge, haz lo siguiente:

Accede a la IU de Edge.
Navega a Administrador > Hosts virtuales.
Selecciona un Entorno específico en el que experimentes el problema de tiempo de espera.
Selecciona el host virtual específico para el que deseas verificar el valor del tiempo de espera de E/S.
En Properties, consulta el valor Proxy Read Timeout en segundos.

En el ejemplo anterior, el tiempo de espera de lectura de proxy se configura con un valor de 120. Esto significa que el tiempo de espera de E/S configurado en este host virtual es de 120 segundos.

Nota: Si el tiempo de espera de lectura del proxy no tiene ningún valor, significa que tomará el valor predeterminado de 57 segundos configurado en el router (a menos que el tiempo de espera de E/S se anule en las instancias del router).

APIs de administración

También puedes verificar el tiempo de espera de lectura del proxy con las siguientes APIs de administración:

Ejecuta la API de Obtener host virtual para obtener la configuración virtualhost como se muestra a continuación:

Usuario de la nube pública

curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME

Usuario de la nube privada

curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME

Donde:

ORGANIZATION_NAME es el nombre de la organización

ENVIRONMENT_NAME es el nombre del entorno.

VIRTUALHOST_NAME es el nombre del host virtual.

Verifica el valor configurado para la propiedad proxy_read_timeout

Ejemplo de definición de host virtual

{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

En el ejemplo anterior, proxy_read_timeout se configura con un valor de 120. Esto significa que el tiempo de espera de E/S configurado en este host virtual es de 120 segundos.

Nota: Si la propiedad proxy_read_timeout no existe en el resultado de la API de administración, eso significa que tomará el valor predeterminado de 57 segundos (a menos que el tiempo de espera de E/S se anule en las instancias del router).

Verifica el tiempo de espera de E/S en el archivo router.properties

Accede a una máquina de router.
Busca la propiedad proxy_read_timeout en el directorio /opt/nginx/conf.d y verifica si se configuró con el valor nuevo de la siguiente manera:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
Verifica el valor establecido para la propiedad proxy_read_timeout en el archivo de configuración de host virtual específico.

Resultado de muestra del comando grep
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
En el resultado de ejemplo anterior, observa que la propiedad proxy_read_timeout se estableció con el valor nuevo 57 en 0-default.conf, que es el archivo de configuración para el host virtual predeterminado. Esto indica que el tiempo de espera de E/S se configuró en 57 segundos en el router para el host virtual predeterminado. Si tienes varios hosts virtuales, verás esta información para cada uno de ellos. Obtén el valor de proxy_read_timeout para el host virtual específico que usaste a fin de realizar las llamadas a la API que fallaron con errores 504.

Verifica el tiempo de espera de E/S en el proxy de API

Puedes ver el tiempo de espera de E/S de la siguiente manera:

Extremo de destino del proxy de API
Política de ServiceFeatured del proxy de API

Ver el tiempo de espera de E/S en el extremo de destino del proxy de API

En la IU de Edge, selecciona el proxy de API específico en el que deseas ver el valor de tiempo de espera de E/S.
Selecciona el extremo de destino específico que quieres verificar.
Consulta la propiedad io.timeout.millis con un valor apropiado en el elemento <HTTPTargetConnection> de la configuración TargetEndpoint.
Por ejemplo, el tiempo de espera de E/S en el siguiente código se establece en 120 segundos:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

Ver el tiempo de espera de E/S en la política ServicePrompt del proxy de API

En la IU de Edge, selecciona el proxy de API específico en el que deseas ver el nuevo valor de tiempo de espera de E/S para la política ServiceReferencia.
Selecciona la política específica de ServiceHighlight que quieres verificar.
Consulta el elemento <Timeout> con un valor adecuado en la configuración <ServiceCallout>.

Por ejemplo, el tiempo de espera de E/S del siguiente código será de 120 segundos:
```
<Timeout>120000</Timeout>
```

Verifica el tiempo de espera de E/S en los procesadores de mensajes

Accede a la máquina del procesador de mensajes.

Busca la propiedad HTTPTransport.io.timeout.millis en el directorio /opt/apigee/edge-message-processor/conf con el siguiente comando:

grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf

Resultado de muestra

/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000

En el resultado de ejemplo anterior, observa que la propiedad HTTPTransport.io.timeout.millis se configuró con el valor 55000 en http.properties. Esto indica que el tiempo de espera de E/S se configuró correctamente en 55 segundos en Message Processor.

Una vez que hayas determinado el tiempo de espera configurado en el router y el procesador de mensajes, verifica si el router o host virtual se configuró con un valor de tiempo de espera más bajo en comparación con el procesador de mensajes o proxy de API.

Toma nota de los valores establecidos en todas las capas, como se muestra en la siguiente tabla:

Tiempo de espera en el router (segundos)	Tiempo de espera en el host virtual (segundos)	Tiempo de espera en Message Processor (segundos)	Tiempo de espera en el proxy de API (segundos)
57	-	55	120

En este ejemplo,

El valor predeterminado de 57 segundos se configura en el router.
El valor de tiempo de espera no está establecido en el host virtual específico. Esto significa que usará el valor predeterminado de 57 segundos configurado en el router.
En Message Processor, se configura un valor predeterminado de 55 segundos.
Sin embargo, en el proxy de API específico, se configura un valor de 120 segundos.

Ten en cuenta que el valor de tiempo de espera más alto solo se configura en el proxy de API, pero el router sigue configurado con 57 segundos. Por lo tanto, el tiempo de espera del router se agota en 57 segundos mientras el procesador o el backend de mensajes aún está procesando tu solicitud. Esto hace que el router responda con el error 504 Gateway Timeout a la aplicación cliente.

Resolución

Sigue estos pasos para configurar el tiempo de espera de E/S adecuado en el router y el procesador de mensajes para resolver este problema.

Consulta las prácticas recomendadas para configurar el tiempo de espera de E/S a fin de comprender qué valores de tiempo de espera se deben establecer en los diferentes componentes involucrados en el flujo de solicitudes a la API a través de Apigee Edge.
En el ejemplo anterior, si determinas que se debe establecer un valor de tiempo de espera más alto porque el servidor de backend requiere más tiempo, y aumentaste el valor del tiempo de espera del Message Processor a 120 segundos, establece un valor más alto de tiempo de espera. Por ejemplo: 123 seconds en el router. Para evitar que se vean afectados todos los proxies de API debido al nuevo valor de tiempo de espera, configura el valor de 123 seconds solo en el host virtual específico que se utiliza en ese proxy en particular.
Sigue las instrucciones en Configura el tiempo de espera de E/S en routers para establecer el tiempo de espera en el host virtual.