Vous consultez la documentation d'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 d'un serveur backend.
Message d'erreur
L'application cliente reçoit le code de réponse suivant:
HTTP/1.1 502 Bad Gateway
En outre, le message d'erreur suivant peut 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 | Les étapes de dépannage peuvent être effectuées par |
| Expiration du handshake TLS/SSL | Un délai avant expiration se produit 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 permettre 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 lorsque le handshake TLS/SSL entre le processeur de messages et un serveur backend expire.
Diagnostic
Cette section explique comment diagnostiquer correctement un délai avant expiration de l'établissement d'une connexion TLS/SSL. Les instructions pour le cloud privé et le cloud public Edge sont indiquées.
Examiner la sortie de la session Trace
La procédure suivante explique comment effectuer un diagnostic préliminaire du problème à l'aide de l'outil de traçage Apigee Edge.
- Dans l'UI Edge, activez une session de trace pour le proxy d'API concerné.
Si la trace de la requête API ayant échoué affiche 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.
- Déterminez si l'erreur 502 Bad Gateway se produit après 55 secondes, qui est le délai d'expiration par défaut défini sur le processeur de messages. Si vous constatez que l'erreur s'est produite au bout de 55 secondes, cela signifie qu'un délai avant expiration est probablement à l'origine du problème.
- 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 avant expiration s'est produit.
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. Un utilisateur de cloud privé peut utiliser cette valeur d'ID pour effectuer d'autres opérations de dépannage, comme expliqué plus loin.
Cliquez sur l'icône Données analytiques enregistrées dans le chemin de la trace:
Faites défiler la page vers le bas et notez la valeur du champ X-Apigee.Message-ID.
Pour vérifier que le délai avant expiration de l'établissement de la liaison TLS/SSL est à l'origine de l'erreur, suivez les étapes décrites dans les sections suivantes, selon que vous utilisez le cloud public ou le cloud privé.
Étapes de diagnostic supplémentaires pour les utilisateurs d'Edge Private Cloud 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. À cette étape, vous recherchez des informations pertinentes dans le fichier journal du processeur de messages. 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.
Vérifiez si vous pouvez vous connecter au serveur backend spécifique directement depuis chacun des processeurs de messages à l'aide de la commande
telnet:Si le serveur backend est résolu en une seule adresse IP, utilisez la commande suivante:
telnet BackendServer-IPaddress 443
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 vous parvenez à vous connecter au serveur backend 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.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.logRecherchez l'ID de message unique (valeur de X-Apigee.Message-ID que vous avez trouvée dans le fichier de trace). Déterminez si un message d'erreur de handshake associé à l'ID du message s'affiche, 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 s'affiche dans le fichier journal du processeur de messages, poursuivez votre analyse. Consultez Étapes de diagnostic supplémentaires pour les utilisateurs du cloud public et privé Edge.
Si le message de handshake ne s'affiche pas dans le fichier journal, accédez à Doit 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.
- Si vous êtes un utilisateur du cloud privé, vous pouvez capturer les paquets TCP/IP sur le serveur backend ou le processeur de messages. De préférence, capturez-les sur le serveur backend, car les paquets sont déchiffrés sur le serveur backend.
- Si vous êtes un utilisateur du cloud public, vous n'avez pas accès au processeur de messages. Toutefois, la capture des paquets TCP/IP sur le serveur backend peut vous aider à identifier un problème.
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 récupérez les paquets TCP/IP sur le serveur backend, utilisez l'adresse IP publique du processeur de messages dans la commande
tcpdump. Pour obtenir de l'aide sur l'utilisation de la commande pour examiner le trafic du serveur backend, consultez 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 sur 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, 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.
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.
Notez dans la sortie Wireshark que l'établissement de la liaison TCP à trois voies se termine correctement dans les trois premiers paquets.
Le processeur de messages envoie ensuite le message "Client Hello" dans le paquet 4.
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.
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.
Comme vous l'avez montré dans l'exemple de session Wireshark, la connexion au backend aboutit (étape 1). Toutefois, le handshake SSL a expiré, car le serveur backend n'a jamais répondu.
Si vous avez suivi les étapes de dépannage de ce guide et déterminé qu'un délai avant expiration entraînait l'erreur de handshake TLS/SSL, accédez à la section Ré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.
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, 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, même après avoir suivi les instructions ci-dessus, veuillez rassembler les informations de diagnostic suivantes. Contactez l'assistance Apigee Edge et partagez-les avec elle:
- Si vous utilisez le cloud public, fournissez les informations suivantes :
- Nom de l'organisation
- Nom de l'environnement
- Nom du proxy d'API
- Exécutez la commande curl pour reproduire l'erreur
- Fichier de suivi affichant l'erreur
- Paquets TCP/IP capturés sur le serveur backend
- Si vous êtes un utilisateur de cloud privé, fournissez les informations suivantes :
- Message d'erreur complet observé
- Bundle de proxy d'API
- Fichier de suivi affichant l'erreur
- Journaux du processeur de messages : /opt/apigee/var/log/edge-message-processor/logs/system.log
- Paquets TCP/IP capturés sur le serveur backend ou le processeur de messages.
- 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.