Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# 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 Dauer, in der sowohl blaue als auch grüne Service-Revisionen gleichzeitig ausgeführt werden, nachdem der Produktionsdatenverkehr verlagert wurde. Amazon ECS berechnet diesen Zeitraum basierend auf der Alarmkonfiguration, die der Bereitstellung zugeordnet ist. Sie können diesen Wert nicht einstellen.
+ 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 [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)in 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 [Statussänderungs-Ereignisse der Amazon-ECS-Servicebereitstellung](ecs_service_deployment_events.md).
+ 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 AWS CLI konfigurieren. Weitere Informationen finden Sie unter [Erstellen eines Services mit definierten Parametern](create-service-console-v2.md#create-custom-service) und [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) 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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) 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 anrufen`DescribeAlarms`, kann dies Auswirkungen auf die Abfrage der Alarme durch Amazon ECS haben. Wenn beispielsweise ein anderer Service genügend `DescribeAlarms`-Aufrufe tätigt, um das Kontingent zu erreichen, wird dieser Service gedrosselt. Amazon ECS wird ebenfalls gedrosselt und kann keine Alarme abrufen. Wenn während des Drosselungszeitraums ein Alarm generiert wird, übersieht Amazon ECS möglicherweise den Alarm und der Rollback findet nicht statt. Es gibt keine weiteren Auswirkungen auf die Bereitstellung. Weitere Informationen zu CloudWatch Servicekontingenten finden Sie unter [CloudWatch Servicekontingenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) 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 behandelt den Fall, in dem Sie eine neue Bereitstellung starten möchten, um einen anfänglichen Bereitstellungsfehler 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](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) 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](cloudwatch-metrics.md#enable_cloudwatch).
+ 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](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) im *Amazon Simple Queue Service Developer Guide*.
## Bake time (Bake-Zeit)
Wenn Sie die Rollback-Option für Ihre Servicebereitstellungen verwenden, wartet Amazon ECS nach der Bereitstellung der Ziel-Servicerevision eine zusätzliche Zeit, bevor es einen Alarm sendet. CloudWatch Dies wird als Bake-Zeit bezeichnet. Diese Zeit beginnt nachdem:
+ Alle Aufgaben für eine Ziel-Service-Revision werden ausgeführt und befinden sich in einem fehlerfreien Zustand.
+ Die Revisionen des Quell-Services auf 0 % herunterskaliert wurden
Die standardmäßige Bake-Zeit weniger als 5 Minuten beträgt. Die Servicebereitstellung nach Ablauf der Bake-Zeit als abgeschlossen markiert wird.
Sie können die Bake-Zeit für eine fortlaufende Bereitstellung konfigurieren. Wenn Sie CloudWatch Alarme verwenden, um Fehler zu erkennen, wenn Sie die Backzeit ändern und dann entscheiden, dass Sie die Amazon ECS-Standardeinstellung verwenden möchten, müssen Sie die Backzeit manuell einstellen.