Comment puis-je résoudre les erreurs HTTP 502 de l'Application Load Balancer ?

Lecture de 7 minute(s)

Je souhaite apprendre à résoudre les erreurs de passerelle HTTP 502 défectueuse de mon équilibreur Application Load Balancer et à identifier la source des erreurs à l’aide des métriques CloudWatch et des journaux d’accès.

Brève description

Les erreurs HTTP 502 : passerelle défectueuse peuvent avoir plusieurs causes possibles. La source de l’erreur peut provenir de votre cible ou de votre équilibreur Application Load Balancer. Pour identifier la source de l’erreur, utilisez les métriques Amazon CloudWatch et les journaux d’accès.

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

Si la cible est une fonction AWS Lambda, consultez** Résoudre les erreurs HTTP 502 lorsque la cible est une fonction Lambda** dans la section Résolution.

Résolution

Trouvez 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, cela signifie que votre équilibreur de charge est à l’origine des erreurs HTTP 502. S’ils apparaissent sous la métrique HTTPCode_Target_5XX_Count, la cause provient de votre cible.

Utilisation des journaux d’accès

Si le** elb_status_code** est « 502 » et que la** target_status_code** est « - », votre équilibreur de charge est à l'origine des erreurs HTTP 502. Si le** elb_status_code** est « 502 » et que la** target_status_code** est « 502 », alors votre cible est à l'origine des erreurs.

Résoudre les erreurs HTTP 502

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

L'équilibreur de charge a reçu un TCP RST de la cible lors de la tentative d’établissement d’une connexion

Vous pouvez recevoir un RST TCP de la part de la cible lors de l’établissement d’une connexion. Ce message apparaît lorsque l’équilibreur de charge ne parvient pas à établir une liaison TCP tridirectionnelle avec la cible. Par conséquent, l’équilibreur de charge ne peut pas transmettre la demande de l’utilisateur à la cible.

Vérifiez si les champs request_processing_time, target_processing_time et response_processing_time dans les journaux d’accès sont tous définis sur la valeur -1. Cette valeur signifie que l’équilibreur de charge ne peut pas envoyer la demande à la cible, car cela nécessite 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 cette entrée du journal d'accès, la request_processing_time, la** target_processing_time** et la** response_processing_time** sont chacune définies sur** -1**.

L’équilibreur de charge a reçu une réponse inattendue de la cible, telle que « 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 sont tous définis sur 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 suspens à destination de la cible

L'équilibreur de charge reçoit une demande et la transmet à la cible. La cible reçoit la demande et commence à la traiter, mais ferme la connexion à l'équilibreur de charge trop tôt. Cela se produit généralement lorsque la durée du délai de** maintien en vie** pour la cible est inférieure à la valeur de délai** d'inactivité** de l'équilibreur de charge. Assurez-vous que la durée du délai de** maintien en vie** 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**.

Consultez l'exemple d'entrée de journal d'accès suivant :

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 cette entrée du journal d'accès, la request_processing_time est** 0,001**, la** target_processing_time** est** 4,205** et la** 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 de la cible.

L'équilibreur de charge a rencontré une erreur de liaison SSL ou un délai d'expiration de la 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 le délai d'établissement de liaison SSL suivant expire. Par conséquent, l’équilibreur de charge ne peut pas transmettre la demande à la cible.

Vérifiez si le groupe cible utilise le protocole HTTPS. S’il n’utilise pas le protocole HTTPS, le délai d’expiration de la liaison SSL n’est pas à l’origine du problème. Si le groupe cible utilise le protocole HTTPS, vérifiez les points suivants :

Vérifiez si les champs request_processing_time, target_processing_time et response_processing_time dans les journaux d’accès sont tous définis sur 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 période du problème afin de vérifier s’il est lié à une prise de contact SSL. Si tel est le cas, suivez les étapes de la section Exécuter une capture de paquets.
Vérifiez si les chiffrements ou les protocoles correspondent.

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

Dans vos événements CloudTrail, recherchez la présence d’un appel d’API avec l’action DeregisterTargets pendant la période du problème. Un appel d’API avec DeregisterTargets qui se produit pendant la période du problème provoque une erreur. Cette erreur se produit lorsque la cible a été désenregistrée trop tôt. Pour résoudre ce problème, augmentez le délai de désinscription afin que les opérations de longue durée 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 raison 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 dans le 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 dans le 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