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 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
De plus, le message d'erreur suivant peut 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 les plus courantes de 502 Bad Gateway Error
. Les raisons suivantes peuvent expliquer ce problème:
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 and Private Cloud |
Exception EOFException du serveur backend | Le serveur backend est susceptible d'envoyer EOF brusquement. | Utilisateurs de cloud privé Edge uniquement |
Délai avant expiration du message keepalive configuré de manière incorrecte | Expirations de délai de conservation actives configurées de manière incorrecte sur Apigee et le serveur backend. | Utilisateurs Edge Public and 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 la surveillance des API:
À l'aide de la surveillance de l'API, vous pouvez examiner les erreurs 502
en suivant la procédure expliquée dans la section Examiner les problèmes. Par exemple :
- Accédez au tableau de bord Enquêter.
- 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 le côté droit, cliquez sur View Logs (Afficher les journaux) pour les erreurs
502
. Celles-ci se présentent comme suit: - La source d'erreurs est
target
- Le code d'erreur est
messaging.adaptors.http.UnexpectedEOFAtTarget
.
Ici, nous pouvons voir 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 de traçage
Pour diagnostiquer l'erreur à l'aide de l'outil Trace:
- Activez la
session de trace, 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.
-
L'échec devrait s'afficher 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 affichées dans le tableau suivant, vous pouvez confirmer que l'erreur
502
provient du serveur cible:En-têtes de réponse Valeur X-Apigee.fault-source 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, procédez comme suit:
Vous pouvez également vous reporter aux journaux d'accès NGINX pour déterminer la cause du code d'état 502
. Cela est particulièrement utile si le problème s'est déjà produit 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 dans le passé) ou toute requête ayant échoué avec502
. - En cas d'erreurs
502
, vérifiez si elles sont causées par la cible qui envoie une erreurUnexpected EOF
. Si les valeurs de X-Apigee.fault-source et X- Apigee.fault-code correspondent aux valeurs indiquées dans le tableau ci-dessous, l'erreur502
est provoquée par la fermeture inattendue de la connexion par la cible:En-têtes de réponse Valeur X-Apigee.fault-source 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
afin d'approfondir la question.
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 du message, le code d'erreur et la source de l'erreur pour l'erreur
502
. - Activez la trace dans l'interface utilisateur pour 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 que la requête de flux cible a démarré. 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
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
TargetServer
illustrée 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). Edge ne lance donc 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 d'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é selon 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 :
- Vous devez disposer d'attributs
SSLInfo
avec les optionsClientAuthEnabled
,Keystore
,KeyAlias
etTruststore
définis correctement, 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 >
- Vous devez disposer d'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 du message, le code d'erreur et la source de l'erreur pour 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, vous pouvez alors la rechercher.Exemple de trace de la 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 voir que l'erreur
java.io.EOFException: eof unexpected
s'est produite lorsque le processeur de messages tente de lire une réponse du serveur backend. Cette exception indique que la fin du fichier (EOF) 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. Toutefois, le serveur backend a mis fin brusquement à la connexion avant que le processeur de messages n'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 constatez des erreurs ou des informations, accédez à Résolution et corrigez le problème de manière appropriée sur 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 l'hôte du 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, exécutez la commande suivante :
tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME
En général, cette erreur est due au fait que le serveur backend répond avec
[FIN,ACK]
dès que le processeur de messages envoie la requête au serveur backend.
- Si l'hôte du serveur backend possède une seule adresse IP, utilisez la commande suivante :
-
Prenons l'exemple
tcpdump
suivant.Exemple d'
tcpdump
utilisé lorsque502 Bad Gateway Error
(UnexpectedEOFAtTarget
) a eu lieu - 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 répond avec[FIN,ACK]
au serveur backend. - Au final, les connexions sont 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. Contactez votre équipe chargée des opérations réseau pour qu'elle examine ce problème plus en détail.
Résolution
Corrigez le problème sur le serveur backend de manière appropriée.
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 avant expiration du message keepalive mal configuré
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 selon 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 du maintien de la disponibilité (keepalive.timeout.millis
) de la propriété.
Le serveur backend et le processeur de messages Apigee utilisent tous deux des délais d'inactivité pour garder les connexions ouvertes les unes avec les autres. Une fois qu'aucune donnée n'est reçue pendant le délai avant expiration du message keepalive, le serveur backend ou le processeur de messages peut fermer la connexion à l'autre.
Les proxys d'API déployés sur un processeur de messages dans Apigee ont, par défaut, un délai d'expiration du message keep-alive défini sur 60s
, sauf s'ils sont remplacés. Si aucune donnée n'est reçue pour 60s
, Apigee ferme la connexion avec le serveur backend. Le serveur backend maintient également un délai avant expiration du message 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 avant expiration de type "keep alive" 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 keepalive est configuré dans le proxy d'API ou le processeur de messages avec une valeur supérieure ou égale au délai d'inactivité 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 avant un délai très proche du seuil de délai 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 n'arrive avant 59 secondes après la diffusion de la requête précédente par le processeur de messages spécifique.
- 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 keep-alive n'est pas encore écoulé), puis envoie la requête au serveur backend.
- Toutefois, avant que la requête n'arrive au serveur backend, le seuil de délai avant expiration du message keep-alive est depuis dépassé sur le serveur backend.
- La requête d'une ressource du processeur de messages est en cours, mais le serveur backend tente de fermer la connexion en envoyant un paquet
FIN
au processeur de messages. - Pendant que le processeur de messages attend la réception des données, il reçoit la réponse
FIN
inattendue et la connexion est interrompue. - Cela se traduit par une exception
Unexpected EOF
, et un502
est ensuite renvoyé 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 sur le processeur de messages et 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 des messages 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 de l'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 traçage ou les journaux d'accès NGINX pour déterminer l'ID des messages, le code d'erreur et la source des erreurs pour 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 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 unEOF
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 ensuite 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 traçage ou les journaux d'accès NGINX pour déterminer l'ID des messages, le code d'erreur et la source des erreurs pour 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 de 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 répond par200 OK.
. - Dans le paquet
6084
, le serveur backend a reçu une autre requêteGET
. - Dans le paquet
6154
, il répond par200 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
) lançant la fermeture de la connexion.
La même connexion a été réutilisée deux fois avec succès dans cet exemple, mais lors de la troisième requête, le serveur backend met fin à la connexion, tandis que le processeur de messages attend les données du serveur backend. Cela suggère que le délai d'inactivité 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 keepalive 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 keep-alive.
-
Toutefois, il est possible que vous ayez ignoré la valeur par défaut dans le proxy d'API. Vous pouvez vérifier cela 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 du point de terminaison cible:
<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 une valeur de 30 secondes (
30000
millisecondes). - Vérifiez ensuite la propriété de délai avant expiration du message keepalive configurée sur votre serveur backend. Supposons que votre serveur backend est 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'expiration du message keepalive 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é du délai avant expiration du message keepalive 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 keep-alive 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 la page Vous devez collecter des informations de diagnostic.
Bonnes pratiques
Il est vivement conseillé de définir, pour les composants en aval, un seuil d'expiration du délai d'expiration des messages keepalive moins élevé que celui configuré sur les serveurs en amont afin d'éviter ce type de conditions de concurrence et les erreurs 502
. Chaque saut en aval doit être inférieur à chaque saut en amont. Dans Apigee Edge, il est recommandé de suivre les consignes suivantes:
- Le délai avant expiration du message keepalive du client doit être inférieur au délai avant expiration du message keep-alive du routeur Edge.
- Le délai avant expiration du message keepalive du routeur Edge doit être inférieur à celui du délai de conservation des messages du processeur de messages.
- Le délai avant expiration du message keepalive du processeur de messages doit être inférieur au délai d'inactivité 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 le client en aval être responsable de fermer la connexion avec l'élément en 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 avec l'erreur
502 Bad Gateway - Unexpected EOF
- Si les erreurs
502
ne se produisent pas actuellement, indiquez la période avec les informations de fuseau horaire lorsque des erreurs502
se sont produites.
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 avec 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 le fuseau horaire au cours de 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