Wie behebe ich Fehler bei der Network-Load-Balancer-Zustandsprüfung für Amazon-ECS-Aufgaben auf Fargate?

Kurzbeschreibung

Informationen zu HTTP- und HTTPS-Zustandsprüfungen findest du unter Wie behebe ich Fehler bei Application-Load-Balancer-Zustandsprüfungen für Amazon-ECS-Aufgaben auf Fargate?

Wenn die Amazon-ECS-Aufgaben eine Network-Load-Balancer-Zustandsprüfung nicht bestehen, erhältst du in den Service-Ereignismeldungen Fehler, die den folgenden Beispielen ähneln:

• „Health checks failed error - (service AWS-service) (port 80) is unhealthy in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) due to (reason Health checks failed)“
• „Target is in an Availability Zone that is not turned on for the load balancer error - (service AWS-service) (port 80) is unhealthy in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) due to (reason Target is in an Availability Zone that is not enabled for the load balancer)“
• „Health checks requests getting timed out - (service AWS-service) (port 8443) is unhealthy in (target-group arn:aws:elasticloadbalancing:us-east-1:111111111111:targetgroup/aws-targetgroup/123456789) due to (reason Request timed out).“

Wenn du Fehler bei der Container-Zustandsprüfung erhältst, findest du weitere Informationen unter Wie behebe ich Fehler bei der Container-Zustandsprüfung für Amazon-ECS-Aufgaben?

Wenn die Amazon-ECS-Aufgaben gestoppt wurden, findest du weitere Informationen unter Fehler bei gestoppten Amazon-ECS-Aufgaben anzeigen.

Lösung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version von AWS CLI verwendest.

Zustandsprüfungen fehlgeschlagen

Gehe wie folgt vor, um Fehler bei der Load-Balancer-Zustandsprüfung bei Fargate-Aufgaben zu beheben.

Überprüfe die Konnektivität zwischen dem Load Balancer und der Amazon-ECS-Aufgabe

Bestätige die folgenden Konfigurationen, damit der Load Balancer Zustandsprüfungen für Amazon-ECS-Aufgaben durchführen kann:

• Wenn dem Container Port 80 zugeordnet ist, lässt die Aufgaben-Sicherheitsgruppe eingehenden Datenverkehr auf Port 80 zu.
• Die Anwendung kann auf dem Port ausgeführt werden, der der Container-Instance in der Aufgabendefinition zugeordnet ist.
• Die Elastic-Network-Schnittstellen-Sicherheitsgruppe ermöglicht den Datenverkehr im CIDR-Bereich von Amazon Virtual Private Cloud (Amazon VPC). Weitere Informationen findest du unter Ziel-Sicherheitsgruppen.
• Die Regeln für Network-Load-Balancer-Sicherheitsgruppen ermöglichen ausgehenden Datenverkehr an die Amazon-ECS-Service-Sicherheitsgruppe auf dem erforderlichen Container-Port.
• Die Netzwerk-Zugriffssteuerungslisten (Netzwerk-ACL) der Netzwerkschnittstellen-Subnetze für die Aufgabe lassen eingehenden Datenverkehr auf dem Zustandsprüfungs-Port zu.
• Die Netzwerk-ACL ermöglicht ausgehenden Datenverkehr auf den kurzlebigen Ports.

Vergewissere dich, dass die Aufgaben korrekt auf manuelle Prüfungen innerhalb der Amazon-VPC-Verbindung reagieren

Vergewissere dich, dass die Amazon Elastic Compute Cloud (Amazon EC2)-Instance-Aufgaben innerhalb der VPC korrekt auf manuelle Prüfungen reagieren.

Hinweis: Du kannst entweder einen Cluster für den Amazon-EC2-Starttyp erstellen oder eine neue Amazon-EC2-Instance starten. Wenn du keine Amazon-EC2-Instance starten möchtest, kannst du ECS Exec verwenden.

Um die Aufgabenantwort zu überprüfen, verwende SSH, um innerhalb der Amazon VPC-Verbindung eine Verbindung zu einer EC2-Instance herzustellen. Führe dann einen der folgenden Befehle aus, um die Zielgruppenkonfiguration zu testen.

HTTP-Zustandsprüfungen:

curl -Iv http://example-task-private-ip:example-port/healthcheck_path

Hinweis: Ersetze example-task-private-ip durch deine Aufgaben-IP-Adresse und example-port durch deinen Port. Die Ausgabe des Befehls zeigt die erfolgreichen Statuscodes im Bereich 200–399 für HTTP-Zustandsprüfungskonfigurationen für die Zielgruppe.

Beispielausgabe:

HTTP/1.1 200 OK

TCP-Zustandsprüfungen, die keinen SSL für die Ziele verwenden:

nc -z -v -w10 example-task-private-ip example-port

Hinweis: Ersetze example-task-private-ip durch deine Aufgaben-IP-Adresse und example-port durch deinen Port.

Beispielausgabe:

nc -z -v -w10 10.x.x.x 80Connection to 10.x.x.x port 80 [tcp/http] succeeded!

TCP-Zustandsprüfungen, die SSL für Backend-Zustandsprüfungen erfordern:

nc -z -v -w10 --ssl example-task-private-ip example-port

Hinweis: Ersetze example-task-private-ip durch deine Aufgaben-IP-Adresse und example-port durch deinen Port.

Beispielausgabe:

nc -z -v -w10 10.x.x.x 443Connection to 10.x.x.x port 443 [tcp/https] succeeded!

Überprüfe den Status und die Konfiguration der Anwendung in der Amazon-ECS-Container-Instance

Ergreife die folgenden Maßnahmen:

• Vergewissere dich, dass du den Ping-Port und den Zustandsprüfungs-Pfad für die Zielgruppe korrekt konfiguriert hast.
• Überwache die Metriken zur CPU- und Speicherauslastung des Service auf einen hohen Ressourcenverbrauch, der dazu führt, dass die Anwendung nicht auf Zustandsprüfungsanforderungen reagiert.

Wenn für die Aufgabe eine längere Kulanzzeit für die Zustandsprüfung erforderlich ist, führe den folgenden AWS-CLI-Befehl update-service aus, um HealthCheckGracePeriodSeconds zu erhöhen:

aws ecs update-service --cluster example-cluster --service example-service --region example-region --health-check-grace-period-seconds example-value --force-new-deployment

Hinweis: Ersetze example-cluster durch deinen Clusternamen, example-service durch deinen Servicenamen, example-region durch deine AWS-Region und example-value durch die Kulanzzeit für die Zustandsprüfung in Sekunden.

Überprüfe, ob Ziele in der Zielgruppe die Zustandsprüfungen nicht bestehen, weil sie länger brauchen, um zu antworten. als der Standard-Timeout-Zeitraum. Um dieses Problem zu beheben, führe den folgenden Befehl modify-target-group aus, um das Zielgruppen-Timeout in Sekunden zu erhöhen:

aws elbv2 modify-target-group --target-group-arn Target-Group-ARN --health-check-timeout-seconds Timeout-Value

Hinweis: Ersetze Target-Group-ARN durch deinen Zielgruppen-ARN und Timeout-Value durch deinen Gruppen-Timeout-Wert in Sekunden.

Überprüfe die Anwendungsprotokolle auf Anwendungsfehler.

Stelle sicher, dass der Antwortcode, die deine Anwendung auf HealthCheckPath sendet, mit dem Antwortcode in den Zustandsprüfungsparametern der Zielgruppe übereinstimmt. Wenn du die Zugriffsprotokollierung für die Anwendung konfiguriert hast, verwende das Schlüsselwort ELB-HealthChecker/2.0, um die protokollierte Antwort zu überprüfen. Wenn du Amazon CloudWatch Logs verwendest, verwende CloudWatch Logs Insights, um die folgende Abfrage auszuführen:

fields @timestamp, @message| sort @timestamp desc
| filter @message like /ELB-HealthChecker/

Die Ausgabe der Abfrage zeigt die Zustandsprüfungsanforderungen, die der Network Load Balancer sendet, den Antwortcode und Fehler.

Das Ziel befindet sich in einer Availability Zone, die für den Load Balancer nicht aktiviert ist

Wenn du Ziele in einer Availability Zone registrierst, musst du die Availability Zone aktivieren, damit die registrierten Ziele Datenverkehr erhalten.

Wichtig: Du kannst Availability Zones für einen Network Load Balancer nicht deaktivieren, nachdem du den Load Balancer erstellt hast. Du kannst jedoch zusätzliche Availability Zones aktivieren.

Führe den folgenden describe-load-balancers-Befehl aus, um die Availability Zones zu identifizieren, für die der Load Balancer konfiguriert ist:

aws elbv2 describe-load-balancers --load-balancer-arn example-arn-load-balancer --region example-region --query "LoadBalancers[].AvailabilityZones[].ZoneName"

Hinweis: Ersetze example-arn-load-balancer durch deinen Load-Balancer-ARN und example-region durch deine Region.

Führe den folgenden describe-services-Befehl aus, um die Availability Zones zu identifizieren, für die die Fargate-Aufgabe konfiguriert ist:

aws ecs describe-services --cluster example-cluster-name --services example-service-name --region example-region --query "services[].networkConfiguration.awsvpcConfiguration.subnets"

Hinweis: Ersetze example-cluster-name durch deinen Clusternamen, example-service-name durch deinen Servicenamen und example-region durch deine Region. Die Ausgabe des Befehls zeigt dir die IDs für die Subnetze im Service.

Führe den folgenden describe-subnets-Befehl aus, um die Availability Zones der Subnetze der Aufgabe zu identifizieren:

aws ec2 describe-subnets --subnet-ids example-subnet-ids --region example-region --query "Subnets[].AvailabilityZone"

Hinweis: Ersetze example-subnet-ids durch deine Subnetz-ID und example-region durch deine Region. Die Ausgabe des Befehls zeigt dir die Availability Zones, für die der Service konfiguriert ist.

Um die Subnetzkonfiguration des Amazon-ECS-Service zu ändern, führe den folgenden update-service-Befehl aus:

aws ecs update-service --cluster cluster-name --service service-name --network-configuration "awsvpcConfiguration={subnets=[subnet-xxxxx,subnet-yyyyy]}"

Hinweis: Ersetze cluster-name durch deinen Clusternamen und service-name durch deinen Servicenamen.

Backend-Abhängigkeit

Wenn der Zustandsprüfungspfad der Anwendung mit einem Upstream- oder Downstream-Service, z. B. einer Datenbank, kommuniziert, stelle sicher, dass die Services verfügbar sind. Probleme mit den Services können dazu führen, dass die Zustandsprüfung fehlschlägt.

Amazon-ECS-Aufgaben können aus mehreren Gründen den Status fehlerhaft haben. Wenn die vorhergehende Lösung dein Problem nicht behebt, findest du weitere Informationen unter Problembehandlung bei Service Load Balancern in Amazon ECS.

Ähnliche Informationen

Zustandsprüfungen für Network-Load-Balancer-Zielgruppen

Netzwerkkonfiguration