502 Passerelle incorrecte inattendue EOF

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 :

  1. Accédez au tableau de bord Enquêter.
  2. 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.
  3. Cochez la case de la matrice lorsque vous constatez un nombre élevé d'erreurs 502.
  4. Sur le côté droit, cliquez sur View Logs (Afficher les journaux) pour les erreurs 502. Celles-ci se présentent comme suit:
  5. Ici, nous pouvons voir les informations suivantes:

    • La source d'erreurs est target
    • Le code d'erreur est messaging.adaptors.http.UnexpectedEOFAtTarget.

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:

  1. Activez la session de trace, puis effectuez l'appel d'API pour reproduire le problème 502 Bad Gateway.
  2. Sélectionnez l'une des requêtes ayant échoué et examinez la trace.
  3. Parcourez les différentes phases de la trace et localisez l'origine de l'échec.
  4. L'échec devrait s'afficher une fois la requête envoyée au serveur cible, comme indiqué ci-dessous:

    alt_text

    alt_text

  5. 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'erreur 502 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:

  1. Vérifiez les journaux d'accès NGINX.
    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
  2. 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é avec 502.
  3. En cas d'erreurs 502, vérifiez si elles sont causées par la cible qui envoie une erreur Unexpected 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'erreur 502 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

  1. 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.
  2. Activez la trace dans l'interface utilisateur pour 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 que la requête de flux 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 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 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 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). 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 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é 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.

  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. Vous devez disposer d'attributs SSLInfo avec les options ClientAuthEnabled, Keystore, KeyAlias et Truststore 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 >
      

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 du message, le code d'erreur et la source de l'erreur pour 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, 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.

  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 constatez 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 aucune information sur votre serveur backend, collectez la sortie tcpdump sur les processeurs de messages :
    1. 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
      
    2. 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.

  5. Prenons l'exemple tcpdump suivant.

    Exemple d'tcpdump utilisé lorsque 502 Bad Gateway Error (UnexpectedEOFAtTarget) a eu lieu

  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 répond avec [FIN,ACK] au serveur backend.
    4. Au final, les connexions sont 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. 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:

  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 n'arrive avant 59 secondes après la diffusion de la requête précédente par le processeur de messages spécifique.
  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 keep-alive n'est pas encore écoulé), puis envoie la requête au serveur backend.
  3. 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.
  4. 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.
  5. 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.
  6. Cela se traduit par une exception Unexpected EOF, et un 502 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

  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 de l'erreur:target
    2. Pour en savoir plus, consultez Utiliser tcpdump.
  2. Si vous êtes un utilisateur de Private Cloud :
    1. 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.
    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 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 un 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 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.

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 de 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 répond par 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 par 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) 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.

Comparer le délai avant expiration du message keepalive 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 keep-alive.
  2. 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 erreurs 502.

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

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

  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é 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:

  1. 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.
  2. 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.
  3. Le délai avant expiration du message keepalive du processeur de messages doit être inférieur au délai d'inactivité 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 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'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.

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