499 Conexión cerrada del cliente

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 error de tiempo de espera para las solicitudes a la API o la solicitud se interrumpe de forma abrupta mientras aún se ejecuta en Apigee.

Observarás el código de estado 499 para esas solicitudes a la API en la supervisión de API y los registros de acceso de NGINX. A veces, verás diferentes códigos de estado en las estadísticas de la API porque muestran el código de estado que muestra el Message Processor.

Mensaje de error

Las aplicaciones cliente pueden ver errores como los siguientes: 

curl: (28) Operation timed out after 6001 milliseconds with 0 out of -1 bytes received

¿Qué causa los tiempos de espera del cliente?

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

Los routers y los procesadores de mensajes dentro de la plataforma Apigee Edge se configuran con valores de tiempo de espera predeterminados adecuados para garantizar que las solicitudes a la API no tarden demasiado en completarse.

Tiempo de espera en el cliente

Las aplicaciones cliente se pueden configurar con un valor de tiempo de espera adecuado según tus necesidades.

Los clientes, como los navegadores web y las aplicaciones para dispositivos móviles, tienen tiempos de espera definidos por el sistema operativo.

Tiempo de espera en el router

El tiempo de espera predeterminado configurado en los routers es de 57 segundos. Esta es la cantidad máxima de tiempo que un proxy de API puede ejecutar 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 y los hosts virtuales, como se explica en Configura el tiempo de espera de E/S en los routers.

Tiempo de espera en los procesadores de mensajes

El tiempo de espera predeterminado configurado en los procesadores de mensajes es de 55 segundos. Esta es la cantidad máxima de tiempo que el servidor de backend puede tardar en procesar la solicitud y responder al procesador de mensajes. El tiempo de espera predeterminado se puede anular en los procesadores de mensajes o dentro del proxy de API, como se explica en Configura el tiempo de espera de E/S en los procesadores de mensajes.

Si el cliente cierra la conexión con el router antes de que se agote el tiempo de espera del proxy de API, entonces tú observarás el error de tiempo de espera para la solicitud a la API específica. El código de estado 499 Client Closed Connection se registra en el router para esas solicitudes, que se pueden observar en la supervisión de API y los registros de acceso de NGINX.

Causas posibles

En Edge, las causas típicas del error 499 Client Closed Connection son las siguientes:

Causa Descripción Instrucciones de solución de problemas aplicables para
El cliente cerró la conexión de forma abrupta Esto sucede cuando el cliente cierra la conexión debido a que el usuario final cancela la solicitud antes de que se complete. Usuarios de la nube pública y privada
Tiempo de espera de la aplicación cliente Esto sucede cuando se agota el tiempo de espera de la aplicación cliente antes de que el proxy de API tenga tiempo de procesar y enviar la respuesta. Por lo general, esto sucede cuando el tiempo de espera del cliente es menor que el tiempo de espera del router. Usuarios de la nube pública y privada

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:

  1. Navega a la página Analizar > Supervisión de API > Investigar.
  2. Filtra los errores 4xx y selecciona el período.
  3. Traza el código de estado en función del tiempo.
  4. Selecciona una celda que tenga errores 499, como se muestra a continuación:

  5. Verás la información sobre el error 499 en el panel de la derecha, como se muestra a continuación:

  6. 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 499:

    • 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.

    También puedes obtener todos los registros con la API de supervisión de API 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 la supervisión de API establece el proxy en - para los errores HTTP 499, puedes usar la API (API de Logs) para 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://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Revisa el tiempo de respuesta para obtener errores 499 adicionales y verifica si el tiempo de respuesta es coherente (por ejemplo, 30 segundos) en todos los errores 499.

Registros de acceso de NGINX

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

  1. Si eres usuario de nube privada, puedes usar los registros de acceso de NGINX para determinar la información clave sobre los errores HTTP 499.
  2. Verifica los registros de acceso de NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Busca para ver si hay errores 499 durante un período específico (si el problema ocurrió en el pasado) o si aún hay solicitudes que fallan con 499.
  4. Ten en cuenta la siguiente información para algunos de los errores 499:
    • Tiempo total de respuesta
    • URI de solicitud
    • Usuario-agente

    Ejemplo de error 499 del registro de acceso de NGINX:

    2019-08-23T06:50:07+00:00       rrt-03f69eb1091c4a886-c-sy      50.112.119.65:47756
10.10.53.154:8443       10.001  -       -       499     -       422     0
   GET /v1/products HTTP/1.1        -       okhttp/3.9.1    api.acme.org
rrt-03f69eb1091c4a886-c-sy-13001-6496714-1
    50.112.119.65   -       -       -       -       -       -       -       -1      -       -       dc-1  router-pod-1
rt-214-190301-0020137-latest-7d
36       TLSv1.2 gateway-1     dc-1  acme    prod  https   -

    En este ejemplo, vemos la siguiente información:

    • Tiempo total de respuesta: 10.001 segundos. Esto indica que se agotó el tiempo de espera del cliente después de 10.001 segundos.
    • Solicitud: GET /v1/products
    • Host:api.acme.org
    • Usuario-agente:okhttp/3.9.1
  5. Verifica si el tiempo total de respuesta y el usuario-agente son coherentes en todos los errores 499.

Causa: El cliente cerró la conexión de forma abrupta

Diagnóstico

  1. Cuando se llama a una API desde una app de una sola página que se ejecuta en un navegador o una aplicación para dispositivos móviles, el navegador anulará la solicitud si el usuario final cierra el navegador de repente, navega a otra página web en la misma pestaña o detiene la carga de la página haciendo clic o presionando para detener la carga.
  2. Si esto sucede, las transacciones con el estado HTTP 499 suelen variar en el tiempo de procesamiento de la solicitud (tiempo de respuesta) para cada una de las solicitudes.
  3. Para determinar si esta es la causa, compara el tiempo de respuesta y verifica si es diferente para cada uno de los errores 499 con la supervisión de API o los registros de acceso de NGINX, como se explica en Pasos comunes de diagnóstico.

Solución

  1. Esto es normal y, por lo general, no es motivo de preocupación si los errores HTTP 499 ocurren en pequeñas cantidades.

  2. Si sucede con frecuencia para la misma ruta de URL, es posible que el proxy en particular asociado con esa ruta sea muy lento y los usuarios no estén dispuestos a esperar.

    Una vez que sepas qué proxy puede verse afectado, usa el panel de análisis de latencia para investigar más a fondo qué causa la latencia del proxy.

    1. En este caso, determina el proxy afectado con los pasos que se indican en Pasos comunes de diagnóstico.
    2. Usa el panel de análisis de latencia para investigar más a fondo qué causa la latencia del proxy y solucionar el problema.
    3. Si descubres que la latencia es la esperada para el proxy específico, es posible que debas informar a los usuarios que este proxy tardará un tiempo en responder.

Causa: Tiempo de espera de la aplicación cliente

Esto puede ocurrir en varias situaciones.

  1. Se espera que la solicitud tarde un tiempo determinado (por ejemplo, 10 segundos) en completarse en condiciones de funcionamiento normales. Sin embargo, la aplicación cliente se establece con un valor de tiempo de espera incorrecto (por ejemplo, 5 segundos), lo que hace que se agote el tiempo de espera de la aplicación cliente antes de que se complete la solicitud a la API, lo que genera 499. En este caso, debemos establecer el tiempo de espera del cliente en un valor adecuado.
  2. Un servidor de destino o una devolución de llamada tarda más de lo esperado. En este caso, debes corregir el componente adecuado y ajustar los valores de tiempo de espera de forma adecuada.
  3. El cliente ya no necesitaba la respuesta y, por lo tanto, se anuló. Esto puede suceder para las APIs de alta frecuencia, como el autocompletado o el sondeo corto.

Diagnóstico

Supervisión de API o registros de acceso de NGINX

Diagnostica el error con la supervisión de API o los registros de acceso de NGINX:

  1. Consulta los registros de la supervisión de API o los registros de acceso de NGINX para las transacciones HTTP 499, como se explica en Pasos comunes de diagnóstico.
  2. Determina si el tiempo de respuesta es coherente para todos los errores 499.
  3. Si es así, es posible que una aplicación cliente en particular haya configurado un tiempo de espera fijo en su extremo. Si un proxy de API o un servidor de destino responden con lentitud, se agotará el tiempo de espera del cliente antes de que se agote el tiempo de espera del proxy, lo que generará grandes cantidades de HTTP 499s para la misma ruta de acceso de URI. En este caso, determina el usuario-agente de los registros de acceso de NGINX, que puede ayudarte a determinar la aplicación cliente específica.
  4. También es posible que haya un balanceador de cargas delante de Apigee, como Akamai, F5, AWS ELB, etcétera. Si Apigee se ejecuta detrás de un balanceador de cargas personalizado, el tiempo de espera de la solicitud del balanceador de cargas debe configurarse para que sea mayor que el tiempo de espera de la API de Apigee. De forma predeterminada, el router de Apigee se agota después de 57 segundos, por lo que es adecuado configurar un tiempo de espera de la solicitud de 60 segundos en el balanceador de cargas.

Seguimiento

Diagnostica el error con el seguimiento

Si el problema sigue activo (499 errores aún ocurren), sigue estos pasos:

  1. Habilita la sesión de seguimiento para la API afectada en la IU de Edge.
  2. Espera a que se produzca el error o, si tienes la llamada a la API, realiza algunas llamadas a la API y reproduce el error.
  3. Verifica el tiempo transcurrido en cada fase y toma nota de la fase en la que se dedica la mayor parte del tiempo se dedica.
  4. Si observas el error con el tiempo transcurrido más largo inmediatamente después de una de las siguientes fases, indica que el servidor de backend es lento o tarda mucho tiempo en procesar la solicitud:
    • Solicitud enviada al servidor de destino
    • Política ServiceCallout

    A continuación, se muestra un seguimiento de la IU de ejemplo que muestra un tiempo de espera de la puerta de enlace después de que se envió la solicitud al servidor de destino:

Solución

  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. Asegúrate de establecer un valor de tiempo de espera adecuado en la aplicación cliente según las prácticas recomendadas.

Si el problema persiste, consulta Se debe recopilar información de diagnóstico .

Se debe recopilar información de diagnóstico

Si el problema persiste, recopila la siguiente información de diagnóstico y, luego, comunícate con Asistencia de Apigee Edge.

Si eres usuario de nube pública, proporciona la siguiente información:

  • Nombre de la organización
  • Nombre del entorno
  • Nombre del proxy de API
  • Comando curl completo que se usó para reproducir el error de tiempo de espera
  • Archivo de seguimiento de las solicitudes a la API para las que ves errores de tiempo de espera del cliente

Si eres usuario de nube privada, proporciona la siguiente información:

  • Mensaje de error completo observado para las solicitudes con errores
  • Nombre del entorno
  • Paquete de proxy de API
  • Archivo de seguimiento de las solicitudes a la API para las que ves errores de tiempo de espera del cliente
  • Registros de acceso de NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Registros del sistema del Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)