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 viendo la documentación de Apigee Edge.
Ve a 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 llamadas a la API.

Esta respuesta de error indica que el cliente no recibió una respuesta oportuna de Apigee Edge o el 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 de API a través de la plataforma perimetral es Cliente > Router > Mensaje Procesador > Backend Server, como se muestra en la siguiente figura:

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

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

Tiempo de espera en el router

El tiempo de espera predeterminado configurado 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 que se recibe la solicitud a la API en Edge hasta la respuesta se devuelve, 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 Configura el tiempo de espera de E/S en los routers.

Causas posibles

En Edge, las causas típicas del error 504 Gateway Timeout debido a Características del tiempo de espera del router:

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 se configuró con un tiempo de espera de E/S incorrecto.	Usuarios perimetrales de nubes públicas y privadas

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 API, haz lo siguiente:

Navega a Analyze > Supervisión de API > Investigar.
Filtra en busca de 5xx errores y selecciona el período.
Traza el Código de estado (Status Code) en comparación con la Hora (Time).
Haz clic en la celda específica que muestra 504 errores para obtener más detalles y una visualización registros sobre estos errores, como se muestra a continuación:

Ejemplo que muestra errores 504
En el panel de la derecha, haz clic en Ver registros.

En la ventana Registros de tráfico, observa los siguientes detalles para algunos errores 504:
- Solicitud: Proporciona el método de solicitud y el URI que se usaron 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 Se agotó el tiempo de espera antes de que Message Processor pudiera responder, ya que el valor está muy cerca. el tiempo de espera de E/S predeterminado del router, que es 57 segundos.
También puedes obtener todos los registros con la API de Monitoring GET de registros. Por ejemplo, si consultas 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 configurar) para estos 504 errores, puedes usar la API (Registros API) para obtener el proxy asociado al 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:
- Fuente del error
- Código de error
- Flujo de fallas
- Política de fallas
- Proxy de fallas
El procesador de mensajes completa estos campos y se configuran con los valores adecuados solo si el router recibe una respuesta del Message Processor. En este caso, el router se agotó el tiempo de espera del procesador de mensajes, 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 los campos mencionados anteriormente se muestran como -.
Revisa el Tiempo de respuesta de los errores 504 adicionales y verifica para ver si el Tiempo de respuesta es coherente (valor de tiempo de espera de E/S configurado 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, haz lo siguiente:

Verifica los registros de acceso de NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Realiza una búsqueda para ver si hay errores 504 durante una duración específica (si el problema ocurrió en el pasado) o si todavía hay solicitudes que fallan 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 el Se agotó el tiempo de espera del router luego 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. tiempo transcurrido entre el primer bytes se leyeron del cliente y la escritura del registro después de que se enviaron los últimos bytes al cliente.
- Solicitud: GET /test-timeout
- Alias de host: myorg-test.apigee.net
Nota: Los siguientes campos mostrarán el valor - para este 504 error:
- Fuente del error
- Código de error
- Flujo de fallas
- Política de fallas
- Proxy de fallas
El procesador de mensajes completa estos campos y se establecerán con los valores adecuados únicamente. si el router recibe una respuesta del Message Processor. En este caso, el router ha cronometrado antes que el procesador de mensajes, ya que no respondió de manera oportuna. Esto fuerza al router para establecer el código de estado en 504 y, como resultado, todas las opciones se muestran como -.
Comprueba si el Tiempo de solicitud es el mismo que el tiempo de espera de E/S. que se configura en el router o host virtual. Si es así, significa que se agotó el tiempo de espera del router antes de que El procesador de mensajes no respondió en este período.

En el ejemplo de la entrada de registro de acceso de NGINX que se muestra arriba, la carpeta Request El tiempo de 57.001 segundos está muy cerca del 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 aparezca el mensaje El procesador podría responder.
Determina el proxy de API para el cual se realizó la solicitud mediante la ruta base en la Request .

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

Diagnóstico

Determina si los errores 504 se deben a que se agotó el tiempo de espera del router antes el Message Processor podría responder. Puedes hacer esto comprobando si el Response Time en API Monitoring/Request Time en el router (ambos campos) representan la misma información,pero se llaman con nombres diferentes) es la misma que Tiempo de espera de E/S configurado en el router o host virtual y los campos Fault Source, Fault Proxy y Fault Code están configurados como - con supervisión de API o acceso NGINX. registros, como se explica en Pasos comunes del diagnóstico.
Comprueba si el valor de tiempo de espera de E/S configurado en el router o el host virtual específico es inferior en comparación con la configurada 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:

Accede a la IU de Edge.
Navega a Administrador > Hosts virtuales.
Selecciona un Entorno específico en el que experimentas el problema de tiempo de espera.
Selecciona el host virtual específico para el que deseas verificar el valor de tiempo de espera de E/S.
En Propiedades, observa el valor 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.

Nota: Si el tiempo de espera de lectura del proxy no tiene ningún valor, significa que tomará un valor predeterminado de 57 segundos configurado en el router (a menos que se agote el tiempo de espera de E/S) anuladas en las instancias de 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 el Obtén la API de host virtual 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 la nube privada
```
curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
Aquí:

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 administración en la API, eso significa que tomará la configuración predeterminada de 57 segundos (a menos que se anule el tiempo de espera de E/S 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 /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 la clase virtual específica. de configuración de host.

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 tiene se estableció con el nuevo valor 57 en 0-default.conf, que es el de Terraform para el host virtual predeterminado. Esto indica que el tiempo de espera de E/S está que se configura en 57 segundos en el router para el host virtual predeterminado. Si tienes en varios hosts virtuales, verá 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 crear la API llamadas que fallaron y se produjeron 504 errores.

Cómo verificar 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 ServicePrompt 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 la E/S. tiempo de espera.
Selecciona el extremo de destino específico que deseas verificar.
Consulta la propiedad io.timeout.millis con un valor adecuado en la Elemento <HTTPTargetConnection> en TargetEndpoint configuración.
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 Service conformidad del proxy de API

En la IU de Edge, selecciona el proxy de API específico en el que deseas ver la nueva E/S. el valor de tiempo de espera para la política ServicePrompt.
Selecciona la política ServiceCallout específica que deseas verificar.
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 procesadores de mensajes

Accede a la máquina del procesador de mensajes.

Busca la propiedad HTTPTransport.io.timeout.millis en /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 Se estableció HTTPTransport.io.timeout.millis con el valor 55000 en http.properties Esto indica que el tiempo de espera de E/S se configuró correctamente para 55 segundos en el Message Processor.

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

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

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 del tiempo de espera no se estableció en el host virtual específico. Esto significa que usará 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 se configura solo en el proxy de API, pero el router sigue estando se configura con 57 segundos. Por lo tanto, el tiempo de espera del router se agota a los 57 segundos, mientras que el mensaje El procesador/backend aún está procesando tu solicitud. Esto hace que el router responda con 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 mensaje o el procesador para resolver este problema.

Consulta Prácticas recomendadas para configurar el tiempo de espera de E/S y comprender qué valores de tiempo de espera se deben configurar en diferentes componentes involucrados en el flujo de solicitudes a la API a través de Apigee Edge.
En el ejemplo anterior, si determinas que debes establecer un valor de tiempo de espera más alto porque el servidor de backend requiere más tiempo, y se ha aumentado el tiempo de espera Message Processor en 120 segundos, configura un valor de tiempo de espera más alto por por ejemplo: 123 seconds en el router. Para evitar el impacto en todos los proxies de API Debido al nuevo valor del tiempo de espera, configura el valor de 123 seconds solo en la host virtual específico que se usa en el proxy de API específico.
Sigue las instrucciones que se indican en Configura el tiempo de espera de E/S en los routers para establecer el tiempo de espera en el host virtual.