502 Passerelle incorrecte inattendue EOF

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
• Outil de traçage
• Journaux d'accès NGINX

Cause: serveur cible mal configuré

Le serveur cible n'est pas correctement configuré pour accepter les connexions TLS/SSL.

Diagnostic

1. 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.
2. Activez la trace dans l'interface utilisateur de l'API concernée.
3. Si la trace de la requête API ayant échoué indique les éléments suivants :
   1. L'erreur 502 Bad Gateway s'affiche dès le début de la requête de flux cible.
   2. error.class affiche messaging.adaptors.http.UnexpectedEOF.

      Dans ce cas, il est très probable que ce problème soit dû à une configuration incorrecte du serveur cible.

4. Obtenez la définition du serveur cible à l'aide de l'appel d'API de gestion Edge :
   1. 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>
      

   2. 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 >
      

5. 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 port 443. 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 erreur UnexpectedEOFAtTarget sur le processeur de messages. Le processeur de messages enverra 502 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.

1. Si le service de backend nécessite une communication SSL unidirectionnelle, procédez comme suit :
   1. Vous devez activer TLS/SSL dans la définition TargetServer en incluant les attributs SSLInfo où l'indicateur enabled 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>
      

   2. 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>
      

2. Si le service de backend nécessite une communication SSL bidirectionnelle, procédez comme suit :
   1. Les attributs SSLInfo doivent être définis correctement avec les options ClientAuthEnabled, Keystore, KeyAlias et Truststore, 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 >
      

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

1. 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.
2. Consultez les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log) et recherchez si vous disposez de eof unexpected pour l'API spécifique ou si vous disposez du messageid 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.

3. 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.
4. Si vous ne trouvez aucune erreur ni aucune information sur votre serveur backend, collectez la sortie tcpdump sur les processeurs de messages :
   1. 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
      

   2. 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.

5. Prenons l'exemple tcpdump suivant.

   Exemple d'tcpdump pris lorsque 502 Bad Gateway Error (UnexpectedEOFAtTarget) s'est produit

   

6. Dans la sortie TCPDump, vous remarquerez la séquence d'événements suivante :
   1. Dans le paquet 985, le processeur de messages envoie la requête API au serveur backend.
   2. Dans le paquet 986, le serveur backend répond immédiatement avec [FIN,ACK].
   3. Dans le paquet 987, le processeur de messages renvoie [FIN,ACK] au serveur backend.
   4. Les connexions sont alors fermées avec [ACK] et [RST] des deux côtés.
   5. Comme le serveur backend envoie [FIN,ACK], vous obtenez l'exception java.io.EOFException: eof unexpected sur le processeur de messages.
7. 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:

1. 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é.
2. 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.
3. 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.
4. 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.
5. 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.
6. Cela se traduit par une erreur Unexpected EOF, et une 502 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

1. Si vous êtes un utilisateur de cloud public :
   1. 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
   2. Pour en savoir plus, consultez Utiliser tcpdump.
2. Si vous êtes un utilisateur de Private Cloud :
   1. 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.
   2. Recherchez l'ID du message dans le journal du processeur de messages
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. 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)
      

   4. L'erreur java.io.EOFException: eof unexpected indique que le processeur de messages a reçu une réponse EOF alors qu'il attendait encore de lire une réponse du serveur backend.
   5. 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'attribut bytesWritten=159 indique qu'il a envoyé la charge utile de requête de 159 octets au serveur backend. Cependant, elle a reçu zéro octet lorsque l'erreur EOF inattendue s'est produite.

   6. 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.

Utiliser tcpdump

1. 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
   

2. Analysez la tcpdump capturée:

   Voici un exemple de résultat tcpdump:

   

   Dans l'exemple tcpdump ci-dessus, vous pouvez voir ce qui suit:

   1. Dans le paquet 5992,, le serveur backend a reçu une requête GET.
   2. Dans le paquet 6064, il renvoie 200 OK..
   3. Dans le paquet 6084, le serveur backend a reçu une autre requête GET.
   4. Dans le paquet 6154, il répond avec 200 OK.
   5. Dans le paquet 6228, le serveur backend a reçu une troisième requête GET.
   6. Cette fois, le serveur backend renvoie un FIN, ACK au processeur de messages (paquet 6285) 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.

Comparer le délai avant expiration du message keep-alive sur Apigee et le serveur backend

1. Par défaut, Apigee utilise une valeur de 60 secondes pour la propriété de délai avant expiration du message keepalive.

2. 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 erreurs 502.

   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).

3. 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.
4. 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.

1. Déterminez la valeur définie pour le délai avant expiration du message keepalive sur le serveur backend.
2. 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:

1. 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.
2. 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.
3. 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.
4. 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'erreur 502.
• 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 erreurs 502 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