502 Bad Gateway – Socket hang up

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 Bad Gateway avec le code ECONNRESET en tant que réponse aux appels d'API dans Edge Microgateway.

Message d'erreur

Le client verra le code de réponse suivant: 

HTTP/1.1 502 Bad Gateway

La réponse inclut le message d'erreur suivant: 

{"message":"socket hang up","code":"ECONNRESET"}

Causes possibles

Cause Description Instructions de dépannage applicables
Délai avant expiration du message keep-alive configuré de manière incorrecte Délais d'expiration du message keep-alive configurés de manière incorrecte entre Edge Microgateway et le serveur cible. Utilisateurs Edge Public and Private Cloud
Le serveur cible ferme prématurément la connexion Le serveur cible ferme prématurément la connexion pendant que Edge Microgateway envoie la charge utile de la requête. Utilisateurs Edge Public and Private Cloud

Étapes de diagnostic courantes

  1. Vérifiez les journaux Edge Microgateway : 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Recherchez s'il existe des erreurs 502 avec le code ECONNRESET pendant une durée spécifique (si le problème s'est produit par le passé) ou si des requêtes échouent toujours avec 502. 
    2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
[emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
[microgateway-core][][GET][502][socket hang up][ECONNRESET][]
  3. Si le niveau de journalisation est défini sur warn ou info, un message [warn] s'affiche également, incluant le nom d'hôte et le port du serveur cible dans le deuxième élément. Dans cet exemple, il s'agit de X.X.X.X:8080, que vous pourrez utiliser ultérieurement pour capturer un tcpdump. 
    2021-06-23T03:52:24.109Z
[warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
[][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
[targetRequest error][GET][][socket hang up][ECONNRESET][395]
  4. Le code d'erreur [socket hang up][ECONNRESET] indique que le serveur cible a fermé la connexion avec Edge Microgateway. Vous pouvez la rechercher dans les journaux pour déterminer la fréquence à laquelle cela se produit.

Cause: délai avant expiration du message keep-alive configuré de manière incorrecte

Diagnostic

  1. Suivez la procédure décrite dans la section Étapes de diagnostic courantes et vérifiez si vous avez obtenu l'erreur [socket hang up][ECONNRESET].

  2. Si c'est le cas, approfondissez le sujet à l'aide de tcpdump, comme expliqué ci-dessous:

Utiliser tcpdump

  1. Capturez un tcpdump entre Edge Microgateway et le serveur backend sur le système d'exploitation hôte Edge Microgateway à l'aide de la commande suivante : 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. Analysez la tcpdump capturée:

    Exemple de résultat tcpdump : ( afficher une image plus grande)

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

    1. Dans le paquet 250288, le client envoie une requête POST.
    2. Dans le paquet 250371, le serveur répond avec 200 OK.
    3. Dans le paquet 250559, le client envoie un ACK.
    4. Dans le paquet 250560, le serveur envoie le message Continuation.
    5. Dans le paquet 250561, le client envoie un ACK.
    6. Dans le paquet 262436, le serveur envoie un message FIN, ACK au client, lançant la fermeture de la connexion. Notez que cela se produit environ cinq secondes après le paquet précédent (250561).
    7. Dans le paquet 262441, le client envoie une autre requête POST. Cependant, cette opération échoue, car le serveur a déjà initié la fermeture de la connexion. Il répond par un RST dans le paquet 262441.

    Dans cet exemple, la même connexion a bien été réutilisée au moins une fois. Toutefois, lors de la requête finale, le serveur lance la fermeture de la connexion après cinq secondes d'inactivité, c'est-à-dire au moment où le client a envoyé une nouvelle requête. Cela suggère que le délai avant expiration du message keep-alive du serveur backend est probablement plus court ou égal à la valeur définie dans le client. Pour vérifier cela, consultez la section Comparer le délai avant expiration du message keep-alive sur Edge Microgateway et le serveur backend.

Comparer les délais avant expiration du message keep-alive

  1. Edge Microgateway ne possède pas de propriété de délai avant expiration spécifique du message keep-alive. Elle est déterminée par le système d'exploitation sur lequel elle s'exécute. Windows, Linux et les conteneurs Docker sont des exemples courants.
  2. Il est possible que cela soit personnalisé dans le système d'exploitation. Contactez votre administrateur système. Par défaut, les systèmes d'exploitation Linux ont un délai avant expiration par défaut de deux heures pour les messages keep-alive.
  3. Vérifiez ensuite la propriété du délai avant expiration du message keep-alive configurée sur votre serveur backend. Imaginons que votre serveur backend soit configuré avec une valeur de 10 secondes.
  4. Si vous déterminez que la valeur du délai avant expiration du message keep-alive sur le système d'exploitation est supérieure à la valeur de la propriété de ce délai sur le serveur backend, comme dans l'exemple ci-dessus, alors 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 le système d'exploitation sur lequel Edge Microgateway est en cours d'exécution 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 keep-alive dans le système d'exploitation, de sorte que la propriété du message keep-alive soit inférieure à la valeur définie sur le serveur backend, en suivant la procédure applicable à votre système d'exploitation.

Bonnes pratiques

Il est vivement conseillé de définir un seuil d'expiration du délai d'expiration des messages keep-alive moins élevé pour les composants en aval 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 Edge Microgateway, il est recommandé de respecter les consignes suivantes:

  1. Le délai avant expiration du message keep-alive sur l'application cliente ou l'équilibreur de charge doit être inférieur au délai avant expiration du message keep-alive Edge Microgateway.

    Pour configurer le délai avant expiration du message keep-alive sur Edge Microgateway, ajoutez la valeur keep_alive_timeout à votre fichier ~/.edgemicro/org-env-config.yaml.

    edgemicro:
  keep_alive_timeout: 65000
  2. Le délai avant expiration du message keep-alive du système d'exploitation Edge Microgateway doit être inférieur au délai avant expiration du message keep-alive du serveur cible.
  3. Si vous avez d'autres sauts devant ou derrière Edge Microgateway, 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.

Cause: le serveur cible ferme prématurément la connexion

Diagnostic

  1. Suivez la procédure décrite dans la section Étapes de diagnostic courantes et vérifiez si vous avez obtenu l'erreur [socket hang up][ECONNRESET].
  2. Si c'est le cas, approfondissez le sujet à l'aide de tcpdump, comme expliqué ci-dessous.

    Le message d'erreur [targetRequest error][GET][][socket hang up][ECONNRESET] dans l'exemple ci-dessus indique que cette erreur s'est produite pendant que Edge Microgateway envoyait la requête au serveur backend (cible). Autrement dit, Edge Microgateway a envoyé la requête API au serveur backend et attendait la réponse. Cependant, le serveur backend a mis fin brusquement à la connexion avant qu'Edge Microgateway ne reçoive une réponse.

  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 le serveur Edge Microgateway : 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Analysez la tcpdump capturée:

    Exemple de résultat tcpdump : ( afficher une image plus grande)

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

    1. Dans le paquet 4, Edge Microgateway a envoyé une requête GET au serveur cible.
    2. Dans le paquet 5, le serveur cible a répondu avec ACK pour accuser réception de la requête.
    3. Cependant, dans le paquet 6, au lieu de répondre avec une charge utile de réponse, le serveur cible envoie un FIN, ACK lançant la fermeture de la connexion.
    4. À partir des paquets 7, la connexion est fermée mutuellement. Comme la connexion a été fermée avant l'envoi de la réponse, Edge Microgateway renvoie l'erreur HTTP 502 au client.
    5. Notez que l'horodatage du paquet 8, 2021-06-23T03:52:24.110Z , correspond à l'horodatage auquel l'erreur a été consignée dans les journaux Edge Microgateway. Les horodatages figurant dans les fichiers journaux et dans le fichier tcpdump permettent souvent de corréler les erreurs avec les paquets réels.

    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 lié à Edge Microgateway, consultez la section Recueil d'informations de diagnostic.

    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:

    • Fichiers journaux: le dossier par défaut est /var/tmp, mais il peut être ignoré dans le fichier config.yaml principal (logging > dir parameter). Il est recommandé de remplacer log > level par info avant de fournir les fichiers journaux à l'assistance Apigee.
    • Fichier de configuration: la configuration principale d'Edge Microgateway se trouve dans le fichier YAML du dossier Edge Microgateway par défaut, $HOME/.edgemicro. Il existe un fichier de configuration par défaut appelé default.yaml, puis un fichier pour chaque environnement ORG-ENV-config.yaml. Veuillez importer ce fichier dans son intégralité pour l'organisation et l'environnement concernés.