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

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

Problème constaté

L'application cliente reçoit un code d'état HTTP 504 avec le message "Gateway Timeout" 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-dessous : 

<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 type d'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 d'accès aux requêtes API

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

Causes possibles :

Dans Apigee Edge, la cause typique d'une réponse 504 Gateway Timeout (Expiration du délai de la passerelle) du serveur backend est la suivante :

Cause Description Instructions de dépannage pour
Le serveur backend répond avec une erreur 504 Gateway Timeout (Expiration du délai de la passerelle) Le délai avant expiration du serveur backend est dépassé et il renvoie une réponse 504 Gateway Timeout (Expiration du délai de la passerelle) au processeur de messages. Utilisateurs d'Edge Cloud privé et public

Le serveur backend répond avec une erreur 504 Gateway Timeout (Expiration du délai de la passerelle)

Le serveur backend peut répondre avec un code de réponse HTTP 504 Gateway Timeout (Expiration du délai de la passerelle).

Diagnostic

Cette section explique comment diagnostiquer correctement une erreur 504 Gateway Timeout (Expiration du délai de la passerelle). Les procédures pour les utilisateurs de Cloud privé et public sont listées.

Procédure 1 : Utiliser Trace (utilisateurs de Cloud privé et public)

  1. Activez Trace dans l'interface utilisateur 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, la cause de l'erreur 504 Gateway Timeout (Expiration du délai de la passerelle) est le serveur backend.
  4. Pour déterminer le temps de réponse, cliquez sur la phase Response received from target server (Réponse reçue du serveur cible) dans Trace. Dans l'exemple présenté, le temps écoulé est de 60 004 ms :

    Détails de la phase dans l'UI

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

    • Elle met en évidence la réponse 504 Gateway Timeout (Expiration du délai de la passerelle) reçue du serveur backend.
    • La section Response Content (Contenu de la réponse) affiche le corps complet de la réponse du serveur backend. Comme indiqué précédemment, le format et le contenu de la charge utile de la réponse peuvent varier en fonction de la mise en œuvre du serveur backend.
    • La section Response Header > Server (En-tête de réponse > Serveur) peut indiquer l'origine de la réponse.
  5. Pour afficher les données Analytics et confirmer le diagnostic, cliquez sur la phase Analytics Data Recorded (Données Analytics enregistrées) dans Trace, comme illustré dans la figure ci-dessous :

    Détails des données analytiques à partir de la trace

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

    Détails de la phase d'analyse dans l'UI

    Si ces champs contiennent les valeurs indiquées dans le tableau ci-dessous, la réponse d'erreur 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
  6. Vérifiez le chaînage de proxy. Pour déterminer si le serveur backend appelle un autre proxy dans Apigee:
      , procédez comme suit :
    1. Revenez à la phase Request sent to target server (Requête 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 est en place. Répétez les étapes ci-dessus pour chaque proxy chaîné afin de diagnostiquer la cause de la réponse d'erreur 504 Gateway Timeout (Expiration du délai de la passerelle). Les délais avant expiration de la passerelle 504 qui se produisent dans les proxys chaînés à d'autres étapes de le cycle requête/réponse peuvent être diagnostiqués à l'aide de ce guide.
    3. Si l'alias d'hôte du serveur backend pointe vers le serveur backend, passez à la section Solution.

Procédure 2 : Appeler directement l'API du serveur backend (utilisateurs de Cloud public et privé)

Appelez directement le serveur backend pour confirmer le même comportement de réponse 504 Gateway Timeout (Expiration du délai de la passerelle) rencontré 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 requis à transmettre au serveur backend dans le cadre de la requête.
  2. Si le service de backend est accessible publiquement, vous pouvez utiliser la commande curl, Postman ou tout autre client REST, et appeler directement l'API du serveur backend.
  3. Si le serveur backend n'est accessible que depuis les processeurs de messages, utilisez la curl commande, Postman ou tout autre client REST pour appeler directement l'API du serveur backend à partir du processeur de messages.
  4. Si le service de backend renvoie une réponse 504 Gateway Timeout (Expiration du délai de la passerelle), passez à la section « Solution ».

Procédure 3 : Vérifier les journaux d'accès NGINX (utilisateurs de Cloud privé uniquement)

Les journaux d'accès NGINX peuvent vous 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 s'il 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 réponse d'erreur 504.
  3. S'il existe des réponses d'erreur 504, déterminez si la réponse d'erreur provient du serveur backend.

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

    Exemple de journaux nginx

    Si les champs X-Apigee-fault-source et X-Apigee-fault-code contiennent les valeurs 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 le chaînage de proxy c'est-à-dire si le serveur backend/point de terminaison cible appelle un autre proxy dans Apigee. Si le proxy d'API utilise le chaînage de proxy , répétez les étapes ci-dessus pour chaque proxy chaîné afin de diagnostiquer la cause de la réponse d'erreur 504 Gateway Timeout (Expiration du délai de la passerelle). Les délais avant expiration de la passerelle 504 qui se produisent dans les proxys chaînés à d'autres étapes peuvent être diagnostiqués à l'aide de ce guide.
  5. S'il n'y a pas de chaînage de proxy et que la réponse d'erreur 504 provient du serveur backend, passez à la section Solution.

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

La surveillance des API vous permet d'isoler rapidement les zones à problèmes pour diagnostiquer les problèmes d'erreur, de performances et de latence et leur source, tels que les applications de développeur, les proxys d'API, les cibles backend ou la plate-forme d'API.

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

Solution

À l'aide des procédures de diagnostic décrites ci-dessus, vous pouvez collaborer avec l'équipe du serveur backend pour résoudre le problème sur le serveur backend. Cela peut inclure l'ajustement des délais avant expiration sur les serveurs backend ou des délais avant expiration sur 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 trace avec les requêtes API recevant une réponse d'erreur 504 Gateway Timeout (Expiration du délai de la passerelle)

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

  • Message d'erreur complet observé pour les requêtes en échec
  • Nom de l'environnement
  • Bundle de proxy d'API
  • Fichier de trace avec les requêtes API recevant une réponse d'erreur 504 Gateway Timeout (Expiration du délai de la passerelle)
  • Journaux d'accès NGINX 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  • Journaux du processeur de messages 
    /opt/apigee/var/log/edge-message-processor/logs/system.log