502 Bad Gateway – Socket hang up

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

Problème constaté

L'application cliente reçoit un code d'état HTTP 502 Bad Gateway avec le code ECONNRESET en réponse aux appels d'API dans Edge Microgateway.

Message d'erreur

Le client voit 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

Étapes de diagnostic courantes

1. Vérifiez les journaux d'Edge Microgateway :

   /var/tmp/edgemicro-`hostname`-*.log

2. Recherchez les erreurs 502 avec le code ECONNRESET pendant une durée spécifique (si le problème s'est produit dans 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] incluant le nom d'hôte et le port du serveur cible s'affiche également dans le deuxième élément. Dans cet exemple, il s'agit de X.X.X.X:8080, qui peut être utilisé 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 effectuer une recherche dans les journaux pour déterminer la fréquence de ce problème.

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

Diagnostic

1. Suivez les étapes décrites dans Étapes de diagnostic courantes et vérifiez si l'erreur [socket hang up][ECONNRESET] s'est produite.

2. Si c'est le cas, examinez le problème plus en détail à l'aide de tcpdump, comme expliqué ci-dessous :

Utilisation de tcpdump

1. Capturez un tcpdump entre Edge Microgateway et le serveur backend sur the Edge Microgateway host operating system with the following command:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. Analysez le tcpdump capturé :

   Exemple de résultat tcpdump ( afficher l'image en plus grand)

   

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

   1. Dans le paquet 250288, le client envoie une POST requête.
   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 Continuation message.
   5. Dans le paquet 250561, le client envoie un ACK.
   6. Dans le paquet 262436, le serveur envoie un FIN, ACK à le client, ce qui lance 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 POST requête. Toutefois, cette requête échoue, car le serveur a déjà lancé la fermeture de la connexion. Il répond avec un RST dans le paquet 262441.

   La même connexion a été réutilisée au moins une fois dans cet exemple, mais lors de la requête finale, le serveur lance une fermeture de la connexion après cinq secondes d'inactivité, ce qui se produit en même temps que le client envoie une nouvelle requête. Cela suggère que le délai avant expiration du message keep-alive du serveur backend est probablement inférieur ou égal à la valeur définie dans le client. Pour le vérifier, consultez Comparer les délais 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 dispose pas de propriété de délai avant expiration du message keep-alive spécifique. Il est déterminé par le système d'exploitation sur lequel il s'exécute. Les exemples courants sont les conteneurs Windows, Linux et Docker.
2. Il est possible que ce paramètre 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 du message keep-alive par défaut de deux heures.
3. Ensuite, vérifiez la propriété de délai avant expiration du message keep-alive configurée sur votre serveur backend. Supposons 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 délai avant expiration du message keep-alive sur le serveur backend, comme dans l'exemple ci-dessus, c'est la cause des erreurs 502.

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 où Edge Microgateway s'exécute par rapport à celle 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é de délai avant expiration du message keep-alive dans le système d'exploitation, de sorte que la propriété de délai avant expiration du message keep-alive soit inférieure à la valeur définie sur le serveur backend, en suivant les étapes applicables à votre système d'exploitation.

Bonnes pratiques

Il est fortement conseillé que les composants en aval aient toujours un seuil de délai avant expiration du message keep-alive inférieur à celui configuré sur les serveurs en amont pour éviter ce type de conditions de concurrence et 502 erreurs. Chaque saut en aval doit être inférieur à chaque saut en amont. Dans Edge Microgateway, il est recommandé de suivre 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 d'Edge Microgateway.

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

   edgemicro:
     keep_alive_timeout: 65000

2. Le délai avant expiration du message keep-alive du système d'exploitation d'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 au client en aval la responsabilité de fermer la connexion avec l'amont.

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

Diagnostic

1. Suivez les étapes décrites dans Étapes de diagnostic courantes et vérifiez si vous avez obtenu l'erreur [socket hang up][ECONNRESET].
2. Si c'est le cas, examinez le problème plus en détail à 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 lorsqu'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. Toutefois, le serveur backend a mis fin à la connexion de manière abrupte avant qu'Edge Microgateway ne reçoive de réponse.

3. Vérifiez les journaux de votre serveur backend et voyez s'il existe des erreurs ou des informations qui auraient pu entraîner la fermeture abrupte de la connexion par le serveur backend. Si vous trouvez des erreurs ou des informations, accédez à la section 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 le tcpdump résultat sur le serveur Edge Microgateway :

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. Analysez le tcpdump capturé :

   Exemple de résultat tcpdump ( afficher l'image en plus grand)

   

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

   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. Toutefois, dans le paquet 6, au lieu de répondre avec une charge utile de réponse, le serveur cible envoie un FIN, ACK qui lance la fermeture de la connexion.
   4. Dans les paquets 7 et suivants, la connexion est fermée mutuellement. Étant donné que 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é enregistrée dans les journaux d'Edge Microgateway logs. Les horodatages des fichiers journaux et du tcpdump peuvent souvent être utilisés pour corréler les erreurs avec les paquets réels.

   Solution

   Corrigez le problème de manière appropriée sur le serveur backend.

   Si le problème persiste et que vous avez besoin d'aide pour résoudre l'erreur 502 Bad Gateway Error ou si vous pensez qu'il s'agit d'un problème dans Edge Microgateway, consultez la page Vous devez collecter des 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 remplacé 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 réside 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 pour chaque environnement ORG-ENV-config.yaml. Veuillez importer ce fichier dans son intégralité pour l'organisation et l'environnement concernés.