502 Bad Gateway – Socket hang up

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

<ph type="x-smartling-placeholder">

Symptôme

L'application cliente reçoit un code d'état HTTP 502 Bad Gateway avec le paramètre coder ECONNRESET en 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 mal configuré Les délais avant expiration du message keep-alive ne sont pas correctement configurés entre Edge Microgateway et le serveur cible. Utilisateurs Edge de cloud public et privé
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 de cloud public et privé

Étapes de diagnostic courantes

  1. Consultez les journaux Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Effectuez une recherche pour voir s'il existe des erreurs 502 avec le code ECONNRESET. pendant une certaine période (si le problème est survenu dans le passé) ou si des demandes é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, être un message [warn] incluant le nom d'hôte et le port du serveur cible dans la deuxième . Dans cet exemple, il s'agit de X.X.X.X:8080, ce qui peut être utilisé 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 mis fin à la connexion avec Edge Microgateway. Vous pouvez effectuer une recherche dans les journaux pour déterminer la fréquence à laquelle cela se produit.

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

<ph type="x-smartling-placeholder">

Diagnostic

  1. Suivez les étapes de la section Étapes de diagnostic courantes pour vérifier si vous avez bien reçu le Erreur [socket hang up][ECONNRESET].

  2. Si c'est le cas, étudiez la situation plus en détail avec l'aide de tcpdump, comme expliqué ci-dessous:

Utiliser tcpdump

  1. Capturez une tcpdump entre Edge Microgateway et le serveur backend sur le système d'exploitation hôte Edge Microgateway en exécutant la commande suivante: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. Analysez les tcpdump capturées:

    Exemple de résultat de tcpdump: ( agrandir l'image)

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

    1. Dans le paquet 250288, le client envoie une requête POST.
    2. Dans le paquet 250371, le serveur renvoie la réponse 200 OK.
    3. Dans le paquet 250559, le client envoie une réponse ACK.
    4. Dans le paquet 250560, le serveur envoie le code Continuation .
    5. Dans le paquet 250561, le client envoie une réponse ACK.
    6. Dans le paquet 262436, le serveur envoie une réponse FIN, ACK au le client à l’origine de la fermeture de la connexion. Notez qu'il s'agit d'environ cinq secondes après le paquet précédent (250561).
    7. Dans le paquet 262441, le client envoie un autre POST requête. Toutefois, cette opération échoue, car le serveur a déjà initié la fermeture du . Il répond avec un RST dans le paquet 262441

    La même connexion a été réutilisée au moins une fois avec succès dans cet exemple, mais sur la demande finale, le serveur ferme la connexion après cinq secondes de temps d'inactivité, qui se produit en même temps que le client a envoyé une nouvelle requête. Ce suggère que le délai avant expiration du message keep-alive du serveur backend est très probablement plus court ou égal à la valeur définie dans le client. Pour le vérifier, consultez Comparez 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é spécifique pour le délai avant expiration du message keep-alive. Il est déterminé par le système d’exploitation sur lequel il s’exécute. Les exemples courants sont Windows, Linux et Docker.
  2. Il est possible que cela soit personnalisé dans le système d'exploitation. Consultez votre administrateur système. Par défaut, les systèmes d'exploitation Linux disposent d'un message keep-alive et un délai avant expiration de deux heures.
  3. Vérifiez ensuite la propriété du 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é du délai avant expiration du message keep-alive sur le serveur backend, comme dans dans l'exemple ci-dessus, cela est à l'origine des erreurs 502.

Solution

Assurez-vous que la propriété du délai avant expiration du message keep-alive est toujours inférieure sur le système d'exploitation où Edge Microgateway est en cours d'exécution par rapport à celle sur le 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 système d'exploitation système, de sorte que la propriété du délai avant expiration du message keep-alive soit inférieure à la valeur définie sur le backend en suivant la procédure applicable à votre système d'exploitation.

Bonne pratique

Il est fortement recommandé que les composants en aval présentent toujours un délai avant expiration de message keep-alive 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. En périphérie Microgateway, il est recommandé d'utiliser les directives suivantes:

  1. Le délai avant expiration du message keep-alive sur l'application cliente ou l'équilibreur de charge doit être inférieur à 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 le Valeur de keep_alive_timeout à votre ~/.edgemicro/org-env-config.yaml.

    edgemicro:
  keep_alive_timeout: 65000
    <ph type="x-smartling-placeholder">
  2. Le délai avant expiration du message keep-alive du système d'exploitation Edge Microgateway doit être inférieur à la cible le délai avant expiration du message keep-alive sur le serveur.
  3. Si d'autres sauts se trouvent devant ou derrière Edge Microgateway, la même règle doit être appliqué. Vous devez toujours laisser la responsabilité du client en aval de conclure la connexion avec le flux en amont.
<ph type="x-smartling-placeholder">

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

<ph type="x-smartling-placeholder">

Diagnostic

  1. Suivez la procédure décrite dans la section Étapes de diagnostic courantes, et vérifiez que : a obtenu l'erreur [socket hang up][ECONNRESET].
  2. Si c'est le cas, étudiez la situation plus en détail avec 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 alors que Edge Microgateway envoyait la requête au serveur backend (cible). Autrement dit, Edge Microgateway a envoyé requête API au serveur backend et attendait la réponse. Toutefois, le backend serveur a interrompu brusquement la connexion avant qu'Edge Microgateway ne reçoive une réponse.

  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 trouvez des erreurs ou informations, puis accédez à la section Résolution et corrigez le problème en conséquence. sur votre serveur backend.
  4. Si vous ne trouvez aucune erreur ni information sur votre serveur backend, collectez les Sortie tcpdump sur le serveur Edge Microgateway: 
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Analysez les tcpdump capturées:

    Exemple de résultat de tcpdump: ( agrandir l'image)

    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 à la cible Google Cloud.
    2. Dans le paquet 5, le serveur cible a répondu 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, la cible envoie un FIN, ACK qui lance la fermeture de la connexion.
    4. Dans les paquets 7 et ultérieurs, la connexion est fermée mutuellement. Puisque la connexion a été fermé avant l'envoi de la réponse, Edge Microgateway renvoie le code HTTP 502 l'erreur au client.
    5. Notez que le code temporel du paquet 8, 2021-06-23T03:52:24.110Z correspond à l'horodatage où l'erreur a été consignée dans Edge Microgateway. journaux. Les horodatages dans les fichiers journaux et dans tcpdump peuvent souvent être utilisée pour corréler les erreurs avec les paquets réels.

    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 le résoudre, 502 Bad Gateway Error ou si vous pensez qu'il s'agit d'un problème lié à Edge Microgateway, accédez à Obligation de recueillir des informations de diagnostic.

    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:

    • 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 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 la YAML dans le dossier Edge Microgateway par défaut, $HOME/.edgemicro. Il y a un fichier de configuration par défaut appelé default.yaml, puis un pour chaque environnement ORG-ENV-config.yaml Veuillez importer ce fichier pour l'organisation et l'environnement concernés.