Comment résoudre les erreurs HTTP 502 liées à un Application Load Balancer ?

Brève description

Il existe plusieurs causes possibles pour les erreurs HTTP 502 : Bad Gateway, et la source peut provenir de votre cible ou de votre Application Load Balancer. Vous pouvez utiliser les métriques Amazon CloudWatch et les journaux d'accès pour identifier la source et la cause de l'erreur.

Avant de commencer à résoudre l'erreur de votre Application Load Balancer, veillez à activer la journalisation des accès. Pour comprendre la signification de chaque champ dans le journal d'accès, reportez-vous à Entrées du journal d'accès.

Si la cible est une fonction AWS Lambda, reportez-vous à Résoudre les erreurs HTTP 502 lorsque la cible est une fonction Lambda dans la section Solution.

Solution

Trouver la source des erreurs HTTP 502

Utilisation des métriques CloudWatch

Si des points de données apparaissent sous la métrique HTTPCode_ELB_502_Count, alors votre équilibreur de charge est la source des erreurs HTTP 502. S'ils apparaissent sous la métrique HTTPCode_Target_5XX_Count, alors votre cible est la source des erreurs.

Utilisation des journaux d'accès

Si elb_status_code est « 502 » et que target_status_code est « - », alors votre équilibreur de charge est la source des erreurs HTTP 502. Si elb_status_code est « 502 » et que target_status_code est « 502 », alors votre cible est la source des erreurs.

Résolution des erreurs HTTP 502

Remarque : Filtrez les journaux d'accès par elb_status_code = « 502 » et target_status_code pour vous aider à déterminer la cause. Suivez ensuite les étapes spécifiques à votre cas d'utilisation.

L'équilibreur de charge a reçu un TCP RST de la cible lorsqu'il tentait d'établir une connexion

La réception d'un TCP RST de la cible lors de l'établissement d'une connexion signifie que l'équilibreur de charge ne peut pas établir une liaison TCP à trois voies avec la cible. Par conséquent, l'équilibreur de charge ne peut pas transférer la demande de l'utilisateur à la cible.

• Vérifiez s'il existe des points de données pour la métrique TargetConnectionErrorCount. Cette métrique représente le nombre de connexions qui n'ont pas été établies correctement entre l'équilibreur de charge et la cible.
• Vérifiez si les champs request_processing_time, target_processing_time et response_processing_time des journaux d'accès ont chacun la valeur -1. Cette valeur signifie que l'équilibreur de charge ne peut pas envoyer la demande à la cible car elle a besoin d'une connexion réussie.

Voici un exemple d'entrée de journal d'accès :

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 -1 -1 -1 502 - 86 155 "GET http://example.com:80/ HTTP/1.1" 
"curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" Root=1-58337262-36d228ad5d99923122bbe354"

Remarque : Dans l'entrée précédente du journal d'accès, request_processing_time, target_processing_time et response_processing_time sont chacun définis sur -1.

L'équilibreur de charge a reçu une réponse inattendue de la part de la cible, telle que « ICMP Destination unreachable (Host unreachable) » (Destination ICMP inaccessible (hôte inaccessible)), lors de la tentative d'établissement d'une connexion

• Vérifiez si les champs request_processing_time, target_processing_time et response_processing_time dans les journaux d'accès ont tous la valeur -1.
• Vérifiez si le trafic est autorisé depuis les sous-réseaux de l'équilibreur de charge vers les cibles sur le port cible.

La cible a fermé la connexion avec un TCP RST ou un TCP FIN alors que l'équilibreur de charge avait une demande en attente à la cible.

L'équilibreur de charge reçoit une demande et la transfère à la cible. La cible reçoit la demande et commence à la traiter, mais ferme trop tôt la connexion vers l'équilibreur de charge. Cela se produit généralement lorsque la durée du délai d'expiration keep-alive pour la cible est inférieure à la valeur du délai d'inactivité de l'équilibreur de charge. Assurez-vous que la durée du délai d'expiration keep-alive est supérieure à la valeur du délai d'inactivité.

Vérifiez les valeurs des champs request_processing_time, target_processing_time et response_processing_time.

Exemple d'entrée de journal d'accès :

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.001 4.205 -1 502 - 94 326 "GET http://example.com:80 HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337262-36d228ad5d99923122bbe354"

Remarque : Dans l'entrée précédente du journal d'accès, request_processing_time est 0,001, target_processing_time est 4,205 et response_processing_time est -1.

La réponse cible est mal formée ou contient des en-têtes HTTP non valides

Effectuez une capture de paquets sur la cible pendant la période du problème afin de comprendre la réponse cible.

L'équilibreur de charge a rencontré une erreur d'établissement de liaison SSL ou un délai d'expiration de liaison SSL (10 secondes) lors de la connexion à une cible

La connexion TCP entre l'équilibreur de charge et l'écouteur HTTPS de la cible est réussie, mais la négociation SSL suivante expire. Par conséquent, l'équilibreur de charge ne peut pas transférer la demande à la cible.

Vérifiez si le groupe cible utilise le protocole HTTPS. Si ce n'est pas le cas, le délai d'expiration de la négociation SSL n'est pas la cause. Si le groupe cible utilise le protocole HTTPS, essayez la procédure suivante :

• Vérifiez si les champs request_processing_time, target_processing_time et response_processing_time dans les journaux d'accès ont tous la valeur -1.
• Vérifiez s'il existe des points de données pour la métrique TargetTLSNegotiationErrorCount.
• Effectuez une capture de paquets sur la cible pendant la durée du problème afin de vérifier s'il est lié à une négociation SSL. Si c'est le cas, suivez les étapes décrites dans la section Effectuer une capture de paquets.
• Vérifiez si les chiffrements ou les protocoles ne correspondent pas.

Le délai de désenregistrement s'est écoulé pour une demande traitée par une cible qui a été désenregistrée

Dans vos événements CloudTrail, recherchez un appel d'API avec l'action DeregisterTargets pendant la période du problème. Si un appel d'API avec DeregisterTargets s'est produit pendant la période du problème, l'erreur est provoquée par une cible qui a été désenregistrée trop tôt. Pour résoudre ce problème, augmentez le délai de désenregistrement afin que les opérations longues puissent se terminer sans échec.

Résoudre les erreurs HTTP 502 lorsque la cible est une fonction Lambda

Remarque : Pour les demandes adressées à une fonction Lambda qui échouent, l'équilibreur de charge stocke les codes de motif d'erreur spécifiques à Lambda dans le champ error_reason des journaux d'accès.

La cible est une fonction Lambda et le corps de la réponse dépasse 1 Mo

• Vérifiez s'il existe un point de données pour la métrique LambdaUserError.
• Vérifiez si le champ error_reason du journal d'accès de l'équilibreur de charge est défini sur LambdaResponseTooLarge.

La cible est une fonction Lambda qui n'a pas répondu avant que le délai d'expiration configuré ne soit atteint

• Vérifiez la configuration du délai d'expiration de la fonction Lambda.
• Vérifiez s'il existe un point de données pour la métrique LambdaUserError.
• Vérifiez si le champ error_reason du journal d'accès de l'équilibreur de charge est défini sur LambdaUnhandled.

La cible est une fonction Lambda qui a renvoyé une erreur, ou la fonction a été limitée par le service Lambda

Contactez AWS Support pour obtenir des conseils sur la limitation des services.

Effectuer une capture de paquets

Pour Linux, utilisez la commande suivante :

sudo tcpdump -i any -w filename.pcap

Pour Microsoft Windows, téléchargez et utilisez l'application Wireshark (depuis le site web de Wireshark).

---