So erkennen CloudWatch Alarme Bereitstellungsfehler bei Amazon ECS

Sie können Amazon ECS so konfigurieren, dass die Bereitstellung auf „Fehlgeschlagen“ gesetzt wird, wenn erkannt wird, dass ein bestimmter CloudWatch Alarm in den ALARM Status übergegangen ist.

Sie können die Konfiguration optional so einrichten, dass eine fehlgeschlagene Bereitstellung auf die zuletzt abgeschlossene Bereitstellung zurückgesetzt wird.

Das folgende create-service AWS CLI Beispiel zeigt, wie ein Linux-Service erstellt wird, wenn die Bereitstellungsalarme mit der Rollback-Option verwendet werden.

aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"

Beachten Sie Folgendes, wenn Sie die CloudWatch Amazon-Alarmmethode für einen Service verwenden.

• Die Bake-Zeit ist ein Zeitraum nach dem Aufskalieren einer neuen Serviceversion und dem Abskalieren der alten Serviceversion. Während dieser Zeit überwacht Amazon ECS weiterhin den der Bereitstellung zugeordneten Alarm. Amazon ECS berechnet diesen Zeitraum basierend auf der Alarmkonfiguration, die der Bereitstellung zugeordnet ist.

• Der deploymentConfiguration-Anfrageparameter enthält jetzt den alarms-Datentyp. Sie können die Alarmnamen angeben, festlegen, ob die Methode verwendet werden soll und ob ein Rollback initiiert werden soll, wenn die Alarme einen Bereitstellungsfehler anzeigen. Weitere Informationen finden Sie CreateServicein der Amazon Elastic Container Service API-Referenz.

• Die DescribeServices-Antwort bietet Einblick in den Status einer Bereitstellung, den rolloutState und rolloutStateReason. Wenn eine neue Bereitstellung gestartet wird, beginnt der Rollout-Status in einem IN_PROGRESS-Status. Wenn der Service einen stabilen Status erreicht und die Bake-Zeit abgeschlossen ist, wechselt der Rollout-Status zu COMPLETED. Wenn der Service keinen stabilen Status erreicht und der Alarm in den ALARM-Status übergegangen ist, wechselt die Bereitstellung in einen FAILED-Status. Eine Bereitstellung in einem FAILED-Status startet keine neuen Aufgaben.

• Zusätzlich zu den Ereignissen zur Statusänderung der Service-Bereitstellung, die Amazon ECS für gestartete und abgeschlossene Bereitstellungen sendet, sendet Amazon ECS auch ein Ereignis, wenn eine Bereitstellung mit aktiviertem Alarmen fehlschlägt. Diese Ereignisse enthalten Details dazu, warum eine Bereitstellung fehlgeschlagen ist oder ob eine Bereitstellung aufgrund eines Rollbacks gestartet wurde. Weitere Informationen finden Sie unter Ereignisse zur Änderung des Bereitstellungsstatus des Amazon ECS-Service.

• Wenn eine neue Bereitstellung gestartet wird, weil eine vorherige Bereitstellung fehlgeschlagen ist und ein Rollback aufgetreten ist, zeigt das reason-Feld des Ereignisses für die Statusänderung der Service-Bereitstellung an, dass die Bereitstellung aufgrund eines Rollbacks gestartet wurde.

• Wenn Sie den Deployment Circuit Breaker und die CloudWatch Amazon-Alarme verwenden, um Fehler zu erkennen, können beide einen Bereitstellungsfehler auslösen, sobald die Kriterien für eine der beiden Methoden erfüllt sind. Ein Rollback erfolgt, wenn Sie die Rollback-Option für die Methode verwenden, die den Bereitstellungsfehler ausgelöst hat.

• Die CloudWatch Amazon-Alarme werden nur für Amazon ECS-Services unterstützt, die den Rolling Update (ECS) Deployment Controller verwenden.

• Sie können diese Option mithilfe der Amazon ECS-Konsole oder der konfigurieren AWS CLI. Weitere Informationen finden Sie unter Erstellen eines Services mit definierten Parametern und create-service in der AWS Command Line Interface -Referenz.

• Möglicherweise stellen Sie fest, dass der Bereitstellungsstatus über einen längeren Zeitraum IN_PROGRESS bleibt. Der Grund dafür ist, dass Amazon ECS den Status erst ändert, wenn die aktive Bereitstellung gelöscht wurde. Dies geschieht erst nach der Bake-Zeit. Abhängig von Ihrer Alarmkonfiguration scheint die Bereitstellung möglicherweise einige Minuten länger zu dauern als ohne Verwendung von Alarmen (obwohl der neue primäre Aufgabensatz hochskaliert und die alte Bereitstellung herunterskaliert wird). Wenn Sie CloudFormation Timeouts verwenden, sollten Sie erwägen, die Timeouts zu erhöhen. Weitere Informationen finden Sie unter Erstellen von Wartebedingungen in einer Vorlage im AWS CloudFormation -Benutzerhandbuch.

• Amazon ECS ruft DescribeAlarms auf, um die Alarme abzufragen. Die Anrufe werden auf die mit Ihrem DescribeAlarms Konto verknüpften CloudWatch Servicekontingente angerechnet. Wenn Sie über andere AWS Dienste verfügen, die anrufenDescribeAlarms, kann dies Auswirkungen auf die Abfrage der Alarme durch Amazon ECS haben. Wenn beispielsweise ein anderer Service genügend DescribeAlarms Anrufe tätigt, um das Kontingent zu erreichen, wird dieser Service gedrosselt und Amazon ECS ist ebenfalls gedrosselt und kann keine Alarme abfragen. Wenn während des Drosselungszeitraums ein Alarm ausgelöst wird, übersieht Amazon ECS den Alarm möglicherweise und das Rollback findet möglicherweise nicht statt. Es gibt keine weiteren Auswirkungen auf die Bereitstellung. Weitere Informationen zu CloudWatch Servicekontingenten finden Sie unter CloudWatch Servicekontingenten im CloudWatch Benutzerhandbuch.

• Wenn sich ein Alarm zu Beginn einer Bereitstellung im Status ALARM befindet, überwacht Amazon ECS keine Alarme für die Dauer dieser Bereitstellung (Amazon ECS ignoriert die Alarmkonfiguration). Dieses Verhalten eignet sich für den Fall, dass Sie eine neue Bereitstellung starten möchten, um einen Fehler bei der ersten Bereitstellung zu beheben.

Empfohlene Alarme

Wir empfehlen die Verwendung der folgenden Alarmmetriken:

• Wenn Sie einen Application Load Balancer verwenden, verwenden Sie die Application-Load-Balancer-Metriken HTTPCode_ELB_5XX_Count und HTTPCode_ELB_4XX_Count. Diese Metriken überprüfen, ob HTTP-Spitzen vorliegen. Weitere Informationen zu den Application Load Balancer-Metriken finden Sie unter CloudWatch Metriken für Ihren Application Load Balancer im Benutzerhandbuch für Application Load Balancers.

• Verwenden Sie bei einer vorhandenen Anwendung die CPUUtilization- und MemoryUtilization-Metriken. Diese Metriken überprüfen den Prozentsatz von CPU und Arbeitsspeicher, den der Cluster oder Service verwendet. Weitere Informationen finden Sie unter Überlegungen.

• Wenn Sie Amazon Simple Queue Service Warteschlangen in Ihren Aufgaben verwenden, verwenden Sie die ApproximateNumberOfMessagesNotVisible Amazon SQS-Metrik. Diese Metrik prüft die Anzahl der Mitteilungen in der Warteschlange, die verzögert und nicht sofort zum Lesen verfügbar sind. Weitere Informationen zu Amazon SQS-Metriken finden Sie unter Verfügbare CloudWatch Metriken für Amazon SQS im Amazon Simple Queue Service Developer Guide.