Vous consultez la documentation Apigee Edge.
Consulter la documentation d'Apigee X en savoir plus
Problème technique
L'application cliente obtient un code d'état HTTP 502
avec le message Bad Gateway
en réponse aux appels d'API.
Le code d'état HTTP 502
signifie que le client ne reçoit pas de réponse valide des serveurs backend devant traiter la requête.
Messages 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": "Unexpected EOF at target", "detail": { "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget" } } }
Causes possibles
L'erreur Unexpected EOF
est l'une des causes typiques de 502 Bad Gateway Error
:
Cause | Détails | Pas donnés pour |
---|---|---|
Serveur cible mal configuré | Le serveur cible n'est pas correctement configuré pour accepter les connexions TLS/SSL. | Utilisateurs Edge Public et Private Cloud |
Exception EOFException du serveur backend | Le serveur backend peut envoyer brusquement un EOF. | Utilisateurs de Cloud privé Edge uniquement |
Délai avant expiration du message keep-alive configuré de manière incorrecte | Expirations de délai keep-alive configurés de manière incorrecte sur Apigee et le serveur backend. | Utilisateurs Edge Public et Private Cloud |
Étapes de diagnostic courantes
Pour diagnostiquer l'erreur, vous pouvez utiliser l'une des méthodes suivantes:
Surveillance des API
Pour diagnostiquer l'erreur à l'aide de l'API Monitoring:
À l'aide de la surveillance des API, vous pouvez examiner les erreurs 502
en suivant la procédure expliquée dans Examiner les problèmes. Par exemple :
- Accédez au tableau de bord Investigate.
- Sélectionnez le code d'état dans le menu déroulant et assurez-vous que la bonne période est sélectionnée lorsque les erreurs
502
se sont produites. - Cochez la case de la matrice lorsque vous constatez un nombre élevé d'erreurs
502
. - Sur la droite, cliquez sur View Logs (Afficher les journaux) pour les erreurs
502
. Celles-ci se présentent comme suit: - Source d'erreur :
target
- Le code d'erreur est
messaging.adaptors.http.UnexpectedEOFAtTarget
.
Nous pouvons voir ici les informations suivantes:
Cela indique que l'erreur 502
est causée par la cible en raison d'un EOF inattendu.
En outre, notez le Request Message ID
pour l'erreur 502
pour un examen plus approfondi.
Outil Trace
Pour diagnostiquer l'erreur à l'aide de l'outil Trace:
- Activez la
session de traçage, puis effectuez l'appel d'API pour reproduire le problème
502 Bad Gateway
. - Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
- Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
-
Vous devriez constater un échec une fois la requête envoyée au serveur cible, comme indiqué ci-dessous:
-
Déterminez la valeur de X-Apigee.fault-source et de X-Apigee.fault-code dans la phase AX (données analytiques enregistrées) de la trace.
Si les valeurs de X-Apigee.fault-source et X-Apigee.fault-code correspondent aux valeurs présentées dans le tableau suivant, vous pouvez confirmer que l'erreur
502
provient du serveur cible:En-têtes de réponse Valeur Source X-Apigee.fault target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
En outre, notez le
X-Apigee.Message-ID
pour l'erreur502
pour un examen plus approfondi.
Journaux d'accès NGINX
Pour diagnostiquer l'erreur à l'aide de NGINX:
Vous pouvez également consulter les journaux d'accès NGINX pour déterminer la cause du code d'état 502
. Cela est particulièrement utile si le problème est survenu par le passé ou s'il est intermittent et que vous ne parvenez pas à capturer la trace dans l'interface utilisateur. Procédez comme suit pour déterminer ces informations à partir des journaux d'accès NGINX:
- Vérifiez les journaux d'accès NGINX.
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
- Recherchez toutes les erreurs
502
pour le proxy d'API spécifique pendant une durée spécifique (si le problème s'est produit auparavant) ou toutes les requêtes qui échouent encore avec502
. - En cas d'erreurs
502
, vérifiez si l'erreur est due au fait que la cible envoie une erreurUnexpected EOF
. Si les valeurs de X-Apigee.fault-source et X- Apigee.fault-code correspondent aux valeurs présentées dans le tableau ci-dessous, l'erreur502
est causée par la cible qui ferme la connexion de manière inattendue:En-têtes de réponse Valeur Source X-Apigee.fault target
X-Apigee.fault-code messaging.adaptors.http.flow.UnexpectedEOFAtTarget
Voici un exemple d'entrée affichant l'erreur
502
causée par le serveur cible:
Notez également les ID de message pour les erreurs 502
pour un examen plus approfondi.
Cause: serveur cible mal configuré
Le serveur cible n'est pas correctement configuré pour accepter les connexions TLS/SSL.
Diagnostic
- Utilisez la surveillance des API, l'outil de traçage ou les journaux d'accès NGINX pour déterminer l'ID des messages, le code d'erreur et la source de l'erreur
502
. - Activez la trace dans l'interface utilisateur de l'API concernée.
- Si la trace de la requête API ayant échoué indique les éléments suivants :
- L'erreur
502 Bad Gateway
s'affiche dès le début de la requête de flux cible. error.class
affichemessaging.adaptors.http.UnexpectedEOF.
Dans ce cas, il est très probable que ce problème soit dû à une configuration incorrecte du serveur cible.
- L'erreur
- Obtenez la définition du serveur cible à l'aide de l'appel d'API de gestion Edge :
- Si vous êtes un utilisateur de cloud public, utilisez cette API :
curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
- Si vous êtes un utilisateur de Private Cloud, utilisez cette API :
curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>
Exemple de définition de
TargetServer
défectueuse:<TargetServer name="target1"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> </TargetServer >
- Si vous êtes un utilisateur de cloud public, utilisez cette API :
-
La définition illustrée de
TargetServer
est un exemple de l'une des erreurs de configuration typiques, expliquée comme suit:Supposons que le serveur cible
mocktarget.apigee.net
est configuré pour accepter les connexions sécurisées (HTTPS) sur le port443
. Toutefois, si vous examinez la définition du serveur cible, aucun autre attribut ou indicateur n'indique qu'il est destiné à des connexions sécurisées. De cette façon, Edge traite les requêtes API envoyées au serveur cible spécifique comme des requêtes HTTP (non sécurisées). Ainsi, Edge ne lancera pas le processus de handshake SSL avec ce serveur cible.Le serveur cible étant configuré pour accepter uniquement les requêtes HTTPS (SSL) sur
443
, il refusera la demande de Edge ou fermera la connexion. Par conséquent, vous obtenez une erreurUnexpectedEOFAtTarget
sur le processeur de messages. Le processeur de messages enverra502 Bad Gateway
en tant que réponse au client.
Résolution
Assurez-vous toujours que le serveur cible est correctement configuré, conformément à vos besoins.
Pour l'exemple illustré ci-dessus, si vous souhaitez envoyer des requêtes à un serveur cible sécurisé (HTTPS/SSL), vous devez inclure les attributs SSLInfo
avec l'option enabled
définie sur true
. Bien qu'il soit autorisé d'ajouter les attributs SSLInfo
pour un serveur cible dans la définition du point de terminaison cible elle-même, nous vous recommandons d'ajouter les attributs SSLInfo
dans la définition du serveur cible pour éviter toute confusion.
- Si le service de backend nécessite une communication SSL unidirectionnelle, procédez comme suit :
- Vous devez activer TLS/SSL dans la définition
TargetServer
en incluant les attributsSSLInfo
où l'indicateurenabled
est défini sur "true", comme indiqué ci-dessous :<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Enabled>true</Enabled> </SSLInfo> </TargetServer>
- Si vous souhaitez valider le certificat du serveur cible dans Edge, nous devons également inclure le Truststore (contenant le certificat du serveur cible) comme indiqué ci-dessous :
<TargetServer name="mocktarget"> <Host>mocktarget.apigee.net</Host> <Port>443</Port> <IsEnabled>true</IsEnabled> <SSLInfo> <Ciphers/> <ClientAuthEnabled>false</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <Protocols/> <TrustStore>mocktarget-truststore</TrustStore> </SSLInfo> </TargetServer>
- Vous devez activer TLS/SSL dans la définition
- Si le service de backend nécessite une communication SSL bidirectionnelle, procédez comme suit :
- Les attributs
SSLInfo
doivent être définis correctement avec les optionsClientAuthEnabled
,Keystore
,KeyAlias
etTruststore
, comme indiqué ci-dessous :<TargetServer name="mocktarget"> <IsEnabled>true</IsEnabled> <Host>www.example.com</Host> <Port>443</Port> <SSLInfo> <Ciphers/> <ClientAuthEnabled>true</ClientAuthEnabled> <Enabled>true</Enabled> <IgnoreValidationErrors>false</IgnoreValidationErrors> <KeyAlias>keystore-alias</KeyAlias> <KeyStore>keystore-name</KeyStore> <Protocols/> <TrustStore>truststore-name</TrustStore> </SSLInfo> </TargetServer >
- Les attributs
Références
Équilibrage de charge sur les serveurs backend
Cause: exception EOFException sur le serveur backend
Le serveur backend est susceptible d'envoyer brusquement une fin de fichier.
Diagnostic
- Utilisez la surveillance des API, l'outil de traçage ou les journaux d'accès NGINX pour déterminer l'ID des messages, le code d'erreur et la source de l'erreur
502
. - Consultez les journaux du processeur de messages (
/opt/apigee/var/log/edge-message-processor/logs/system.log
) et recherchez si vous disposez deeof unexpected
pour l'API spécifique ou si vous disposez dumessageid
unique pour la requête API, puis recherchez-le.Exemple de trace de pile d'exception à partir du journal du processeur de messages
"message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na] at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na] at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na] at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
Dans l'exemple ci-dessus, vous pouvez constater que l'erreur
java.io.EOFException: eof unexpected
s'est produite pendant que le processeur de messages tente de lire une réponse du serveur backend. Cette exception indique que la fin du fichier ou la fin du flux a été atteinte de manière inattendue.Autrement dit, le processeur de messages a envoyé la requête API au serveur backend et a attendu ou lu la réponse. Cependant, le serveur backend a brusquement mis fin à la connexion avant que le processeur de messages obtienne la réponse ou puisse lire la réponse complète.
- Vérifiez les journaux de votre serveur backend et vérifiez si des erreurs ou des informations auraient pu amener le serveur backend à interrompre brusquement la connexion. Si vous trouvez des erreurs ou des informations, accédez à Résolution et corrigez le problème de manière appropriée dans votre serveur backend.
- Si vous ne trouvez aucune erreur ni aucune information sur votre serveur backend, collectez la sortie
tcpdump
sur les processeurs de messages :- Si votre hôte de serveur backend possède une seule adresse IP, utilisez la commande suivante :
tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME
- Si l'hôte de votre serveur backend possède plusieurs adresses IP, utilisez la commande suivante :
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
En général, cette erreur se produit lorsque le serveur backend répond avec
[FIN,ACK]
dès que le processeur de messages envoie la requête au serveur backend.
- Si votre hôte de serveur backend possède une seule adresse IP, utilisez la commande suivante :
-
Prenons l'exemple
tcpdump
suivant.Exemple d'
tcpdump
pris lorsque502 Bad Gateway Error
(UnexpectedEOFAtTarget
) s'est produit - Dans la sortie TCPDump, vous remarquerez la séquence d'événements suivante :
- Dans le paquet
985
, le processeur de messages envoie la requête API au serveur backend. - Dans le paquet
986
, le serveur backend répond immédiatement avec[FIN,ACK]
. - Dans le paquet
987
, le processeur de messages renvoie[FIN,ACK]
au serveur backend. - Les connexions sont alors fermées avec
[ACK]
et[RST]
des deux côtés. - Comme le serveur backend envoie
[FIN,ACK]
, vous obtenez l'exceptionjava.io.EOFException: eof unexpected
sur le processeur de messages.
- Dans le paquet
- Cela peut se produire en cas de problème réseau au niveau du serveur backend. Faites appel à l'équipe chargée des opérations réseau pour qu'elle examine le problème plus en détail.
Résolution
Corrigez correctement le problème sur le serveur backend.
Si le problème persiste et que vous avez besoin d'aide pour résoudre 502 Bad Gateway Error
ou si vous pensez qu'il s'agit d'un problème dans Edge, contactez l'assistance Apigee Edge.
Cause: délai d'inactivité du message keep-alive configuré de manière incorrecte
Avant de déterminer si cela est à l'origine des erreurs 502
, veuillez prendre connaissance des concepts suivants.
Connexions persistantes dans Apigee
Apigee par défaut (et ultérieurement avec la norme HTTP/1.1) utilise des connexions persistantes pour communiquer avec le serveur backend cible. Les connexions persistantes peuvent améliorer les performances en permettant de réutiliser une connexion TCP et (le cas échéant) TLS/SSL déjà établie, ce qui réduit les coûts de latence. La durée de persistance d'une connexion est contrôlée via un délai avant expiration de la conservation des messages actifs (keepalive.timeout.millis
).
Le serveur backend et le processeur de messages Apigee utilisent tous deux des délais d'inactivité pour maintenir les connexions ouvertes les unes avec les autres. Une fois qu'aucune donnée n'est reçue avant l'expiration du délai de conservation des messages, le serveur backend ou le processeur de messages peut fermer la connexion avec l'autre serveur.
Le délai avant expiration des proxys d'API déployés sur un processeur de messages dans Apigee est défini par défaut sur 60s
, sauf s'il est remplacé. Une fois qu'aucune donnée n'est reçue pour 60s
, Apigee ferme la connexion avec le serveur backend. Le serveur backend conserve également un délai avant expiration de type keepalive. Une fois celui-ci expiré, le serveur backend ferme la connexion avec le processeur de messages.
Implication d'une configuration incorrecte du délai avant expiration du message keep-alive
Si Apigee ou le serveur backend est configuré avec des délais d'expiration de message keepalive incorrects, cela entraîne une condition de concurrence qui oblige le serveur backend à envoyer une réponse End Of File
(FIN)
inattendue en réponse à une requête de ressource.
Par exemple, si le délai avant expiration du message keep-alive est configuré dans le proxy d'API ou le processeur de messages avec une valeur supérieure ou égale au délai avant expiration du serveur backend en amont, la condition de concurrence suivante peut se produire. Autrement dit, si le processeur de messages ne reçoit aucune donnée jusqu'à une date très proche du seuil d'expiration du message keepalive du serveur backend, une requête aboutit et est envoyée au serveur backend à l'aide de la connexion existante. Cela peut entraîner une erreur 502 Bad Gateway
en raison d'une erreur EOF inattendue, comme expliqué ci-dessous:
- Supposons que le délai avant expiration du message keep-alive défini sur le processeur de messages et le serveur backend soit de 60 secondes, et qu'aucune nouvelle requête ne soit effectuée avant 59 secondes après le traitement de la requête précédente par le processeur de messages concerné.
- Le processeur de messages traite la requête arrivée à la 59e seconde à l'aide de la connexion existante (car le délai avant expiration du message keepalive n'est pas encore écoulé) et envoie la requête au serveur backend.
- Toutefois, avant que la requête n'arrive au serveur backend, le délai avant expiration du message keepalive est depuis dépassé sur le serveur backend.
- La demande d'une ressource du processeur de messages est en cours, mais le serveur backend tente de fermer la connexion en lui envoyant un paquet
FIN
. - Pendant que le processeur de messages attend que les données soient reçues, il reçoit à la place le message
FIN
inattendu et la connexion est interrompue. - Cela se traduit par une erreur
Unexpected EOF
, et une502
est ensuite renvoyée au client par le processeur de messages.
Dans ce cas, nous avons constaté que l'erreur 502
s'est produite, car la même valeur de délai d'inactivité de 60 secondes a été configurée à la fois sur le processeur de messages et sur le serveur backend. De même, ce problème peut également se produire si une valeur plus élevée est configurée pour le délai d'expiration du message keep-alive sur le processeur de messages par rapport au serveur backend.
Diagnostic
- Si vous êtes un utilisateur de cloud public :
- Utilisez l'outil de surveillance ou de traçage des API (comme expliqué dans la section Étapes de diagnostic courantes) et vérifiez que vous disposez des deux paramètres suivants :
- Code d'erreur:
messaging.adaptors.http.flow.UnexpectedEOFAtTarget
- Source d'erreur:
target
- Code d'erreur:
- Pour en savoir plus, consultez Utiliser tcpdump.
- Utilisez l'outil de surveillance ou de traçage des API (comme expliqué dans la section Étapes de diagnostic courantes) et vérifiez que vous disposez des deux paramètres suivants :
- Si vous êtes un utilisateur de Private Cloud :
- Utilisez l'outil de trace ou les journaux d'accès NGINX pour déterminer l'ID des messages, le code d'erreur et la source de l'erreur
502
. - Recherchez l'ID du message dans le journal du processeur de messages
(/opt/apigee/var/log/edge-message-processor/logs/system.log
). - Le
java.io.EOFEXception: eof unexpected
s'affiche comme indiqué ci-dessous :2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1 NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms lastIO=479ms isOpen=true.onExceptionRead exception: {} java.io.EOFException: eof unexpected at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80) at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)
- L'erreur
java.io.EOFException: eof unexpected
indique que le processeur de messages a reçu une réponseEOF
alors qu'il attendait encore de lire une réponse du serveur backend. - L'attribut
useCount=7
dans le message d'erreur ci-dessus indique que le processeur de messages a réutilisé cette connexion environ sept fois, et l'attributbytesWritten=159
indique qu'il a envoyé la charge utile de requête de159
octets au serveur backend. Cependant, elle a reçu zéro octet lorsque l'erreurEOF
inattendue s'est produite. -
Cela montre que le processeur de messages a réutilisé la même connexion plusieurs fois. À cette occasion, il a envoyé des données, mais a reçu peu de temps après avoir reçu un
EOF
avant que des données ne soient reçues. Cela signifie qu'il est fort probable que le délai avant expiration du message keepalive du serveur backend soit inférieur ou égal à celui défini dans le proxy d'API.Vous pouvez approfondir vos recherches à l'aide de
tcpdump
, comme expliqué ci-dessous.
- Utilisez l'outil de trace ou les journaux d'accès NGINX pour déterminer l'ID des messages, le code d'erreur et la source de l'erreur
Utiliser tcpdump
- Capturez un
tcpdump
sur le serveur backend à l'aide de la commande suivante :tcpdump -i any -s 0 host MP_IP_Address -w File_Name
- Analysez la
tcpdump
capturée:Voici un exemple de résultat tcpdump:
Dans l'exemple
tcpdump
ci-dessus, vous pouvez voir ce qui suit:- Dans le paquet
5992,
, le serveur backend a reçu une requêteGET
. - Dans le paquet
6064
, il renvoie200 OK.
. - Dans le paquet
6084
, le serveur backend a reçu une autre requêteGET
. - Dans le paquet
6154
, il répond avec200 OK
. - Dans le paquet
6228
, le serveur backend a reçu une troisième requêteGET
. - Cette fois, le serveur backend renvoie un
FIN, ACK
au processeur de messages (paquet6285
) qui lance la fermeture de la connexion.
La même connexion a été réutilisée à deux reprises dans cet exemple, mais lors de la troisième requête, le serveur backend met fin à la connexion pendant que le processeur de messages attend les données du serveur backend. Cela suggère que le délai avant expiration du message keepalive du serveur backend est probablement plus court ou égal à la valeur définie dans le proxy d'API. Pour le vérifier, consultez la section Comparer le délai avant expiration du message keepalive sur Apigee et le serveur backend.
- Dans le paquet
Comparer le délai avant expiration du message keep-alive sur Apigee et le serveur backend
- Par défaut, Apigee utilise une valeur de 60 secondes pour la propriété de délai avant expiration du message keepalive.
-
Toutefois, il est possible que vous ayez remplacé la valeur par défaut dans le proxy d'API. Vous pouvez le vérifier en vérifiant la définition
TargetEndpoint
spécifique dans le proxy d'API défaillant qui génère des erreurs502
.Exemple de configuration de TargetEndpoint:
<TargetEndpoint name="default"> <HTTPTargetConnection> <URL>https://mocktarget.apigee.net/json</URL> <Properties> <Property name="keepalive.timeout.millis">30000</Property> </Properties> </HTTPTargetConnection> </TargetEndpoint>
Dans l'exemple ci-dessus, la propriété du délai avant expiration du message keepalive est remplacée par la valeur de 30 secondes (
30000
millisecondes). - Ensuite, vérifiez la propriété du délai d'expiration du message keep-alive configurée sur votre serveur backend. Imaginons que votre serveur backend soit configuré avec la valeur
25 seconds
. - Si vous déterminez que la valeur de la propriété de délai avant expiration du message keepalive sur Apigee est supérieure à la valeur de la propriété de délai d'inactivité sur le serveur backend, comme dans l'exemple ci-dessus, c'est la cause des erreurs
502
.
Résolution
Assurez-vous que la propriété de délai avant expiration du message keep-alive est toujours inférieure sur Apigee (dans le composant Proxy d'API et processeur de messages) par rapport au serveur backend.
- Déterminez la valeur définie pour le délai avant expiration du message keepalive sur le serveur backend.
- Configurez une valeur appropriée pour la propriété de délai avant expiration du message keepalive dans le proxy d'API ou le processeur de messages, de sorte que la propriété de délai avant expiration du message keepalive soit inférieure à la valeur définie sur le serveur backend, en suivant les étapes décrites dans la section Configurer le délai avant expiration du message keepalive sur les processeurs de messages.
Si le problème persiste, consultez Vous devez collecter des informations de diagnostic.
Bonnes pratiques
Il est fortement recommandé que les composants en aval présentent toujours un seuil d'expiration des messages keepalive inférieur à celui configuré sur les serveurs en amont, afin d'éviter ces types de conditions de concurrence et d'erreurs 502
. Chaque saut en aval doit être inférieur à chaque saut en amont. Dans Apigee Edge, il est recommandé d'utiliser les directives suivantes:
- Le délai avant expiration des messages keep-alive du client doit être inférieur à celui du service de maintien de la disponibilité du routeur périphérique.
- Le délai avant expiration du message keepalive du routeur périphérique doit être inférieur à celui du message keepalive du processeur de messages.
- Le délai avant expiration du message keepalive du processeur de messages doit être inférieur au délai avant expiration du message keep-alive du serveur cible.
- Si vous avez d'autres sauts devant ou derrière Apigee, la même règle doit être appliquée. Vous devez toujours laisser au client en aval la responsabilité de fermer la connexion avec l'amont.
Vous devez collecter des informations de diagnostic
Si le problème persiste même après avoir suivi les instructions ci-dessus, rassemblez les informations de diagnostic suivantes, puis contactez l'assistance Apigee Edge.
Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes:
- Le nom de l'organisation.
- Nom de l'environnement
- Nom du proxy d'API
- Exécutez la commande
curl
pour reproduire l'erreur502
. - Fichier de suivi contenant les requêtes présentant l'erreur
502 Bad Gateway - Unexpected EOF
- Si les erreurs
502
ne se produisent pas actuellement, indiquez la période au cours de laquelle les erreurs502
se sont produites avec le fuseau horaire.
Si vous êtes un utilisateur du Private Cloud, fournissez les informations suivantes:
- Message d'erreur complet observé pour les requêtes ayant échoué
- Organisation, nom de l'environnement et nom du proxy d'API pour lesquels vous observez des erreurs
502
- Groupe de proxys d'API
- Fichier de suivi contenant les requêtes présentant l'erreur
502 Bad Gateway - Unexpected EOF
- 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
- Période contenant les informations de fuseau horaire pendant laquelle les erreurs
502
se sont produites Tcpdumps
collectées sur les processeurs de messages ou le serveur backend, ou les deux lorsque l'erreur s'est produite