499 Conexión cerrada del cliente

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 error de tiempo de espera para las solicitudes a la API o la solicitud se finaliza de forma abrupta mientras la solicitud a la API 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 API Analytics porque muestra el código de estado que muestra 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 de los clientes?

La ruta típica para una solicitud a la API en la plataforma Edge es Cliente > Router > Message Processor > Backend Server, como se muestra en la siguiente figura:

Los routers y 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 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 y hosts virtuales como se explica en Configura el tiempo de espera de E/S en los routers.

Tiempo de espera en Message Processor

El tiempo de espera predeterminado configurado en Message Processor 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 Message Processor o en el proxy de API, como se explica en Configura el tiempo de espera de E/S en Message Processor.

Si el cliente cierra la conexión con el router antes de que se agote el tiempo de espera del proxy de API, verás el error de tiempo de espera de la solicitud específica a la API. 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 APIs 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 repentina Esto sucede cuando el cliente cierra la conexión porque el usuario final cancela la solicitud antes de que se complete. Usuarios de nubes públicas y privadas
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 del router. Usuarios 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 la API, sigue estos pasos:

  1. Navega a la página Analyze > API Monitoring > Investigate.
  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 499 errores, como se muestra a continuación:

  5. En el panel derecho, verás la información sobre el error 499, como se muestra a continuación:

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

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

    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 el cliente agotó el tiempo de espera.

    Dado que Monitoring de la API establece el proxy en - para los errores HTTP 499, puedes usar la API (API de registros) 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://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Revisa el Tiempo de respuesta para ver si hay errores 499 adicionales y verifica si el Tiempo de respuesta es coherente (como 30 segundos) en todos los errores 499.

Registros de acceso de NGINX

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

  1. Si eres usuario de una nube privada, puedes usar los registros de acceso de NGINX para determinar la información clave de 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 hay alguna solicitud que aún falla 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

    Error 499 de muestra 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   -

    Para este ejemplo, vemos la siguiente información:

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

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

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 cuando hace clic o presiona detener la carga.
  2. Si esto sucede, el tiempo de procesamiento de solicitudes (tiempo de respuesta) de cada una de las solicitudes suele variar en las transacciones con estado HTTP 499.
  3. Puedes determinar si esta es la causa comparando el tiempo de respuesta y verificando si es diferente para cada uno de los errores 499 con la supervisión de la API o los registros de NGINX Access, como se explica en Pasos comunes de diagnóstico.

Resolució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, podría deberse a que el proxy específico asociado con esa ruta es muy lento y los usuarios no están dispuestos a esperar.

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

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

Causa: Se agotó el tiempo de espera de la aplicación cliente

Esto puede ocurrir en varias situaciones.

  1. Se espera que la solicitud demore un cierto tiempo (por ejemplo, 10 segundos) en completarse en condiciones de funcionamiento normales. Sin embargo, la aplicación cliente se configura 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 lleva a 499. En este caso, necesitamos establecer el tiempo de espera del cliente en un valor adecuado.
  2. Un servidor de destino o un texto destacado está tardando más de lo esperado. En este caso, debes corregir el componente apropiado y ajustar los valores de tiempo de espera de manera adecuada.
  3. El cliente ya no necesitaba la respuesta y, por lo tanto, se anuló. Esto puede suceder con las APIs de alta frecuencia, como la función de autocompletar o los sondeos cortos.

Diagnóstico

Supervisión de API o registros de acceso NGINX

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

  1. Verifica los registros de supervisión de la 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 con todos los errores 499.
  3. Si es así, podría deberse a que una aplicación cliente en particular configuró un tiempo de espera fijo. Si un proxy de API o un servidor de destino responde con lentitud, el cliente agotará el tiempo de espera antes de que se agote el tiempo de espera del proxy, lo que generaría grandes cantidades de 499s HTTP para la misma ruta 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 podría ser posible que haya un balanceador de cargas frente a 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 se debe configurar para que sea mayor que el tiempo de espera de la API de Apigee. De forma predeterminada, el tiempo de espera del router de Apigee se agota después de 57 segundos, por lo que es adecuado configurar un tiempo de espera de solicitud de 60 segundos en el balanceador de cargas.

Trace

Cómo diagnosticar el error con Trace

Si el problema sigue activo (todavía se producen errores 499), sigue estos pasos:

  1. Habilita la sesión de seguimiento para la API afectada en la IU de Edge.
  2. Espera a que ocurra 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 pasa la mayor parte del tiempo.
  4. Si observas el error con el tiempo transcurrido más largo inmediatamente después de una de las siguientes fases, significa que el servidor de backend es lento o que tarda mucho en procesar la solicitud:
    • Se envió la solicitud al servidor de destino
    • Política ServiceCallout

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

Resolución

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

Si el problema persiste, ve a Debes 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 el equipo de asistencia de Apigee Edge.

Si eres usuario de una 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 usa para reproducir el error de tiempo de espera
  • Archivo de seguimiento de las solicitudes a la API para las que se muestran errores de tiempo de espera del cliente

Si eres usuario de una 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 se muestran 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 procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log)