499 Conexión cerrada del cliente

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 error de tiempo de espera para las solicitudes a la API o la solicitud finaliza. de forma abrupta mientras la solicitud a la API se sigue ejecutando en Apigee.

Observarás el código de estado 499 para esas solicitudes a la API en la supervisión de API. Registros de acceso de NGINX. A veces, verás diferentes códigos de estado en las estadísticas de la API 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é provoca tiempos de espera del cliente?

La ruta típica de acceso a una solicitud a la API en la plataforma perimetral es Cliente > Router > Procesador de mensajes > Backend Server, como se muestra en la siguiente figura:

Los routers y procesadores de mensajes de la plataforma Apigee Edge se configuran con los valores de tiempo de espera predeterminados 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.

Algunos clientes, como los navegadores web y las apps 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 El proxy de API puede ejecutarse desde que se recibe la solicitud a la API en Edge hasta que la respuesta se que se envían de vuelta, incluida la respuesta del backend y todas las políticas que se ejecutan. Predeterminado el tiempo de espera 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 los procesadores de mensajes

El tiempo de espera predeterminado configurado en Message Processor es de 55 segundos. Esta es la cantidad máxima de tiempo que puede tardar el servidor backend en procesar la solicitud y responder al Mensaje Procesador. El tiempo de espera predeterminado se puede anular en Message Processor o en la API Proxy 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, tú observará el error de tiempo de espera para la solicitud específica a la API. El código de estado 499 Client Closed Connection se registra en el router para esas solicitudes, lo que se puede observar en la API. Monitoring y NGINX Access.

Causas posibles

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

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 el 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 y envía la respuesta. Esto suele suceder cuando el tiempo de espera del cliente es menor que el tiempo de espera 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 API, haz lo siguiente:

  1. Navega a Analyze > Supervisión de API > Investigar.
  2. Filtra en busca de 4xx errores y selecciona el período.
  3. Traza el Código de estado (Status Code) en comparación con la Hora (Time).
  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 indica a continuación: 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, observa los siguientes detalles para algunos 499 errores:

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

    También puedes obtener todos los registros con la API de Monitoring GET de registros. Para Por ejemplo, consultando los registros de org, env, timeRange y status, podrás descargar todas las registros de transacciones en las que se agotó el tiempo de espera del cliente.

    Dado que la supervisión de API establece el proxy en - para HTTP 499 errores, puedes usar la API (API de Registros) para obtener 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 de los errores 499 adicionales y verifica si el tiempo de respuesta es coherente (supongamos 30 segundos) en todas las 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 una nube privada, puedes usar los registros de acceso de NGINX para determinar la información clave sobre los errores 499 de HTTP.
  2. Verifica los registros de acceso de NGINX:
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Realiza una búsqueda para ver si hay errores 499 durante una duración específica (si el problema ocurrió en el pasado) o si todavía hay solicitudes que fallan 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   -

    En este ejemplo, vemos la siguiente información:

    • Tiempo de respuesta total: 10.001 segundos. Esto indica que el Se agotó el tiempo de espera del cliente después de 10.001 segundos
    • Solicitud: GET /v1/products
    • Presentador:api.acme.org
    • Usuario-agente:okhttp/3.9.1
  5. Verifica si el Tiempo de respuesta total y el Usuario-agente coinciden. 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 aplicación de una sola página que se ejecuta en un navegador o una aplicación 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 que detiene la carga al hacer clic o presionar dejar de cargar.
  2. Si esto sucede, las transacciones con el estado HTTP 499 normalmente variarían en el tiempo de procesamiento de la solicitud (tiempo de respuesta) de cada una de las solicitudes.
  3. Para determinar si esta es la causa, puedes comparar el Tiempo de respuesta y verificar si es diferente para cada uno de los errores 499 que usan API Monitoring o NGINX Access registros, como se explica en Pasos comunes del diagnóstico.

Solución

  1. Esto es normal y no suele ser un motivo de preocupación si se produce un error HTTP 499 suceden en pequeñas cantidades.

  2. Si ocurre con frecuencia en la misma ruta de URL, podría deberse a que el proxy específico asociados con esa ruta es muy lenta y los usuarios no están dispuestos a esperar.

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

    1. En este caso, determine qué proxy se ve afectado siguiendo los pasos que se indican en Pasos comunes del diagnóstico.
    2. Utiliza el Panel de análisis de latencia para investigar en más detalle qué causa la latencia del proxy solucionar el problema.
    3. Si descubres que la latencia es la esperada para el proxy específico, entonces es posible para informar a los usuarios que este Proxy tardará un tiempo 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 tarde un tiempo determinado (por ejemplo, 10 segundos) en completarse en condiciones normales de funcionamiento. Sin embargo, la aplicación cliente está configurada con un tiempo de espera (supongamos 5 segundos) que hace que la aplicación cliente agote el tiempo de espera antes de se completa la solicitud a la API, lo que lleva a 499. En este caso, debemos configurar del tiempo de espera del cliente a un valor adecuado.
  2. Un servidor de destino o texto destacado está tardando más de lo esperado. En este caso, debes corregir el error el componente adecuado y ajustar los valores del tiempo de espera de manera apropiada.
  3. El cliente ya no necesitaba la respuesta y, por lo tanto, se anuló. Esto puede suceder con altos niveles de de frecuencia, como autocompletar o sondeo corto.

Diagnóstico

Registros de acceso de NGINX o supervisión de API

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

  1. Verifica los registros de supervisión de API o los registros de acceso de NGINX para las transacciones HTTP 499 como se explica en Pasos comunes del diagnóstico.
  2. Determina si el Tiempo de respuesta es coherente para 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. por su parte. Si un proxy de API o un servidor de destino responde lentamente, el cliente agotaría el tiempo de espera. antes de que se agote el tiempo de espera del proxy, lo que genera grandes cantidades de 499s de HTTP para el 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, la solicitud del balanceador de cargas debe configurarse de modo que sea superior al tiempo de espera de la API de Apigee. De De forma predeterminada, se agota el tiempo de espera del router de Apigee después de 57 segundos, por lo que es adecuado configurar una solicitud de 60 segundos en el balanceador de cargas.

Trace

Diagnostica el error con Trace

Si el problema sigue activo (499 todavía se producen errores), realiza lo siguiente: los siguientes pasos:

  1. Habilita el 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 reproducirlo.
  3. Comprueba el tiempo transcurrido en cada fase y toma nota de la fase en la que la mayor parte del tiempo se agota el tiempo de respuesta.
  4. Si observas el error con el tiempo transcurrido más largo inmediatamente después de uno de fases, indica que el servidor de backend está lento o tarda mucho tiempo para procesar la solicitud:
    • Se envió la solicitud al servidor de destino
    • Política ServiceCallout

    A continuación, se muestra un ejemplo de seguimiento de la IU en el que se muestra el Tiempo de espera de puerta de enlace después de que se finalizaba la Solicitud. enviados al servidor de destino:

Solución

  1. Consulta Prácticas recomendadas para configurar el tiempo de espera de E/S y comprender qué valores de tiempo de espera se deben establecer sobre 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 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 la nube pública, proporciona la siguiente información:

  • Nombre de la organización
  • Nombre del entorno
  • Nombre del proxy de API
  • Completa el comando curl que se usa 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 la nube privada, proporciona la siguiente información:

  • Mensaje de error completo observado para las solicitudes fallidas
  • 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 procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log)