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

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente recibe un código de estado HTTP 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 típica para una solicitud a la API a través de la plataforma de Edge es Cliente > Router > Message Processor > Servidor de backend, como se muestra en la siguiente figura:

Todos los componentes del flujo de tiempo 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 upstream 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 este manual, se describe cómo solucionar y resolver un error de 504 que se produce cuando se agota el tiempo de espera del router.

Tiempo de espera en el router

El tiempo de espera predeterminado configurado en los routers de Apigee Edge es de 57 segundos. Es la cantidad máxima de tiempo que un proxy de API puede ejecutarse desde el momento en que se recibe la solicitud a la API en Edge hasta que se envía la respuesta, incluida la respuesta del 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 Configuración del tiempo de espera de E/S en los routers.

Causas posibles

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

Causa Descripción Instrucciones de solución de problemas aplicables para
Configuración incorrecta del tiempo de espera en el router Esto sucede si el Router está configurado con un período de 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 API Monitoring, haz lo siguiente:

  1. Navega a la página Analizar > Supervisión de API > Investigar.
  2. Filtra los errores de 5xx y selecciona el período.
  3. Genera un gráfico del código de estado en función del tiempo.

  4. Haz clic en la celda específica que muestra errores de 504 para ver más detalles y los registros sobre estos errores, como se muestra a continuación:

    Ejemplo que muestra errores 504

  5. En el panel de la derecha, haz clic en Ver registros.

    En la ventana Registros de tráfico, ten en cuenta los siguientes detalles para algunos errores de 504:

    • Solicitud: Proporciona el método de solicitud y el URI que se usan para realizar las llamadas.
    • Tiempo de respuesta: Proporciona el tiempo total transcurrido para la solicitud.

    En el ejemplo anterior,

    • La solicitud apunta a GET /test-timeout.
    • El tiempo de respuesta es de 57.001 segundos. Esto indica que el router agotó el tiempo de espera antes de que el 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 con la API de API Monitoring GET logs. 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 API Monitoring establece el proxy en - (not set) para estos errores de 504, puedes usar la API (API de Logging) para obtener el proxy asociado para la ruta de acceso y el host virtual.

    For example :

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
  6. Revisa el Tiempo de respuesta para detectar errores adicionales de 504 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 de 504.

Registros de acceso de NGINX

Para diagnosticar el error con los registros de acceso de NGINX, haz lo siguiente:

  1. Verifica los registros de acceso de NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. Busca si hay errores de 504 durante un período específico (si el problema ocurrió en el pasado) o si hay solicitudes que aún fallan con 504.
  3. Ten en cuenta la siguiente información para algunos errores de 504:
    • Tiempo de respuesta
    • URI de solicitud

    En este ejemplo, vemos la siguiente información:

    • Tiempo de solicitud: 57.001 segundos. Esto indica que el router agotó el tiempo de espera después de 57.001 segundos.

    • Solicitud: GET /test-timeout
    • Alias de host: myorg-test.apigee.net

  4. Comprueba si el Tiempo de solicitud es el mismo que el tiempo de espera de E/S configurado en el router o el host virtual. Si es así, significa que el router agotó el tiempo de espera antes de que el Message Processor no respondiera dentro de este período.

    En la entrada de registro de acceso de NGINX de ejemplo que se muestra arriba, el tiempo de solicitud de 57.001 segundos está muy cerca del tiempo de espera de E/S predeterminado establecido en el router. Esto indica claramente que el router agotó el tiempo de espera antes de que el procesador de mensajes pudiera responder.

  5. Determina el proxy de API para el que se realizó la solicitud usando la ruta de acceso base en el campo Solicitud .

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

Diagnóstico

  1. Determina si los errores 504 se deben a que el Router agotó el tiempo de espera antes de que el Message Processor pudiera responder. Para ello, verifica si el Tiempo de respuesta en Supervisión de API o el Tiempo de solicitud en el router (ambos campos representan la misma información, pero se denominan de manera diferente) es el mismo que el tiempo de espera de E/S configurado en el router o el host virtual, y si los campos Fuente de la falla, Proxy de la falla y Código de falla están configurados como - con la Supervisión de API o los registros de acceso de NGINX, como se explica en Pasos de diagnóstico comunes.

  2. Verifica si el valor de tiempo de espera de E/S configurado en el router o en el host virtual específico es más bajo en comparación con el configurado en Message Processor o en el proxy de API específico.

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

Cómo verificar 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:

  1. Accede a la IU de Edge.
  2. Navega a Admin > Virtual Hosts.
  3. Selecciona un entorno específico en el que experimentes el problema de tiempo de espera.
  4. Selecciona el host virtual específico para el que deseas verificar el valor de tiempo de espera de E/S.
  5. En Propiedades, consulta el valor de Tiempo de espera de lectura del proxy en segundos.

    En el ejemplo anterior, el tiempo de espera de lectura del 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.

APIs de administración

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

  1. Ejecuta la API de Get virtual host para obtener la configuración de 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 Private Cloud

    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.

  2. Verifica el valor configurado para la propiedad proxy_read_timeout.

    Definición de host virtual de muestra

    {
  "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.

Cómo verificar el tiempo de espera de E/S en el archivo router.properties

  1. Accede a una máquina de Router.
  2. Busca la propiedad proxy_read_timeout en el directorio /opt/nginx/conf.d y verifica si se configuró con el nuevo valor de la siguiente manera: 
    grep -ri "proxy_read_timeout" /opt/nginx/conf.d

  3. Verifica el valor establecido para la propiedad proxy_read_timeout en el archivo de configuración del 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 ejemplo de salida anterior, observa que la propiedad proxy_read_timeout se estableció con el nuevo valor 57 en 0-default.conf, que es el archivo de configuración del host virtual predeterminado. Esto indica que el tiempo de espera de E/S está configurado 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 para realizar las llamadas a la API que fallaron con errores de 504.

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

Puedes ver el tiempo de espera de E/S en lo siguiente:

  • Es el extremo de destino del proxy de API.
  • Política ServiceCallout del proxy de API
Visualiza el tiempo de espera de E/S en el extremo de destino del proxy de API
  1. 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.
  2. Selecciona el extremo de destino específico que deseas verificar.
  3. Consulta la propiedad io.timeout.millis con un valor adecuado en el elemento <HTTPTargetConnection> de la configuración de 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>
Visualiza el tiempo de espera de E/S en la política ServiceCallout del proxy de API
  1. 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 ServiceCallout.
  2. Selecciona la política ServiceCallout específica que deseas verificar.

  3. Consulta el elemento <Timeout> con un valor adecuado en la configuración de <ServiceCallout>.

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

    <Timeout>120000</Timeout>

Cómo verificar el tiempo de espera de E/S en los Message Processors

  1. Accede a la máquina de Message Processor.

  2. 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
  3. En el resultado de ejemplo anterior, observa que la propiedad HTTPTransport.io.timeout.millis se estableció con el valor 55000 en http.properties. Esto indica que el tiempo de espera de E/S se configuró correctamente en 55 segundos en el Message Processor.

Una vez que hayas determinado el tiempo de espera configurado en el router y el Message Processor, verifica si el router o el host virtual se configuraron con un valor de tiempo de espera inferior al del Message Processor o el 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 el procesador de mensajes (segundos) Tiempo de espera en el proxy de API (segundos)
57 - 55 120

En este ejemplo,

  • El valor predeterminado de 57 segundos está configurado en el router.
  • El valor de tiempo de espera no se establece en el host virtual específico. Esto significa que usará el valor predeterminado de 57 segundos configurado en el propio router.
  • En el 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 aún se configura con 57 segundos. Por lo tanto, el router agota el tiempo de espera a los 57 segundos, mientras que el procesador de mensajes o el backend aún están procesando tu solicitud. Esto hace que el enrutador responda con el error 504 Gateway Timeout a la aplicación cliente.

Solució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.

  1. Consulta Prácticas recomendadas para configurar el tiempo de espera de E/S para 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.
  2. 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 de tiempo de espera del Message Processor a 120 segundos, establece un valor de tiempo de espera más alto, por ejemplo, 123 seconds en el router. Para evitar que el nuevo valor de tiempo de espera afecte a todos los proxies de API, establece el valor de 123 seconds solo en el host virtual específico que se usa en el proxy de API específico.
  3. Sigue las instrucciones en Configuración del tiempo de espera de E/S en routers para establecer el tiempo de espera en el host virtual.