504 Expiration du délai de la passerelle du serveur backend

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente reçoit un code d'état HTTP 504 avec le message "Gateway Timeout" (Délai avant expiration de la passerelle) en réponse aux appels d'API

Cette réponse d'erreur indique que le client n'a pas reçu de réponse rapide d'Apigee Edge ou du serveur backend lors de l'exécution d'un appel d'API.

Message d'erreur

L'application cliente reçoit le code de réponse suivant: 

HTTP/1.1 504 Gateway Timeout

Ce code peut être suivi d'un message d'erreur semblable à celui-ci: 

<html>
<head><title>504 Gateway Timeout</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Timeout</h1></center>
</body>
</html>

Quelles sont les causes des délais avant expiration de la passerelle ?

Le chemin typique pour une requête API effectuée via Apigee Edge est Client -> Routeur -> Processeur de messages -> Serveur backend, comme illustré dans la figure ci-dessous:

Chemin de la requête API

L'application cliente, les routeurs et les processeurs de messages sont configurés avec des valeurs de délai d'expiration appropriées. Apigee Edge attend une réponse pour chaque requête API dans un laps de temps donné en fonction des valeurs de délai d'expiration. Si la réponse n'est pas reçue dans le délai spécifié, une réponse 504 Gateway Timeout est renvoyée.

Causes possibles :

Dans Apigee Edge, la cause typique d'une réponse 504 Gateway Timeout du serveur backend est la suivante:

Cause Description Instructions de dépannage pour
Réponse du serveur backend avec un délai d'expiration de la passerelle 504 Le serveur backend expire et renvoie une réponse "504 Gateway Timeout" au processeur de messages. Utilisateurs de cloud privé et public Edge

Réponse du serveur backend avec un code d'expiration de la passerelle 504

Le serveur backend peut répondre avec un code de réponse HTTP "504 Gateway Timeout".

Diagnostic

Cette section explique comment diagnostiquer correctement un délai d'expiration de passerelle 504. Les procédures pour les réseaux privés et Les utilisateurs du cloud public y sont répertoriés.

Procédure n° 1: Utiliser Trace (utilisateurs de cloud privé et public)

  1. Activez Trace dans l'interface utilisateur d'Apigee pour l'API concernée.
  2. Envoyez une requête au serveur backend.
  3. Si la requête API en échec affiche une réponse 504 du serveur backend dans Trace, alors la cause du délai d'expiration de la passerelle 504 est le serveur backend.
  4. Pour déterminer le temps de réponse, cliquez sur la réponse reçue du serveur cible. dans Trace. Dans l'exemple que vous voyez, le temps écoulé est de 60 004 ms:

    détails de la phase à partir de l&#39;UI

    La section "Phase Details" (Détails de la phase) fournit des informations supplémentaires:

    • Il met en surbrillance la réponse 504 Gateway Timeout (Délai avant expiration de la passerelle 504) reçue du serveur backend.
    • La section Response Content (Contenu de la réponse) affiche le corps complet de la réponse du à votre serveur backend. Comme indiqué précédemment, le format et le contenu de la charge utile de la réponse peuvent différer en fonction de l'implémentation du serveur backend.
    • En-tête de réponse > Server peut indiquer l'origine de la réponse.
  5. Pour afficher les données Analytics et confirmer le diagnostic, cliquez sur Données Analytics enregistrées. dans Trace, comme illustré dans la figure ci-dessous:

    détails d&#39;analyse à partir de la trace

    La section Response Headers (En-têtes de réponse) des "Phase Details" (Détails de la phase) affiche les valeurs des X-Apigee-fault-code et X-Apigee-fault-source, comme indiqué dans les figure ci-dessous:

    détails de la phase d&#39;analyse à partir de l&#39;UI

    Si ces champs contiennent les valeurs indiquées dans le tableau ci-dessous, l'erreur 504 se produit à partir du serveur backend:

    En-têtes de réponse Valeur
    X-Apigee-fault-source cible
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  6. Rechercher le chaînage de proxy. Procédez comme suit pour déterminer si le serveur backend appelle un autre proxy dans Apigee: <ph type="x-smartling-placeholder">
      </ph>
    1. Revenez à la phase Request sent to target server (Demande envoyée au serveur cible), puis cliquez sur le bouton Show Curl (Afficher Curl) pour afficher l'alias d'hôte du serveur backend.
    2. Si l'alias d'hôte du serveur backend pointe vers un alias d'hôte virtuel, le chaînage de proxy se trouve dans à un emplacement. Répétez les étapes ci-dessus pour chaque proxy enchaîné afin de diagnostiquer la cause de la passerelle 504. Réponse d'erreur de délai d'inactivité. 504 Délais d'inactivité de la passerelle survenant dans les proxys en chaîne à d'autres étapes de le cycle demande/réponse peut être diagnostiqué à l'aide de ce playbook.
    3. Si l'alias d'hôte du serveur backend pointe vers le serveur backend, passez à Résolution.

Procédure n° 2: appeler directement l'API du serveur backend (utilisateurs de cloud public et privé)

Appelez directement le serveur backend pour vérifier que le comportement de la réponse 504 Gateway Timeout a été identique au délai d'expiration de la passerelle. lorsque la requête est effectuée via Apigee Edge.

  1. Assurez-vous de disposer de tous les en-têtes, paramètres de requête et identifiants nécessaires pour est transmise au serveur backend dans la requête.
  2. Si le service de backend est accessible publiquement, vous pouvez utiliser la commande curl, Postman ou tout autre client REST, puis appelez directement l'API du serveur backend.
  3. Si le serveur backend n'est accessible qu'à partir des processeurs de messages, utilisez le curl , Postman ou tout autre client REST pour appeler l'API du serveur backend directement à partir du Processeur de messages.
  4. Si le service de backend renvoie une réponse 504 Gateway Timeout, passez à Résolution.

Procédure n° 3: vérifier les journaux d'accès NGINX (utilisateurs Private Cloud uniquement)

Les journaux d'accès NGINX peuvent aider à déterminer si la réponse d'erreur 504 a été envoyée par le serveur backend. Cela est particulièrement utile si le problème s'est produit par le passé, s'il est intermittent ou ne peut pas être capturé dans Trace. Procédez comme suit pour vérifier les journaux d'accès NGINX:

  1. Affichez les journaux d'accès NGINX à l'aide de la commande suivante: 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  2. Recherchez les réponses d'erreur 504 pour le proxy d'API concerné. Vous pouvez vérifier une période spécifique, si le problème s'est produit par le passé, ou déterminer si les requêtes échouent toujours avec une erreur 504.
  3. En cas de réponses d'erreur 504, déterminez si elles proviennent du à votre serveur backend.

    4. La figure ci-dessous est un exemple d'entrée de journal NGINX affichant une erreur 504 causée par la serveur cible:

    exemples de journaux nginx

    Si les champs X-Apigee-fault-source et X-Apigee-fault-code contiennent le paramètre indiquées dans le tableau ci-dessous, la réponse 504 provient du serveur backend:

    En-têtes de réponse Valeur
    X-Apigee-fault-source cible
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  4. Examinez le proxy d'API concerné pour vérifier s'il existe un chaînage de proxy. En d'autres termes, le serveur backend/le point de terminaison cible appelle un autre proxy dans Apigee. Si le proxy d'API est à l'aide du chaînage de proxy , répétez les étapes ci-dessus pour chaque proxy enchaîné afin de diagnostiquer la cause de l'expiration de la passerelle 504. . 504 Les délais d'inactivité de la passerelle survenant dans les proxys en chaîne à d'autres étapes peuvent être diagnostiqués à l'aide de ce playbook.
  5. Si aucun via un chaînage de proxy et que la réponse d'erreur 504 provient du serveur backend. passez à l'étape Résolution.

Procédure n° 4: Utiliser la surveillance des API (utilisateurs de cloud public uniquement)

La surveillance des API vous permet d'isoler les problèmes pour diagnostiquer rapidement les erreurs, les performances et la latence, ainsi que leur source, comme les applications de développement, Les proxys d'API, les cibles backend ou la plate-forme d'API.

Examiner un exemple de scénario qui montre comment résoudre les problèmes 5xx de vos API à l'aide de la surveillance des API. Par exemple : configurer une alerte pour avertir les administrateurs lorsque le nombre de codes d'état 504 dépasse un certain seuil.

Solution

En vous appuyant sur les procédures de diagnostic décrites ci-dessus, vous pouvez résoudre le problème avec l'équipe du serveur backend le problème sur le serveur backend. Il peut s'agir, par exemple, d'ajuster les délais d'inactivité dans les serveurs backend ou les délais avant expiration dans tous les équilibreurs de charge devant les serveurs cibles.

Recueillir des informations de diagnostic

Si le problème persiste, partagez les informations de diagnostic suivantes avec l'assistance Apigee.

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

  • Nom de l'organisation
  • Nom de l'environnement
  • Nom du proxy d'API
  • Commande curl complète utilisée pour reproduire la réponse d'erreur 504
  • Fichier de suivi avec les requêtes API recevant une réponse d'erreur "504 Gateway Timeout" (Délai d'expiration de la passerelle)

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

  • Message d'erreur complet observé pour les requêtes en échec
  • Nom de l'environnement
  • Groupe de proxys d'API
  • Fichier de suivi contenant les requêtes API recevant une réponse d'erreur 504 Gateway Timeout
  • Journaux d'accès NGINX 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  • Journaux de processeur de messages 
    /opt/apigee/var/log/edge-message-processor/logs/system.log