499 Connexion fermée du client

Vous consultez la documentation Apigee Edge.
Accédez à la documentation**Apigee X**. info

Problème constaté

L'application cliente reçoit une erreur de délai avant expiration pour les requêtes API ou la requête est arrêtée brusquement alors qu'elle est toujours en cours d'exécution sur Apigee.

Le code d'état 499 s'affiche pour ces requêtes API dans la surveillance des API et les journaux d'accès NGINX. Parfois, différents codes d'état s'affichent dans l'analyse des API, car ils indiquent le code d'état renvoyé par le processeur de messages.

Message d'erreur

Les applications clientes peuvent afficher des erreurs telles que : 

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

Quelles sont les causes des délais avant expiration du client ?

Le chemin d'une requête API sur la plate-forme Edge est généralement le suivant : Client > Routeur > Processeur de messages > Serveur backend , comme illustré dans la figure ci-dessous :

Les routeurs et les processeurs de messages de la plate-forme Apigee Edge sont configurés avec des valeurs de délai avant expiration par défaut appropriées pour s'assurer que les requêtes API ne prennent pas trop de temps.

Délai avant expiration sur le client

Les applications clientes peuvent être configurées avec une valeur de délai avant expiration appropriée en fonction de vos besoins.

Les clients tels que les navigateurs Web et les applications mobiles ont des délais avant expiration définis par le système d'exploitation.

Délai avant expiration sur le routeur

Le délai avant expiration par défaut configuré sur les routeurs est de 57 secondes. Il s'agit de la durée maximale pendant laquelle un proxy d'API peut s'exécuter à partir du moment où la requête API est reçue sur Edge jusqu'à ce que la réponse soit renvoyée, y compris la réponse du backend et toutes les règles exécutées. Le délai avant expiration par défaut peut être remplacé sur les routeurs et les hôtes virtuels, comme expliqué dans Configuration du délai avant expiration des E/S sur les routeurs.

Délai avant expiration sur les processeurs de messages

Le délai avant expiration par défaut configuré sur les processeurs de messages est de 55 secondes. Il s'agit de la durée maximale pendant laquelle le serveur backend peut traiter la requête et répondre au processeur de messages . Le délai avant expiration par défaut peut être remplacé sur les processeurs de messages ou dans le proxy d'API, comme expliqué dans Configuration du délai avant expiration des E/S sur les processeurs de messages.

Si le client ferme la connexion avec le routeur avant l'expiration du délai avant expiration du proxy d'API, vous observerez l'erreur de délai avant expiration pour la requête API spécifique. Le code d'état 499 Client Closed Connection est consigné dans le routeur pour ces requêtes, ce qui peut être observé dans la surveillance des API et les journaux d'accès NGINX.

Causes possibles :

Dans Edge, les causes typiques de l'erreur 499 Client Closed Connection sont les suivantes :

Cause Description Instructions de dépannage applicables
Le client a fermé la connexion de manière inattendue Cela se produit lorsque le client ferme la connexion, car l'utilisateur final annule la requête avant qu'elle ne soit terminée. Utilisateurs de Cloud public et privé
Délai avant expiration de l'application cliente Cela se produit lorsque le délai avant expiration de l'application cliente est dépassé avant que le proxy d'API n'ait le temps de traiter et d'envoyer la réponse. Cela se produit généralement lorsque le délai avant expiration du client est inférieur à celui du routeur. Utilisateurs de Cloud public et privé

Étapes de diagnostic courantes

Utilisez l'un des outils/techniques suivants pour diagnostiquer cette erreur :

  • Surveillance des API
  • Journaux d'accès NGINX

Surveillance des API

Pour diagnostiquer l'erreur à l'aide de la surveillance des API :

  1. Accédez à la page Analyze > API Monitoring > Investigate (Analyser > Surveillance des API > Examiner).
  2. Filtrez les erreurs 4xx et sélectionnez la période.
  3. Tracez le code d'état par rapport au temps.
  4. Sélectionnez une cellule contenant des erreurs 499, comme illustré ci-dessous :

  5. Les informations sur l'erreur 499 s'affichent dans le volet de droite, comme illustré ci-dessous :

  6. Dans le volet de droite, cliquez sur View logs (Afficher les journaux).

    Dans la fenêtre Traffic Logs (Journaux de trafic), notez les détails suivants pour certaines erreurs 499 :

    • Request (Requête) : fournit la méthode de requête et l'URI utilisés pour effectuer les appels.
    • Response Time (Temps de réponse) : fournit le temps total écoulé pour la requête.

    Vous pouvez également obtenir tous les journaux à l'aide de l'API Monitoring GET logs de la surveillance des API. Par exemple, en interrogeant les journaux pour org, env, timeRange, et status, vous pouvez télécharger tous les journaux des transactions pour lesquelles le délai avant expiration du client a été dépassé.

    Étant donné que la surveillance des API définit le proxy sur - pour les erreurs HTTP 499, vous pouvez utiliser l'API (API Logs) pour obtenir le proxy associé à l’hôte virtuel et au chemin d’accès.

    For example : 

    curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https://VIRTUAL_HOST/BASEBATH" -H "Authorization: Bearer $TOKEN"
  7. Examinez le temps de réponse pour les erreurs 499 supplémentaires et vérifiez si le temps de réponse est cohérent (par exemple, 30 secondes) pour toutes les erreurs 499.

Journaux d'accès NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX :

  1. Si vous êtes un utilisateur de Cloud privé, vous pouvez utiliser les journaux d’accès NGINX pour déterminer les informations clés sur les erreurs HTTP 499.
  2. Consultez les journaux d'accès NGINX :
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  3. Recherchez s'il existe des erreurs 499 pendant une durée spécifique (si le problème s'est produit dans le passé) ou si des requêtes échouent toujours avec 499.
  4. Notez les informations suivantes pour certaines erreurs 499 :
    • Temps de réponse total
    • URI de la demande
    • User-agent

    Exemple d'erreur 499 dans le journal d'accès 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   -

    Dans cet exemple, les informations suivantes s'affichent :

    • Temps de réponse total : 10.001 secondes. Cela indique que le délai avant expiration du client a été dépassé après 10,001 secondes.
    • Requête : GET /v1/products
    • Hôte:api.acme.org
    • User-agent :okhttp/3.9.1
  5. Vérifiez si le temps de réponse total et le user-agent sont cohérents pour toutes les erreurs 499.

Cause : le client a fermé la connexion de manière inattendue

Diagnostic

  1. Lorsqu'une API est appelée à partir d'une application monopage exécutée dans un navigateur ou une application mobile, le navigateur abandonne la requête si l'utilisateur final ferme soudainement le navigateur, accède à une autre page Web dans le même onglet ou arrête le chargement de la page en cliquant ou en appuyant sur Arrêter le chargement.
  2. Dans ce cas, le temps de traitement des requêtes (temps de réponse) des transactions avec l'état HTTP 499 varie généralement pour chaque requête.
  3. Pour déterminer si c'est la cause, comparez le temps de réponse et vérifiez s'il est différent pour chacune des erreurs 499 à l'aide de la surveillance des API ou des journaux d'accès NGINX, comme expliqué dans Étapes de diagnostic courantes.

Solution

  1. C'est normal et cela ne doit généralement pas être une source d'inquiétude si les erreurs HTTP 499 se produisent en petites quantités.

  2. Si cela se produit souvent pour le même chemin d'URL, cela peut être dû au fait que le proxy associé à ce chemin est très lent et que les utilisateurs ne sont pas disposés à attendre.

    Une fois que vous savez quel proxy peut être affecté, utilisez le tableau de bord d'analyse de la latence pour examiner plus en détail la cause de la latence du proxy.

    1. Dans ce cas, déterminez le proxy affecté en suivant les étapes décrites dans Étapes de diagnostic courantes.
    2. Utilisez le tableau de bord d'analyse de la latence pour examiner plus en détail la cause de la latence du proxy et résoudre le problème.
    3. Si vous constatez que la latence est attendue pour le proxy spécifique, vous devrez peut-être informer vos utilisateurs que ce proxy mettra un certain temps à répondre.

Cause : délai avant expiration de l'application cliente

Cela peut se produire dans plusieurs scénarios.

  1. Il est prévu que la requête prenne un certain temps (par exemple, 10 secondes) dans des conditions de fonctionnement normales. Toutefois, l'application cliente est définie avec une valeur de délai avant expiration incorrecte (par exemple, 5 secondes), ce qui entraîne l'expiration du délai avant expiration de l'application cliente avant la fin de la requête API, ce qui entraîne une erreur 499. Dans ce cas, nous devons définir le délai avant expiration du client sur une valeur appropriée.
  2. Un serveur cible ou un appel prend plus de temps que prévu. Dans ce cas, vous devez corriger le composant approprié et ajuster les valeurs de délai avant expiration de manière appropriée.
  3. Le client n'a plus besoin de la réponse et a donc abandonné la requête. Cela peut se produire pour les API à haute fréquence, telles que la saisie semi-automatique ou l'interrogation courte.

Diagnostic

Surveillance des API ou journaux d'accès NGINX

Diagnostiquez l'erreur à l'aide de la surveillance des API ou des journaux d'accès NGINX :

  1. Consultez les journaux de surveillance des API ou les journaux d'accès NGINX pour les transactions HTTP 499, comme expliqué dans Étapes de diagnostic courantes.
  2. Déterminez si le temps de réponse est cohérent pour toutes les erreurs 499.
  3. Si c'est le cas, il est possible qu'une application cliente spécifique ait configuré un délai avant expiration fixe de son côté. Si un proxy d'API ou un serveur cible répond lentement, le délai avant expiration du client est dépassé avant celui du proxy, ce qui entraîne un grand nombre d'erreurs HTTP 499s pour le même chemin d'URI. Dans ce cas, déterminez le user-agent à partir des journaux d’accès NGINX, ce qui peut vous aider à identifier l’application cliente spécifique.
  4. Il est également possible qu'un équilibreur de charge se trouve devant Apigee, tel qu'Akamai, F5, AWS ELB, etc. Si Apigee s'exécute derrière un équilibreur de charge personnalisé, le délai avant expiration de la requête de l'équilibreur de charge doit être configuré pour être supérieur au délai avant expiration de l'API Apigee. Par défaut, le délai avant expiration du routeur Apigee est de 57 secondes. Il est donc approprié de configurer un délai avant expiration de la requête de 60 secondes sur l'équilibreur de charge.

Trace

Diagnostiquez l'erreur à l'aide de Trace

Si le problème persiste (499 erreurs se produisent toujours), procédez comme suit :

  1. Activez la session de trace pour l'API concernée dans l'interface utilisateur Edge.
  2. Attendez que l'erreur se produise ou, si vous disposez de l'appel d'API, effectuez quelques appels d'API et reproduisez l'erreur.
  3. Vérifiez le temps écoulé à chaque phase et notez la phase où la plupart du temps est passé.
  4. Si l'erreur avec le temps écoulé le plus long s'affiche immédiatement après l'une des des phases suivantes, cela indique que le serveur backend est lent ou qu'il met beaucoup de temps à traiter la requête :
    • Requête envoyée au serveur cible
    • Règle ServiceCallout

    Voici un exemple de trace d'interface utilisateur montrant un délai avant expiration de la passerelle après l'envoi de la requête au serveur cible :

Solution

  1. Consultez Bonnes pratiques pour configurer le délai avant expiration des E/S afin de comprendre les valeurs de délai avant expiration à définir sur les différents composants impliqués dans le flux de requêtes API via Apigee Edge.
  2. Assurez-vous de définir une valeur de délai avant expiration appropriée sur l'application cliente, conformément aux bonnes pratiques.

Si le problème persiste, consultez la page Vous devez collecter des informations de diagnostic .

Vous devez collecter des informations de diagnostic

Si le problème persiste, rassemblez les informations de diagnostic suivantes, puis contactez l'assistance Apigee Edge.

Si vous êtes un utilisateur de Cloud public, fournissez les informations suivantes :

  • Nom de l'organisation
  • Nom de l'environnement
  • Nom de proxy d'API
  • Commande curl complète utilisée pour reproduire l'erreur de délai avant expiration
  • Fichier de trace pour les requêtes API pour lesquelles vous voyez des erreurs de délai avant expiration du client

Si vous êtes un utilisateur de Cloud privé, fournissez les informations suivantes :

  • Message d'erreur complet observé pour les requêtes ayant échoué
  • Nom de l'environnement
  • Bundle de proxy d'API
  • Fichier de trace pour les requêtes API pour lesquelles vous voyez des erreurs de délai avant expiration du client
  • Journaux d'accès NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  • Journaux système du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log)