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

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

Problème constaté

L'application cliente reçoit un code d'état HTTP 504 avec le message "Gateway Timeout" en réponse à des appels d'API.

Cette réponse d'erreur indique que le client n'a pas reçu de réponse dans les délais 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 d'inactivité de la passerelle ?

Le chemin typique 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 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'inactivité appropriées. Apigee Edge attend une réponse pour chaque requête API dans un délai 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 Expiration de la passerelle est renvoyée.

Causes possibles :

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

Cause Description Instructions de dépannage pour
Le serveur backend répond avec un délai d'inactivité de la passerelle 504 Le serveur backend expire et renvoie une réponse 504 Gateway Timeout au processeur de messages. Utilisateurs périphériques de cloud privé et public

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

Le serveur backend peut répondre par le code de réponse HTTP 504 Expiration de la passerelle.

Diagnostic

Cette section explique comment diagnostiquer correctement un délai d'expiration de la passerelle 504. Les procédures destinées aux utilisateurs de cloud privé et public sont listées.

Procédure n° 1: Utiliser Trace (utilisateurs de clouds privés et publics)

  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 qui a échoué affiche une réponse 504 du serveur backend dans Trace, le serveur backend est à l'origine du délai avant expiration de la passerelle 504.
  4. Pour déterminer le temps de réponse, cliquez sur la phase Réponse reçue du serveur cible dans Trace. Dans l'exemple ci-dessous, le temps écoulé est de 60 004 ms:

    Détails de la phase dans l&#39;UI

    La section "Détails de la phase" fournit des informations supplémentaires:

    • Il met en surbrillance la réponse 504 Gateway Timeout reçue du serveur backend.
    • La section 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 réponse peuvent différer en fonction de la mise en œuvre du serveur backend.
    • La section 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 Données analytiques enregistrées dans Trace, comme illustré dans la figure ci-dessous:

    les détails de l&#39;analyse à partir d&#39;une trace

    La section Response Headers (En-têtes de réponse) du panneau "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&#39;analyse depuis l&#39;interface utilisateur

    Si ces champs contiennent les valeurs présenté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 la présence d'un chaînage de proxy. Suivez ces étapes pour déterminer si le serveur backend appelle un autre proxy dans Apigee :
    1. Revenez à la phase Request sent to target server (Requête envoyée au serveur cible), puis cliquez sur le bouton Show Curl (Afficher l'URL) pour afficher l'alias 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 en chaîne afin de diagnostiquer la cause de la réponse d'erreur 504 Gateway Timeout. 504 Les délais d'inactivité de la passerelle qui se produisent dans des proxys en chaîne à d'autres étapes du cycle de requête/réponse peuvent être diagnostiqués à l'aide de ce playbook.
    3. Si l'alias de l'hôte du serveur backend pointe vers le serveur backend, passez à la section Résolution.

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

Appelez directement le serveur backend pour confirmer le même comportement de réponse 504 Délai avant expiration de la passerelle que celui 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 nécessaires pour transmettre la requête au serveur backend.
  2. Si le service de backend est accessible au public, vous pouvez utiliser la commande curl, Postman ou tout autre client REST, puis appeler directement l'API du serveur backend.
  3. Si le serveur backend n'est accessible que depuis les processeurs de messages, utilisez la commande 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 de type 504 "Expiration du délai de passerelle", passez à la section Résolution.

Procédure n° 3: Vérifier les journaux d'accès NGINX (utilisateurs du cloud privé 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 est survenu par le passé, s'il est intermittent ou ne peut pas être capturé dans Trace. Pour vérifier les journaux d'accès NGINX, procédez comme suit:

  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 dans 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 elles proviennent 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:

    exemples 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 s'il existe un chaînage de proxy. Autrement dit, le serveur backend ou le point de terminaison cible appelle un autre proxy dans Apigee. Si le proxy d'API utilise un chaînage de proxy , répétez les étapes ci-dessus pour chaque proxy en chaîne afin de diagnostiquer la cause de la réponse d'erreur 504 – Délai avant expiration de la passerelle. 504 Les délais d'inactivité de la passerelle qui se produisent dans les proxys en chaîne à d'autres étapes peuvent être diagnostiqués à l'aide de ce playbook.
  5. En l'absence de chaînage de proxy et que la réponse d'erreur 504 provient du serveur backend, passez à la section Résolution.

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

La surveillance des API vous permet d'isoler rapidement les problèmes afin de diagnostiquer les problèmes d'erreur, de performances et de latence, ainsi que leur source. C'est par exemple le cas des applications pour développeurs, des proxys d'API, des cibles backend ou de la plate-forme d'API.

Suivez un exemple de scénario qui montre comment résoudre les problèmes de 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.

Résolution

En suivant les procédures de diagnostic décrites ci-dessus, vous pouvez collaborer avec l'équipe du serveur backend pour résoudre le problème au niveau du serveur backend. Cela peut inclure l'ajustement des délais avant expiration sur les serveurs backend ou de ceux des équilibreurs de charge devant les serveurs cibles.

Collecte d'informations de diagnostic

Si le problème persiste, transmettez les informations de diagnostic suivantes à 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
  • Terminez la commande curl permettant de reproduire la réponse d'erreur 504.
  • Fichier de suivi dans lequel les requêtes API reçoivent une réponse d'erreur 504 Gateway Timeout

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
  • Groupe de proxys d'API
  • Fichier de suivi dans lequel les requêtes API reçoivent une réponse d'erreur 504 Gateway Timeout (Expiration de la passerelle 504).
  • 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