502 Passerelle incorrecte inattendue EOF

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Symptôme

L'application cliente reçoit le 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 du des serveurs backend qui doivent réellement répondre à 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

Unexpected EOF est l'une des causes courantes des problèmes de 502 Bad Gateway Error qui peut être due aux raisons suivantes:

Cause	Détails	Pas effectués pour
Serveur cible mal configuré	Le serveur cible n'est pas correctement configuré pour prendre en charge les connexions TLS/SSL.	Utilisateurs Edge de cloud public et privé
Exception EOFException du serveur backend	Le serveur backend peut envoyer un EOF brusquement.	Utilisateurs de cloud privé Edge uniquement
Délai avant expiration du message keep-alive mal configuré	Les délais avant expiration de Keep Alive sont mal configurés sur Apigee et le serveur backend.	Utilisateurs Edge de cloud public et privé

É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 prendre en charge les connexions TLS/SSL.

Diagnostic

1. utiliser la surveillance des API, l'outil de traçage ou 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 la trace dans l'interface utilisateur pour l'API concernée.
3. Si la trace de la requête API qui a échoué affiche les éléments suivants: <ph type="x-smartling-placeholder">
   </ph>
   1. L'erreur 502 Bad Gateway s'affiche dès que la requête de flux cible démarre.
   2. Le error.class affiche messaging.adaptors.http.UnexpectedEOF..

      Ce problème est très probablement dû à un serveur cible incorrect. configuration.

4. Obtenez la définition du serveur cible à l'aide de l'appel d'API de gestion Edge: <ph type="x-smartling-placeholder">
   </ph>
   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 du 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 d'une TargetServer défectueuse:

      <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 d'erreurs de configuration expliquées comme suit:

   Supposons que le serveur cible mocktarget.apigee.net est configuré pour accepter les connexions sécurisées (HTTPS) sur le port 443. Cependant, si vous regardez la définition du serveur cible, aucun autre attribut/indicateur n'indique qu'il s'agit conçue pour des connexions sécurisées. Cela oblige Edge à traiter les requêtes API dirigées vers le un serveur cible spécifique en tant que requêtes HTTP (non sécurisées). Ainsi, Edge ne lancer 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 rejeter la demande d'Edge ou fermer la connexion. Vous obtenez ainsi 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 configuré correctement selon vos besoins.

Dans l'exemple illustré ci-dessus, si vous souhaitez envoyer des requêtes à une cible sécurisée (HTTPS/SSL) vous devez inclure les attributs SSLInfo avec l'option enabled définie. à true. Bien qu'il soit autorisé à ajouter les attributs SSLInfo pour un serveur cible dans la définition du point de terminaison proprement dite, nous vous recommandons d'ajouter les attributs SSLInfo dans le la définition du serveur pour éviter toute confusion.

1. Si le service de backend nécessite une communication SSL unidirectionnelle: <ph type="x-smartling-placeholder">
   </ph>
   1. Vous devez activer TLS/SSL dans la définition de TargetServer en incluant 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 incluez 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: <ph type="x-smartling-placeholder">
   </ph>
   1. Vous devez disposer d'attributs SSLInfo avec ClientAuthEnabled, Keystore, KeyAlias et Les options Truststore sont correctement définies, 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 entre les serveurs backend

Cause: EOFException au niveau du serveur backend

Le serveur backend peut envoyer une instruction EOF (Fin de fichier) brusquement.

Diagnostic

1. utiliser la surveillance des API, l'outil de traçage ou Journaux d'accès NGINX pour déterminer l'ID du message le code d'erreur et la source de l'erreur 502.
2. Vérifier les journaux du processeur de messages (/opt/apigee/var/log/edge-message-processor/logs/system.log), puis effectuez une recherche avoir eof unexpected pour l'API spécifique ou si vous disposez du messageid unique pour l'API ; requête, vous pouvez alors la rechercher.

   Exemple de trace de la pile d'exceptions dans le 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 alors que le processeur de messages tente de lire une réponse à partir de le serveur backend. Cette exception indique la fin du fichier (EOF) ou la fin du flux a été atteint de manière inattendue.

   Autrement dit, le processeur de messages a envoyé la requête API au serveur backend et attendait ou en lisant la réponse. Cependant, le serveur backend a interrompu brusquement la connexion avant que le processeur de messages obtienne la réponse ou puisse lire la réponse complète.

3. Vérifiez dans les journaux de votre serveur backend si des erreurs ou des informations ont conduit le serveur backend à interrompre brusquement la connexion. Si vous en trouvez erreurs ou informations, puis accédez à la section Résolution. et résolvez le problème de manière appropriée sur votre serveur backend.
4. Si vous ne trouvez aucune erreur ni information sur votre serveur backend, collectez le résultat tcpdump sur les processeurs de messages: <ph type="x-smartling-placeholder">
   </ph>
   1. Si l'hôte de votre 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
      

      Généralement, 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.

5. Prenons l'exemple tcpdump suivant.

   Échantillon tcpdump pris lorsque 502 Bad Gateway Error (UnexpectedEOFAtTarget) s'est produit

   

6. La sortie TCPDump indique la séquence d'événements suivante: <ph type="x-smartling-placeholder">
   </ph>
   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 par [FIN,ACK].
   3. Dans le paquet 987, le processeur de messages répond avec [FIN,ACK] au backend. Google Cloud.
   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 exception sur le message Processeur.
7. Cela peut se produire en cas de problème réseau au niveau du serveur backend. Suscitez l'intérêt de votre réseau l'équipe des opérations pour examiner ce problème plus en détail.

Solution

Corrigez le problème sur le serveur backend en conséquence.

Si le problème persiste et que vous avez besoin d'aide pour résoudre le problème 502 Bad Gateway Error ou vous pensez qu'il s'agit d'un problème dans Edge, contactez l'assistance Apigee Edge.

Cause: Délai avant expiration du message keep-alive mal configuré

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

Connexions persistantes dans Apigee

Apigee utilise par défaut des connexions persistantes (et comme suit la norme HTTP/1.1) lors de la communication avec le serveur backend cible. Les connexions persistantes peuvent améliorer les performances en permettant la réutilisation d’une connexion TCP déjà établie et (le cas échéant) TLS/SSL, ce qui et réduit les coûts de latence. La durée pendant laquelle une connexion doit être conservée est contrôlée via un délai d'inactivité de propriété (keepalive.timeout.millis).

Le serveur backend et le processeur de messages Apigee utilisent tous deux des délais avant expiration de conservation des connexions s'ouvrent les unes avec les autres. Une fois qu'aucune donnée n'est reçue pendant le délai d'expiration du message keep-alive le serveur backend ou le processeur de messages peut 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é de conservation défini sur 60s, sauf s'il a été remplacé. Une fois qu'aucune donnée n'est reçue pour 60s, Apigee fermer la connexion avec le serveur backend. Le serveur backend maintient également un délai d'expiration de message keep-alive, et une fois que cela expire, le serveur backend fermera 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 keep-alive incorrects, il entraîne une condition de concurrence entraînant l'envoi par le serveur backend d'un End Of File (FIN) inattendu 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 dans le Processeur dont la valeur est supérieure ou égale au délai avant expiration du serveur backend en amont, puis la condition de concurrence suivante peut se produire. En d'autres termes, si le processeur de messages ne reçoit aucune jusqu'à ce qu'il soit très proche du seuil du délai avant expiration de conservation du serveur backend, une requête arrive et est envoyée au serveur backend à l'aide de la connexion existante. Cela peut entraîner 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 soit défini sur le processeur de messages et sur le serveur backend est de 60 secondes, a eu lieu jusqu'à 59 secondes après la diffusion de la requête précédente par Processeur de messages.
2. Le processeur de messages traite la requête qui est arrivée à la 59e seconde. à l'aide de la connexion existante (puisque le délai avant expiration du message keep-alive n'est pas encore écoulé) et envoie le au serveur backend.
3. Toutefois, avant que la requête n'arrive au serveur backend, le délai avant expiration du message keep-alive a depuis été dépassé sur le serveur backend.
4. La demande de ressource du processeur de messages est en cours de transfert, mais le serveur backend tente de fermer la connexion en envoyant un paquet FIN au message Processeur.
5. Pendant que le processeur de messages attend que les données soient reçues, il reçoit à la place le FIN inattendu, et la connexion est interrompue.
6. Il en résulte une Unexpected EOF, puis une 502 est renvoyés au client par le processeur de messages.

Dans ce cas, nous avons observé l'erreur 502, car le même délai avant expiration du message keep-alive s'est produit. 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 survenir si une valeur plus élevée est configurée pour le délai avant expiration de la conservation que sur le serveur backend.

Diagnostic

1. Si vous êtes un utilisateur de cloud public: <ph type="x-smartling-placeholder">
   </ph>
   1. Utilisez l'outil de surveillance ou de traçage des API (comme expliqué dans Étapes de diagnostic courantes) et vérifiez que vous : paramètres: <ph type="x-smartling-placeholder">
      </ph>
      • Code d'erreur: messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Source de l'erreur:target
   2. Pour en savoir plus, consultez la page Utiliser tcpdump.
2. Si vous êtes un utilisateur Private Cloud: <ph type="x-smartling-placeholder">
   </ph>
   1. à l'aide de l'outil Trace ; 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 Le processeur de messages a reçu un EOF alors qu'il attendait encore de lire un 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 a envoyé la requête de 159 octets au serveur backend. Cependant, il n'a reçu aucun octet 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 à cette occasion, il a envoyé des données, mais peu de temps après, il a reçu une EOF avant de recevoir des données. Cela signifie qu'il est très probable que le backend le délai d'expiration du message keep-alive du serveur est plus court ou égal à celui défini dans le proxy API.

      Vous pouvez approfondir la question avec 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 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 backend a reçu une requête GET.
   2. Dans le paquet 6064, la réponse est 200 OK..
   3. Dans le paquet 6084, le serveur backend a reçu une autre requête GET.
   4. Dans le paquet 6154, il renvoie 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 fois avec succès dans cet exemple, mais lors de la troisième requête, le serveur backend initie une fermeture de la connexion, tandis que le processeur de messages est qui attend les données du serveur backend. Cela suggère que l'état de conservation du serveur délai avant expiration est très probablement plus court ou égal à la valeur définie dans le proxy d'API. Pour valider consultez la section Comparer le délai avant expiration du message keep-alive 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é du délai avant expiration du message keep alive.

2. Cependant, il est possible que vous ayez remplacé la valeur par défaut dans le proxy d'API. Pour le vérifier, vérifiez 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é du délai avant expiration de la conservation est remplacée par une valeur de 30 secondes (30000 millisecondes).

3. Vérifiez ensuite la propriété du délai avant expiration du message keep-alive configurée sur votre serveur backend. Disons que votre serveur backend est configuré avec la valeur 25 seconds.
4. Si vous déterminez que la valeur de la propriété du délai avant expiration du message keep-alive sur Apigee est supérieure que la valeur de la propriété du délai avant expiration du message keep-alive sur le serveur backend, comme dans l'exemple ci-dessus dans cet exemple, c'est la cause des erreurs 502.

Solution

Assurez-vous que la propriété du délai avant expiration du message keep-alive est toujours inférieure sur Apigee (dans les API Proxy et du processeur de messages) par rapport à celui du serveur backend.

1. Déterminez la valeur définie pour le délai avant expiration du message keep-alive sur le serveur backend.
2. Configurez une valeur appropriée pour la propriété du délai avant expiration du message keep-alive dans le proxy d'API ou Processeur de messages, de sorte que la propriété du délai d'expiration du message keep-alive soit inférieure à la valeur définie sur le en suivant la procédure décrite dans la section <ph type="x-smartling-placeholder"></ph> 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.

Bonne pratique

Il est vivement conseillé de toujours définir un délai avant expiration de conservation des composants en aval inférieur. que celui configuré sur les serveurs en amont pour éviter ces types de conditions de concurrence 502 erreur. Chaque saut en aval doit être inférieur à chaque saut en amont. Dans Apigee Edge, il est recommandé de suivre les directives suivantes:

1. Le délai avant expiration du maintien actif du client doit être inférieur au délai avant expiration du message de messages de message de message de message de message de message de routeur Edge.
2. Le délai d'inactivité du routeur Edge Router doit être inférieur au délai d'inactivité du processeur de messages.
3. Le délai avant expiration du message keepalive 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 la responsabilité du client en aval de boucler la avec la connexion en amont.

Vous devez collecter des informations de diagnostic

Si le problème persiste alors que vous avez suivi les instructions ci-dessus, rassemblez les informations suivantes : de diagnostic, puis contactez l'assistance Apigee Edge.

Si vous êtes un utilisateur de cloud public, fournissez les informations suivantes:

• Nom de l'organisation
• Nom de l'environnement
• Nom du proxy d'API
• Exécutez la commande curl pour reproduire l'erreur 502.
• 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 erreurs 502 se sont produites dans le passé.

Si vous êtes un utilisateur du Private Cloud, fournissez les informations suivantes:

• Message d'erreur complet observé pour les requêtes en échec
• Nom de l'organisation, de l'environnement et du proxy d'API que vous observez 502 erreur
• 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 avec les informations de fuseau horaire au cours de laquelle les erreurs 502 se sont produites
• Tcpdumps recueillies sur les processeurs de messages ou sur le serveur backend, ou les deux lorsque l'erreur eu lieu