499 Connexion fermée du client

Vous consultez la documentation d'Apigee Edge.
Consultez la documentation Apigee X. en savoir plus

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 interrompue soudainement pendant que la requête API est toujours en cours d'exécution sur Apigee.

Vous allez observer le code d'état 499 pour ces requêtes API dans l'API Monitoring et les journaux d'accès NGINX. Vous verrez parfois des codes d'état différents dans API Analytics, car il indique le code d'état renvoyé par le processeur de messages.

Message d'erreur

Les applications clientes peuvent rencontrer 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 d'inactivité du client ?

Le chemin typique d'une requête API sur la plate-forme périphérique est Client > Routeur > Processeur de messages > Serveur backend, comme illustré dans la figure suivante:

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

Expiration du délai d'attente du client

Les applications clientes peuvent être configurées avec une valeur de délai d'inactivité adaptée à vos besoins.

Le système d'exploitation définit des délais d'inactivité pour les clients tels que les navigateurs Web et les applications mobiles.

Délai d'inactivité du 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 d'exécution d'un proxy d'API entre le moment où la demande API est reçue sur Edge et le renvoi de la réponse, y compris la réponse du backend et toutes les stratégies qui sont exécutées. Le délai avant expiration par défaut peut être ignoré sur les routeurs et les hôtes virtuels, comme expliqué dans la section Configurer le délai avant expiration des E/S sur les routeurs.

Délai d'inactivité 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 que le serveur backend peut prendre pour traiter la requête et répondre au processeur de messages. Le délai avant expiration par défaut peut être ignoré sur les processeurs de messages ou dans le proxy d'API, comme expliqué dans la section Configurer le délai avant expiration des E/S sur les processeurs de messages.

Si le client ferme la connexion avec le routeur avant que le proxy d'API n'expire, vous verrez l'erreur de délai d'inactivité pour la requête API spécifique. Le code d'état 499 Client Closed Connection est enregistré dans le routeur pour ces requêtes, qui peut être observé dans les journaux de surveillance de l'API et 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 brusquement fermé la connexion Cela se produit lorsque le client ferme la connexion, car l'utilisateur final a annulé la requête avant qu'elle ne soit terminée. Utilisateurs des clouds publics et privés
Délai avant expiration de l'application cliente Cela se produit lorsque l'application cliente expire 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 au délai avant expiration du routeur. Utilisateurs des clouds publics et privés

Étapes de diagnostic courantes

Utilisez l'un des outils ou 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 > Enquêter).
  2. Filtrez les erreurs 4xx et sélectionnez la période.
  3. Représentez le code d'état par rapport à l'heure.
  4. Sélectionnez une cellule contenant 499 erreur, comme indiqué 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 Afficher les journaux.

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

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

    Vous pouvez également obtenir tous les journaux à l'aide de l'API GET logs de Monitoring. Par exemple, en interrogeant les journaux sur org, env, timeRange et status, vous pouvez télécharger tous les journaux des transactions pour lesquelles le client a expiré.

    Étant donné que l'API Monitoring 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 identifier d'autres erreurs 499 et vérifiez si le temps de réponse est cohérent (disons 30 secondes) pour toutes les erreurs 499.

Journaux d'accès NGINX

Pour diagnostiquer l'erreur à l'aide des journaux d'accès NGINX, procédez comme suit:

  1. Si vous êtes un utilisateur du cloud privé, vous pouvez utiliser les journaux d'accès NGINX pour déterminer les informations essentielles sur les erreurs HTTP 499.
  2. Vérifiez 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 déjà produit par le passé) ou si des requêtes échouent toujours avec 499.
  4. Notez les informations suivantes pour certaines des erreurs 499 :
    • Temps de réponse total
    • URI de la requête
    • User-agent

    Exemple d'erreur 499 à partir du 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   -

    Pour cet exemple, nous voyons les informations suivantes:

    • Temps de réponse total:10.001 secondes. Cela indique que le client a expiré 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 l'user-agent sont cohérents pour toutes les erreurs 499.

Cause: le client a brusquement fermé la connexion

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 annule 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 (temps de réponse) des transactions associées à l'état HTTP 499 varie généralement pour chacune des requêtes.
  3. Pour déterminer si c'est le cas, comparez le temps de réponse et vérifiez s'il est différent pour chacune des erreurs 499 à l'aide de l'API Monitoring ou des journaux d'accès NGINX, comme expliqué dans la section Étapes de diagnostic courantes.

Résolution

  1. Ce comportement est normal et n'est généralement pas un problème 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 prêts à attendre.

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

    1. Dans ce cas, identifiez le proxy concerné à l'aide de la procédure décrite dans la section Étapes de diagnostic courantes.
    2. Utilisez le tableau de bord d'analyse de 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 la réponse de ce proxy prendra un certain temps.

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

Cela peut se produire dans plusieurs cas.

  1. Dans des conditions de fonctionnement normales, il est prévu que la requête prenne un certain temps (par exemple, 10 secondes). Cependant, l'application cliente est définie avec une valeur de délai d'inactivité incorrecte (disons 5 secondes), ce qui entraîne le délai d'inactivité de l'application cliente avant la fin de la requête API, ce qui génère 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 annulé. 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 l'API Monitoring ou des journaux d'accès NGINX:

  1. Vérifiez les journaux de surveillance de l'API ou les journaux d'accès NGINX pour les transactions HTTP 499, comme expliqué dans la section Étapes de diagnostic courantes.
  2. Déterminez si le temps de réponse est cohérent pour toutes les erreurs 499.
  3. Si oui, il est possible qu'une application cliente particulière ait configuré un délai avant expiration fixe à son extrémité. Si un proxy d'API ou un serveur cible répond lentement, le client expire avant que le proxy n'expire, ce qui génère de grandes quantités de 499s HTTP pour le même chemin d'URI. Dans ce cas, identifiez le user-agent à partir des journaux d'accès NGINX, qui peuvent vous aider à déterminer 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 des requêtes 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 routeur Apigee expire au bout de 57 secondes. Vous pouvez donc configurer un délai avant expiration de la requête de 60 secondes sur l'équilibreur de charge.

Trace

Diagnostiquer l'erreur à l'aide de Trace

Si le problème est toujours actif (des erreurs 499 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 d'un appel d'API, effectuez des appels d'API et reproduisez l'erreur.
  3. Vérifiez le temps écoulé à chaque phase et notez la phase au cours de laquelle la majeure partie du temps est consacrée.
  4. Si vous observez l'erreur avec le temps le plus long immédiatement après l'une des phases suivantes, cela signifie que le serveur backend est lent ou que le traitement de la requête prend beaucoup de temps :
    • Requête envoyée au serveur cible
    • Règle ServiceCallout

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

Résolution

  1. Reportez-vous aux bonnes pratiques de configuration du délai d'expiration des E/S pour comprendre quelles valeurs de délai d'expiration doivent être définies sur les différents composants impliqués dans le flux de requêtes API via Apigee Edge.
  2. Veillez à 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 Obligation de recueillir 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:

  • Le nom de l'organisation.
  • Nom de l'environnement
  • Nom du proxy d'API
  • Exécuter la commande curl permettant de reproduire l'erreur de délai avant expiration
  • Fichier de suivi des requêtes API pour lesquelles vous constatez des erreurs d'expiration du délai du client

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

  • Message d'erreur complet observé pour les requêtes ayant échoué
  • Nom de l'environnement
  • Groupe de proxys d'API
  • Fichier de suivi des requêtes API pour lesquelles vous constatez des erreurs d'expiration du délai 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)