502 – Erreur de délai avant expiration de la passerelle incorrecte

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

Symptôme

L'application cliente reçoit une erreur 502 Bad Gateway. Le processeur de messages renvoie cette erreur à l'application cliente lorsqu'elle ne reçoit pas de réponse. à partir d'un serveur backend.

Message d'erreur

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

HTTP/1.1 502 Bad Gateway

Le message d'erreur suivant peut également s'afficher:

{
 "fault": {
    "faultstring":"Bad Gateway",
    "detail":{
        "errorcode":"messaging.adaptors.http.flow.BadGateway"
    }
 }
}

Cause possible

La cause possible de ce problème est indiquée dans le tableau suivant:

Cause Description La procédure de dépannage peut être effectuée
Expiration du handshake TLS/SSL Le délai est expiré lors du handshake TLS/SSL entre le processeur de messages et le serveur backend. Utilisateurs du cloud privé et public Edge

Cause : Dépassement du délai d'expiration du handshake TLS/SSL

Dans Apigee Edge, vous pouvez configurer une connexion TLS/SSL au serveur backend pour activer la communication TLS. entre le processeur de messages Edge et un serveur backend.

Un handshake TLS/SSL implique plusieurs étapes. Cette erreur se produit généralement le handshake TLS/SSL entre le processeur de messages et un serveur backend expire.

Diagnostic

Cette section explique comment diagnostiquer correctement le délai avant expiration d'un handshake TLS/SSL. Vous trouverez la liste des instructions pour le cloud privé et le cloud public Edge.

Examiner le résultat de la session Trace

Les étapes suivantes expliquent comment effectuer un diagnostic préliminaire du problème à l'aide de l'outil Apigee Edge Trace.

  1. Dans l'interface utilisateur Edge, activez une session de trace pour le proxy d'API concerné.

  2. Si la trace de la requête API ayant échoué indique ce qui suit, il est probable qu'une erreur de délai avant expiration du handshake TLS/SSL se soit produite. La cause probable de l'erreur est que le pare-feu du serveur backend bloque le trafic provenant d'Apigee.

    1. Déterminez si l'erreur 502 Bad Gateway se produit après 55 secondes, ce qui est le délai avant expiration par défaut défini sur le processeur de messages. Si vous voyez que l'erreur s'est produite au bout de 55 secondes, cela vous indique qu'un délai avant expiration a été la cause probable du problème.
    2. Déterminez si l'erreur est à l'origine de l'erreur: messaging.adaptors.http.BadGateway. Encore une fois, cette erreur indique généralement qu'un délai a expiré.

    3. Si vous utilisez le cloud privé Edge, notez la valeur du champ X-Apigee.Message-ID dans la sortie de la trace, comme indiqué ci-dessous. Une application privée L'utilisateur Cloud peut utiliser cette valeur d'ID pour effectuer d'autres opérations de dépannage, comme expliqué plus loin.

      1. Cliquez sur l'icône Données Analytics enregistrées dans le chemin de la trace :

      2. Faites défiler la page vers le bas et notez la valeur du champ X-Apigee.Message-ID.

Pour confirmer que le délai avant expiration du handshake TLS/SSL est à l'origine de l'erreur, suivez les étapes décrites dans les sections suivantes, selon que vous utilisez un cloud public ou un cloud privé.

Étapes de diagnostic supplémentaires pour les utilisateurs de cloud privé Edge uniquement

Si vous utilisez le cloud privé Apigee Edge, vous pouvez suivre les étapes ci-dessous pour identifier la cause de l'erreur d'établissement de la liaison. Au cours de cette étape, vous allez inspecter le fichier journal du processeur de messages à la recherche d'informations pertinentes. Si vous utilisez un cloud public Edge, vous pouvez ignorer cette section et passer à la section Étapes de diagnostic supplémentaires pour les utilisateurs de cloud privé et public.

  1. Vérifiez si vous pouvez vous connecter au serveur backend spécifique directement à partir de chacun des processeurs de messages à l'aide de la commande telnet :

    1. Si le serveur backend est résolu en une seule adresse IP, utilisez la commande suivante :

      telnet BackendServer-IPaddress 443

    2. Si le serveur backend résout plusieurs adresses IP, utilisez le nom d'hôte du serveur backend dans la commande telnet, comme indiqué ci-dessous :

      telnet BackendServer-HostName 443

    Si la connexion au serveur backend s'effectue sans erreur, passez à l'étape suivante.

    Si la commande telnet échoue, vous devez collaborer avec votre équipe réseau pour vérifier la connectivité entre le processeur de messages et le serveur backend.

  2. Vérifiez le fichier journal du processeur de messages pour détecter tout échec d'établissement de la liaison. Ouvrez le fichier :

    /opt/apigee/var/log/edge-message-processor/system.log

    Recherchez l'ID de message unique (valeur de X-Apigee.Message-ID que vous avez trouvée dans le fichier de trace). Déterminez si vous voyez un message d'erreur de handshake associé avec l'ID du message, comme indiqué ci-dessous:

    org:xxx env:xxx api:xxx rev:x messageid:<MESSAGE_ID> NIOThread@1 ERROR HTTP.CLIENT -
HTTPClient$Context.handshakeTimeout() : SSLClientChannel[Connected: Remote:X.X.X.X:443
Local:X.X.X.X]@739028 useCount=1 bytesRead=0 bytesWritten=0 age=55221ms lastIO=55221ms
isOpen=true handshake timeout

Si cette erreur apparaît dans le fichier journal du processeur de messages, poursuivez vos recherches. Passez à la section Étapes de diagnostic supplémentaires pour les utilisateurs de cloud privé et public Edge.

Si le message d'établissement de la liaison n'apparaît pas dans le fichier journal, consultez la section Vous devez collecter des informations de diagnostic.

Autres étapes de diagnostic pour les utilisateurs d'Edge Private et Public Cloud

Pour identifier plus précisément le problème, vous pouvez utiliser l'outil tcpdump pour analyser les paquets TCP/IP afin de vérifier si un délai avant expiration s'est produit lors du handshake TLS/SSL.

  1. Si vous êtes un utilisateur de Private Cloud, vous pouvez capturer les paquets TCP/IP sur le serveur backend ou processeur de messages. De préférence, capturez-les sur le backend. car les paquets sont déchiffrés sur le serveur backend.
  2. Si vous êtes un utilisateur de cloud public, vous n'avez pas accès au message Sous-traitant Toutefois, la capture des paquets TCP/IP sur le serveur backend peut aider identifier un problème.

  3. Après avoir décidé où capturer les paquets TCP/IP, utilisez la commande tcpdump suivante pour les capturer.

    tcpdump -i any -s 0 host <IP address> -w <File name>

    • Si vous prenez les paquets TCP/IP sur le serveur backend, utilisez l'adresse IP publique Adresse IP du processeur de messages dans la commande tcpdump. Pour obtenir de l'aide concernant l'utilisation du pour examiner le trafic du serveur backend, consultez la section tcpdump.

    • Si vous récupérez les paquets TCP/IP sur le processeur de messages, utilisez l'adresse IP publique du serveur backend dans la commande tcpdump. Pour obtenir de l'aide concernant l'utilisation de la commande pour examiner le trafic du processeur de messages, consultez tcpdump.

    • S'il existe plusieurs adresses IP pour le serveur backend/le processeur de messages, alors vous devez essayer une autre utilisation de la commande tcpdump. Pour en savoir plus sur cet outil et sur d'autres variantes de cette commande, consultez tcpdump.

  4. Analysez les paquets TCP/IP à l'aide de l'outil Wireshark ou d'un outil similaire. La capture d'écran suivante montre des paquets TCP/IP dans Wireshark.

  5. Notez dans la sortie Wireshark que la poignée de main TCP à trois voies se termine avec succès dans les 3 premiers paquets.

  6. Le processeur de messages envoie ensuite le message "Client Hello" dans le paquet n° 4.

  7. Comme aucune confirmation n'est reçue du serveur backend, le processeur de messages retransmit le message "Client Hello" plusieurs fois dans les paquets 5, 6 et 7 après avoir attendu un intervalle de temps prédéfini.

  8. Lorsque le processeur de messages ne reçoit aucun accusé de réception après trois tentatives, il envoie le message FIN, ACK au serveur backend pour indiquer qu'il ferme la connexion.

  9. Comme vous l'avez montré dans l'exemple de session Wireshark, la connexion au backend réussi (étape 1), cependant, le handshake SSL a expiré car le backend et le serveur n'a jamais répondu.

Si vous avez suivi les étapes de dépannage de ce playbook et déterminé qu'un délai avant expiration a causé l'erreur de poignée TLS/SSL, consultez la section Solution.

Identifier un problème à l'aide de la surveillance des API

API Monitoring 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.

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, vous pouvez configurer une alerte pour être averti lorsque le nombre de défaillances messaging.adaptors.http.BadGateway dépasse un seuil particulier.

Solution

En règle générale, les délais avant expiration de l'établissement de la liaison SSL se produisent en raison de restrictions de pare-feu sur le serveur backend qui bloquent le trafic provenant d'Apigee Edge. Si vous avez suivi les étapes de diagnostic et déterminé que l'erreur d'établissement de la liaison est due à un délai avant expiration, vous devez faire appel à votre équipe réseau pour identifier la cause et corriger les restrictions du pare-feu.

Notez que les restrictions de pare-feu peuvent être imposées à différentes couches réseau. Il est important de s'assurer que les restrictions concernant les adresses IP du processeur de messages sont supprimées à tous les niveaux de la couche réseau afin de garantir un flux de trafic fluide entre Apigee Edge et le serveur backend.

Si aucune restriction de pare-feu n'est appliquée et/ou si le problème persiste, consultez la section Vous devez collecter des informations de diagnostic.

Vous devez collecter des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez l'assistance Apigee Edge et partagez-les avec elle :

  1. Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
      </ph>
    1. Nom de l'organisation
    2. Nom de l'environnement
    3. Nom du proxy d'API
    4. Commande curl complète pour reproduire l'erreur
    5. Fichier de suivi affichant l'erreur
    6. Paquets TCP/IP capturés sur le serveur backend
  2. Si vous êtes un utilisateur de Private Cloud, fournissez les informations suivantes: <ph type="x-smartling-placeholder">
      </ph>
    1. Message d'erreur complet observé
    2. Bundle de proxy d'API
    3. Fichier de suivi affichant l'erreur
    4. Journaux de processeur de messages /opt/apigee/var/log/edge-message-processor/logs/system.log
    5. Paquets TCP/IP capturés sur le serveur backend ou le processeur de messages.
  3. Détails sur les sections de ce playbook que vous avez essayées et toute autre information qui nous aidera à résoudre rapidement ce problème.