502 Passerelle incorrecte inattendue EOF

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

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 de backend qui devraient normalement 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'une des causes typiques de l'erreur 502 Bad Gateway Error est l'erreur Unexpected EOF, qui peut être due aux raisons suivantes :

Étapes de diagnostic courantes

Pour diagnostiquer l'erreur, vous pouvez utiliser l'une des méthodes suivantes :

• Surveillance des API
• Outil Trace
• 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 API Monitoring, l'outil Trace ou les journaux d'accès NGINX pour déterminer l'ID du message, le code d'erreur et la source de l'erreur 502.
2. Activez le traçage dans l'interface utilisateur pour l'API concernée.
3. Si la trace de la requête API défaillante affiche les éléments suivants :
   1. L'erreur 502 Bad Gateway s'affiche dès que le flux de requête cible a démarré.
   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 du 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 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 incorrecte :

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. La définition TargetServer illustrée est un exemple de l'une des erreurs de configuration typiques, qui est expliquée comme suit :

   Supposons que le serveur cible mocktarget.apigee.net soit configuré pour accepter les connexions sécurisées (HTTPS) sur le port 443. Toutefois, si vous examinez la définition du serveur cible, vous ne trouverez aucun autre attribut ni indicateur indiquant qu'il est destiné aux connexions sécurisées. Edge traite alors les requêtes d'API envoyées au serveur cible spécifique comme des requêtes HTTP (non sécurisées). Edge n'initiera donc pas le processus de handshake SSL avec ce serveur cible.

   Étant donné que le serveur cible est configuré pour n'accepter que les requêtes HTTPS (SSL) sur 443, il rejettera la requête d'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 réponse au client.

Solution

Assurez-vous toujours que le serveur cible est correctement configuré selon vos besoins.

Dans 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'indicateur enabled défini 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 lui-même, il est recommandé d'ajouter les attributs SSLInfo dans la définition du serveur cible pour éviter toute confusion.

1. Si le service de backend requiert 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 requiert une communication SSL bidirectionnelle, procédez comme suit :
   1. Vous devez définir correctement les attributs SSLInfo avec les indicateurs 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 de backend

Cause : EOFException du serveur backend

Le serveur de backend peut envoyer EOF (End of File) de manière abrupte.

Diagnostic

1. Utilisez API Monitoring, l'outil Trace ou les journaux d'accès NGINX pour déterminer l'ID du message, 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 avez eof unexpected pour l'API spécifique ou si vous avez le messageid unique pour la requête d'API.

   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 a tenté 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 de backend et attendait ou lisait la réponse. Toutefois, le serveur backend a mis fin à la connexion de manière abrupte avant que le processeur de messages n'obtienne la réponse ou ne puisse lire la réponse complète.

3. Consultez les journaux de votre serveur backend pour voir si des erreurs ou des informations ont pu entraîner l'arrêt brutal de la connexion par le serveur backend. Si vous trouvez des erreurs ou des informations, accédez à Résolution et corrigez le problème de manière appropriée sur votre serveur backend.
4. Si vous ne trouvez aucune erreur ni information dans votre serveur backend, collectez la sortie tcpdump sur les processeurs de messages :
   1. Si l'hôte de votre serveur backend ne possède qu'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 de backend possède plusieurs adresses IP, utilisez la commande suivante :

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      En règle générale, cette erreur se produit parce que 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 tcpdump prélevé lorsque 502 Bad Gateway Error (UnexpectedEOFAtTarget) s'est produit

   

6. Dans le résultat TCPDump, vous remarquez 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 de backend répond immédiatement avec [FIN,ACK].
   3. Dans le paquet 987, le processeur de messages répond avec [FIN,ACK] au serveur backend.
   4. Les connexions sont finalement fermées avec [ACK] et [RST] des deux côtés.
   5. Étant donné que 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. Contactez votre équipe chargée des opérations réseau pour qu'elle examine ce problème plus en détail.

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 les problèmes liés à 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 actif mal configuré

Avant de déterminer si c'est la cause des erreurs 502, veuillez lire les concepts suivants.

Connexions persistantes dans Apigee

Par défaut, Apigee utilise des connexions persistantes (conformément à la norme HTTP/1.1) pour communiquer avec le serveur de 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 la latence. La durée pendant laquelle une connexion doit être conservée est contrôlée par une propriété keep-alive timeout (keepalive.timeout.millis).

Le serveur de backend et le processeur de messages Apigee utilisent tous deux des délais d'inactivité pour maintenir les connexions ouvertes entre eux. Une fois qu'aucune donnée n'est reçue pendant la durée du délai d'inactivité, le serveur backend ou le processeur de messages peuvent fermer la connexion avec l'autre.

Par défaut, les proxys d'API déployés sur un processeur de messages dans Apigee ont un délai d'inactivité défini sur 60s, sauf si cette valeur est remplacée. Si aucune donnée n'est reçue pendant 60s, Apigee ferme la connexion avec le serveur backend. Le serveur backend maintient également un délai avant expiration de keep-alive. Une fois ce délai expiré, le serveur backend ferme la connexion avec le processeur de messages.

Implication d'une configuration incorrecte du délai avant expiration actif

Si Apigee ou le serveur de backend sont configurés avec des délais avant expiration actifs incorrects, cela entraîne une condition de concurrence qui amène le serveur de backend à envoyer un code d'état End Of File (FIN) inattendu en réponse à une requête de ressource.

Par exemple, si le délai d'inactivité 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 d'inactivité du serveur de backend en amont, la condition de concurrence suivante peut se produire. En d'autres termes, si le processeur de messages ne reçoit aucune donnée jusqu'à ce que le délai d'inactivité du serveur backend soit presque atteint, une requête est reçue et envoyée au serveur backend à l'aide de la connexion existante. Cela peut entraîner un 502 Bad Gateway en raison d'une erreur EOF inattendue, comme expliqué ci-dessous :

1. Supposons que le délai d'inactivité keep-alive défini à la fois sur le processeur de messages et sur le serveur backend soit de 60 secondes, et qu'aucune nouvelle requête n'ait été envoyée jusqu'à 59 secondes après que la requête précédente a été traitée par le processeur de messages spécifique.
2. Le processeur de messages traite la requête reçue à la 59e seconde à l'aide de la connexion existante (car le délai avant expiration de la connexion persistante n'est pas encore écoulé) et envoie la requête au serveur backend.
3. Toutefois, avant que la requête n'arrive sur le serveur de backend, le seuil de délai d'inactivité a été dépassé sur le serveur de backend.
4. La requête du processeur de messages pour une ressource est en cours, mais le serveur backend tente de fermer la connexion en envoyant un paquet FIN au processeur de messages.
5. Alors que le processeur de messages attend la réception des données, il reçoit à la place le FIN inattendu et la connexion est interrompue.
6. Cela entraîne un Unexpected EOF, puis un 502 qui est renvoyé au client par le processeur de messages.

Dans ce cas, nous avons observé que l'erreur 502 s'est produite, car la même valeur de délai avant expiration actif de 60 secondes a été configurée à la fois sur le processeur de messages et sur le serveur de backend. De même, ce problème peut également se produire si une valeur plus élevée est configurée pour le délai avant expiration de Keep-Alive sur le processeur de messages que sur le serveur backend.

Diagnostic

1. Si vous êtes un utilisateur du cloud public :
   1. Utilisez l'outil de surveillance des API ou Trace (comme expliqué dans Étapes de diagnostic courantes) et vérifiez que vous disposez des deux paramètres suivants :
      • Code de défaillance : messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Source de la défaillance : target
   2. Pour en savoir plus, consultez Utiliser tcpdump.
2. Si vous êtes un utilisateur de Private Cloud :
   1. Utilisez l'outil Trace ou les journaux d'accès NGINX pour déterminer l'ID du message, 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 suit :

      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 un EOF alors qu'il attendait toujours 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 avait réutilisé cette connexion environ sept fois, et l'attribut bytesWritten=159 indique que le processeur de messages avait envoyé la charge utile de la requête de 159 octets au serveur backend. Cependant, il n'a reçu aucun octet en retour lorsque l'erreur EOF inattendue s'est produite.

   6. Cela montre que le processeur de messages avait réutilisé la même connexion plusieurs fois et qu'à cette occasion, il avait envoyé des données, mais avait reçu peu de temps après un EOF avant d'avoir reçu des données. Cela signifie qu'il y a une forte probabilité que le délai avant expiration du message keep-alive du serveur de backend soit inférieur ou égal à celui défini dans le proxy d'API.

      Vous pouvez approfondir votre enquête à l'aide de tcpdump, comme expliqué ci-dessous.

Utiliser tcpdump

1. Capturez un tcpdump sur le serveur de backend à l'aide de la commande suivante :

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. Analysez les tcpdump capturées :

   Voici un exemple de résultat tcpdump :

   

   Dans l'exemple tcpdump ci-dessus, vous pouvez voir les éléments suivants :

   1. Dans le paquet 5992,, le serveur de backend a reçu une requête GET.
   2. Dans le paquet 6064, il répond avec 200 OK.
   3. Dans le paquet 6084, le serveur de backend a reçu une autre requête GET.
   4. Dans le paquet 6154, il répond par 200 OK.
   5. Dans le paquet 6228, le serveur de 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), ce qui déclenche la fermeture de la connexion.

   Dans cet exemple, la même connexion a été réutilisée deux fois avec succès, mais lors de la troisième requête, le serveur backend lance la fermeture de la connexion, tandis que le processeur de messages attend les données du serveur backend. Cela suggère que le délai avant expiration du message keep-alive du serveur de backend est probablement inférieur ou égal à la valeur définie dans le proxy d'API. Pour valider cela, consultez Comparer le délai avant expiration actif sur Apigee et le serveur backend.

Comparer le délai avant expiration actif sur Apigee et sur le serveur de 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. Pour le vérifier, consultez la définition TargetEndpoint spécifique dans le proxy d'API défaillant qui génère des erreurs 502.

   Exemple de configuration 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é de délai avant expiration de la connexion est remplacée par une valeur de 30 secondes (30000 millisecondes).

3. Vérifiez ensuite la propriété de délai avant expiration actif configurée sur votre serveur de backend. Supposons que votre serveur de backend soit configuré avec une valeur de 25 seconds.
4. Si vous constatez que la valeur de la propriété de délai avant expiration actif sur Apigee est supérieure à celle de la propriété de délai avant expiration actif sur le serveur de backend, comme dans l'exemple ci-dessus, cela explique les erreurs 502.

Solution

Assurez-vous que la propriété de délai avant expiration du message keep-alive est toujours inférieure sur Apigee (dans le proxy d'API et le composant Processeur de messages) par rapport à celle du serveur de backend.

1. Déterminez la valeur définie pour le délai avant expiration actif sur le serveur backend.
2. Configurez une valeur appropriée pour la propriété de délai avant expiration du message keep-alive dans le proxy d'API ou le processeur de messages, de sorte que cette propriété soit inférieure à la valeur définie sur le serveur backend, en suivant les étapes décrites dans Configuration du délai avant expiration du message keep-alive sur les processeurs de messages.

Si le problème persiste, consultez la page Vous devez collecter des informations de diagnostic.

Bonnes pratiques

Il est fortement conseillé que les composants en aval aient toujours un seuil de délai avant expiration actif inférieur à celui configuré sur les serveurs en amont pour éviter ce type 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é de suivre les consignes suivantes :

1. Le délai d'inactivité du client doit être inférieur à celui du routeur Edge.
2. Le délai d'inactivité du routeur Edge doit être inférieur à celui du processeur de messages.
3. Le délai d'inactivité du processeur de messages doit être inférieur à celui 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 le client 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 du cloud public, fournissez les informations suivantes :

• Nom de l'organisation
• Nom de l'environnement
• Nom du proxy d'API
• Commande curl complète pour reproduire l'erreur 502
• Fichier de trace 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 sur le fuseau horaire où les erreurs 502 se sont produites dans le passé.

Si vous êtes un utilisateur du cloud privé, fournissez les informations suivantes :

• Message d'erreur complet observé pour les requêtes ayant échoué
• Nom de l'organisation, de l'environnement et du proxy d'API pour lesquels vous observez des erreurs 502
• Bundle de proxy d'API
• Fichier de trace 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 avec les informations de fuseau horaire au cours de laquelle les erreurs 502 se sont produites
• Tcpdumps collectées sur les processeurs de messages ou sur le serveur backend, ou les deux, lorsque l'erreur s'est produite