Code d'état 460 sur l'équilibreur de charge d'application
Je vois une quantité inquiétante de 460 codes d'état dans les journaux de mon équilibreur de charge d'application. Je ne vois aucun modèle sur ces codes en ce qui concerne les heures, les serveurs ou les URL de demande. Selon ce message sur le forum , le 460 signifie:
Le client a fermé la connexion avec l'ALB avant que le délai d'inactivité ne se déclenche sur la connexion frontale ou la connexion principale.
Je peux voir la demande qui parvient au serveur principal et le serveur principal traite la demande sans problème et très rapidement. Pourquoi ces erreurs se produisent-elles? Cet ALB fait un trafic important avec 6-8 serveurs principaux.
Exemple de journal ALB:
https 2017-01-30T22:46:27.451363Z app/LOAD-BALANCER/bbab458ad0b80d X.X.X.X:55999 10.5.X.X:80 0.000 -1 -1 460 - 132 0 "GET https://www.website.com:443/app/page HTTP/1.1" "-" ECDHE-RSA-AES128-SHA TLSv1 arn:aws:elasticloadbalancing:us-west-2:743462462234:targetgroup/TARGET-GROUP/e6120e5adr245b79107e "Root=1-588fc23e-77aea5adf4534af3de09659d13a08"
Exemple de journal NGINX du backend:
X.X.X.X 1485807955.048 www.website.com /app/page - GET 200 - 0.056 24 text/html; charset=UTF-8 -
La documentation du code d'état 460 est mise à jour pour les équilibreurs de charge d'application.
Cette erreur se produit lorsque l'équilibreur de charge a reçu une demande d'un client, mais que le client a fermé la connexion avec l'équilibreur de charge avant l'expiration du délai d'inactivité.
Vérifiez si le délai d'expiration du client est supérieur au délai d'inactivité pour l'équilibreur de charge. Assurez-vous que votre cible fournit une réponse au client avant l'expiration du délai d'expiration du client, ou augmentez le délai d'expiration du client pour correspondre au délai d'inactivité de l'équilibreur de charge, si le client le prend en charge.
Vous pouvez lire le document complet ici: http://docs.aws.Amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-460-issues
Il y a probablement un indice dans cette séquence:
0,000 -1 -1 460 -
Les champs sont request_processing_time, target_processing_time, response_processing_time, elb_status_code, target_status_code
Les champs target_processing_time et response_processing_time étant -1 suggèrent qu'il y a eu un problème de distribution de la demande à l'hôte cible, conformément à http://docs.aws.Amazon.com/elasticloadbalancing/latest/application/load-balancer- access-logs.html
Vérifiez que votre cible reçoit la demande, il pourrait y avoir un problème de configuration ou de réseau entre l'ALB et la cible. ALB insère un en-tête de suivi X-Amzn-Trace-Id dans la demande lorsqu'il l'envoie à la cible, peut-être les enregistrer sur votre backend NGINX et voir si vous obtenez les demandes spécifiques qui échouent.
J'ai eu affaire à un problème similaire et il semble être lié à la perte de nos hôtes TCP paquets en raison de TCP déchargement sur nos hôtes Windows).