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.
# Amazon-ECS-Fehlersuche
Möglicherweise müssen Sie bei Ihren Load Balancers, Aufgaben, Services oder Container-Instances Fehler beheben. In diesem Kapitel finden Sie Diagnoseinformationen für den Amazon-ECS-Container-Agenten, den Docker-Daemon auf der Container-Instance und das Service-Ereignisprotokoll in der Amazon-ECS-Konsole.
Informationen über gestoppte Aufgaben finden Sie in den folgenden Themen.
| Action | Weitere Informationen |
| --- | --- |
| Beheben Sie Fehler bei beendeten Aufgaben. | [Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md) |
| Fehler bei beendeten Aufgaben anzeigen. | [Aufgabe-Beendet-Fehler in Amazon ECS beheben](resolve-stopped-errors.md) |
| Fehlercodes Aufgabe-Beendet-Fehlern überprüfen. | [Aufgabe-Beendet-Fehlermeldungen in Amazon ECS](stopped-task-error-codes.md) |
| Überprüfen Sie die CannotPullContainer Aufgabenfehler. | [CannotPullContainer Aufgabenfehler in Amazon ECS](task_cannot_pull_image.md) |
| Aufgaben-IAM-Rollenanfragen anzeigen. | [IAM-Rollenanfragen für Amazon-ECS-Aufgaben anzeigen](task_iam_roles-logs.md) |
| Problembehandlung mithilfe von Aufgabenereignissen. | [Amazon ECS-Ereigniserfassung in der Konsole](task-lifecycle-events.md) |
Informationen zu Servicefehlern finden Sie in den folgenden Themen.
| Action | Weitere Informationen |
| --- | --- |
| Service-Ereignismeldungen anzeigen | [Anzeigen von Service-Ereignismeldungen von Amazon ECS](service-event-messages.md) |
| Service-Ereignismeldungen überprüfen | [Service-Ereignismeldungen in Amazon ECS](service-event-messages-list.md) |
| Überprüfen Sie die Probleme mit dem Load Balancer. | [Fehlerbehebung bei Service-Load Balancers in Amazon ECS](troubleshoot-service-load-balancers.md) |
| Überprüfen Sie Probleme mit Service-Auto-Scaling. | [Fehlerbehebung bei Service-Auto-Scaling in Amazon ECS](troubleshoot-service-auto-scaling.md) |
Informationen zu Aufgabendefinitionsfehlern finden Sie in den folgenden Themen.
| Action | Weitere Informationen |
| --- | --- |
| Beheben Sie den Arbeitsspeicherfehler bei der Aufgabendefinition. | [Fehlerbehebung bei ungültigen CPU- oder Arbeitsspeicher-Fehlern in der Amazon-ECS-Aufgabendefinition](task-cpu-memory-error.md) |
Informationen zu Fehlern des Amazon-ECS-Agenten finden Sie in den folgenden Themen.
| Action | Weitere Informationen |
| --- | --- |
| Protokolle des Amazon-ECS-Container-Agenten anzeigen | [Protokolle des Amazon-ECS-Container-Agenten anzeigen](logs.md) |
| Erfahren Sie, wie Sie Amazon-ECS-Protokolle erfassen. | [Erfassung von Container-Protokollen mit Amazon ECS Log Collector](ecs-logs-collector.md) |
| Rufen Sie Diagnosedetails mit dem Amazon-ECS-Agenten ab. | [Amazon-ECS-Diagnosedetails mit Agent-Introspektion](introspection-diag.md) |
Informationen zu Docker-Fehlern finden Sie in den folgenden Themen.
| Action | Weitere Informationen |
| --- | --- |
| Verwenden Sie Docker-Diagnosen. | [Docker-Diagnose in Amazon ECS](docker-diags.md) |
| Schalten Sie den Docker-Debug-Modus ein. | [Konfiguration der ausführlichen Ausgabe vom Docker-Daemon in Amazon ECS](docker-debug-mode.md) |
| Beheben Sie den Docker-API-Fehler 500. | [Fehlerbehebung beim Docker-`API error (500): devmapper` in Amazon ECS](CannotCreateContainerError.md) |
Informationen zu Fehlern mit ECS Exec und Amazon ECS Anywhere finden Sie in den folgenden Themen.
| Action | Weitere Informationen |
| --- | --- |
| Fehlerbehebung bei ECS Exec | [Fehlerbehebung bei Amazon-ECS-Exec-Problemen](ecs-exec-troubleshooting.md) |
| Fehler bei Amazon ECS Anywhere beheben. | [Fehlerbehebung bei Amazon-ECS-Anywhere-Problemen](ecs-anywhere-troubleshooting.md) |
Informationen zu Problemen beim Anhängen von Amazon-EBS-Volumes an Amazon-ECS-Aufgaben finden Sie im Folgenden:
| Action | Weitere Informationen |
| --- | --- |
| Fehlerbehebung bei Amazon-EBS-Volume-Anhängen an Amazon ECS-Aufgaben. | [Fehlerbehebung bei Amazon-EBS-Volume-Anhängen an Amazon-ECS-Aufgaben](troubleshoot-ebs-volumes.md) |
| Statussgründe für den Anhang von Amazon-EBS-Volumes an Amazon-ECS-Aufgaben | [Statussgründe für den Anhang von Amazon-EBS-Volumes an Amazon-ECS-Aufgaben](troubleshoot-ebs-volumes-scenarios.md) |
Informationen zu Problemen bei der Verwendung von gemeinsam genutzten AWS Cloud Map Namespaces mit Amazon ECS Service Connect finden Sie in einer der folgenden Seiten:
| Action | Weitere Informationen |
| --- | --- |
| Fehlerbehebung bei Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces. | [Fehlerbehebung bei Amazon ECS Service Connect mit gemeinsam genutzten AWS Cloud Map Namespaces](service-connect-shared-namespaces-troubleshooting.md) |
Informationen zu Problemen mit der Drosselung finden Sie in den folgenden Themen.
| Action | Weitere Informationen |
| --- | --- |
| Erfahren Sie mehr über die Drosselungsquoten von Fargate. | [AWS Fargate Drosselung von Kontingenten](throttling.md) |
| Erfahren Sie mehr über die bewährten Methoden für die Drosselung in Amazon ECS. | [Probleme mit der Drosselung von Amazon ECS beheben](operating-at-scale-dealing-with-throttles.md) |
Informationen zu API-Fehlern finden Sie in den folgenden Themen.
| Action | Weitere Informationen |
| --- | --- |
| Beheben von API-Fehlern | [Gründe für das Fehlschlagen der Amazon-ECS-API](api_failures_messages.md) |
Informationen zur KI-gestützten Fehlerbehebung finden Sie im Folgenden:
| Action | Weitere Informationen |
| --- | --- |
| Beheben Sie Probleme mit Amazon Q Developer in der Konsole. | [Problembehandlung mit Amazon Q Developer](troubleshooting-with-Q.md) |
| Beheben Sie Probleme mit KI-Assistenten, die den Amazon ECS MCP-Server verwenden. | [Amazon ECS MCP-Server](ecs-mcp-introduction.md) |
# Aufgabe-Beendet-Fehler in Amazon ECS beheben
Wenn Ihre Aufgabe nicht gestartet werden kann, wird in der Konsole und in den `describe-tasks`-Ausgabeparametern (`stoppedReason` und `stopCode`) eine Fehlermeldung angezeigt.
Sie können gestoppte Aufgaben eine Stunde lang in der Konsole anzeigen. Um gestoppte Aufgaben zu sehen, müssen Sie die Filteroption ändern. Weitere Informationen finden Sie unter [Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
Auf den folgenden Seiten finden Sie Informationen zu beendeten Aufgaben.
+ Erfahren Sie mehr über Änderungen an Fehlermeldungen zu beendeten Aufgaben.
[Aktualisierungen der Aufgabe-Beendet-Fehlermeldungen in Amazon ECS](stopped-tasks-error-messages-updates.md)
+ Sehen Sie sich Ihre angehaltenen Aufgaben an, um Informationen über die Ursache zu erhalten.
[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md)
+ Erfahren Sie mehr über die Fehlermeldungen zu beendeten Aufgaben und mögliche Gründe für die Fehler.
[Aufgabe-Beendet-Fehlermeldungen in Amazon ECS](stopped-task-error-codes.md)
+ Erfahren Sie, wie Sie die Konnektivität gestoppter Aufgaben überprüfen und die Fehler beheben können.
[Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md)
# Aktualisierungen der Aufgabe-Beendet-Fehlermeldungen in Amazon ECS
Ab dem 14. Juni 2024 ändert das Amazon-ECS-Team die Fehlermeldungen für gestoppte Aufgaben wie in den folgenden Tabellen beschrieben. Der `stopCode` ändert sich nicht. Wenn Ihre Anwendungen von exakten Fehlermeldungszeichenfolgen abhängen, müssen Sie Ihre Anwendungen mit den neuen Zeichenfolgen aktualisieren. Wenn Sie Hilfe bei Fragen oder Problemen benötigen, wenden Sie sich an AWS Support.
**Anmerkung**
Wir empfehlen Ihnen, sich bei Ihrer Automatisierung nicht auf die Fehlermeldungen zu verlassen, da sich die Fehlermeldungen ändern können.
## CannotPullContainerError
| Alte Fehlermeldung. | Neue Fehlermeldung |
| --- | --- |
| CannotPullContainerError: Fehlerantwort vom Daemon: Pull-Zugriff verweigert fürrepository, Repository existiert nicht oder erfordert möglicherweise eine Docker-Anmeldung: verweigert: Benutzer: roleARN | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/stopped-tasks-error-messages-updates.html) |
| CannotPullContainerError: Fehlerantwort vom Daemon: Get: net/http: Die Anfrage imageURI wurde beim Warten auf die Verbindung abgebrochen | CannotPullContainerError: Die Aufgabe kann das Bild nicht abrufen. Überprüfen Sie die Netzwerkkonfiguration. Fehlerantwort vom Daemon: Get: net/httpimage: Anfrage wurde beim Warten auf die Verbindung abgebrochen (Client.Timeout wurde beim Warten auf Header überschritten) |
| CannotPullContainerError: ref pull wurde 5 mal wiederholt: konnte nicht kopiert werden:: konnte nicht geöffnet werden: Anfrage konnte nicht ausgeführt werden httpReadSeeker: Get: dial tcp: timeout registry-uri i/o | CannotPullContainerError: Die Aufgabe kann keine Daten image-uri aus der Registrierung abrufen. registry-uri Es besteht ein Verbindungsproblem zwischen der Aufgabe und der Registry. Überprüfen Sie die Netzwerkkonfiguration Ihrer Aufgabe.: Fehler beim Kopieren: httpReadSeeker: Fehler beim Öffnen: Fehler beim Ausführen der Anfrage: Abrufenregistry-uri: Dial TCP: i/o Timeout |
## ResourceNotFoundException
| Alte Fehlermeldung. | Neue Fehlermeldung |
| --- | --- |
| Beim Abrufen geheimer Daten aus AWS Secrets Manager der region Region: secretsercretARN: ResourceNotFoundException: Secrets Manager kann das angegebene Geheimnis nicht finden. | ResourceNotFoundException: Die Aufgabe kann das Geheimnis mit dem ARN 'sercretARN' von nicht abrufen AWS Secrets Manager. Überprüfen Sie, ob das Geheimnis in der angegebenen Region vorhanden ist. ResourceNotFoundException: Geheime Daten aus AWS Secrets Manager einer Region abrufenregion: secretsercretARN: ResourceNotFoundException: Secrets Manager kann das angegebene Geheimnis nicht finden. |
## ResourceInitializationError
| Alte Fehlermeldung. | Neue Fehlermeldung |
| --- | --- |
| ResourceInitializationError: Geheimnisse oder Registrierungsauthentifizierung konnten nicht abgerufen werden: Fehler beim Abrufen der Ausführungsressource: ECR-Registrierungsauthentifizierung konnte nicht abgerufen werden: Der Serviceaufruf wurde dreimal wiederholt:: Die Anfrage konnte nicht gesendet werden, verursacht durch RequestError: Post "https://api.ecr.us-east-1.amazonaws.com/“: dial tcp:: timeout. i/o Bitte überprüfen Sie die Netzwerkkonfiguration der Aufgabe. | ResourceInitializationError: Geheimnisse oder Registrierungsauthentifizierung können nicht abgerufen werden: Die Aufgabe kann die Registrierungsauthentifizierung nicht von Amazon ECR abrufen: Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon ECR. Überprüfen Sie die Netzwerkkonfiguration Ihrer Aufgabe. RequestError: Die Anfrage konnte nicht gesendet werden. Grund: Post "https://api.ecr.us-east-1.amazonaws.com„: dial tcp:: i/o timeout |
| ResourceInitializationError: Schlüssel oder Registrierungsauthentifizierung konnten nicht abgerufen werden: Fehler beim Abrufen der Ausführungsressource: Es konnten keine Geheimnisse von SSM abgerufen werden: Der Serviceaufruf wurde fünfmal wiederholt:: Der Anforderungskontext wurde abgebrochen, verursacht durch RequestCanceled: Kontext-Frist überschritten | ResourceInitializationError: Geheimnisse oder Registrierungsauthentifizierung können nicht abgerufen werden: Geheimnisse können nicht von SSM abgerufen werden: Die Aufgabe kann keine Geheimnisse aus SSM abrufen. AWS Systems Manager Es besteht ein Verbindungsproblem zwischen der Aufgabe und AWS Systems Manager Parameter Store. Überprüfen Sie die Netzwerkkonfiguration Ihrer Aufgabe. RequestCanceled: Der Anforderungskontext wurde abgebrochen, weil: Die Frist für den Kontext wurde überschritten |
| ResourceInitializationError: Env-Dateien konnten nicht heruntergeladen werden: Befehl zum Herunterladen der Datei: nicht leerer Fehlerstream: RequestCanceled: Der Anforderungskontext wurde abgebrochen, verursacht durch: Kontext-Frist überschritten | ResourceInitializationError: Env-Dateien konnten nicht heruntergeladen werden: Die Aufgabe kann die Umgebungsvariablendateien nicht von Amazon S3 herunterladen. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon S3. Überprüfen Sie die Netzwerkkonfiguration Ihrer Aufgabe. Der Serviceaufruf wurde 5 Mal wiederholt:: Der Anforderungskontext wurde abgebrochen, verursacht durch RequestCanceled: Kontext-Frist überschritten |
| ResourceInitializationError: Logger args: :signal:killed konnte nicht validiert werden | ResourceInitializationError: Logger-Argumente konnten nicht validiert werden: Die Aufgabe kann die in der Aufgabendefinition definierte CloudWatch Amazon-Protokollgruppe nicht finden. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon CloudWatch. Überprüfen Sie Ihre Netzwerkkonfiguration. : Signal: abgebrochen |
| ResourceInitializationError: Geheimnisse oder Registry Auth können nicht abgerufen werden: Pull-Befehl ist fehlgeschlagen:: Signal: beendet | ResourceInitializationError: Geheimnisse oder Registrierungsauthentifizierung konnten nicht abgerufen werden: Überprüfen Sie die Netzwerkkonfiguration Ihrer Aufgabe.: Signal: getötet |
# Aufgabe-Beendet-Fehler in Amazon ECS anzeigen
Wenn Sie Probleme beim Starten einer Aufgabe haben, wird Ihre Aufgabe möglicherweise aufgrund von Anwendungs- oder Konfigurationsfehlern angehalten. Sie führen beispielsweise eine Aufgabe aus, und die Aufgabe zeigt einen Status `PENDING` an, verschwindet dann aber.
Wenn Ihre Aufgabe von einem Amazon-ECS-Service erstellt wurde, werden die Aktionen, die Amazon ECS zur Wartung des Service durchführt, in den Service-Ereignissen veröffentlicht. Sie können die Ereignisse in der AWS-Managementkonsole,, AWS CLI AWS SDKs, Amazon ECS-API oder in Tools, die die SDKs and-API verwenden, anzeigen. Zu diesen Ereignissen gehört, dass Amazon ECS eine Aufgabe anhält und ersetzt, weil die Container in der Aufgabe nicht mehr ausgeführt werden oder zu viele Zustandsprüfungen von Elastic Load Balancing fehlgeschlagen sind.
Wenn Ihre Aufgabe auf einer Container-Instance in Amazon EC2 oder externen Computern ausgeführt wurde, können Sie auch die Protokolle der Container-Laufzeit und des Amazon-ECS-Agenten anzeigen lassen. Diese Protokolle befinden sich auf der Host-Amazon-EC2-Instance oder dem externen Computer. Weitere Informationen finden Sie unter [Protokolle des Amazon-ECS-Container-Agenten anzeigen](logs.md).
## Verfahren
------
#### [ Console ]
**AWS-Managementkonsole**
Die folgenden Schritte können verwendet werden, um Aufgabe-Beendet-Fehler in der Konsole zu überprüfen. Um gestoppte Aufgaben zu sehen, müssen Sie die Filteroption ändern.
Beendete Aufgaben werden nur 1 Stunde lang in der Konsole angezeigt.
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der *name* Seite **Cluster:** die Registerkarte **Aufgaben** aus.
1. Konfigurieren Sie den Filter so, dass gestoppte Aufgaben angezeigt werden. Wählen Sie für **Gewünschten Status filtern** die Option **Angehalten** aus.
Die Option **Angehalten** zeigt Ihre angehaltenen Aufgaben an und **Beliebiger Status** zeigt alle Ihre Aufgaben an.
1. Wählen Sie die zu untersuchende angehaltene Aufgabe aus.
1. Wählen Sie in der Zeile für Ihre gestoppte Aufgabe in der Spalte **Letzter Status** die Option **Angehalten** aus.
In einem Pop-up-Fenster wird der Grund für das Anhalten angezeigt.
------
#### [ AWS CLI ]
1. Rufen Sie eine Liste der gestoppten Aufgaben in einem Cluster ab. Die Ausgabe enthält den Amazon-Ressourcennamen (ARN) der Aufgabe, die Sie zur Beschreibung der Aufgabe benötigen.
```
aws ecs list-tasks \
--cluster cluster_name \
--desired-status STOPPED \
--region region
```
1. Beschreiben Sie die angehaltene Aufgabe, um die Informationen abzurufen. *Weitere Informationen finden Sie unter [describe-tasks](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-tasks.html) in der AWS Command Line Interface Referenz.*
```
aws ecs describe-tasks \
--cluster cluster_name \
--tasks arn:aws:ecs:region:account_id:task/cluster_name/task_ID \
--region region
```
Verwenden Sie die folgenden Ausgabeparameter.
+ `stopCode`- Der Stoppcode gibt beispielsweise an, warum eine Aufgabe gestoppt wurde ResourceInitializationError
+ `StoppedReason` – Der Grund, warum die Aufgabe angehalten wurde.
+ `reason` (in der `containers`-Struktur) – Der Grund liefert weitere Informationen zum angehaltenen Container.
------
## Nächste Schritte
Sehen Sie sich Ihre angehaltenen Aufgaben an, um Informationen über die Ursache zu erhalten. Weitere Informationen finden Sie unter [Aufgabe-Beendet-Fehlermeldungen in Amazon ECS](stopped-task-error-codes.md).
# Aufgabe-Beendet-Fehlermeldungen in Amazon ECS
Im Folgenden finden Sie die möglichen Fehlermeldungen, die Sie erhalten, wenn Ihre Aufgabe unerwartet angehalten wird.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wird AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
**Tipp**
Sie können die Assistenten [Amazon ECS MCP-Server](ecs-mcp-introduction.md) mit KI verwenden, um Aufgabenfehler und Container-Logs in natürlicher Sprache zu analysieren.
Fehlercodes für gestoppte Aufgaben sind mit einer Kategorie verknüpft, zum Beispiel "ResourceInitializationError“. Weitere Informationen zu jeder Kategorie finden Sie in den folgenden Themen:
| Kategorie | Weitere Informationen |
| --- | --- |
| TaskFailedToStart | [Behebung von Amazon TaskFailedToStart ECS-Fehlern](failed-to-start-error.md) |
| ResourceInitializationError | [Behebung von Amazon ResourceInitializationError ECS-Fehlern](resource-initialization-error.md) |
| ResourceNotFoundException | [Behebung von Amazon ResourceNotFoundException ECS-Fehlern](resource-not-found-error.md) |
| SpotInterruptionError | [Behebung von Amazon SpotInterruption ECS-Fehlern](spot-interruption-errors.md) |
| InternalError | [Behebung von Amazon InternalError ECS-Fehlern](internal-error.md) |
| OutOfMemoryError | [Behebung von Amazon OutOfMemoryError ECS-Fehlern](out-of-memory.md) |
| ContainerRuntimeError | [Behebung von Amazon ContainerRuntimeError ECS-Fehlern](container-runtime-error.md) |
| ContainerRuntimeTimeoutError | [Behebung von Amazon ContainerRuntimeTimeoutError ECS-Fehlern](container-runtime-timeout-error.md) |
| CannotStartContainerError | [Behebung von Amazon CannotStartContainerError ECS-Fehlern](cannot-start-container.md) |
| CannotStopContainerError | [Behebung von Amazon CannotStopContainerError ECS-Fehlern](cannot-stop-container.md) |
| CannotInspectContainerError | [Behebung von Amazon CannotInspectContainerError ECS-Fehlern](cannot-inspect-container.md) |
| CannotCreateVolumeError | [Behebung von Amazon CannotCreateVolumeError ECS-Fehlern](cannot-create-volume.md) |
| CannotPullContainer | [CannotPullContainer Aufgabenfehler in Amazon ECS](task_cannot_pull_image.md) |
# Behebung von Amazon TaskFailedToStart ECS-Fehlern
Im Folgenden finden Sie einige `TaskFailedToStart`-Fehlermeldungen und Maßnahmen, die Sie ergreifen können, um die Fehler zu beheben.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wird AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## Unerwarteter EC2-Fehler beim Versuch, eine Netzwerkschnittstelle mit aktivierter öffentlicher IP-Zuweisung im Subnetz 'zu erstellen *subnet-id*
Dies passiert, wenn eine Fargate-Aufgabe, die den `awsvpc`-Netzwerkmodus verwendet und in einem Subnetz mit einer öffentlichen IP-Adresse ausgeführt wird, und das Subnetz nicht über genügend IP-Adressen verfügt.
Die Anzahl der verfügbaren IP-Adressen kann auf der Subnetz-Detailseite in der Amazon-EC2-Konsole angezeigt werden, oder mit `[describe-subnets](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-subnets.html)`. Weitere Informationen finden Sie unter [Subnetz anzeigen](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#view-subnet) im *Benutzerhandbuch für Amazon VPC*.
Um dieses Problem zu beheben, können Sie ein neues Subnetz erstellen, in dem Ihre Aufgabe ausgeführt werden soll.
## InternalError: **
Dieser Fehler tritt auf, wenn eine ENI-Anlage angefordert wird. Amazon EC2 übernimmt asynchron die Bereitstellung der ENI. Der Bereitstellungsprozess nimmt Zeit in Anspruch. Amazon ECS hat ein Timeout für den Fall, dass es zu langen Wartezeiten oder nicht gemeldeten Fehlern kommt. Es gibt Zeiten, in denen die ENI bereitgestellt wird, aber der Bericht wird nach dem Fehler-Timeout an Amazon ECS gesendet. In diesem Fall erkennt Amazon ECS den gemeldeten Aufgabenfehler mit einer verwendeten ENI.
## Die ausgewählte Aufgabendefinition ist nicht mit der ausgewählten Rechenstrategie kompatibel
Dieser Fehler tritt auf, wenn Sie eine Aufgabendefinition mit einem Starttyp auswählen, der nicht dem Cluster-Kapazitätstyp entspricht. Sie müssen eine Aufgabendefinition auswählen, die dem Kapazitätsanbieter entspricht, der Ihrem Cluster zugewiesen ist.
## Die Netzwerkschnittstelle konnte nicht an den Index ungenutzter Geräte angehängt werden
Dieser Fehler tritt auf, wenn der `awsvpc` Netzwerktyp verwendet wird und nicht genug CPU/memory für die Aufgabe vorhanden ist. Überprüfen Sie zunächst die CPU für die Instances. Weitere Informationen finden Sie unter [Spezifikationen für Instance-Typen von Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html) unter *Instance-Typen von Amazon EC2*. Nehmen Sie den CPU-Wert für die Instanz und multiplizieren Sie ihn mit der Nummer von ENIs für die Instanz. Verwenden Sie diesen Wert e in der Aufgabendefinition.
## AGENT
Die Container-Instance, auf der Sie eine Aufgabe zu starten versucht haben, hat einen Agenten, der derzeit nicht verbunden ist. Um langen Wartezeiten für die Platzierung der Aufgabe vorzubeugen, wurde die Anfrage zurückgewiesen.
Informationen zur Fehlerbehebung finden Sie unter [Wie behebe ich Probleme mit einem getrennten Amazon-ECS-Agenten](https://repost.aws/knowledge-center/ecs-agent-disconnected-linux2-ami).
# Behebung von Amazon ResourceInitializationError ECS-Fehlern
Im Folgenden finden Sie einige `ResourceInitialization`-Fehlermeldungen und Maßnahmen, die Sie ergreifen können, um die Fehler zu beheben.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
**Topics**
+ [Die Aufgabe kann die Registrierungsauthentifizierung nicht von Amazon ECR abrufen. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon ECR. Überprüfen Sie die Netzwerkkonfiguration der Aufgabe.](#unable-to-pull-secrets-ecr)
+ [Die Aufgabe kann die Umgebungsvariablendateien nicht von Amazon S3 herunterladen. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon S3. Überprüfen Sie die Netzwerkkonfiguration der Aufgabe.](#failed-to-download-env-files)
+ [Die Aufgabe kann keine Geheimnisse aus dem AWS Systems Manager Parameterspeicher abrufen. Überprüfen Sie Ihre Netzwerkverbindung zwischen der Aufgabe und AWS Systems Manager.](#unable-to-pull-secrets-sys-manager)
+ [Die Aufgabe kann keine Geheimnisse abrufen AWS Secrets Manager. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Secrets Manager. Überprüfen Sie die Netzwerkkonfiguration der Aufgabe.](#unable-to-pull-secrets-asm-no-arn)
+ [Die Aufgabe kann das Geheimnis nicht aus Secrets Manager abrufen. Die Aufgabe kann das Geheimnis mit dem ARN '*secretARN*' nicht aus dem Secrets Manager abrufen. Überprüfen Sie, ob das Geheimnis in der angegebenen Region vorhanden ist.](#unable-to-pull-secrets-asm)
+ [Pull-Befehl fehlgeschlagen: Secrets oder Registrysauthentifizierung können nicht abgerufen werden. Überprüfen Sie die Netzwerkkonfiguration Ihrer Aufgabe.](#pull-command-failed)
+ [Die Aufgabe kann die in der Aufgabendefinition definierte CloudWatch Amazon-Protokollgruppe nicht finden. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon CloudWatch. Überprüfen Sie die Netzwerkkonfiguration.](#failed-to-initialize-logging-network)
+ [Initialisierung des Protokollierungstreibers fehlgeschlagen](#failed-to-initialize-logging)
+ [Fehler beim Aufrufen der EFS-Serviceprogrammbefehle zum Einrichten von EFS-Volumes](#efs-utils-failed)
## Die Aufgabe kann die Registrierungsauthentifizierung nicht von Amazon ECR abrufen. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon ECR. Überprüfen Sie die Netzwerkkonfiguration der Aufgabe.
Dieser Fehler weist darauf hin, dass die Aufgabe keine Verbindung zu Amazon ECR herstellen kann.
Überprüfen Sie die Verbindung zwischen der Aufgabe und Amazon ECR. Weitere Informationen finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## Die Aufgabe kann die Umgebungsvariablendateien nicht von Amazon S3 herunterladen. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon S3. Überprüfen Sie die Netzwerkkonfiguration der Aufgabe.
Dieser Fehler tritt auf, wenn Ihre Aufgabe Ihre Umgebungsdatei nicht von Amazon S3 herunterladen kann.
Überprüfen Sie die Verbindung zwischen der Aufgabe und dem Amazon-S3-VPC-Endpunkt. Weitere Informationen finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## Die Aufgabe kann keine Geheimnisse aus dem AWS Systems Manager Parameterspeicher abrufen. Überprüfen Sie Ihre Netzwerkverbindung zwischen der Aufgabe und AWS Systems Manager.
Dieser Fehler tritt auf, wenn Ihre Aufgabe das in der Aufgabendefinition definierte Image nicht mithilfe der Anmeldeinformationen in Systems Manager abrufen kann.
Überprüfen Sie die Verbindung zwischen der Aufgabe und dem Systems-Manager-VPC-Endpunkt. Weitere Informationen finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## Die Aufgabe kann keine Geheimnisse abrufen AWS Secrets Manager. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Secrets Manager. Überprüfen Sie die Netzwerkkonfiguration der Aufgabe.
Dieser Fehler tritt auf, wenn Ihre Aufgabe das in der Aufgabendefinition definierte Image nicht mithilfe der Anmeldeinformationen in Secrets Manager abrufen kann.
Der Fehler weist darauf hin, dass ein Netzwerkverbindungsproblem zwischen dem Systems-Manager-VPC-Endpunkt und der Aufgabe besteht.
Informationen zur Überprüfung der Konnektivität zwischen der Aufgabe und dem Endpunkt finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## Die Aufgabe kann das Geheimnis nicht aus Secrets Manager abrufen. Die Aufgabe kann das Geheimnis mit dem ARN '*secretARN*' nicht aus dem Secrets Manager abrufen. Überprüfen Sie, ob das Geheimnis in der angegebenen Region vorhanden ist.
Dieser Fehler tritt auf, wenn Ihre Aufgabe das in der Aufgabendefinition definierte Image nicht mithilfe der Anmeldeinformationen in Secrets Manager abrufen kann.
Dieses Problem kann durch einen der folgenden Gründe bedingt sein.
| Ursache des Fehlers. | Vorgehensweise |
| --- | --- |
| Netzwerkverbindungsproblem zwischen dem Secrets-Manager-VPC-Endpunkt und der Aufgabe. Das Problem ist ein Netzwerkproblem, wenn Sie eine der folgenden Zeichenfolgen in der Fehlermeldung sehen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/resource-initialization-error.html) | Überprüfen Sie die Verbindung zwischen dem Secrets-Manager-VPC-Endpunkt und der Aufgabe. Weitere Informationen finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md). |
| Die in der Aufgabendefinition definierte Aufgabenausführungsrolle hat nicht die Berechtigungen für Secrets Manager. | Fügen Sie die erforderlichen Berechtigungen für Secrets Manager zur Aufgabenausführungsrolle hinzu. Weitere Informationen finden Sie unter [Berechtigungen für Secrets Manager oder Systems Manager](task_execution_IAM_role.md#task-execution-secrets). |
| Der geheime ARN ist nicht vorhanden | Überprüfen Sie, ob der ARN in Secrets Manager vorhanden ist. Informationen zum Anzeigen Ihrer Images finden Sie unter [Gehemnisse in Secrets Manager suchen](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_search-secret.html) im Entwicklerhandbuch für Secrets Manager. |
## Pull-Befehl fehlgeschlagen: Secrets oder Registrysauthentifizierung können nicht abgerufen werden. Überprüfen Sie die Netzwerkkonfiguration Ihrer Aufgabe.
Dieser Fehler tritt auf, wenn Ihre Aufgabe keine Verbindung zu Amazon ECR, Systems Manager oder Secrets Manager herstellen kann. Dies ist auf eine Fehlkonfiguration in Ihrem Netzwerk zurückzuführen.
Überprüfen Sie die Konnektivität zwischen der Aufgabe und Amazon ECR, um dieses Problem zu beheben. Sie müssen auch die Konnektivität zwischen Ihrer Aufgabe und dem Service überprüfen, der Ihr Geheimnis speichert (Systems Manager oder Secrets Manager). Weitere Informationen finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## Die Aufgabe kann die in der Aufgabendefinition definierte CloudWatch Amazon-Protokollgruppe nicht finden. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon CloudWatch. Überprüfen Sie die Netzwerkkonfiguration.
Dieser Fehler tritt auf, wenn Ihre Aufgabe die CloudWatch Protokollgruppe, die Sie in der Aufgabendefinition definiert haben, nicht findet.
Der Fehler weist darauf hin, dass ein Netzwerkverbindungsproblem zwischen dem CloudWatch VPC-Endpunkt und der Aufgabe besteht.
Informationen zur Überprüfung der Konnektivität zwischen der Aufgabe und dem Endpunkt finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## Initialisierung des Protokollierungstreibers fehlgeschlagen
Dieser Fehler tritt auf, wenn Ihre Aufgabe die CloudWatch Protokollgruppe, die Sie in der Aufgabendefinition definiert haben, nicht findet.
Der Fehler weist darauf hin, dass die CloudWatch Gruppe in der Aufgabendefinition nicht existiert.
Gehen Sie wie folgt vor, um das Fehlende zu finden CloudWatch.
1. Führen Sie den folgenden Befehl aus, um die Aufgabendefinition-Informationen abzurufen.
```
aws ecs describe-task-definition \
--task-definition task-def-name
```
Sehen Sie sich die Ausgabe für jeden Container an und notieren Sie sich den `awslogs-group`-Wert.
```
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/example-group",
"awslogs-create-group": "true",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
},
```
1. Vergewissern Sie sich, dass die Gruppe existiert. CloudWatch Weitere Informationen finden Sie unter [Arbeiten mit Protokollgruppen und Protokollströmen](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) im *Amazon CloudWatch Logs-Benutzerhandbuch*.
Das Problem besteht entweder darin, dass die in der Aufgabendefinition angegebene Gruppe falsch ist oder dass die Protokollgruppe nicht vorhanden ist.
1. Beheben Sie das Problem.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/resource-initialization-error.html)
## Fehler beim Aufrufen der EFS-Serviceprogrammbefehle zum Einrichten von EFS-Volumes
Die folgenden Probleme könnten Sie daran hindern, Ihre Amazon-EFS-Volumes auf Ihren Anfragen bereitzustellen:
+ Das Amazon-EFS-Dateisystem ist nicht korrekt konfiguriert.
+ Die Aufgabe verfügt nicht über die erforderlichen Berechtigungen.
+ Es bestehen Probleme im Zusammenhang mit Netzwerk- und VPC-Konfigurationen.
Informationen zum Debuggen und Beheben dieses Problems finden Sie unter [Warum kann ich meine Amazon EFS-Volumes nicht für meine AWS Fargate Aufgaben bereitstellen auf](https://repost.aws/knowledge-center/fargate-unable-to-mount-efs) AWS re:POST.
# Behebung von Amazon ResourceNotFoundException ECS-Fehlern
Im Folgenden finden Sie einige ` ResourceNotFoundException`-Fehlermeldungen und Maßnahmen, die Sie ergreifen können, um die Fehler zu beheben.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## Die Aufgabe kann das Geheimnis mit dem ARN '*sercretARN*' von nicht abrufen AWS Secrets Manager. Überprüfen Sie, ob das Geheimnis in der angegebenen Region vorhanden ist.
Dieser Fehler tritt auf, wenn die Aufgabe das Geheimnis nicht aus Secrets Manager abrufen kann. Das bedeutet, dass das in der Aufgabendefinition angegebene (und in der Fehlermeldung enthaltene) Geheimnis nicht in Secrets Manager vorhanden ist.
Die Region ist in der Fehlermeldung aufgeführt.
Beim Abrufen geheimer Daten aus AWS Secrets Manager der Region*region*: secret*sercretARN*: ResourceNotFoundException: Secrets Manager kann das angegebene Geheimnis nicht finden.
Weitere Informationen zum Suchen eines Geheimnisses finden Sie unter [Geheimnisse suchen in AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_search-secret.html) im *Benutzerhandbuch für AWS Secrets Manager *.
Bestimmen und beheben Sie den Fehler anhand der folgenden Tabelle.
| Problem | Aktionen |
| --- | --- |
| Das Geheimnis befindet sich in einer anderen Region als die Aufgabendefinition. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/resource-not-found-error.html) |
| Die Aufgabendefinition hat den falschen Geheimnis-ARN. Das richtige Geheimnis ist in Secrets Manager vorhanden. | Aktualisieren Sie die Aufgabendefinition mit dem richtigen Geheimnis. Weitere Informationen finden Sie unter [Aktualisieren einer Amazon-ECS-Aufgabendefinition mithilfe der Konsole](update-task-definition-console-v2.md) oder [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html)in der Amazon Elastic Container Service API-Referenz. |
| Das Geheimnis ist nicht mehr vorhanden. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/resource-not-found-error.html) |
# Behebung von Amazon SpotInterruption ECS-Fehlern
Der `SpotInterruption` Fehler hat unterschiedliche Gründe für Fargate und EC2s.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wird AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## Fargate
Der `SpotInterruption`-Fehler tritt auf, wenn keine Fargate-Spot-Kapazität vorhanden ist oder wenn Fargate Spot-Kapazität zurücknimmt.
Sie können Ihre Aufgaben in mehreren Availability Zones ausführen lassen, um mehr Kapazität zu ermöglichen.
## EC2
Dieser Fehler tritt auf, wenn keine Spot Instances verfügbar sind oder EC2 die Spot-Instance-Kapazität zurücknimmt.
Sie können Ihre Instances in mehreren Availability Zones ausführen lassen, um mehr Kapazität zu ermöglichen.
# Behebung von Amazon InternalError ECS-Fehlern
**Gilt für**: Fargate
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wird AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
Der `InternalError`-Fehler, wenn der Agent einen unerwarteten, nicht-laufzeitbezogenen internen Fehler findet.
Dieser Fehler tritt nur auf, wenn die Plattformversion `1.4` oder höher verwendet wird.
Informationen zum Debuggen und Beheben dieses Problems finden Sie unter [Aufgabe-Beendet-Fehlermeldungen in Amazon ECS](stopped-task-error-codes.md).
# Behebung von Amazon OutOfMemoryError ECS-Fehlern
Im Folgenden finden Sie einige OutOfMemoryError Fehlermeldungen und Maßnahmen, mit denen Sie die Fehler beheben können.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## Container aufgrund der Speichernutzung beendet
Dieser Fehler tritt auf, wenn ein Container aufgrund von Prozessen im Container beendet wird, die mehr Arbeitsspeicher belegen als in der Aufgabendefinition zugewiesen wurde, oder aufgrund von Beschränkungen des Hosts oder des Betriebssystems.
# Behebung von Amazon ContainerRuntimeError ECS-Fehlern
Im Folgenden finden Sie einige ContainerRuntimeError Fehlermeldungen und Maßnahmen, mit denen Sie die Fehler beheben können.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## ContainerRuntimeError
Dieser Fehler tritt auf, wenn der Agent einen unerwarteten Fehler von `containerd` für einen laufzeitspezifischen Vorgang erhält. Dieser Fehler wird normalerweise durch einen internen Fehler im Agent oder in der `containerd`-Laufzeitumgebung verursacht.
Dieser Fehler tritt nur auf, wenn Sie die Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` oder höher (Windows) verwenden.
Informationen zum Debuggen und Beheben dieses Problems finden Sie unter [Warum wurde meine Amazon ECS-Aufgabe auf AWS re:POST gestoppt](https://repost.aws/knowledge-center/ecs-task-stopped)?
# Behebung von Amazon ContainerRuntimeTimeoutError ECS-Fehlern
Im Folgenden finden Sie einige ContainerRuntimeTimeoutError Fehlermeldungen und Maßnahmen, mit denen Sie die Fehler beheben können.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## Es konnte nicht zur Ausführung übergegangen werden; Timeout nach 1 m Wartezeit oder Docker-Timeout-Fehler
Dieser Fehler tritt auf, wenn ein Container innerhalb des Timeout-Zeitraums weder in einen Status `RUNNING` oder `STOPPED` wechseln konnte. Der Grund und der Timeout-Wert werden in der Fehlermeldung angegeben.
# Behebung von Amazon CannotStartContainerError ECS-Fehlern
Im Folgenden finden Sie einige CannotStartContainerError Fehlermeldungen und Maßnahmen, mit denen Sie die Fehler beheben können.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## Der Container-Status konnte nicht abgerufen werden: **
Dieser Fehler tritt auf, wenn ein Container nicht gestartet werden kann.
Wenn Ihr Container versucht, den hier angegebenen Arbeitsspeicher zu überschreiten, wird der Container angehalten. Erhöhen Sie den Speicher, der dem Container bereitgestellt wird. Dies ist der `memory`-Parameter in der Aufgabendefinition. Weitere Informationen finden Sie unter [Arbeitsspeicher](task_definition_parameters.md#container_definition_memory).
# Behebung von Amazon CannotStopContainerError ECS-Fehlern
Im Folgenden finden Sie einige CannotStopContainerError Fehlermeldungen und Maßnahmen, mit denen Sie die Fehler beheben können.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## CannotStopContainerError
Dieser Fehler tritt auf, wenn ein Container nicht angehalten werden kann.
Informationen zum Debuggen und Beheben dieses Problems finden Sie unter [Warum wurde meine Amazon ECS-Aufgabe auf AWS re:POST gestoppt](https://repost.aws/knowledge-center/ecs-task-stopped)?
# Behebung von Amazon CannotInspectContainerError ECS-Fehlern
Im Folgenden finden Sie einige CannotInspectContainerError Fehlermeldungen und Maßnahmen, mit denen Sie die Fehler beheben können.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## CannotInspectContainerError
Dieser Fehler tritt auf, wenn der Container-Agent den Container nicht über die Containerlaufzeit beschreiben kann.
Bei Verwendung der Plattformversion `1.3` oder niedriger gibt der Amazon-ECS-Agent den Grund von Docker zurück.
Bei Verwendung der Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` oder höher (Windows) gibt der Fargate-Agent den Grund von `containerd` zurück.
Informationen zum Debuggen und Beheben dieses Problems finden Sie unter [Warum wurde meine Amazon ECS-Aufgabe auf AWS re:POST gestoppt](https://repost.aws/knowledge-center/ecs-task-stopped)?
# Behebung von Amazon CannotCreateVolumeError ECS-Fehlern
Im Folgenden finden Sie einige CannotCreateVolumeError Fehlermeldungen und Maßnahmen, mit denen Sie die Fehler beheben können.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wurde AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
## CannotCreateVolumeError
Dieser Fehler tritt auf, wenn der Agent die in der Aufgabendefinition angegeben Volume-Bereitstellung nicht erstellen kann.
Dieser Fehler tritt nur auf, wenn Sie die Plattformversion `1.4.0` oder höher (Linux) oder `1.0.0` oder höher (Windows) verwenden.
Informationen zum Debuggen und Beheben dieses Problems finden Sie unter [Warum wurde meine Amazon ECS-Aufgabe auf AWS re:POST gestoppt](https://repost.aws/knowledge-center/ecs-task-stopped)?
# CannotPullContainer Aufgabenfehler in Amazon ECS
Die folgenden Fehler weisen darauf hin, dass die Aufgabe nicht gestartet werden konnte, weil Amazon ECS das angegebene Container-Image nicht abrufen kann.
**Anmerkung**
Die 1.4 Fargate Plattformversion schneidet lange Fehlermeldungen ab.
Informationen dazu, wie Sie mithilfe von überprüfen können, ob bei Ihren gestoppten Aufgaben eine Fehlermeldung angezeigt wird AWS-Managementkonsole, finden Sie unter[Aufgabe-Beendet-Fehler in Amazon ECS anzeigen](stopped-task-errors.md).
**Tipp**
Sie können das [Amazon ECS MCP-Server](ecs-mcp-introduction.md) mit KI-Assistenten verwenden, um Fehler beim Abrufen von Bildern mithilfe natürlicher Sprache zu untersuchen.
**Topics**
+ [Die Aufgabe kann das Image nicht abrufen. Vergewissern Sie sich, dass die Rolle berechtigt ist, Images aus der Registry abzurufen.](#pull-request-image-not-found)
+ [Die Aufgabe kann '*image-name*' nicht aus dem Amazon ECR-Repository '*repository URI*' abrufen. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon ECR. Überprüfen Sie die Netzwerkkonfiguration der Aufgabe.](#pull-image-io-timeout)
+ [Die Aufgabe kann das Image nicht abrufen. Überprüfen Sie die Netzwerkkonfiguration](#pull-request-image-not-found-network)
+ [CannotPullContainerError: Das Pull-Image-Manifest wurde 5 Mal wiederholt: Referenz konnte nicht aufgelöst werden](#pull-request-image-tag)
+ [API-Fehler (500): Get: net/http https://111122223333.dkr.ecr.us-east-1.amazonaws.com/v2/: Anfrage wurde abgebrochen, während auf eine Verbindung gewartet wurde](#request-canceled)
+ [API-Fehler](#pull-request-api-error)
+ [write/var/lib/docker/tmp/*GetImageBlob111111111*: kein Platz mehr auf dem Gerät](#pull-request-write-error)
+ [ERROR: toomanyrequests: Zu viele Anfragen oder Sie haben Ihr Abruf-Limit erreicht.](#container-pull-too-many-requests)
+ [Fehlerantwort vom Daemon: Get: net/http*url*: Anfrage wurde abgebrochen, während auf eine Verbindung gewartet wurde](#container-pull-request-canceled-connection)
+ [ref pull wurde 1 mal wiederholt: konnte nicht kopiert werden:: Fehler beim Öffnen httpReaderSeeker: unerwarteter Statuscode](#container-pull-failed-open)
+ [Abruf-Zugriff verweigert](#container-pull-access-denied.title)
+ [Pull-Befehl fehlgeschlagen: Panik: Laufzeitfehler: Ungültige Speicheradresse oder Nullzeiger-Derefenzierung](#container-pull-runtime-error.title)
+ [Fehler beim Abrufen des Bilds beim conf/error Abrufen der Bildkonfiguration](#container-pull-pulling-image.title)
+ [Kontext abgebrochen](#container-pull-context-canceled)
## Die Aufgabe kann das Image nicht abrufen. Vergewissern Sie sich, dass die Rolle berechtigt ist, Images aus der Registry abzurufen.
Dieser Fehler weist darauf hin, dass die Aufgabe das in der Aufgabendefinition angegebene Image aufgrund von Berechtigungsproblemen nicht abrufen kann.
So beheben Sie dieses Problem
1. Überprüfen Sie, ob das Bild in der vorhanden ist*repository*. Informationen zum Anzeigen Ihrer Images finden Sie unter [Image-Details in Amazon ECR anzeigen](https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-info.html) im *Benutzerhandbuch für Amazon Elastic Container Registry*.
1. Stellen Sie sicher, dass der *role-arn* über die richtigen Berechtigungen zum Abrufen des Images verfügt.
Informationen zum Aktualisieren von Rollen finden Sie unter [Aktualisieren von Berechtigungen für eine Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) im *Benutzerhandbuch für AWS Identity and Access Management *.
Die Aufgabe verwendet eine der folgenden Rollen:
+ Für Aufgaben mit Fargate ist dies die Aufgabenausführungsrolle. Weitere Informationen zum Arbeiten mit zusätzlichen Berechtigungen für Amazon ECR finden Sie unter [Berechtigungen für Fargate-Aufgaben, Amazon-ECR-Images über Schnittstellen-Endpunkte abzurufen](task_execution_IAM_role.md#task-execution-ecr-conditionkeys).
+ Für Aufgaben mit EC2 ist dies die Container-Instance-Rolle. Weitere Informationen zum Arbeiten mit zusätzlichen Berechtigungen für Amazon ECR finden Sie unter [Amazon-ECR-Berechtigungen](instance_IAM_role.md#container-instance-role-ecr).
## Die Aufgabe kann '*image-name*' nicht aus dem Amazon ECR-Repository '*repository URI*' abrufen. Es besteht ein Verbindungsproblem zwischen der Aufgabe und Amazon ECR. Überprüfen Sie die Netzwerkkonfiguration der Aufgabe.
Dieser Fehler weist darauf hin, dass die Aufgabe keine Verbindung zu Amazon ECR herstellen kann. Überprüfen Sie die Verbindung zum *repository URI* Repository.
Weitere Informationen zum Verifizieren und Beheben dieser Probleme finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## Die Aufgabe kann das Image nicht abrufen. Überprüfen Sie die Netzwerkkonfiguration
Dieser Fehler weist darauf hin, dass die Aufgabe keine Verbindung zu Amazon ECR herstellen kann.
Weitere Informationen zum Verifizieren und Beheben dieser Probleme finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## CannotPullContainerError: Das Pull-Image-Manifest wurde 5 Mal wiederholt: Referenz konnte nicht aufgelöst werden
Dieser Fehler weist darauf hin, dass die Aufgabe das Image nicht abrufen kann.
Um dieses Problem zu lösen, können Sie Folgendes unternehmen:
+ Stellen Sie sicher, dass das in der Aufgabendefinition angegeben Image mit dem Image im Repository übereinstimmt.
+ Amazon ECS erzwingt die Stabilität der Image-Version. Wenn das Original-Image nicht mehr verfügbar ist, erhalten Sie diesen Fehler. Das Image-Tag ist Teil der Durchsetzung dieses Verhaltens. Ändern Sie das Image in der Aufgabendefinition von der Verwendung von :latest als Tag zu einer bestimmten Version. Weitere Informationen finden Sie unter [Container-Image-Auflösung](deployment-type-ecs.md#deployment-container-image-stability).
Weitere Informationen zum Verifizieren und Beheben dieser Probleme finden Sie unter [Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat](verify-connectivity.md).
## API-Fehler (500): Get: net/http https://111122223333.dkr.ecr.us-east-1.amazonaws.com/v2/: Anfrage wurde abgebrochen, während auf eine Verbindung gewartet wurde
Dieser Fehler weist darauf hin, dass das Timeout für eine Verbindung überschritten wurde, weil keine Route zum Internet existiert.
Um dieses Problem zu lösen, können Sie:
+ Für Aufgabe in öffentlichen Subnetzen geben Sie beim Starten der Aufgabe **ENABLED** unter **Auto-assign public IP** (Öffentliche IP automatisch zuweisen) an. Weitere Informationen finden Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md).
+ Für Aufgaben in privaten Subnetzen geben Sie beim Starten der Aufgabe **DISABLED (DEAKTIVIERT)** für **Auto-assign public IP (Öffentliche IP automatisch zuweisen)** an und konfigurieren ein NAT-Gateway in Ihrer VPC, um Anforderungen an das Internet weiterzuleiten. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Amazon VPC-Benutzerhandbuch*.
## API-Fehler
Diese Fehlermeldung weist auf ein Verbindungsproblem mit dem Amazon-ECR-Endpunkt hin.
Informationen zur Behebung dieses Problems finden Sie auf der Support Website unter [How can I resolve the Amazon ECR error "CannotPullContainerError: API error“ in Amazon ECS](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-pull-container-api-error-ecr/).
## write/var/lib/docker/tmp/*GetImageBlob111111111*: kein Platz mehr auf dem Gerät
Dieser Fehler weist darauf hin, dass nicht genügend Speicherplatz vorhanden ist.
Um dieses Problem zu lösen, müssen Sie Speicherplatz freigeben.
Wenn Sie das Amazon-ECS-optimierte AMI verwenden, können Sie mit dem folgenden Befehl die 20 größten Dateien auf Ihrem Dateisystem abrufen:
```
du -Sh / | sort -rh | head -20
```
Beispielausgabe:
```
5.7G /var/lib/docker/containers/50501b5f4cbf90b406e0ca60bf4e6d4ec8f773a6c1d2b451ed8e0195418ad0d2
1.2G /var/log/ecs
594M /var/lib/docker/devicemapper/mnt/c8e3010e36ce4c089bf286a623699f5233097ca126ebd5a700af023a5127633d/rootfs/data/logs
...
```
In manchen Fällen kann das Stamm-Volume von einem ausgeführten Container ausgefüllt sein. Wenn der Container den Standardprotokolltreiber `json-file` ohne eine `max-size`-Beschränkung verwendet, kann die Protokolldatei einen Großteil des Speicherplatzes belegen. Mit dem Befehl `docker ps` können Sie überprüfen, welcher Container den Speicherplatz belegt. Hierzu wird der Verzeichnisname aus der Ausgabe oben der Container-ID zugewiesen. Zum Beispiel:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
50501b5f4cbf amazon/amazon-ecs-agent:latest "/agent" 4 days ago Up 4 days ecs-agent
```
Bei Verwendung des Protokolltreibers `json-file` erfasst Docker standardmäßig die Standardausgabe (und Standardfehler) aller Container und schreibt diese in Dateien im JSON-Format. Sie können `max-size` als Protokolltreiberoption festlegen, was vermeidet, dass die Protokolldatei zu groß wird. Weitere Informationen finden Sie unter [JSON-Protokollierungstreiber](https://docs.docker.com/engine/logging/drivers/json-file/) in der Docker-Dokumentation.
Nachfolgend finden Sie einen Ausschnitt aus einer Containerdefinition mit dieser Option:
```
{
"log-driver": "json-file",
"log-opts": {
"max-size": "256m"
}
}
```
Wenn Ihre Container-Protokolle zu viel Speicherplatz belegen, können Sie alternativ auch den Protokolltreiber `awslogs` verwenden. Der `awslogs` Protokolltreiber sendet die Protokolle an CloudWatch, wodurch Speicherplatz frei wird, der sonst für Ihre Container-Logs auf der Container-Instance verwendet werden würde. Weitere Informationen finden Sie unter [Amazon ECS-Protokolle senden an CloudWatch](using_awslogs.md).
Möglicherweise müssen Sie die Festplattengröße aktualisieren, auf die Docker zugreifen kann.
Weitere Informationen finden Sie unter [CannotPullContainerError: Kein Speicherplatz mehr auf dem Gerät](https://repost.aws/questions/QUx6Ix1R1SSNisYSs1Sw8EBA/cannotpullcontainererror-no-space-left-on-device).
## ERROR: toomanyrequests: Zu viele Anfragen oder Sie haben Ihr Abruf-Limit erreicht.
Diese Fehlermeldung weist auf eine Docker-Hub-Ratenbegrenzung hin.
Wenn eine der folgenden Fehlermeldungen angezeigt wird, treffen Sie wahrscheinlich die Tarifbeschränkungen des Docker-Hubs:
Weitere Informationen über die Docker-Hub-Ratenlimits finden Sie unter [Grundlegendes zur Begrenzung der Docker-Hub-Rate](https://www.docker.com/increase-rate-limits).
Wenn Sie das Docker-Hub-Ratenlimit erhöht haben und Sie Ihre Docker-Pulls für Ihre Container-Instances authentifizieren müssen, finden Sie weitere Informationen unter [Private-Registry-Authentifizierung für Container-Instances](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/private-auth-container-instances.html).
## Fehlerantwort vom Daemon: Get: net/http*url*: Anfrage wurde abgebrochen, während auf eine Verbindung gewartet wurde
Dieser Fehler weist darauf hin, dass das Timeout für eine Verbindung überschritten wurde, weil keine Route zum Internet existiert.
Um dieses Problem zu lösen, können Sie:
+ Für Aufgabe in öffentlichen Subnetzen geben Sie beim Starten der Aufgabe **ENABLED** unter **Auto-assign public IP** (Öffentliche IP automatisch zuweisen) an. Weitere Informationen finden Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md).
+ Für Aufgaben in privaten Subnetzen geben Sie beim Starten der Aufgabe **DISABLED (DEAKTIVIERT)** für **Auto-assign public IP (Öffentliche IP automatisch zuweisen)** an und konfigurieren ein NAT-Gateway in Ihrer VPC, um Anforderungen an das Internet weiterzuleiten. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Amazon VPC-Benutzerhandbuch*.
## ref pull wurde 1 mal wiederholt: konnte nicht kopiert werden:: Fehler beim Öffnen httpReaderSeeker: unerwarteter Statuscode
Diese Fehlermeldung weist auf einen Fehler beim Kopieren eines Images hin.
Lesen Sie die folgenden Berichte, um dieses Problem zu beheben:
+ Informationen zu Fargate-Aufgaben finden Sie unter [Wie löse ich den Fehler „cannotpullcontainererror“ für meine Amazon-ECS-Aufgaben auf Fargate](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-fargate-pull-container-error/).
+ Für andere Aufgaben, siehe [Wie löse ich den Fehler „cannotpullcontainererror“ für meine Amazon-ECS-Aufgaben](https://aws.amazon.com/premiumsupport/knowledge-center/ecs-pull-container-error/).
## Abruf-Zugriff verweigert
Diese Fehlermeldung weist darauf hin, dass kein Zugriff für das Image besteht.
Um dieses Problem zu beheben, müssen Sie möglicherweise Ihren Docker-Client mit Amazon ECR authentifizieren. Weitere Informationen finden Sie unter [Private-Registry-Authentifizierung](https://docs.aws.amazon.com/AmazonECR/latest/userguide/registry_auth.html) im *Amazon-ECR-Benutzerhandbuch*.
## Pull-Befehl fehlgeschlagen: Panik: Laufzeitfehler: Ungültige Speicheradresse oder Nullzeiger-Derefenzierung
Dieser Fehler weist darauf hin, dass aufgrund einer ungültigen Speicheradresse oder einer Nullzeiger-Dereferenzierung kein Zugriff auf das Image möglich ist.
So beheben Sie dieses Problem
+ Vergewissern Sie sich, dass Sie über die Sicherheitsgruppenregeln verfügen, um Amazon S3 zu erreichen.
+ Wenn Sie Gateway-Endpunkte verwenden, müssen Sie in der Routing-Tabelle eine Route hinzufügen, um auf den Endpunkt zuzugreifen.
## Fehler beim Abrufen des Bilds beim conf/error Abrufen der Bildkonfiguration
Dieser Fehler weist darauf hin, dass ein Ratenlimit erreicht wurde oder dass ein Netzwerkfehler vorliegt:
Informationen zur Behebung dieses Problems finden Sie unter [Wie kann ich den Fehler "CannotPullContainerError" in meiner Amazon ECS EC2 Launch Type Task beheben](https://repost.aws/knowledge-center/ecs-pull-container-error)?
## Kontext abgebrochen
Dieser Fehler weist darauf hin, dass der Kontext abgebrochen wurde.
Die häufige Ursache für diesen Fehler liegt darin, dass die von Ihrer Aufgabe verwendete VPC über keine Route zum Abrufen des Container-Images von Amazon ECR verfügt.
# Überprüfung, ob Amazon ECS die Aufgabenkonnektivität beendet hat
Es kann vorkommen, dass eine Aufgabe aufgrund eines Problems mit der Netzwerkverbindung beendet wird. Möglicherweise handelt es sich um ein zeitweiliges Problem, das jedoch höchstwahrscheinlich dadurch verursacht wird, dass die Aufgabe keine Verbindung zu einem Endpunkt herstellen kann.
## Testen der Aufgabenkonnektivität
Sie können das Runbook `AWSSupport-TroubleshootECSTaskFailedToStart` verwenden, um die Aufgabenkonnektivität zu testen. Wenn Sie das Runbook verwenden, benötigen Sie die folgenden Ressourceninformationen:
+ Die ID der Aufgabe
Verwenden Sie die ID der letzten fehlgeschlagenen Aufgabe.
+ Der Cluster, in dem sich die Aufgabe befand
Informationen zur Verwendung des Runbooks finden Sie unter [https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshootecstaskfailedtostart.html](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshootecstaskfailedtostart.html) in der *Referenz zum AWS Systems Manager -Automatisierungs-Runbook*.
Das Runbook analysiert die Aufgabe. Sie können sich die Ergebnisse der folgenden Probleme, die das Starten einer Aufgabe verhindern können, im Abschnitt **Ausgabe** anzeigen lassen:
+ Netzwerkkonnektivität zur konfigurierten Container-Registry
+ Konnektivität des VPC-Endpunkts
+ Konfiguration der Sicherheitsgruppenregel
## Behebung von Problemen mit VPC-Endpunkten
Wenn das Ergebnis des Runbook `AWSSupport-TroubleshootECSTaskFailedToStart` auf ein Problem mit dem VPC-Endpunkt hinweist, überprüfen Sie die folgende Konfiguration:
+ Die VPC, auf der Sie den Endpunkt erstellen, und der VPC-Endpunkt müssen Private DNS verwenden.
+ Stellen Sie sicher, dass Sie in derselben VPC wie die Aufgabe einen AWS PrivateLink Endpunkt für den Service haben, zu dem die Aufgabe keine Verbindung herstellen kann. Weitere Informationen finden Sie unter einem der folgenden Themen:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Konfigurieren Sie eine ausgehende Regel für das Aufgaben-Subnetz, die HTTPS auf Port 443 DNS (TCP)-Datenverkehr zulässt. Weitere Informationen finden Sie unter [Sicherheitsgruppenregeln konfigurieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules) im *Benutzerhandbuch für Amazon Elastic Compute Cloud*.
+ Wenn Sie einen Domain-Server mit benutzerdefiniertem Namen verwenden, bestätigen Sie die Einstellungen der DNS-Abfrage. Die Abfrage muss ausgehenden Zugriff auf Port 53 haben und das UDP- und TCP-Protokoll verwenden. Außerdem muss sie über HTTPS-Zugriff auf Port 443 verfügen. Weitere Informationen finden Sie unter [Sicherheitsgruppenregeln konfigurieren](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/changing-security-group.html#add-remove-security-group-rules) im *Benutzerhandbuch für Amazon Elastic Compute Cloud*.
+ Wenn das Subnetz über eine Netzwerk-ACL verfügt, sind die folgenden ACL-Regeln erforderlich:
+ Eine ausgehende Regel, die Datenverkehr auf den Ports 1 024–65 535 zulässt.
+ Eine Regel, die TCP-Datenverkehr auf Port 443 zulässt.
Informationen zur Konfiguration von Regeln finden Sie unter [Steuern des Datenverkehrs zu Subnetzen mithilfe des Netzwerks ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*.
## Beheben von Netzwerkproblemen
Wenn das Ergebnis des Runbook `AWSSupport-TroubleshootECSTaskFailedToStart` auf ein Netzwerkproblem hinweist, überprüfen Sie die folgende Konfiguration:
### Aufgaben, die den awsvpc-Netzwerkmodus in einem öffentlichen Subnetz verwenden
Führen Sie die folgende Konfiguration auf der Grundlage des Runbooks durch:
+ Für Aufgabe in öffentlichen Subnetzen geben Sie beim Starten der Aufgabe **ENABLED** unter **Auto-assign public IP** (Öffentliche IP automatisch zuweisen) an. Weitere Informationen finden Sie unter [Ausführen einer Anwendung als Amazon-ECS-Aufgabe](standalone-task-create.md).
+ Sie benötigen ein Gateway, um den Internetverkehr abzuwickeln. Die Routing-Tabelle für das Task-Subnetz muss eine Route für den Verkehr zum Gateway enthalten.
Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von Routen aus einer Routing-Tabelle](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) im *Benutzerhandbuch für Amazon Virtual Private Cloud*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Wenn das Aufgaben-Subnetz über eine Netzwerk-ACL verfügt, sind die folgenden ACL-Regeln erforderlich:
+ Eine ausgehende Regel, die Datenverkehr auf den Ports 1 024–65 535 zulässt.
+ Eine Regel, die TCP-Datenverkehr auf Port 443 zulässt.
Informationen zur Konfiguration von Regeln finden Sie unter [Steuern des Datenverkehrs zu Subnetzen mithilfe des Netzwerks ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*.
### Aufgaben, die den awsvpc-Netzwerkmodus in einem privaten Subnetz verwenden
Führen Sie die folgende Konfiguration auf der Grundlage des Runbooks durch:
+ Wählen Sie **DISABLED** für **Öffentliche IP automatisch zuweisen**, wenn Sie die Aufgabe starten.
+ Konfigurieren Sie ein NAT-Gateway in Ihrer VPC, um Anfragen an das Internet weiterzuleiten. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Benutzerhandbuch für Amazon Virtual Private Cloud*.
+ Die Routing-Tabelle für das Aufgaben-Subnetz muss eine Route für den Datenverkehr zum Gateway enthalten.
Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von Routen aus einer Routing-Tabelle](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) im *Benutzerhandbuch für Amazon Virtual Private Cloud*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Wenn das Aufgaben-Subnetz über eine Netzwerk-ACL verfügt, sind die folgenden ACL-Regeln erforderlich:
+ Eine ausgehende Regel, die Datenverkehr auf den Ports 1 024–65 535 zulässt.
+ Eine Regel, die TCP-Datenverkehr auf Port 443 zulässt.
Informationen zur Konfiguration von Regeln finden Sie unter [Steuern des Datenverkehrs zu Subnetzen mithilfe des Netzwerks ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*.
### Aufgaben, die nicht den awsvpc-Netzwerkmodus in einem öffentlichen Subnetz verwenden
Führen Sie die folgende Konfiguration auf der Grundlage des Runbooks durch:
+ Wählen Sie bei der Erstellung des Clusters für **automatische IP-Zuweisung** unter **Netzwerk für Amazon-EC2-Instances** die Option **Einschalten** .
Diese Option weist der primären Netzwerkschnittstelle der Instance eine öffentliche IP-Adresse zu.
+ Sie benötigen ein Gateway, um den Internetverkehr abzuwickeln. Die Routing-Tabelle für das Instance-Subnetz muss eine Route für den Verkehr zum Gateway enthalten.
Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von Routen aus einer Routing-Tabelle](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) im *Benutzerhandbuch für Amazon Virtual Private Cloud*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Wenn das Instance-Subnetz über eine Netzwerk-ACL verfügt, sind die folgenden ACL-Regeln erforderlich:
+ Eine ausgehende Regel, die Datenverkehr auf den Ports 1 024–65 535 zulässt.
+ Eine Regel, die TCP-Datenverkehr auf Port 443 zulässt.
Informationen zur Konfiguration von Regeln finden Sie unter [Steuern des Datenverkehrs zu Subnetzen mithilfe des Netzwerks ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*.
### Aufgaben, die nicht den awsvpc-Netzwerkmodus in einem privaten Subnetz verwenden
Führen Sie die folgende Konfiguration auf der Grundlage des Runbooks durch:
+ Wählen Sie bei der Erstellung des Clusters für **Automatische IP-Zuweisung** unter **Netzwerk für Amazon-EC2-Instances** die Option **Ausschalten**.
+ Konfigurieren Sie ein NAT-Gateway in Ihrer VPC, um Anfragen an das Internet weiterzuleiten. Weitere Informationen finden Sie unter [NAT-Gateways](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) im *Amazon VPC-Benutzerhandbuch*.
+ Die Routing-Tabelle für das Instance-Subnetz muss eine Route für den Datenverkehr zum NAT-Gateway enthalten.
Weitere Informationen finden Sie unter [Hinzufügen und Entfernen von Routen aus einer Routing-Tabelle](https://docs.aws.amazon.com/vpc/latest/userguide/WorkWithRouteTables.html#AddRemoveRoutes) im *Benutzerhandbuch für Amazon Virtual Private Cloud*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/verify-connectivity.html)
+ Wenn das Aufgaben-Subnetz über eine Netzwerk-ACL verfügt, sind die folgenden ACL-Regeln erforderlich:
+ Eine ausgehende Regel, die Datenverkehr auf den Ports 1 024–65 535 zulässt.
+ Eine Regel, die TCP-Datenverkehr auf Port 443 zulässt.
Informationen zur Konfiguration von Regeln finden Sie unter [Steuern des Datenverkehrs zu Subnetzen mithilfe des Netzwerks ACLs](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html) im *Amazon Virtual Private Cloud Cloud-Benutzerhandbuch*.
# IAM-Rollenanfragen für Amazon-ECS-Aufgaben anzeigen
Wenn Sie einen Anbieter für Ihre Aufgabenanmeldeinformationen in einer IAM-Rolle verwenden, werden die Anbieteranfragen in einem Auditprotokoll gespeichert. Das Überwachungsprotokoll übernimmt dieselben Protokollrotationseinstellungen wie das Container-Agent-Protokoll. Die Konfigurationsvariablen `ECS_LOG_ROLLOVER_TYPE`, `ECS_LOG_MAX_FILE_SIZE_MB` und `ECS_LOG_MAX_ROLL_COUNT` des Container-Agenten können so eingestellt werden, dass sie das Verhalten des Überwachungsprotokolls beeinflussen. Weitere Informationen finden Sie unter [Protokoll-Konfigurationsparameter für den Amazon-ECS-Container-Agenten](ecs-agent-versions.md#agent-logs).
Für Container-Agent Version 1.36.0 und höher befindet sich das Überwachungsprotokoll unter `/var/log/ecs/audit.log`. Wenn das Protokoll rotiert wird, wird am Ende des Protokolldateinamens ein Zeitstempel im `YYYY-MM-DD-HH`-Format hinzugefügt.
Für Container-Agent Version 1.35.0 und früher befindet sich das Überwachungsprotokoll unter `/var/log/ecs/audit.log.YYYY-MM-DD-HH`.
Das Format des Protokolleintrags ist wie folgt:
+ Zeitstempel
+ HTTP-Antwortcode
+ IP-Adresse und Portnummer von Abfrageursprung
+ Relative URI des Anmeldeinformationsanbieters
+ Der Benutzeragent, der die Abfrage gesendet hat
+ Der ARN der Aufgabe, zu dem der abfragende Container gehört
+ Der `GetCredentials`-API-Name und Versionsnummer
+ Der Name des Amazon-ECS-Clusters, für den die Container-Instance registriert ist
+ Der ARN der Container-Instance
Sie können den folgenden Befehl verwenden, um die Protokolldateien anzuzeigen.
```
cat /var/log/ecs/audit.log.2016-07-13-16
```
Ausgabe:
```
2016-07-13T16:11:53Z 200 172.17.0.5:52444 "/v1/credentials" "python-requests/2.7.0 CPython/2.7.6 Linux/4.4.14-24.50.amzn1.x86_64" TASK_ARN GetCredentials 1 CLUSTER_NAME CONTAINER_INSTANCE_ARN
```
# Anzeigen von Service-Ereignismeldungen von Amazon ECS
Wenn Sie ein Problem mit einem Service beheben möchten, sollten Sie zuerst im Service-Ereignisprotokoll nach Diagnoseinformationen suchen. Sie können Serviceereignisse mithilfe der `DescribeServices` API AWS CLI, der oder mithilfe von anzeigen. AWS-Managementkonsole
Beim Anzeigen von Service-Ereignismeldungen mit der Amazon-ECS-API werden nur die Ereignisse aus dem Service-Scheduler zurückgegeben. Dazu gehören die aktuellste Aufgabenplatzierung und Instance-Integritätsereignisse. Die Amazon-ECS-Konsole zeigt jedoch Service-Ereignisse aus den folgenden Quellen an.
+ Aufgabenplatzierung und Instance-Integritätsereignisse aus dem Amazon-ECS-Service-Scheduler. Diese Ereignisse haben das Präfix **Service *(service-name)***. Um sicherzustellen, dass diese Event-Ansicht hilfreich ist, zeigen wir nur die `100` neuesten Ereignisse an. Doppelte Service-Ereignismeldungen werden ausgelassen, bis entweder die Ursache beseitigt ist oder sechs Stunden vergangen sind. Wenn die Ursache nicht innerhalb von sechs Stunden behoben wird, erhalten Sie eine weitere Meldung über ein Service-Ereignis für diese Ursache.
+ Service Auto Scaling-Events. Diese Ereignisse haben ein Präfix von **Message** und treten nur auf, wenn ein Service mit einer Skalierungsrichtlinie für Application Auto Scaling konfiguriert ist.
**Tipp**
Sie können das [Amazon ECS MCP-Server](ecs-mcp-introduction.md) zusammen mit KI-Assistenten verwenden, um Serviceereignisse in natürlicher Sprache zu analysieren.
Gehen Sie wie folgt vor, um Ihre aktuellen Service-Ereignismeldungen anzuzeigen.
------
#### [ Console ]
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie den zu untersuchenden Service aus.
1. Sehen Sie sich die Nachrichten auf der Registerkarte **Ereignisse** an.
------
#### [ AWS CLI ]
Verwenden Sie den Befehl [describe-services](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-services.html), um die Serviceereignismeldungen für einen angegebenen Service anzuzeigen.
Im folgenden AWS CLI Beispiel wird der *service-name* Dienst im *default* Cluster beschrieben, der die neuesten Dienstereignismeldungen bereitstellt.
```
aws ecs describe-services \
--cluster default \
--services service-name \
--region us-west-2
```
------
# Service-Ereignismeldungen in Amazon ECS
Im Folgenden finden Sie Beispiele für Service-Ereignismeldungen, die in der Amazon-ECS-Konsole angezeigt werden können:
## service (*service-name*) hat einen stabilen Zustand erreicht.
Der Service Scheduler sendet ein `service (service-name) has reached a steady state.`-Service-Ereignis, wenn der Service fehlerfrei ist und die gewünschte Anzahl von Aufgaben hat, und erreicht so einen konstanten Status.
Der Service-Scheduler meldet den Status regelmäßig, sodass Sie diese Nachricht möglicherweise mehrmals erhalten.
## service (*service-name*) konnte eine Aufgabe nicht platzieren, da keine Container-Instance alle ihre Anforderungen erfüllte.
Der Service Scheduler sendet diese Ereignismeldung, wenn er die verfügbaren Ressourcen zum Hinzufügen einer weiteren Aufgabe nicht finden konnte. Mögliche Ursachen dafür sind:
Verwenden Sie Kapazitätsanbieter, um Ihre EC2-Instances automatisch zu skalieren. Weitere Informationen finden Sie unter [Amazon-ECS-Kapazitätsanbieter für EC2-Workloads](asg-capacity-providers.md).
Wenn Sie beabsichtigen, einen Kapazitätsanbieter zu verwenden, stellen Sie sicher, dass Sie entweder eine Kapazitätsanbieter-Strategie übergeben oder Ihrem Cluster eine Standardstrategie für Kapazitätsanbieter zugeordnet haben und dass Starttyp und Kapazitätsanbieter-Strategie nicht als Eingabe übergeben werden.
Es wurden keine Container-Instances in Ihrem Cluster gefunden
Wenn keine Container-Instances in dem Cluster registriert sind, in dem Sie versucht haben, eine Aufgabe auszuführen, erhalten Sie diese Fehlermeldung. Sie sollten Ihrem Cluster Container-Instances hinzufügen. Weitere Informationen finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
Nicht genügend Ports
Wenn Ihre Aufgabe feste Host-Port-Zuweisung verwendet (wenn zum Beispiel Ihre Aufgabe Port 80 auf dem Host für einen Webserver verwendet), brauchen Sie mindestens eine Container-Instance pro Aufgabe, weil nur ein Container einen einzelnen Host-Port auf einmal verwenden kann. Sie sollten Ihrem Cluster Container-Instances hinzufügen oder die Anzahl gewünschter Aufgaben reduzieren.
Registrierung einer zu großen Zahl von Ports
Die am besten übereinstimmende Container-Instance für die Aufgabenplatzierung darf die maximal zulässige Anzahl reservierter Ports von 100 Host-Ports pro Container-Instance nicht überschreiten. Ein dynamisches Host-Port-Mapping behebt das Problem möglicherweise.
Port wird bereits verwendet
Die Aufgabendefinition dieser Aufgabe verwendet denselben Port in ihrer Port-Zuordnung als eine Aufgabe, die bereits auf der ausgewählten Container-Instance ausgeführt wird. Die Serviceereignis-Nachricht hätte die gewählte Container-Instance-ID als Teil der folgenden Nachricht.
```
The closest matching container-instance is already using a port required by your task.
```
Speicher reicht nicht aus
Wenn Ihre Aufgabendefinition 1000 MiB Speicher angibt und jede Container-Instance in Ihrem Cluster 1024 MiB Speicher hat, können Sie nur eine Kopie dieser Aufgabe pro Container-Instance ausführen. Sie können mit weniger Speicher in Ihrer Aufgabendefinition experimentieren, sodass Sie mehr als eine Aufgabe pro Container-Instance oder mehr Container-Instances in Ihrem Cluster starten können.
Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen, lesen Sie nach unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
CPU reicht nicht aus
Eine Container-Instance hat 1 024 CPU-Einheiten für jeden CPU-Kern. Wenn Ihre Aufgabendefinition 1.000 CPU-Einheiten angibt und jede Container-Instance in Ihrem Cluster 1 024 CPU-Einheiten hat, können Sie nur eine Kopie dieser Aufgabe pro Container-Instance ausführen. Sie können mit weniger CPU-Einheiten in Ihrer Aufgabendefinition experimentieren, sodass Sie mehr als eine Aufgabe pro Container-Instance oder mehr Container-Instances in Ihrem Cluster starten können.
Nicht genügend verfügbare ENI-Befestigungspunkte
Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, erhalten ihre eigene Elastic-Network-Schnittstelle (ENI), die an die Container-Instance angehängt wird, die sie hostet. Die Anzahl der Amazon EC2 EC2-Instances, die an sie angehängt werden können ENIs , ist begrenzt, und es gibt keine Container-Instances im Cluster, für die ENI-Kapazität verfügbar ist.
Das ENI-Limit für einzelne Container-Instances hängt von den folgenden Bedingungen ab:
+ Wenn Sie sich **nicht** für die `awsvpcTrunking`-Kontoeinstellung angemeldet haben, hängt das ENI-Limit für jede Container-Instance vom Instance-Typ ab. Weitere Informationen finden Sie unter [IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) im *Amazon EC2-Benutzerhandbuch*.
+ Wenn Sie sich für die `awsvpcTrunking`-Kontoeinstellung angemeldet **haben**, Sie aber nach der Anmeldung **keine** neuen Container-Instances unter Verwendung eines unterstützten Instance-Typs gestartet haben, wird das ENI-Limit für jede Container-Instance weiterhin auf dem Standardwert liegen. Weitere Informationen finden Sie unter [IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) im *Amazon EC2-Benutzerhandbuch*.
+ Wenn Sie sich für die `awsvpcTrunking` Kontoeinstellungen entschieden **haben** **und nach der Anmeldung neue Container-Instances mit einem unterstützten Instance-Typ gestartet haben**, ENIs sind weitere verfügbar. Weitere Informationen finden Sie unter [Unterstützte Instances für mehr Amazon-ECS-Container-Netzwerkschnittstellen](eni-trunking-supported-instance-types.md).
Weitere Informationen zum Aktivieren der `awsvpcTrunking`-Kontoeinstellung finden Sie unter [Erhöhung der Netzwerkschnittstellen für Linux-Container-Instances von Amazon ECS](container-instance-eni.md).
Sie können Ihrem Cluster Container-Instances hinzufügen, um weitere Netzwerkadapter zur Verfügung zu stellen.
Container-Instance fehlt erforderliches Attribut
Einige Aufgabendefinitionsparameter erfordern, dass eine bestimmte Docker-Remote-API-Version auf der Container-Instance installiert wird. Andere, wie die Optionen für Protokolltreiber, erfordern, dass die Container-Instances diese Protokolltreiber bei der Variablen zur Konfiguration des Agenten `ECS_AVAILABLE_LOGGING_DRIVERS` registrieren. Wenn Ihre Aufgabendefinition einen Parameter enthält, der ein bestimmtes Container-Instance-Attribut erfordert, und Sie keine Container-Instances zur Verfügung haben, die diese Anforderung erfüllen können, kann die Aufgabe nicht platziert werden.
Eine häufige Ursache für diesen Fehler ist, dass Ihr Service Aufgaben verwendet, die den `awsvpc`-Netzwerkmodus und EC2 verwenden. Für den angegebenen Cluster ist keine Container-Instance in demselben Subnetz registriert, das bei der Erstellung des Service in `awsvpcConfiguration` angegeben wurde.
Sie können das AWSSupport-TroubleshootECSContainerInstance Runbook zur Fehlerbehebung verwenden. Das Runbook überprüft, ob die Benutzerdaten für die Instance die richtigen Cluster-Informationen enthalten, ob das Instance-Profil die erforderlichen Berechtigungen enthält und ob Probleme mit der Netzwerkkonfiguration auftreten. Weitere Informationen finden Sie unter [AWSSupport-TroubleshootECSContainerInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshoot-ecs-container-instance.html) im *Benutzerhandbuch zur AWS Systems Manager -Automatisierungs-Runbook-Referenz*.
Weitere Informationen darüber, welche Attribute für bestimmte Aufgabendefinitionsparameter und Agentenkonfigurationsvariablen erforderlich sind, finden Sie unter [Amazon-ECS-Aufgabendefinitionsparameter für Fargate](task_definition_parameters.md) und [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
## service (*service-name*) konnte eine Aufgabe nicht platzieren, da keine Container-Instance alle ihre Anforderungen erfüllte. Für die Container-Instance, die am ehesten passt, sind nicht *container-instance-id* genügend CPU-Einheiten verfügbar.
Die am besten passende Container-Instance für die Aufgabenplatzierung enthält nicht genügend CPU-Einheiten, um die Anforderungen in der Aufgabendefinition zu erfüllen. Überprüfen Sie die CPU-Anforderungen sowohl in den Aufgabengrößen- als auch den Containerdefinitionsparametern der Aufgabendefinition.
## service (*service-name*) konnte eine Aufgabe nicht platzieren, da keine Container-Instance alle ihre Anforderungen erfüllte. Bei der Container-Instance, die am ehesten passt, ist der Fehler „AGENT“ *container-instance-id* aufgetreten.
Der Amazon-ECS-Container-Agent auf der am besten passenden Container-Instance für die Aufgabenplatzierung wird getrennt. Wenn Sie mit SSH eine Verbindung zu der Container-Instance herstellen können, können Sie die Agenten-Protokolle überprüfen. Weitere Informationen finden Sie unter [Protokoll-Konfigurationsparameter für den Amazon-ECS-Container-Agenten](ecs-agent-versions.md#agent-logs). Sie sollten auch prüfen, ob der Agent auf der Instance ausgeführt wird. Wenn Sie das Amazon-ECS-optimierte AMI verwenden, können Sie versuchen, den Agenten mit dem folgenden Befehl zu stoppen und neu zu starten.
+ Für das Amazon-ECS-optimierte Amazon-Linux-2-AMI und das Amazon-ECS-optimierte Amazon-Linux-2023-AMI
```
sudo systemctl restart ecs
```
+ Für das Amazon-ECS-optimierte Amazon-Linux-AMI
```
sudo stop ecs && sudo start ecs
```
## service (*service-name*) (task*task-id*) (instance*instance-id*) ist in (elb*elb-name*) fehlerhaft, und zwar aus dem folgenden Grund: Die Instanz hat mindestens die UnhealthyThreshold Anzahl der Integritätsprüfungen nacheinander nicht bestanden.
Dieser Service ist mit einem Load Balancer registriert und die Zustandsprüfungen des Load Balancer sind fehlgeschlagen. Die Nachricht enthält die Aufgaben-ID, anhand derer festgestellt werden kann, welche spezifische Aufgabe die Zustandsprüfungen nicht besteht. Weitere Informationen finden Sie unter [Fehlerbehebung bei Service-Load Balancers in Amazon ECS](troubleshoot-service-load-balancers.md).
## service (*service-name*) kann Aufgaben nicht konsistent erfolgreich starten.
Dieser Service enthält Aufgaben, die nach mehrmaligen Versuchen nicht gestartet werden konnten. Zu diesem Zeitpunkt beginnt der Service-Scheduler, die Zeit zwischen erneuten Versuchen inkrementell zu erhöhen. Sie sollten eine Fehlersuche durchführen, um festzustellen, warum Ihre Aufgaben nicht starten. Weitere Informationen finden Sie unter [Service-Drosselungslogik in Amazon ECS](service-throttle-logic.md).
Nachdem der Service aktualisiert wurde, z. B. durch eine aktualisierte Aufgabendefinition, nimmt der Service-Scheduler sein normales Verhalten wieder auf.
## service (*service-name*) -Operationen werden gedrosselt. Wird es später neu versuchen.
Dieser Service kann aufgrund von API-Beschränkungen keine weiteren Aufgaben starten. Sobald der Service-Scheduler in der Lage ist, weitere Aufgaben zu starten, wird er fortgesetzt.
Wenn Sie eine Kontingenterhöhung des API-Ratenlimits beantragen möchten, öffnen Sie die Seite [AWS Support -Center](https://console.aws.amazon.com/support/home#/), melden sich gegebenenfalls an und wählen **Create case (Fall erstellen)**. Wählen Sie **Service Limit increase (Erhöhung des Servicelimits)**. Füllen Sie das Formular aus und senden Sie es ab.
## service (*service-name*) konnte aufgrund der Konfiguration der Dienstbereitstellung während einer Bereitstellung keine Aufgaben beenden oder starten. Aktualisieren Sie den Wert minimumHealthyPercent oder MaximumPercent und versuchen Sie es erneut.
Dieser Service kann Aufgaben während einer Servicebereitstellung aufgrund der Bereitstellungskonfiguration nicht anhalten oder starten. Die Bereitstellungskonfiguration besteht aus den Werten `minimumHealthyPercent` und `maximumPercent`, die beim Erstellen des Service definiert werden. Diese Werte können auch für einen vorhandenen Service aktualisiert werden.
`minimumHealthyPercent` stellt die Untergrenze für die Anzahl der Aufgaben dar, die für einen Service während einer Bereitstellung oder wenn eine Container-Instance entlastet wird, ausgeführt werden sollen. Der Wert entspricht einem Prozentsatz der gewünschten Anzahl von Aufgaben für den Service. Dieser Wert wird aufgerundet. Zum Beispiel, wenn der minimale fehlerfreie Prozentsatz `50` ist und die gewünschte Aufgabenanzahl vier ist, kann der Scheduler zwei bestehende Aufgaben anhalten, bevor er zwei neue Aufgaben startet. Ebenso kann der Scheduler, wenn der minimale fehlerfreie Prozentsatz 75 % beträgt und die gewünschte Anzahl zwei ist, keine Aufgaben stoppen, da der resultierende Wert auch zwei ist.
`maximumPercent` stellt die Obergrenze für die Anzahl der Aufgaben dar, die für einen Service während einer Bereitstellung oder wenn eine Container-Instance entlastet wird, ausgeführt werden sollen. Der Wert entspricht einem Prozentsatz der gewünschten Anzahl von Aufgaben für einen Service. Dieser Wert wird abgerundet. Zum Beispiel, wenn der maximale Prozentsatz `200` ist und die gewünschte Aufgabenanzahl vier ist, kann der Scheduler vier neue Aufgaben starten, bevor er vier vorhandene Aufgaben beendet. Ebenso, wenn der maximale Prozentsatz `125`. ist und die gewünschte Aufgabenanzahl drei ist, kann der Scheduler keine Aufgaben starten, da der resultierende Wert ebenfalls drei ist.
Wenn Sie einen minimalen fehlerfreien Prozentsatz oder einen maximalen Prozentsatz festlegen, sollten Sie sicherstellen, dass der Scheduler mindestens eine Aufgabe anhalten oder starten kann, wenn eine Bereitstellung ausgelöst wird.
## service (*service-name*) konnte keine Aufgabe platzieren. Grund: Sie haben das Limit für die Anzahl der Aufgaben erreicht, die Sie gleichzeitig ausführen können
Sie können eine Kontingenterhöhung für die Ressource anfordern, die den Fehler verursacht hat. Weitere Informationen finden Sie unter [Amazon-ECS-Service-Kontingente](service-quotas.md). Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter [Beantragen einer Kontingenterhöhung](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) im *Benutzerhandbuch zu Service Quotas*.
## service (*service-name*) konnte keine Aufgabe platzieren. Grund: Interner Fehler.
Im Folgenden finden Sie den möglichen Grund für diesen Fehler:
Der Service kann eine Aufgabe nicht starten, da sich ein Subnetz in einer nicht unterstützten Availability Zone befindet.
Informationen zu den unterstützten Fargate-Regionen und Availability Zones finden Sie unter [Unterstützte Regionen für Amazon ECS auf AWS Fargate](AWS_Fargate-Regions.md).
Weitere Informationen zum Anzeigen der Subnetz-Availability-Zone finden Sie unter [Anzeigen Ihres Subnetzes](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#view-subnet) im *Benutzerhandbuch zu Amazon VPC*.
## service (*service-name*) konnte keine Aufgabe platzieren. Grund: Die angeforderte CPU-Konfiguration liegt über Ihrem Limit.
Sie können eine Kontingenterhöhung für die Ressource anfordern, die den Fehler verursacht hat. Weitere Informationen finden Sie unter [Amazon-ECS-Service-Kontingente](service-quotas.md). Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter [Beantragen einer Kontingenterhöhung](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) im *Benutzerhandbuch zu Service Quotas*.
## service (*service-name*) konnte keine Aufgabe platzieren. Grund: Die angeforderte MEMORY-Konfiguration liegt über Ihrem Limit.
Sie können eine Kontingenterhöhung für die Ressource anfordern, die den Fehler verursacht hat. Weitere Informationen finden Sie unter [Amazon-ECS-Service-Kontingente](service-quotas.md). Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter [Beantragen einer Kontingenterhöhung](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) im *Benutzerhandbuch zu Service Quotas*.
## service (*service-name*) konnte keine Aufgabe platzieren. Grund: Sie haben das Limit für die Anzahl von v erreicht, die CPUs Sie gleichzeitig ausführen können
AWS Fargate geht von Quoten auf Basis der Task-Anzahl auf vCPU-basierte Kontingente über.
Sie können eine Kontingenterhöhung für das vCPU-basierte Kontingent von Fargate anfordern. Weitere Informationen finden Sie unter [Amazon-ECS-Service-Kontingente](service-quotas.md). Informationen zur Erhöhung eines Fargate-Kontingents finden Sie unter [Anfordern einer Kontingenterhöhung](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) im *Service-Quotas-Benutzerhandbuch*.
## service (*service-name*) konnte den Steady-State nicht erreichen, weil Task Set (*taskSet-ID*) nicht skalieren konnte. Grund: Die Anzahl der geschützten Aufgaben übersteigt die gewünschte Anzahl von Aufgaben.
Der Service verfügt über mehr geschützte Aufgaben als die gewünschte Anzahl von Aufgaben. Sie können eine der folgenden Aktionen durchführen:
+ Warten Sie, bis der Schutz für die aktuellen Aufgaben abgelaufen ist, damit diese beendet werden können.
+ Ermitteln Sie, welche Aufgaben angehalten werden können, und verwenden Sie die `UpdateTaskProtection`-API mit der `protectionEnabled`-Option auf `false` gestellt, um den Schutz für diese Aufgaben zu deaktivieren.
+ Erhöhen Sie die Anzahl der gewünschten Aufgaben des Services auf mehr als die Anzahl der geschützten Aufgaben.
## service (*service-name*) konnte den stationären Status nicht erreichen. Grund: In Ihrem Kapazitätsanbieter wurden keine Container-Instances gefunden.
Der Service Scheduler sendet diese Ereignismeldung, wenn er die verfügbaren Ressourcen zum Hinzufügen einer weiteren Aufgabe nicht finden konnte. Mögliche Ursachen dafür sind:
Dem Cluster ist kein Kapazitätsanbieter zugeordnet
Verwenden Sie `describe-services`, um zu überprüfen, ob dem Cluster ein Kapazitätsanbieter zugeordnet ist. Sie können die Kapazitätsanbieter-Strategie für den Service aktualisieren.
Stellen Sie sicher, dass Kapazität im Kapazitätsanbieter verfügbar ist. Stellen Sie im Fall von EC2 sicher, dass die Container-Instances die Anforderungen der Aufgabendefinition erfüllen.
Es wurden keine Container-Instances in Ihrem Cluster gefunden
Wenn keine Container-Instances in dem Cluster registriert sind, in dem Sie versucht haben, eine Aufgabe auszuführen, erhalten Sie diese Fehlermeldung. Sie sollten Ihrem Cluster Container-Instances hinzufügen. Weitere Informationen finden Sie unter [Starten einer Amazon ECS Linux-Container-Instance](launch_container_instance.md).
Nicht genügend Ports
Wenn Ihre Aufgabe feste Host-Port-Zuweisung verwendet (wenn zum Beispiel Ihre Aufgabe Port 80 auf dem Host für einen Webserver verwendet), brauchen Sie mindestens eine Container-Instance pro Aufgabe. Nur ein Container kann jeweils einen einzigen Host-Port gleichzeitig verwenden. Sie sollten Ihrem Cluster Container-Instances hinzufügen oder die Anzahl gewünschter Aufgaben reduzieren.
Registrierung einer zu großen Zahl von Ports
Die am besten übereinstimmende Container-Instance für die Aufgabenplatzierung darf die maximal zulässige Anzahl reservierter Ports von 100 Host-Ports pro Container-Instance nicht überschreiten. Ein dynamisches Host-Port-Mapping behebt das Problem möglicherweise.
Port wird bereits verwendet
Die Aufgabendefinition dieser Aufgabe verwendet denselben Port in ihrer Port-Zuordnung als eine Aufgabe, die bereits auf der ausgewählten Container-Instance ausgeführt wird. Die Serviceereignis-Nachricht hätte die gewählte Container-Instance-ID als Teil der folgenden Nachricht.
```
The closest matching container-instance is already using a port required by your task.
```
Speicher reicht nicht aus
Wenn Ihre Aufgabendefinition 1000 MiB Speicher angibt und jede Container-Instance in Ihrem Cluster 1024 MiB Speicher hat, können Sie nur eine Kopie dieser Aufgabe pro Container-Instance ausführen. Sie können mit weniger Speicher in Ihrer Aufgabendefinition experimentieren, sodass Sie mehr als eine Aufgabe pro Container-Instance oder mehr Container-Instances in Ihrem Cluster starten können.
Wenn Sie versuchen, Ihre Ressourcennutzung zu maximieren, indem Sie Ihren Aufgaben so viel Arbeitsspeicher wie möglich für einen bestimmten Instance-Typ zuweisen, lesen Sie nach unter [Arbeitsspeicher für Linux-Container-Instances von Amazon ECS reservieren](memory-management.md).
Nicht genügend verfügbare ENI-Befestigungspunkte
Aufgaben, die den Netzwerkmodus `awsvpc` verwenden, erhalten ihre eigene Elastic-Network-Schnittstelle (ENI), die an die Container-Instance angehängt wird, die sie hostet. Die Anzahl der Amazon EC2 EC2-Instances ENIs , die an sie angehängt werden können, ist begrenzt, und es gibt keine Container-Instances im Cluster, für die ENI-Kapazität verfügbar ist.
Das ENI-Limit für einzelne Container-Instances hängt von den folgenden Bedingungen ab:
+ Wenn Sie sich **nicht** für die `awsvpcTrunking`-Kontoeinstellung angemeldet haben, hängt das ENI-Limit für jede Container-Instance vom Instance-Typ ab. Weitere Informationen finden Sie unter [IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) im *Amazon EC2-Benutzerhandbuch*.
+ Wenn Sie sich für die `awsvpcTrunking`-Kontoeinstellung angemeldet **haben**, Sie aber nach der Anmeldung **keine** neuen Container-Instances unter Verwendung eines unterstützten Instance-Typs gestartet haben, wird das ENI-Limit für jede Container-Instance weiterhin auf dem Standardwert liegen. Weitere Informationen finden Sie unter [IP-Adressen pro Netzwerkschnittstelle pro Instance-Typ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) im *Amazon EC2-Benutzerhandbuch*.
+ Wenn Sie sich für die `awsvpcTrunking` Kontoeinstellungen entschieden **haben** **und nach der Anmeldung neue Container-Instances mit einem unterstützten Instance-Typ gestartet haben**, ENIs sind weitere verfügbar. Weitere Informationen finden Sie unter [Unterstützte Instances für mehr Amazon-ECS-Container-Netzwerkschnittstellen](eni-trunking-supported-instance-types.md).
Weitere Informationen zum Aktivieren der `awsvpcTrunking`-Kontoeinstellung finden Sie unter [Erhöhung der Netzwerkschnittstellen für Linux-Container-Instances von Amazon ECS](container-instance-eni.md).
Sie können Ihrem Cluster Container-Instances hinzufügen, um weitere Netzwerkadapter zur Verfügung zu stellen.
Container-Instance fehlt erforderliches Attribut
Einige Aufgabendefinitionsparameter erfordern, dass eine bestimmte Docker-Remote-API-Version auf der Container-Instance installiert wird. Andere, wie die Optionen für Protokolltreiber, erfordern, dass die Container-Instances diese Protokolltreiber bei der Variablen zur Konfiguration des Agenten `ECS_AVAILABLE_LOGGING_DRIVERS` registrieren. Wenn Ihre Aufgabendefinition einen Parameter enthält, der ein bestimmtes Container-Instance-Attribut erfordert, und Sie keine Container-Instances zur Verfügung haben, die diese Anforderung erfüllen können, kann die Aufgabe nicht platziert werden.
Eine häufige Ursache für diesen Fehler ist, wenn Ihr Service Aufgaben mit dem Netzwerkmodus `awsvpc` und EC2 verwendet und für den angegebenen Cluster keine Container-Instance in demselben Subnetz registriert ist, das beim Erstellen des Service in `awsvpcConfiguration` angegeben wurde.
Sie können das AWSSupport-TroubleshootECSContainerInstance Runbook zur Fehlerbehebung verwenden. Das Runbook überprüft, ob die Benutzerdaten für die Instance die richtigen Cluster-Informationen enthalten, ob das Instance-Profil die erforderlichen Berechtigungen enthält und ob Probleme mit der Netzwerkkonfiguration auftreten. Weitere Informationen finden Sie unter [AWSSupport-TroubleshootECSContainerInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-troubleshoot-ecs-container-instance.html) im *Benutzerhandbuch zur AWS Systems Manager -Automatisierungs-Runbook-Referenz*.
Weitere Informationen darüber, welche Attribute für bestimmte Aufgabendefinitionsparameter und Agentenkonfigurationsvariablen erforderlich sind, finden Sie unter [Amazon-ECS-Aufgabendefinitionsparameter für Fargate](task_definition_parameters.md) und [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
## service (*service-name*) konnte keine Aufgabe platzieren. Grund: Kapazität ist derzeit nicht verfügbar. Bitte versuchen Sie es später erneut oder in einer anderen Availability Zone.
Derzeit ist keine Kapazität verfügbar, mit der Ihr Service ausgeführt werden kann.
Sie können eine der folgenden Aktionen durchführen:
+ Warten Sie, bis die Fargate-Kapazität- oder EC2-Container-Instances verfügbar sind.
+ Starten Sie den Service neu und geben Sie zusätzliche Subnetze an.
## Die Bereitstellung von service (*service-name*) ist fehlgeschlagen: Aufgaben konnten nicht gestartet werden.
Die Aufgaben im Service konnten nicht gestartet werden.
Informationen dazu, wie Sie angehaltene Aufgaben debuggen können, finden Sie unter [Aufgabe-Beendet-Fehlermeldungen in Amazon ECS](stopped-task-error-codes.md).
## service (*service-name*) Beim Warten auf den Start von Amazon ECS Agent ist eine Zeitüberschreitung aufgetreten. Bitte überprüfen Sie die Protokolle unter „/var/log/ecs/ecs-agent.log“.
Der Amazon-ECS-Container-Agent auf der am besten passenden Container-Instance für die Aufgabenplatzierung wird getrennt. Wenn Sie mit SSH eine Verbindung zu der Container-Instance herstellen können, können Sie die Agenten-Protokolle überprüfen. Weitere Informationen finden Sie unter [Protokoll-Konfigurationsparameter für den Amazon-ECS-Container-Agenten](ecs-agent-versions.md#agent-logs). Sie sollten auch prüfen, ob der Agent auf der Instance ausgeführt wird. Wenn Sie das Amazon-ECS-optimierte AMI verwenden, können Sie versuchen, den Agenten mit dem folgenden Befehl zu stoppen und neu zu starten.
+ Für das Amazon-ECS-optimierte Amazon-Linux-2-AMI
```
sudo systemctl restart ecs
```
+ Für das Amazon-ECS-optimierte Amazon-Linux-AMI
```
sudo stop ecs && sudo start ecs
```
## service (*service-name*) task set (*taskSet-ID*) (task*task-id*) ist in target-group (*targetGroup-ARN)*) nicht fehlerfrei aufgrund von. `TARGET GROUP IS NOT FOUND`
Die für den Service festgelegte Aufgabe hat die Zustandsprüfungen nicht bestanden, weil die Zielgruppe nicht gefunden wurde. Die Nachricht enthält die Aufgaben-ID, anhand derer festgestellt werden kann, welche spezifische Aufgabe die Zustandsprüfungen nicht besteht. Sie sollten den Service löschen und erneut erstellen. Löschen Sie keine Zielgruppe von Elastic Load Balancing, es sei denn, der entsprechende Amazon-ECS-Service wurde bereits gelöscht.
## service (*service-name*) task set (*taskSet-ID*) (task*task-id*) ist in target-group (*targetGroup-ARN)*) nicht fehlerfrei aufgrund von. `TARGET IS NOT FOUND`
Die für den Service festgelegte Aufgabe hat die Zustandsprüfungen nicht bestanden, weil das Ziel nicht gefunden wurde. Die Nachricht enthält die Aufgaben-ID, anhand derer festgestellt werden kann, welche spezifische Aufgabe die Zustandsprüfungen nicht besteht.
## Die IAM-Berechtigungsrichtlinien wurden falsch konfiguriert oder geändert, und ECS kann Ihren Service nicht mehr aufrechterhalten
Der Service kann aufgrund falsch konfigurierter oder geänderter IAM-Berechtigungsrichtlinien keine Aufgaben verwalten. Für die IAM-Rolle, die Ihrem ECS-Service oder Ihren ECS-Aufgaben zugeordnet ist, fehlen möglicherweise die erforderlichen Berechtigungen.
Um dieses Problem zu beheben, fügen Sie der IAM-Rolle die erforderlichen Berechtigungen hinzu. Informationen zum Verwalten von IAM-Berechtigungen finden Sie unter [Hinzufügen und Entfernen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) im *IAM-Benutzerhandbuch*.
## Die IAM-Vertrauensbeziehungen wurden falsch konfiguriert oder geändert, und ECS kann Ihren Service nicht mehr aufrechterhalten
Der Service kann aufgrund einer falsch konfigurierten oder geänderten IAM-Vertrauensbeziehung keine Aufgaben verwalten. Die mit Ihrem ECS-Service oder Ihren ECS-Aufgaben verknüpfte IAM-Rolle hat möglicherweise eine falsche Vertrauensrichtlinie.
Um dieses Problem zu beheben, konfigurieren Sie eine Vertrauensrichtlinie für die in Ihrer Aufgabendefinition verwendete Rolle. Weitere Informationen zum Erstellen von Vertrauensrichtlinien für benutzerdefinierte Rollen finden Sie unter [Erstellen einer Rolle für einen benutzerdefinierten Anwendungsfall](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) im *IAM-Benutzerhandbuch*.
## service (*service-name*) konnte keine *number* Aufgaben für die Bereitstellung starten. *deployment-id*
Der Service Scheduler sendet diese Ereignismeldung, wenn ein Bereitstellungsworkflow einige Aufgaben erfolgreich startet, aber aufgrund von Kapazitätsfehlern nicht alle angeforderten Aufgaben gestartet werden können. Dies tritt in der Regel auf, wenn Circuit Breaker aktiviert ist, und gibt Aufschluss darüber, warum Bereitstellungen fehlschlagen oder rückgängig gemacht werden können.
Die Meldung enthält den spezifischen Fehlergrund, z. B. unzureichende CPU-, Arbeitsspeicher- oder andere Ressourcenbeschränkungen. Auf diese Weise können Sie besser verstehen, welche Ressourcen zur Lösung des Bereitstellungsproblems benötigt werden.
Weitere Informationen finden Sie unter [service (*service-name*) konnte eine Aufgabe nicht platzieren, da keine Container-Instance alle ihre Anforderungen erfüllte.](#service-event-messages-1).
## service (*service-name*) konnte keine Aufgaben in Ihrem Cluster platzieren, da das Kapazitätslimit für die Bereitstellung von Aufgaben überschritten wurde.
Der Service Scheduler sendet diese Ereignisnachricht, wenn Ihr Cluster das Limit von 500 Aufgaben erreicht hat, die sich gleichzeitig im `PROVISIONING` Status befinden können. Dies ist ein Limit auf Clusterebene, kein dienstspezifisches Problem.
Dies tritt in der Regel auf, wenn Sie einen Dienst mit einer hohen Anzahl von gewünschten Aufgaben und begrenzter vorab bereitgestellter Kapazität starten oder wenn mehrere Dienste gleichzeitig gestartet werden, was zu einer hohen Aufgabenabwanderung führt.
So beheben Sie dieses Problem
+ Warten Sie, bis die Bereitstellung vorhandener Aufgaben abgeschlossen ist, und wechseln Sie in den Status. `RUNNING`
+ Erwägen Sie, Ihre Dienste schrittweise zu skalieren, um zu vermeiden, dass das Bereitstellungslimit überschritten wird.
+ Überprüfen Sie die Konfiguration des Kapazitätsanbieters Ihres Clusters, um sicherzustellen, dass angemessene Ressourcen verfügbar sind.
Weitere Informationen zu Amazon ECS-Servicekontingenten finden Sie unter [Amazon Elastic Container Service Endpoints and Quotas](https://docs.aws.amazon.com/general/latest/gr/ecs-service.html) in der *Amazon Web Services General Reference.*
# Amazon-ECS-Ereignismeldungen bei fehlerhaftem Service
Im Folgenden finden Sie Beispiele für Service-Fehlerhaft-Ereignismeldungen.
## EC2: (Service*service-name*) (Task*task-id*) (Instance*instance-id*) (Port*port-number*) ist in (Zielgruppe) aus (Grund*target-group-name*) fehlerhaft *failure-reason*
Diese Meldung weist darauf hin, dass eine Aufgabe, die auf einer EC2-Instance ausgeführt wird, die Zustandsprüfungen nicht bestanden hat. Weitere Informationen finden Sie hier:
+ [Wie schaffe ich es, dass meine Amazon-ECS-Aufgaben, die EC2 verwenden, die Zustandsprüfung des Application Load Balancer bestehen?](https://repost.aws/knowledge-center/troubleshoot-unhealthy-checks-ecs)
## EC2 mit TaskSet: (Service*service-name*, TaskSet*taskSet-id*) (Task) (Instanz*task-id*) (Port*instance-id*) ist in (Zielgruppe*port-number*) aus (Grund) fehlerhaft *target-group-name* *failure-reason*
Diese Meldung weist darauf hin, dass eine Aufgabe in einem Aufgabensatz, der auf einer EC2-Instance ausgeführt wird, die Zustandsprüfungen nicht bestanden hat. Weitere Informationen finden Sie hier:
+ [Wie schaffe ich es, dass meine Amazon-ECS-Aufgaben, die EC2 verwenden, die Zustandsprüfung des Application Load Balancer bestehen?](https://repost.aws/knowledge-center/troubleshoot-unhealthy-checks-ecs)
## Fargate: (Service*service-name*) (Task*task-id*) (Port*port-number*) ist in (Zielgruppe) aus (Grund*target-group-name*) ungesund *failure-reason*
Diese Meldung weist darauf hin, dass eine Fargate-Aufgabe die Zustandsprüfungen nicht besteht.
Weitere Informationen zur Behebung fehlgeschlagener Zustandsprüfungen bei Fargate-Aufgaben finden Sie unter [Wie behebe ich Fehler bei Zustandsprüfungen für Amazon-ECS-Aufgaben in Fargate?](https://repost.aws/knowledge-center/ecs-fargate-health-check-failures)
## Fargate mit TaskSet: (Service*service-name*, TaskSet*taskSet-id*) (Task) (Port *task-id**port-number*) ist in (Zielgruppe*target-group-name*) aus (Grund) ungesund *failure-reason*
Diese Meldung weist darauf hin, dass eine Aufgabe in einem Aufgabensatz, der in Fargate ausgeführt wird, die Zustandsprüfungen nicht bestanden hat.
Weitere Informationen zur Behebung fehlgeschlagener Zustandsprüfungen bei Fargate-Aufgaben finden Sie unter [Wie behebe ich Fehler bei Zustandsprüfungen für Amazon-ECS-Aufgaben in Fargate?](https://repost.aws/knowledge-center/ecs-fargate-health-check-failures)
# Ereignismeldungen für die Neubalancierung des Availability-Zone-Services in Amazon ECS
Im Folgenden finden Sie Beispiele für Service-Ereignismeldungen, die Sie sehen könnten:
## service (*service-name*) ist nicht ausgewogen mit *number-tasks* Aufgaben in, in und in*Availability Zone 1*. *number-tasks* *Availability Zone 2* *number-tasks* *Availability Zone 3* Der AZ-Neuausgleich wird ausgeführt.
Der Service Scheduler sendet ein `service (service-name) is not AZ balanced`-Service-Ereignis, wenn die Anzahl der Aufgaben nicht gleichmäßig auf die Availability Zones verteilt ist. Es müssen keine Maßnahmen ergriffen werden. Es handelt sich um eine Informationsereignis.
## service (*service-name*) ist AZ-ausgewogen mit *number-tasks* Aufgaben in*Availability Zone 1*, *number-tasks* Aufgaben in *Availability Zone 2* und *number-tasks* Aufgaben in*Availability Zone 3*.
Der Service Scheduler sendet ein `service (service-name) is AZ balanced`-Service-Ereignis, wenn der Service-Neuausgleich der Availability Zone abgeschlossen ist. Es müssen keine Maßnahmen ergriffen werden. Es handelt sich um eine Informationsereignis.
## *service-name*hat *number-tasks* Aufgaben in *Availability Zone* AZ Rebalance: *task-ids* gestartet.
Der Service Scheduler sendet das Ereignis „*service-name*/*task-set-name*hat *number* Aufgaben in *Availability Zone* Service gestartet“, wenn er Aufgaben in einer Availability Zone startet, weil ein Service Rebalancing stattfindet. Es müssen keine Maßnahmen ergriffen werden. Es handelt sich um eine Informationsereignis.
## *service-name*hat die *number-tasks* Ausführung von Aufgaben *Availability Zone* aufgrund eines AZ-Rebalancing beendet:. *task-id*
Der Service Scheduler sendet die Meldung „*service-name*/*task-set-name*hat *number* Aufgaben gestoppt“ in einem *Availability Zone* Serviceereignis, wenn er Aufgaben in einer Availability Zone aufgrund einer Neuverteilung von Diensten stoppt. Es müssen keine Maßnahmen ergriffen werden. Es handelt sich um eine Informationsereignis.
## service (*service-name*) kann eine Aufgabe nicht platzieren, *Availability Zone* da keine Container-Instance alle ihre Anforderungen erfüllt hat.
Der Service Scheduler sendet *service-name* das Ereignis „Kann eine Aufgabe nicht in *Availability Zone* Dienst stellen“, weil keine Container-Instance alle ihre Anforderungen erfüllt hat. Um das Problem zu beheben, starten Sie Instances in der Availability Zone.
## service (*service-name*) kann eine Aufgabe nicht platzieren. *Availability Zone*
Der Service Scheduler sendet *service-name* das Ereignis „Kann keine Aufgabe in *Availability Zone* Betrieb nehmen“, wenn Sie das Fargate verwenden und keine Kapazität verfügbar ist.
Sie können in der Fehlermeldung weitere Subnetze in der Availability Zone hinzufügen oder Kontakt aufnehmen, um zusätzliche Kapazität Support zu erhalten.
## service (*service-name*) konnte AZ Rebalance nicht durchführen, da aufgrund von nicht skaliert werden *task-set-name* konnte. *reason*
Der Service Scheduler sendet die Meldung „AZ Rebalance *service-name* konnte nicht ausgeführt werden, weil die Skalierung aufgrund eines *reason* Serviceereignisses nicht möglich *task-set-name* war“, wenn Sie den Task-Scale-In-Schutz verwenden.
Sie können eine der folgenden Aktionen durchführen:
+ Warten Sie, bis der Schutz für die aktuellen Aufgaben abgelaufen ist, damit diese beendet werden können.
+ Ermitteln Sie, welche Aufgaben angehalten werden können, und verwenden Sie die `UpdateTaskProtection`-API mit der `protectionEnabled`-Option auf `false` gestellt, um den Schutz für diese Aufgaben zu deaktivieren.
+ Erhöhen Sie die Anzahl der gewünschten Aufgaben des Services auf mehr als die Anzahl der geschützten Aufgaben.
## service (*service-name*) hat AZ Rebalancing gestoppt.
Der Service Scheduler sendet ein Serviceereignis, das AZ Rebalancing *service-name* beendet hat, als der Vorgang zum Rebalancing in der Availability Zone beendet wurde. Es handelt sich um eine Informationsereignis. Amazon ECS sendet zusätzliche Ereignisse, die weitere Informationen liefern.
# Fehlerbehebung bei Service-Load Balancers in Amazon ECS
Amazon-ECS-Services können Aufgaben bei einem Elastic Load Balancing-Load Balancer registrieren. Fehler bei der Konfiguration von Load Balancers sind häufig die Ursache für gestoppte Aufgaben. Wenn Ihre gestoppten Aufgaben von Services gestartet wurden, die einen Load Balancer verwenden, ziehen Sie folgende mögliche Ursachen in Betracht.
**Die mit dem Service verknüpfte Amazon ECS-Rolle ist nicht vorhanden**
Die Amazon ECS servicegebundene Rolle ermöglicht es Amazon-ECS-Services Container-Instances mit Elastic Load Balancing-Load Balancern zu registrieren. Die servicegebundene Rolle muss in Ihrem Konto erstellt werden. Weitere Informationen finden Sie unter [Verwendung von serviceverknüpften Rollen für Amazon ECS](using-service-linked-roles.md).
**Sicherheitsgruppe für Container-Instances**
Wenn Ihr Container dem Port 80 auf Ihrer Container-Instance zugewiesen ist, muss Ihre Container-Instance-Sicherheitsgruppe eingehenden Datenverkehr auf Port 80 für die Zustandsprüfungen des Load Balancer erlauben.
**Elastic Load Balancing Load Balancer ist nicht für alle Availability Zones konfiguriert**
Ihr Load Balancer sollte so konfiguriert sein, dass er alle Availability Zones in einer Region verwenden kann, oder zumindest alle Availability Zones, in denen sich Ihre Container-Instances befinden. Wenn ein Service einen Load Balancer verwendet und eine Aufgabe auf einer Container-Instance startet, die sich in einer Availability Zone befindet, für deren Verwendung der Load Balancer nicht konfiguriert wurde, besteht die Aufgabe nie die Zustandsprüfung. Dies führt dazu, dass die Aufgabe beendet wird.
**Elastic Load Balancing Load Balancer Health Check falsch konfiguriert**
Die Parameter der Zustandsprüfung des Load Balancer können übermäßig restriktiv sein oder auf Ressourcen zeigen, die nicht existieren. Wenn festgestellt wird, dass eine Container-Instance fehlerhaft ist, wird sie vom Load Balancer entfernt. Stellen Sie sicher, dass die folgenden Parameter korrekt für Ihren Service-Load Balancer konfiguriert sind.
Ping-Port
Der Wert **Ping-Port** für eine Load Balancer-Zustandsprüfung ist der Port auf den Container-Instances, den der Load Balancer prüft, um festzustellen, ob er fehlerfrei ist. Wenn dieser Port falsch konfiguriert ist, meldet der Load Balancer Ihre Container-Instance wahrscheinlich von sich ab. Dieser Port sollte so konfiguriert sein, dass er den Wert `hostPort` für den Container in der Aufgabendefinition Ihres Services verwendet, die Sie bei der Zustandsprüfung verwenden.
Ping-Pfad
Dies ist Teil der Load-Balancer-Zustandsprüfung. Es handelt sich um einen Endpunkt in Ihrer Anwendung, der einen erfolgreichen Statuscode (z. B. 200) zurückgeben kann, wenn die Anwendung fehlerfrei ist. Dieser Wert wird oft auf `index.html` festgelegt, aber wenn Ihr Service auf diese Anfrage nicht antwortet, schlägt die Zustandsprüfung fehl. Wenn Ihr Container keine Datei `index.html` hat, können Sie dies auf `/` festlegen, um so auf die Basis-URL für die Container-Instance abzuzielen.
Reaktions-Timeout
Dies ist die Zeitdauer, innerhalb derer Ihr Container eine Antwort auf den Ping der Zustandsprüfung zurücksenden muss. Wenn dieser Wert niedriger ist als die Zeitdauer, die für eine Antwort erforderlich ist, schlägt die Zustandsprüfung fehl.
Zustandsprüfungsintervall
Dies ist die Zeitdauer zwischen Zustandsprüfungs-Pings. Je kürzer Ihre Zustandsprüfungsintervalle sind, desto schneller kann Ihre Container-Instance den **Unhealthy Threshold** erreichen.
Unhealthy Threshold (Schwellenwert für anormalen Zustand)
Dies ist die Anzahl der Male, die Ihre Zustandsprüfung fehlschlagen kann, bevor Ihre Container-Instance als fehlerhaft betrachtet wird. Wenn Sie einen Fehlerhaft-Schwellenwert von 2 und ein Zustandsprüfungsintervall von 30 Sekunden haben, dann hat Ihre Aufgabe 60 Sekunden Zeit, um auf den Zustandsprüfungs-Ping zu antworten, bevor sie als fehlerhaft gilt. Sie können den Unhealthy Threshold oder das Zustandsprüfungsintervall erhöhen, um Ihren Aufgaben mehr Zeit zum Antworten zu geben.
**Der Dienst konnte nicht aktualisiert werden*servicename*: Der** **Name oder der Port des Load Balancer-Containers wurden in der Aufgabendefinition geändert**
Wenn Ihr Service einen Load Balancer verwendet, können Sie das AWS CLI oder SDK verwenden, um die Load Balancer-Konfiguration zu ändern. Informationen zum Ändern der Konfiguration finden Sie [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*. Wenn Sie die Aufgabendefinition für den Service aktualisieren, müssen der Containername und der Container-Port, die in der Load-Balancer-Konfiguration angegeben sind, in der Aufgabendefinition verbleiben.
**Sie haben das Limit für die Anzahl der Aufgaben erreicht, die Sie gleichzeitig ausführen können.**
Für ein neues Konto sind Ihre Kontingente möglicherweise niedriger als die Service Quotas. Das Servicekontingent für Ihr Konto kann in der Service-Quotas-Konsole angezeigt werden. Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter [Anfordern einer Kontingenterhöhung](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html) im *Benutzerhandbuch zu Service Quotas*.
# Fehlerbehebung bei Service-Auto-Scaling in Amazon ECS
Application Auto Scaling deaktiviert Abskalierungsprozesse, während Amazon-ECS-Bereitstellungen ausgeführt werden, und sie werden fortgesetzt, sobald die Bereitstellung abgeschlossen ist. Scale-Out-Prozesse werden während einer Bereitstellung jedoch weiterhin ausgeführt, es sei denn, sie werden angehalten. Weitere Informationen finden Sie unter [Unterbrechen und Wiederaufnehmen der Skalierung für Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html).
# Amazon ECS-Ereigniserfassung in der Konsole
Die Amazon ECS-Konsole bietet Funktionen zur Erfassung von Ereignissen, mit denen von Amazon ECS generierte Ereignisse, wie Serviceaktionen und Änderungen des Aufgabenstatus, in Amazon CloudWatch Logs gespeichert werden. EventBridge Dieses Feature beinhaltet eine Abfrageschnittstelle mit Filterfunktionen zur Überwachung und Fehlerbehebung.
Ereignisse bieten detaillierte Informationen darüber, wie Ihre Servicebereitstellungen, Services, Aufgaben und Instances funktionieren. Sie können diese Informationen verwenden, um Fehler bei der Bereitstellung von Aufgaben oder Services zu beheben.
Wenn Sie die Ereigniserfassung aktivieren, haben Sie Zugriff auf alle Ereignisse, die Amazon ECS für einen Aufbewahrungszeitraum Ihrer Wahl generiert. Dies geht über die systemeigenen Beschränkungen der letzten 100 ungefilterten Ereignisse oder gestoppten Aufgaben hinaus, die nur 1 Stunde lang sichtbar sind.
## Funktionsweise
Event Capture verwendet EventBridge , um Ereignisse in einer vordefinierten Amazon CloudWatch Logs-Protokollgruppe zu speichern. Die Amazon-ECS-Konsole bietet vorgefertigte Abfragen und Filteroptionen und korreliert Ereignisse, um Aufgabenlebenszyklen in einem intuitiven Format bereitzustellen.
Sie können die folgenden Arten von Ereignissen abfragen und abrufen:
+ **Serviceaktionsereignisse** – Helfen bei der Identifizierung von Problemen bei der Bereitstellung oder Ressourcenzuweisung
+ **Ereignisse im Aufgabenlebenszyklus** – Helfen bei der Klärung, warum Aufgaben oder Container nicht gestartet werden können oder nicht mehr ausgeführt werden
Die Amazon ECS-Konsole ermöglicht Ihnen die Einrichtung der Ereigniserfassung mit einem Klick und bietet häufig verwendete Abfragen und Filterung, ohne dass Sie Abfragesprachen lernen oder zwischen mehreren Konsolen navigieren müssen.
## Event types (Ereignistypen)
Event Capture speichert alle von Amazon ECS generierten Ereignisse in den folgenden Kategorien:
Änderungsereignisse des Aufgabenstatus
Container-Stopps und andere Terminierungsereignisse, die Sie zur Fehlerbehebung oder zur Überwachung der Lebenszyklen von Aufgaben verwenden können.
Service-Aktionen
Ereignisse wie das Erreichen eines stabilen Zustands, fehlgeschlagene Aufgabenplatzierung oder Ressourcenengpässe.
Statusänderungen der Servicebereitstellung
Ereignisse wie laufende, abgeschlossene oder fehlgeschlagene Bereitstellungen, ausgelöst durch Circuit Breaker- und Rollback-Einstellungen, um den Status einer Dienstbereitstellung zu überwachen.
Statusänderungen der Container-Instance
Für Workloads auf EC2- und Amazon ECS-verwalteten Instances zeigen Ereignisse den Status „Verbunden“ und „Getrennt“ an.
## Konfiguration der Protokollgruppe
Wenn Sie die Ereigniserfassung aktivieren, erstellt Amazon ECS automatisch die folgenden Ressourcen:
+ Eine Amazon CloudWatch Logs-Protokollgruppe mit dem Namen `/aws/events/ecs/containerinsights/${clusterName}/performance`
+ Eine EventBridge Regel, die alle Ereignisse aus der `aws.ecs` Quelle aufnimmt und an die Protokollgruppe weiterleitet
Sie können für die Protokollgruppe einen Aufbewahrungszeitraum von 1 Tag bis 10 Jahren angeben. Die Standardaufbewahrungsdauer beträgt 7 Tage.
## Überlegungen
Beachten Sie bei der Verwendung von Event Capture Folgendes:
+ Event Capture speichert der Einfachheit halber alle Ereignisse. Sie können in der Amazon ECS-Konsole keine Regeln so konfigurieren, dass nur bestimmte Ereignisse erfasst werden.
+ Die Amazon ECS-Konsole bietet vordefinierte Abfragekriterien. Verwenden Sie für erweiterte Abfragen Amazon CloudWatch Logs Logs Insights, um die Protokollgruppe direkt abzufragen.
+ Die Live-Tail-Funktionalität ist in der Amazon ECS-Konsole nicht verfügbar. Verwenden Sie Amazon CloudWatch Logs direkt für Live-Tail.
+ Wenn Sie die Ereigniserfassung deaktivieren, wird die EventBridge Regel gelöscht.
+ Bei der Erfassung von Ereignissen fallen zusätzliche Kosten für die EventBridge Datenaufnahme, die Speicherung von Amazon CloudWatch Logs und die Ausführung von Abfragen an.
[Informationen zur Preisgestaltung finden Sie unter EventBridge Preise. EventBridge ](https://aws.amazon.com/eventbridge/pricing/)
Informationen zur CloudWatch Preisgestaltung finden Sie unter [CloudWatch Preisgestaltung](https://aws.amazon.com/cloudwatch/pricing/).
## Ereignisbasierte Problembehandlung
Verwenden Sie von Amazon ECS generierte Ereignisse, um häufig gestellte Fragen zur Fehlerbehebung zu beantworten.
### Analyse von Aufgabenfehlern
Sie können Ereignisse zur Änderung des `STOPPED` Aufgabenstatus, Stoppcodes und Container-Exitcodes überprüfen, um festzustellen, warum eine Aufgabe nicht oder während der Ausführung nicht gestartet werden konnte.
Sie können Serviceaktionsereignisse auf Platzierungsfehler und Informationen zu Ressourcenbeschränkungen überprüfen, um festzustellen, warum eine Aufgabe aufgrund von Ressourcenbeschränkungen nicht platziert werden konnte
### Häufige Szenarien, in denen Aufgaben fehlschlagen
Die häufigsten Fehler bei abnormalen Aufgaben hängen mit den folgenden Problemen zusammen:
+ Fehler bei der Bereitstellung des CI/CD-Dienstes
+ Fehler bei der automatischen Skalierung
+ Fehler beim Rebalancing von Aufgaben
+ Ungewöhnliche Container-Exits, wie z. B. out-of-memory (OOM-) Fehler
Abnormale Aufgabenfehler führen zu Ereignissen zur Änderung des `STOPPED` Aufgabenstatus mit einem `TaskFailedToStart` Stoppcode `EssentialContainerExited` oder. Sie können nach diesen Stoppcodes filtern, um das Verhalten von Containern bei der Ausführung und beim Stoppen zu untersuchen.
# Aktivieren Sie die Ereigniserfassung für einen vorhandenen Amazon ECS-Cluster
Sie können die Ereigniserfassung in einem vorhandenen Amazon ECS-Cluster aktivieren, um von Amazon ECS generierte Ereignisse in Amazon CloudWatch Logs zu speichern. EventBridge Diese Funktion hilft Ihnen bei der Überwachung und Behebung von Aufgabenausfällen, Servicebereitstellungen und anderen Cluster-Aktivitäten.
Nachdem Sie die Ereigniserfassung aktiviert haben, erstellt Amazon ECS die folgenden Ressourcen:
+ Eine Amazon CloudWatch Logs-Protokollgruppe mit dem Namen `/aws/events/ecs/containerinsights/${clusterName}/performance`
+ Eine EventBridge Regel, die alle Ereignisse aus der `aws.ecs` Quelle erfasst
In der Clusteransicht wird eine Registerkarte „**Verlauf**“ angezeigt, auf der Sie Ereignisse und Serviceaktionen im Aufgabenlebenszyklus abfragen können. Die Erfassung von Ereignissen beginnt sofort und speichert alle von Amazon ECS generierten Ereignisse gemäß Ihrer angegebenen Aufbewahrungsfrist.
## Voraussetzungen
+ Ein vorhandener Amazon ECS-Cluster
+ Entsprechende IAM-Berechtigungen zum Ändern der Cluster-Einstellungen und zum Erstellen von Amazon CloudWatch Logs-Ressourcen
## Aktivieren Sie die Ereigniserfassung über die Konsole
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version](https://console.aws.amazon.com/ecs/v2) 2.
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie den Cluster aus, in dem Sie die Ereigniserfassung aktivieren möchten.
Die Cluster-Detailseite wird angezeigt.
1. Wählen Sie **Konfiguration**.
1. Wählen Sie im Abschnitt **ECS-Ereignisse** die Option **Ereigniserfassung aktivieren** aus.
Das Dialogfeld „**Ereigniserfassung aktivieren**“ wird angezeigt.
1. Wählen Sie **für Expire event** den Aufbewahrungszeitraum für die Amazon CloudWatch Logs-Protokollgruppe aus. Die Standardeinstellung ist 7 Tage.
1. Wählen Sie **Turn on** (Einschalten) aus.
# Ereignisse zur Änderung des Amazon ECS-Service- und Aufgabenstatus anzeigen
Die Amazon ECS-Konsole bietet Funktionen zur Erfassung von Ereignissen, mit denen von Amazon ECS generierte Ereignisse, wie Serviceaktionen und Änderungen des Aufgabenstatus, in Amazon CloudWatch Logs gespeichert werden. EventBridge Diese Funktion umfasst eine Abfrageschnittstelle mit Filterfunktionen zur Verbesserung der Überwachung und Fehlerbehebung.
Ereignisse bieten detaillierte Informationen darüber, wie Ihre Servicebereitstellungen, Services, Aufgaben und Instances funktionieren. Sie können diese Informationen verwenden, um Fehler bei der Bereitstellung von Aufgaben oder Services zu beheben.
Sie können jedes der folgenden Kriterien verwenden, um die Ereignisse zu filtern:
+ Bereitstellungs-ID (Diese ist nur auf der Service-Detailseite verfügbar)
+ Startzeit
+ Endzeit
+ Dienstname (gilt nur auf der Cluster-Detailseite, auf der Dienstdetailseite, dies ist standardmäßig der aktuelle Dienst)
+ Aufgaben-ID
+ Letzter Status der Aufgabe
+ Familie der Aufgabendefinitionen
+ Überarbeitung der Aufgabendefinition
## Ereignisse auf Cluster-Ebene anzeigen
1. [Öffnen Sie die Konsole auf Version 2. https://console.aws.amazon.com/ecs/](https://console.aws.amazon.com/ecs/v2)
1. Klicken Sie auf **Cluster**.
Die Seite mit der Cluster-Liste wird angezeigt.
1. Wählen Sie den Cluster aus.
Die Cluster-Detailseite wird angezeigt.
1. Legen Sie unter **Verlauf** fest, welche Ereignisse angezeigt werden sollen.
1. Um Serviceaktionsereignisse anzuzeigen, wählen Sie **Serviceaktionsereignisse** aus.
1. Um Ereignisse zur Änderung des Aufgabenstatus anzuzeigen, wählen Sie Ereignisse zur **Änderung des Aufgabenstatus** aus.
1. (Optional) Geben Sie im Feld **Abfragekriterien** die Filter für die Ereignisse ein, die Sie anzeigen möchten.
1. Wählen Sie **Abfrage ausführen**.
Die Ereignisse werden in einer Liste angezeigt.
1. Um die vollständigen Details des Ereignisses anzuzeigen, wählen Sie das Ereignis aus.
## Anzeige auf Serviceebene
1. Öffnen Sie die Konsole auf [https://console.aws.amazon.com/ecs/Version 2.](https://console.aws.amazon.com/ecs/v2)
1. Wählen Sie auf der **Cluster**-Seite den Cluster aus.
1. Wählen Sie auf der Seite mit den Cluster-Details im Abschnitt **Services** den Service aus.
Die Seite mit den Service-Details wird angezeigt.
1. Legen Sie unter **Verlauf** fest, welche Ereignisse angezeigt werden sollen.
1. Um Serviceaktionsereignisse anzuzeigen, wählen Sie **Serviceaktionsereignisse** aus.
1. Um Ereignisse zur Änderung des Aufgabenstatus anzuzeigen, wählen Sie Ereignisse zur **Änderung des Aufgabenstatus** aus.
1. (Optional) Geben Sie im Feld **Abfragekriterien** die Filter für die Ereignisse ein, die Sie anzeigen möchten.
1. Wählen Sie **Abfrage ausführen**.
Die Ereignisse werden in einer Liste angezeigt.
1. Um die vollständigen Details des Ereignisses anzuzeigen, wählen Sie das Ereignis aus.
# Fehlerbehebung bei ungültigen CPU- oder Arbeitsspeicher-Fehlern in der Amazon-ECS-Aufgabendefinition
Bei der Registrierung einer Aufgabendefinition mithilfe der Amazon ECS-API oder AWS CLI, wenn Sie einen ungültigen `cpu` `memory` Wert angeben, wird der folgende Fehler zurückgegeben.
```
An error occurred (ClientException) when calling the RegisterTaskDefinition operation: Invalid 'cpu' setting for task.
```
**Anmerkung**
Bei Verwendung von Terraform kann der folgende Fehler zurückgegeben werden.
```
Error: ClientException: No Fargate configuration exists for given values.
```
Um dieses Problem zu lösen, müssen Sie in Ihrer Aufgabendefinition einen unterstützten Wert für die Aufgaben-CPU und den Speicher angeben. Der `cpu` Wert kann in CPU-Einheiten oder in V CPUs in einer Aufgabendefinition ausgedrückt werden. Wenn die Aufgabendefinition registriert ist, wird ein Wert in eine Ganzzahl umgewandelt, die die CPU-Einheiten angibt. Der `memory`-Wert kann in einer Aufgabendefinition in MiB oder GiB ausgedrückt werden. Wenn die Aufgabendefinition registriert ist, wird ein Wert in eine Ganzzahl umgewandelt, die die MiB angibt.
Für Aufgabendefinitionen, die `FARGATE` für den `requiresCompatibilities`-Parameter angeben (auch wenn `EC2` ebenso angegeben wird), müssen Sie einen der Werte aus der folgenden Tabelle verwenden. Diese Werte bestimmen den Bereich der unterstützten Werte für den CPU- und Speicherparameter.
Für Aufgaben, die auf Fargate gehostet werden, zeigt die folgende Tabelle die gültigen CPU- und Arbeitsspeicher-Kombinationen. Die Speicherwerte in der JSON-Datei sind in MiB angegeben. Sie können den GB-Wert in MiB konvertieren, indem Sie den Wert mit 1 024 multiplizieren. Zum Beispiel 1 GB = 1 024 MiB.
| CPU-Wert | Speicherwert | Für AWS Fargate unterstützte Betriebssysteme |
| --- | --- | --- |
| 256 (0,25 vCPU) | 512 MiB, 1 GB, 2 GB | Linux |
| 512 (0,5 vCPU) | 1 GB, 2 GB, 3 GB, 4 GB | Linux |
| 1024 (1 vCPU) | 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB | Linux, Windows |
| 2048 (2 vCPU) | Zwischen 4 GB und 16 GB in 1-GB-Schritten | Linux, Windows |
| 4096 (4 vCPU) | Zwischen 8 GB und 30 GB in 1-GB-Schritten | Linux, Windows |
| 8 192 (8 vCPU) Diese Option erfordert die Linux-Plattform `1.4.0` oder höher. | Zwischen 16 GB und 60 GB in 4-GB-Schritten | Linux |
| 16 384 (16 vCPU) Diese Option erfordert die Linux-Plattform `1.4.0` oder höher. | Zwischen 32 GB und 120 GB in 8-GB-Schritten | Linux |
Für Aufgaben, die auf Amazon EC2 gehostet werden, liegen die unterstützten Task-CPU-Werte zwischen 0,25 V CPUs und 192 V. CPUs
Der CPU-Steuerungsmechanismus unterscheidet sich zwischen EC2 und Fargate:
+ Für Aufgaben, die in Amazon EC2 gehostet werden: Amazon ECS verwendet den CPU-Zeitraum und das CPU-Kontingent, um die CPU-Festgrenzen für die Aufgabengröße zu steuern. Wenn Sie die vCPU in Ihrer Aufgabendefinition angeben, rechnet Amazon ECS den Wert im CPU-Zeitraum und die CPU-Kontingenteinstellungen um, die für `cgroup` gelten.
+ Für Aufgaben, die in Fargate gehostet werden: Amazon ECS verwendet CPU-Anteile zur Steuerung der CPU-Zuweisung. Die Werte für CPU-Kontingent und -Zeitraum werden nicht für die CPU-Begrenzung in Fargate-Aufgaben verwendet.
Bei Amazon-EC2-Aufgaben steuert das CPU-Kontingent die Menge an CPU-Zeit, die einer `cgroup` während eines bestimmten CPU-Zeitraums gewährt wird. Beide Einstellungen werden in Mikrosekunden ausgedrückt. Wenn das CPU-Kontingent der CPU-Periode entspricht, bedeutet das, dass a bis zu 100% auf einer vCPU ausgeführt werden `cgroup` kann (oder jeder andere Bruchteil, der bei mehreren V 100% ergibt). CPUs Das CPU-Kontingent hat ein Maximum von 1 000 000 us und der CPU-Zeitraum ein Minimum von 1 ms. Sie können diese Werte verwenden, um die Grenzwerte für Ihre CPU-Anzahl festzulegen. Wenn Sie den CPU-Zeitraum ändern, ohne das CPU-Kontingent zu ändern, gelten andere effektive Grenzwerte als die, die Sie in Ihrer Aufgabendefinition angegeben haben.
Der Zeitraum von 100 ms ermöglicht einen Wert von v im Bereich von CPUs 0,125 bis 10.
**Anmerkung**
CPU- und Speicherparameter auf Aufgabenebene werden für Windows-Container ignoriert.
# Protokolle des Amazon-ECS-Container-Agenten anzeigen
Amazon ECS speichert Protokolle im Ordner `/var/log/ecs` Ihrer Container-Instances. Es sind Protokolle vom Amazon-ECS-Container-Agenten und vom `ecs-init`-Service verfügbar, der den Status des Agenten (Start/Stopp) auf der Container-Instance kontrolliert. Sie können diese Protokolldateien anzeigen, indem Sie sich mithilfe von SSH mit der Container-Instance verbinden.
**Anmerkung**
Wenn Sie nicht sicher sind, wie Sie alle verschiedenen Protokolle auf Ihren Container-Instances sammeln können, können Sie den Amazon-ECS-Protokollsammler verwenden. Weitere Informationen finden Sie unter [Erfassung von Container-Protokollen mit Amazon ECS Log Collector](ecs-logs-collector.md).
## Linux Operating System
Der Prozess `ecs-init` speichert Protokolle unter `/var/log/ecs/ecs-init.log`.
Die `ecs-init.log`-Datei enthält Informationen über die Lebenszyklusverwaltung, die Konfiguration und das Bootstrapping des Container-Agenten.
Sie können den folgenden Befehl verwenden, um die Protokolldateien anzuzeigen.
```
cat /var/log/ecs/ecs-init.log
```
Ausgabe:
```
2018-02-16T18:13:54Z [INFO] pre-start
2018-02-16T18:13:56Z [INFO] start
2018-02-16T18:13:56Z [INFO] No existing agent container to remove.
2018-02-16T18:13:56Z [INFO] Starting Amazon Elastic Container Service Agent
```
## Windows Operating System
Sie können Amazon ECS Log Collector für Windows verwenden. Weitere Informationen finden Sie unter [Amazon ECS Logs Collector für Windows](https://github.com/awslabs/aws-ecs-logs-collector-for-windows?tab=readme-ov-file#aws-ecs-logs-collector-for-windows) auf Github.
1. Verbinden Sie sich mit der Instance.
1. Öffnen Sie die folgenden Befehle PowerShell und führen Sie sie dann mit Administratorrechten aus. Die Befehle laden das Skript herunter und erfassen die Protokolle.
```
Invoke-WebRequest -OutFile ecs-logs-collector.ps1 https://raw.githubusercontent.com/awslabs/aws-ecs-logs-collector-for-windows/master/ecs-logs-collector.ps1
.\ecs-logs-collector.ps1
```
Sie können die Debug-Protokollierung für den Amazon-ECS-Agenten und den Docker-Daemon aktivieren. Diese Option ermöglicht es dem Skript, die Protokolle zu erfassen, bevor der Debug-Modus aktiviert wird. Das Skript startet den Docker-Daemon und den Amazon-ECS-Agenten neu und beendet dann alle Container, die auf der Instance ausgeführt werden. Bevor Sie den folgenden Befehl ausführen, gleichen Sie die Container-Instance aus und verschieben Sie alle wichtigen Aufgaben auf andere Container-Instances.
Führen Sie folgenden Befehl aus, um die Protokollierung einzuschalten.
```
.\ecs-logs-collector.ps1 -RunMode debug
```
# Erfassung von Container-Protokollen mit Amazon ECS Log Collector
**Anmerkung**
Sie können Amazon ECS Log Collector nicht für Amazon ECS Managed Instances verwenden.
Wenn Sie nicht sicher sind, wie Sie all die verschiedenen Protokolle auf Ihren Container-Instances sammeln können, können Sie den Amazon-ECS-Protokollsammler verwenden. Es ist sowohl GitHub für [Linux](https://github.com/awslabs/ecs-logs-collector) als auch für [Windows](https://github.com/awslabs/aws-ecs-logs-collector-for-windows) verfügbar. Das Skript sammelt allgemeine Betriebssystemprotokolle sowie Docker- und Amazon ECS-Container-Agent-Protokolle, die bei der Fehlerbehebung hilfreich sein können AWS Support . Anschließend komprimiert und archiviert es die erfassten Informationen in einer einzigen Datei, die problemlos für Diagnosezwecke weitergegeben werden kann. Außerdem unterstützt es die Aktivierung des Debug-Modus für den Docker-Daemon und den Amazon-ECS-Container-Agenten auf Amazon Linux-Varianten, wie etwa das Amazon-ECS-optimierte AMI.
**Anmerkung**
Unter Amazon Linux, der für Amazon ECS optimierten AMIs Version 20250909 und höher, ist der Amazon ECS-Protokollsammler vorinstalliert und kann verwendet werden, ohne dass er von heruntergeladen werden `/opt/amazon/ecs/ecs-logs-collector.sh` muss. GitHub Weitere Informationen finden Sie unter [ECS Logs Collector](https://github.com/aws/amazon-ecs-ami?tab=readme-ov-file#ecs-logs-collector) in der ECS-optimierten AMI-Dokumentation.
Derzeit unterstützt der Amazon-ECS-Protokollsammler die folgenden Betriebssysteme:
+ Amazon Linux
+ Red Hat Enterprise Linux
+ Ubuntu
+ Windows Server
**So führen Sie den Amazon ECS Logs Collector für Linux aus (ECS-optimiertes AMI)**
1. Stellen Sie eine Verbindung mit Ihrer Container-Instance her.
1. Führen Sie das Skript aus, um die Protokolle zu erfassen und das Archiv zu erstellen.
**Anmerkung**
Um den Debug-Modus für den Docker-Daemon und den Amazon-ECS-Container-Agenten zu aktivieren, fügen Sie die Option `--mode=enable-debug` zum folgenden Befehl hinzu. Dies kann den Docker-Daemon möglicherweise neu starten, wodurch alle aktuell auf der Instance ausgeführten Container abgebrochen werden. Sie sollten in Betracht ziehen, die Container-Instance auszugleichen und alle wichtigen Aufgaben in andere Container-Instances zu verschieben, bevor Sie den Debug-Modus aktivieren. Weitere Informationen finden Sie unter [Entlastung von Amazon-ECS-Container-Instances](container-instance-draining.md).
```
[ec2-user ~]$ sudo /opt/amazon/ecs/ecs-logs-collector.sh
```
Nachdem Sie das Skript ausgeführt haben, können Sie die gesammelten Protokolle im Ordner `collect`, den das Skript erstellt hat, untersuchen. Bei der `collect.tgz` Datei handelt es sich um ein komprimiertes Archiv aller Protokolle, das Sie AWS Support zur Diagnoseunterstützung zur Verfügung stellen können.
**So laden Sie den Amazon-ECS-Protokollsammler für Linux herunter und führen ihn aus**
1. Stellen Sie eine Verbindung mit Ihrer Container-Instance her.
1. Laden Sie das Skript des Amazon-ECS-Protokollsammlers herunter.
```
curl -O https://raw.githubusercontent.com/awslabs/ecs-logs-collector/master/ecs-logs-collector.sh
```
1. Führen Sie das Skript aus, um die Protokolle zu erfassen und das Archiv zu erstellen.
```
$ sudo bash ./ecs-logs-collector.sh
```
**So laden Sie den Amazon-ECS-Protokollsammler für Windows herunter und führen ihn aus**
1. Stellen Sie eine Verbindung mit Ihrer Container-Instance her. Weitere Informationen finden Sie unter [Herstellen einer Verbindung mit Ihrer Windows-Instance über RDP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecting_to_windows_instance.html) im *Amazon-EC2-Benutzerhandbuch*.
1. Laden Sie das Amazon ECS-Logs-Collector-Skript mit herunter PowerShell.
```
Invoke-WebRequest -OutFile ecs-logs-collector.ps1 https://raw.githubusercontent.com/awslabs/aws-ecs-logs-collector-for-windows/master/ecs-logs-collector.ps1
```
1. Führen Sie das Skript aus, um die Protokolle zu erfassen und das Archiv zu erstellen.
**Anmerkung**
Um den Debug-Modus für den Docker-Daemon und den Amazon-ECS-Container-Agenten zu aktivieren, fügen Sie die Option `-RunMode debug` zum folgenden Befehl hinzu. Dies startet den Docker-Daemon neu, wodurch alle aktuell auf der Instance ausgeführten Container gestoppt werden. Sie sollten in Betracht ziehen, die Container-Instance auszugleichen und alle wichtigen Aufgaben in andere Container-Instances zu verschieben, bevor Sie den Debug-Modus aktivieren. Weitere Informationen finden Sie unter [Entlastung von Amazon-ECS-Container-Instances](container-instance-draining.md).
```
.\ecs-logs-collector.ps1
```
Nachdem Sie das Skript ausgeführt haben, können Sie die gesammelten Protokolle im Ordner `collect`, den das Skript erstellt hat, untersuchen. Bei der `collect.tgz` Datei handelt es sich um ein komprimiertes Archiv aller Protokolle, das Sie mit dem AWS Support teilen können, um Hilfe bei der Diagnose zu erhalten.
# Amazon-ECS-Diagnosedetails mit Agent-Introspektion
Die Introspektions-API des Amazon-ECS-Agenten bietet Informationen über den Gesamtstatus des Amazon-ECS-Agenten und der Container-Instances.
Sie können mithilfe der Agent-Introspektions-API die Docker-ID für einen Container in der Aufgabe erhalten. Sie können die Agenten-Introspektions-API verwenden, indem Sie sich mithilfe von SSH mit einer Container-Instance verbinden.
**Wichtig**
Ihre Container-Instance muss über eine IAM-Rolle verfügen, die den Zugriff auf Amazon ECS erlaubt, um die Introspektions-API zu erreichen. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon-ECS-Container-Instance](instance_IAM_role.md).
Das Beispiel unten zeigt zwei Aufgaben, eine, die derzeit ausgeführt wird und eine, die angehalten wurde.
**Anmerkung**
Der Befehl unten wird durch **python -mjson.tool** geleitet, um besser lesbar zu sein.
```
curl http://localhost:51678/v1/tasks | python -mjson.tool
```
Ausgabe:
```
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1095 100 1095 0 0 117k 0 --:--:-- --:--:-- --:--:-- 133k
{
"Tasks": [
{
"Arn": "arn:aws:ecs:us-west-2:aws_account_id:task/090eff9b-1ce3-4db6-848a-a8d14064fd24",
"Containers": [
{
"DockerId": "189a8ff4b5f04affe40e5160a5ffadca395136eb5faf4950c57963c06f82c76d",
"DockerName": "ecs-console-sample-app-static-6-simple-app-86caf9bcabe3e9c61600",
"Name": "simple-app"
},
{
"DockerId": "f7f1f8a7a245c5da83aa92729bd28c6bcb004d1f6a35409e4207e1d34030e966",
"DockerName": "ecs-console-sample-app-static-6-busybox-ce83ce978a87a890ab01",
"Name": "busybox"
}
],
"Family": "console-sample-app-static",
"KnownStatus": "STOPPED",
"Version": "6"
},
{
"Arn": "arn:aws:ecs:us-west-2:aws_account_id:task/1810e302-eaea-4da9-a638-097bea534740",
"Containers": [
{
"DockerId": "dc7240fe892ab233dbbcee5044d95e1456c120dba9a6b56ec513da45c38e3aeb",
"DockerName": "ecs-console-sample-app-static-6-simple-app-f0e5859699a7aecfb101",
"Name": "simple-app"
},
{
"DockerId": "096d685fb85a1ff3e021c8254672ab8497e3c13986b9cf005cbae9460b7b901e",
"DockerName": "ecs-console-sample-app-static-6-busybox-92e4b8d0ecd0cce69a01",
"Name": "busybox"
}
],
"DesiredStatus": "RUNNING",
"Family": "console-sample-app-static",
"KnownStatus": "RUNNING",
"Version": "6"
}
]
}
```
Im vorherigen Beispiel hat die gestoppte Aufgabe (*090eff9b-1ce3-4db6-848a-a8d14064fd24*) zwei Container. Mit **docker inspect *container-ID*** können Sie detaillierte Informationen zu jedem Container anzeigen. Weitere Informationen finden Sie unter [Amazon-ECS-Container-Introspektion](ecs-agent-introspection.md).
# Docker-Diagnose in Amazon ECS
Docker bietet mehrere Diagnosetools, die bei der Behebung von Problemen mit Ihren Containern und Aufgaben helfen. Weitere Informationen über alle verfügbaren Docker-Befehlszeilen-Tools finden Sie in der [Docker-CLI-Referenz](https://docs.docker.com/reference/cli/docker/) in der Docker-Dokumentation. Sie können auf die Docker-Befehlszeilen-Tools zugreifen, indem Sie mithilfe von SSH eine Verbindung zu einer Container-Instance herstellen.
Die Exitcodes, die Docker-Container berichten, können auch Diagnoseinformationen enthalten (zum Beispiel bedeutet Exitcode 137, dass der Container ein Signal `SIGKILL` empfangen hat). Weitere Informationen finden Sie unter [Exit Status](https://docs.docker.com/reference/cli/docker/container/run/#exit-status) in der Docker-Dokumentation.
## Docker-Container in Amazon ECS auflisten
Sie können mithilfe des Befehls **docker ps** auf Ihrer Container-Instance die Container auflisten, die gerade ausgeführt werden. Im folgenden Beispiel wird nur der Amazon-ECS-Container-Agent ausgeführt. Weitere Informationen finden Sie unter [docker ps](https://docs.docker.com/reference/cli/docker/#ps) in der Docker-Dokumentation.
```
docker ps
```
Ausgabe:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
cee0d6986de0 amazon/amazon-ecs-agent:latest "/agent" 22 hours ago Up 22 hours 127.0.0.1:51678->51678/tcp ecs-agent
```
Sie können mithilfe des Befehls **docker ps -a** alle Container anzeigen (auch gestoppte oder abgebrochene Container). Dies ist hilfreich, um Container aufzulisten, die unerwartet gestoppt wurden. Im folgenden Beispiel wurde der Container `f7f1f8a7a245` vor 9 Sekunden beendet, daher wird er in einer **docker ps**-Ausgabe ohne das Flag `-a` nicht aufgeführt.
```
docker ps -a
```
Ausgabe:
```
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
db4d48e411b1 amazon/ecs-emptyvolume-base:autogenerated "not-applicable" 19 seconds ago ecs-console-sample-app-static-6-internalecs-emptyvolume-source-c09288a6b0cba8a53700
f7f1f8a7a245 busybox:buildroot-2014.02 "\"sh -c '/bin/sh -c 22 hours ago Exited (137) 9 seconds ago ecs-console-sample-app-static-6-busybox-ce83ce978a87a890ab01
189a8ff4b5f0 httpd:2 "httpd-foreground" 22 hours ago Exited (137) 40 seconds ago ecs-console-sample-app-static-6-simple-app-86caf9bcabe3e9c61600
0c7dca9321e3 amazon/ecs-emptyvolume-base:autogenerated "not-applicable" 22 hours ago ecs-console-sample-app-static-6-internalecs-emptyvolume-source-90fefaa68498a8a80700
cee0d6986de0 amazon/amazon-ecs-agent:latest "/agent" 22 hours ago Up 22 hours 127.0.0.1:51678->51678/tcp ecs-agent
```
## Docker-Protokolle in Amazon ECS anzeigen
Sie können die Streams `STDOUT` und `STDERR` für einen Container mithilfe des Befehls **docker logs** anzeigen. In diesem Beispiel werden die Protokolle für den *dc7240fe892a* Container angezeigt und der Kürze halber über den **head** Befehl weitergeleitet. Weitere Informationen finden Sie unter [docker logs](https://docs.docker.com/reference/cli/docker/#logs) in der Docker-Dokumentation.
**Anmerkung**
Docker-Protokolle stehen nur in der Container-Instance zur Verfügung, wenn Sie den Standardtreiber für `json`-Protokolle verwenden. Wenn Sie Ihre Aufgaben für die Verwendung des `awslogs` Protokolltreibers konfiguriert haben, sind Ihre Container-Protokolle unter Logs verfügbar. CloudWatch Weitere Informationen finden Sie unter [Amazon ECS-Protokolle senden an CloudWatch](using_awslogs.md).
```
docker logs dc7240fe892a | head
```
Ausgabe:
```
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.11. Set the 'ServerName' directive globally to suppress this message
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.11. Set the 'ServerName' directive globally to suppress this message
[Thu Apr 23 19:48:36.956682 2015] [mpm_event:notice] [pid 1:tid 140327115417472] AH00489: Apache/2.4.12 (Unix) configured -- resuming normal operations
[Thu Apr 23 19:48:36.956827 2015] [core:notice] [pid 1:tid 140327115417472] AH00094: Command line: 'httpd -D FOREGROUND'
10.0.1.86 - - [23/Apr/2015:19:48:59 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:48:59 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:49:28 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:49:29 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:49:50 +0000] "-" 408 -
10.0.0.154 - - [23/Apr/2015:19:49:50 +0000] "-" 408 -
10.0.1.86 - - [23/Apr/2015:19:49:58 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:49:59 +0000] "GET / HTTP/1.1" 200 348
10.0.1.86 - - [23/Apr/2015:19:50:28 +0000] "GET / HTTP/1.1" 200 348
10.0.0.154 - - [23/Apr/2015:19:50:29 +0000] "GET / HTTP/1.1" 200 348
time="2015-04-23T20:11:20Z" level="fatal" msg="write /dev/stdout: broken pipe"
```
## Docker-Container in Amazon ECS untersuchen
Wenn Sie die Docker-ID eines Containers haben, können Sie ihn mithilfe des Befehls **docker inspect** untersuchen. Die Untersuchung von Containern bietet die detaillierteste Ansicht der Umgebung, in der der Container gestartet wurde. Weitere Informationen finden Sie unter [docker inspect](https://docs.docker.com/reference/cli/docker/#inspect) in der Docker-Dokumentation.
```
docker inspect dc7240fe892a
```
Ausgabe:
```
[{
"AppArmorProfile": "",
"Args": [],
"Config": {
"AttachStderr": false,
"AttachStdin": false,
"AttachStdout": false,
"Cmd": [
"httpd-foreground"
],
"CpuShares": 10,
"Cpuset": "",
"Domainname": "",
"Entrypoint": null,
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/apache2/bin",
"HTTPD_PREFIX=/usr/local/apache2",
"HTTPD_VERSION=2.4.12",
"HTTPD_BZ2_URL=https://www.apache.org/dist/httpd/httpd-2.4.12.tar.bz2"
],
"ExposedPorts": {
"80/tcp": {}
},
"Hostname": "dc7240fe892a",
...
```
# Konfiguration der ausführlichen Ausgabe vom Docker-Daemon in Amazon ECS
Wenn Sie Probleme mit Docker-Containern oder -Images haben, können Sie den Debug-Modus für Ihren Docker-Daemon aktivieren. Die Verwendung von Debugging bietet eine ausführlichere Ausgabe vom Daemon. Sie können damit Fehlermeldungen abrufen, die von Container-Registrys wie Amazon ECR gesendet werden.
**Wichtig**
Dieses Verfahren wurde für das Amazon-ECS-optimierte Amazon Linux AMI geschrieben. Informationen zu anderen Betriebssystemen finden Sie unter [Debugging aktivieren](https://docs.docker.com/engine/admin/#enable-debugging) und [Docker mit systemd steuern und konfigurieren]() in der Docker-Dokumentation.
**So aktivieren Sie den Debug-Modus des Docker-Daemon im Amazon-ECS-optimierten Amazon-Linux-AMI**
1. Stellen Sie eine Verbindung mit Ihrer Container-Instance her.
1. Öffnen Sie die Datei mit den Docker-Optionen in einem Text-Editor, wie z. B. **vi**. Für das Amazon-ECS-optimierte Amazon Linux AMI befindet sich die Datei mit den Docker-Optionen unter `/etc/sysconfig/docker`.
1. Suchen Sie nach der Anweisung für die Docker-Optionen und fügen Sie die Option `-D` in Anführungszeichen zur Zeichenfolge hinzu.
**Anmerkung**
Wenn die Anweisung für die Docker-Optionen mit einem `#` beginnt, entfernen Sie dieses Zeichen, um die Auskommentierung der Anweisung aufzuheben und die Optionen zu aktivieren.
Für das Amazon-ECS-optimierte Amazon Linux AMI wird die Anweisung für die Docker-Optionen `OPTIONS` genannt. Zum Beispiel:
```
# Additional startup options for the Docker daemon, for example:
# OPTIONS="--ip-forward=true --iptables=true"
# By default we limit the number of open files per container
OPTIONS="-D --default-ulimit nofile=1024:4096"
```
1. Speichern Sie die Datei und beenden Sie den Text-Editor.
1. Starten Sie den Docker-Daemon erneut.
```
sudo service docker restart
```
Die Ausgabe sieht wie folgt aus:
```
Stopping docker: [ OK ]
Starting docker: . [ OK ]
```
1. Starten Sie den Amazon-ECS-Agenten neu.
```
sudo service ecs restart
```
Ihre Docker-Protokolle sollten jetzt mehr Informationen enthalten.
```
time="2015-12-30T21:48:21.907640838Z" level=debug msg="Unexpected response from server: \"{\\\"errors\\\":[{\\\"code\\\":\\\"DENIED\\\",\\\"message\\\":\\\"User: arn:aws:sts::1111:assumed-role/ecrReadOnly/i-abcdefg is not authorized to perform: ecr:InitiateLayerUpload on resource: arn:aws:ecr:us-east-1:1111:repository/nginx_test\\\"}]}\\n\" http.Header{\"Connection\":[]string{\"keep-alive\"}, \"Content-Type\":[]string{\"application/json; charset=utf-8\"}, \"Date\":[]string{\"Wed, 30 Dec 2015 21:48:21 GMT\"}, \"Docker-Distribution-Api-Version\":[]string{\"registry/2.0\"}, \"Content-Length\":[]string{\"235\"}}"
```
# Fehlerbehebung beim Docker-`API error (500): devmapper` in Amazon ECS
Der folgende Docker-Fehler gibt an, dass der Thin-Pool-Speicher für Ihre Container-Instance vollständig belegt ist und der Docker-Daemon keine neuen Container erstellen kann:
```
CannotCreateContainerError: API error (500): devmapper: Thin Pool has 4350 free data blocks which is less than minimum required 4454 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior
```
Standardmäßig wird Amazon ECS-optimiertes Amazon Linux AMIs ab Version `2015.09.d` und höher mit einem 8-GiB-Volume für das Betriebssystem gestartet, das an das Dateisystem angehängt `/dev/xvda` und als Stammverzeichnis des Dateisystems bereitgestellt ist. Es gibt ein zusätzliches 22-GiB-Volume, das unter `/dev/xvdcz` angefügt ist und das von Docker zum Speichern von Images und Metadaten verwendet wird. Wenn dieser Speicherplatz voll ist, kann der Docker-Daemon keine neuen Container mehr erstellen.
Der einfachste Weg, Speicher zu Container-Instances hinzuzufügen, besteht darin, die bestehenden Instances zu beenden und neue mit größeren Datenspeichervolumes zu starten. Wenn Sie das allerdings nicht tun können, können Sie Speicher zu der Volume-Gruppe hinzufügen, die Docker verwendet, und sein logisches Volume mithilfe der Verfahren in [Amazon ECS-optimiertes Linux AMIs](ecs-optimized_AMI.md) erweitern.
Wenn sich der Speicher Ihrer Container-Instance zu schnell füllt, können Sie einige Maßnahmen ergreifen, um diesen Effekt zu reduzieren:
+ Führen Sie den folgenden Befehl für Ihre Container-Instance aus, um die Thin Poll-Informationen anzuzeigen:
```
docker info
```
+ (Amazon-ECS-Container-Agent 1.8.0 und später) Sie können die Dauer reduzieren, die angehaltene oder beendete Container auf Ihren Container-Instances bleiben. Die Variable zur Agentenkonfiguration `ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION` stellt die Zeitdauer ein, die gewartet wird, von dem Zeitpunkt, zu dem eine Aufgabe gestoppt wird, bis zu dem Zeitpunkt, zu dem der Docker-Container entfernt wird (standardmäßig beträgt dieser Wert 3 Stunden). Dadurch werden die Daten des Docker-Containers entfernt. Wenn dieser Wert zu niedrig eingestellt ist, können Sie möglicherweise Ihre gestoppten Container nicht untersuchen oder die Protokolle nicht anzeigen, bevor sie entfernt werden. Weitere Informationen finden Sie unter [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md).
+ Sie können Container, die nicht ausgeführt werden, und nicht verwendete Images von Ihren Container-Instances entfernen. Sie können mithilfe der folgenden Beispielbefehle gestoppte Container und nicht verwendete Images manuell löschen. Gelöschte Container können später nicht geprüft werden und gelöschte Images müssen noch mal abgerufen werden, bevor neue Container von ihnen gestartet werden können.
Um nicht ausgeführte Container zu entfernen, führen Sie den folgenden Befehl auf Ihrer Container-Instance aus:
```
docker rm $(docker ps -aq)
```
Um nicht verwendete Images zu entfernen, führen Sie den folgenden Befehl auf Ihrer Container-Instance aus:
```
docker rmi $(docker images -q)
```
+ Sie können nicht verwendete Datenblöcke aus Containern entfernen. Mithilfe des folgenden Befehls können Sie **fstrim** auf jedem laufenden Container ausführen und alle Datenblöcke verwerfen, die von dem Container-Dateisystem nicht verwendet werden.
```
sudo sh -c "docker ps -q | xargs docker inspect --format='{{ .State.Pid }}' | xargs -IZ fstrim /proc/Z/root/"
```
# Fehlerbehebung bei Amazon-ECS-Exec-Problemen
Im Folgenden finden Sie Hinweise zur Fehlerbehebung, um zu diagnostizieren, warum Sie bei der Verwendung von ECS Exec einen Fehler erhalten.
## Überprüfen mit dem Exec Checker
Das ECS-Exec-Checker-Skript bietet eine Möglichkeit, zu überprüfen und zu bestätigen, ob Ihr Amazon-ECS-Cluster und Ihre Aufgabe die Voraussetzungen für die Verwendung des ECS-Exec-Features erfüllt haben. Das ECS Exec Checker-Skript überprüft, ob sowohl Ihre AWS CLI Umgebung als auch Ihr Cluster und die Aufgaben für ECS Exec bereit sind, indem es verschiedene in Ihrem Namen aufruft. APIs Das Tool benötigt die neueste Version von AWS CLI und muss verfügbar sein. `jq` Weitere Informationen finden Sie unter [ECS Exec Checker](https://github.com/aws-containers/amazon-ecs-exec-checker) unter. GitHub
## Fehler beim Aufruf von `execute-command`
Wenn ein `The execute command failed`-Fehler auftritt, könnte folgendes die möglichen Ursachen sein.
+ Der Task verfügt nicht über die erforderlichen Berechtigungen. Stellen Sie sicher, dass für die Aufgabendefinition, die zum Starten der Aufgabe verwendet wird, eine Aufgaben-IAM-Rolle definiert ist und dass die Rolle über die erforderlichen Berechtigungen verfügt. Weitere Informationen finden Sie unter [ECS-Exec-Berechtigungen](task-iam-roles.md#ecs-exec-required-iam-permissions).
+ Der SSM-Agent ist nicht installiert oder wird nicht ausgeführt.
+ Es gibt einen Amazon-VPC-Schnittstellen-Endpunkt für Amazon ECS, aber es gibt keinen für Systems Manager Session Manager.
# Fehlerbehebung bei Amazon-ECS-Anywhere-Problemen
Amazon ECS Anywhere bietet Unterstützung für die Registrierung einer *externen Instance*, z. B. eines On-Premises-Servers oder einer virtuellen Maschine (VM), in Ihrem Amazon-ECS-Cluster. Im Folgenden finden Sie häufig auftretende Probleme sowie allgemeine Empfehlungen zur Fehlerbehebung für sie.
**Topics**
+ [Registrierungsprobleme bei externen Instances](#ecs-anywhere-troubleshooting-registration)
+ [Netzwerkprobleme mit externen Instances](#ecs-anywhere-troubleshooting-networking)
+ [Probleme beim Ausführen von Aufgaben auf Ihrer externen Instance](#ecs-anywhere-troubleshooting-runtask)
## Registrierungsprobleme bei externen Instances
Wenn Sie eine externe Instance bei Ihrem Amazon-ECS-Cluster registrieren, müssen folgende Anforderungen erfüllt sein:
+ Eine AWS Systems Manager Aktivierung, die aus einer *Aktivierungs-ID und einem *Aktivierungscode** besteht, muss abgerufen werden. Sie verwenden sie, um die externe Instance als verwaltete Instance von Systems Manager zu registrieren. Wenn eine Systems-Manager-Aktivierung angefordert wird, können Sie ein Registrierungslimit und ein Ablaufdatum angeben. Die Registrierungsgrenze gibt die maximale Anzahl der Instances an, die mit der Aktivierung registriert werden können. Der Standardwert für das Registrierungslimit ist `1` Instance. Das Ablaufdatum gibt an, wann die Aktivierung abläuft. Der Standardwert beträgt 24 Stunden. Wenn die Systems Manager-Aktivierung, die Sie zur Registrierung Ihrer externen Instance verwenden, nicht gültig ist, fordern Sie eine neue an. Weitere Informationen finden Sie unter [Registrieren einer externen Instance in einem Amazon-ECS-Cluster](ecs-anywhere-registration.md).
+ Eine IAM-Richtlinie wird verwendet, um Ihrer externen Instanz die Berechtigungen zu gewähren, die sie für die Kommunikation mit AWS API-Vorgängen benötigt. Wenn diese verwaltete Richtlinie nicht ordnungsgemäß erstellt wurde und nicht die erforderlichen Berechtigungen enthält, schlägt die Registrierung externer Instances fehl. Weitere Informationen finden Sie unter [IAM-Rolle für Amazon ECS Anywhere](iam-role-ecsanywhere.md).
+ Amazon ECS stellt ein Installationsskript bereit, das Docker, den Amazon-ECS-Container Agent und den Systems Manager Agent auf Ihrer externen Instance installiert. Wenn das Installationsskript fehlschlägt, kann das Skript wahrscheinlich nicht erneut auf derselben Instance ausgeführt werden, ohne dass ein Fehler auftritt. Folgen Sie in diesem Fall dem Bereinigungsprozess, um AWS Ressourcen aus der Instanz zu löschen, sodass Sie das Installationsskript erneut ausführen können. Weitere Informationen finden Sie unter [Abmelden einer externen Amazon-ECS-Instance](ecs-anywhere-deregistration.md).
**Anmerkung**
Beachten Sie, dass, wenn das Installationsskript die Aktivierung von Systems Manager erfolgreich angefordert und verwendet hat, die Aktivierung des Systems Managers erneut verwendet wird, wenn das Installationsskript ein zweites Mal ausgeführt wird. Dies kann wiederum dazu führen, dass Sie das Registrierungslimit für diese Aktivierung erreichen. Wenn diese Limits erreicht ist, müssen Sie eine neue Aktivierung erstellen.
+ Wenn Sie das Installationsskript auf einer externen Instance für GPU-Workloads ausführen, tritt ein Fehler auf, wenn der NVIDIA-Treiber nicht richtig erkannt oder konfiguriert wird. Das Installationsskript verwendet den `nvidia-smi`-Befehl, um das Vorhandensein des NVIDIA-Treibers zu bestätigen.
## Netzwerkprobleme mit externen Instances
Um Änderungen mitzuteilen, benötigt Ihre externe Instance eine Netzwerkverbindung zu AWS. Wenn Ihre externe Instance ihre Netzwerkverbindung zu verliert, werden Aufgaben AWS, die auf Ihren Instances ausgeführt werden, trotzdem weiter ausgeführt, sofern sie nicht manuell beendet werden. Nachdem die Verbindung zu wiederhergestellt AWS ist, werden die AWS Anmeldeinformationen, die vom Amazon ECS-Container-Agenten und dem Systems Manager Manager-Agenten auf der externen Instance verwendet werden, automatisch erneuert. Weitere Informationen zu den AWS Domänen, die für die Kommunikation zwischen Ihrer externen Instance und verwendet werden AWS, finden Sie unter[Netzwerk](ecs-anywhere.md#ecs-anywhere-networking).
## Probleme beim Ausführen von Aufgaben auf Ihrer externen Instance
Wenn Ihre Aufgaben oder Container auf Ihrer externen Instance nicht ausgeführt werden können, sind die häufigsten Ursachen entweder netzwerk- oder berechtigungsbezogen. Wenn Ihre Container ihre Images von Amazon ECR abrufen oder so konfiguriert sind, dass sie Container-Logs an CloudWatch Logs senden, muss Ihre Aufgabendefinition eine gültige IAM-Rolle für die Aufgabenausführung angeben. Ohne eine gültige IAM-Rolle für die Aufgabenausführung können Ihre Container nicht gestartet werden. Weitere Informationen zu Netzwerkproblemen finden Sie unter [Netzwerkprobleme mit externen Instances](#ecs-anywhere-troubleshooting-networking).
**Wichtig**
Amazon ECS bietet das Tool zur Erfassung von Amazon-ECS-Protokollen. Sie können es verwenden, um Protokolle von Ihren externen Instances zu Fehlerbehebungszwecken zu sammeln. Weitere Informationen finden Sie unter [Erfassung von Container-Protokollen mit Amazon ECS Log Collector](ecs-logs-collector.md).
# Fehlerbehebung bei Problemen beim Laden von Java-Klassen in Fargate
Java-Anwendungen, die in Fargate ausgeführt werden, können nach Plattformupdates auf Probleme beim Laden von Klassen stoßen, insbesondere wenn die Anwendung auf einem nicht deterministischen Verhalten beim Laden von Klassen basiert. Dies kann sich in Fehlern bei der Injektion von Abhängigkeiten, Spring-Boot-Fehlern oder anderen Laufzeitausnahmen äußern, die in früheren Bereitstellungen nicht vorhanden waren.
## Symptome
Möglicherweise treten die folgenden Symptome auf:
+ Spring-Boot-Fehler bei der Abhängigkeits-Injektion
+ ClassNotFoundException oder Ausnahmen NoClassDefFoundError
+ Anwendungen, die zuvor in Fargate funktionierten, schlagen jetzt zeitweise fehl
+ Das gleiche Container-Image funktioniert in Amazon EC2, schlägt aber in Fargate fehl
+ Inkonsistentes Verhalten bei Bereitstellungen mit identischen Container-Images
## Ursachen
Diese Probleme treten in der Regel aufgrund folgender Ursachen auf:
+ **Nicht deterministisches Laden von Klassen:** Java-Anwendungen, die von der Reihenfolge abhängen, in der Klassen aus JAR-Dateien geladen werden, können fehlschlagen, wenn die zugrunde liegende Plattform die Art und Weise ändert, wie auf Dateien zugegriffen oder zwischengespeichert wird.
+ **Plattformupdates:** Versionsupdates der Fargate-Plattform können das Verhalten des zugrunde liegenden Dateisystems ändern und sich auf die Reihenfolge auswirken, in der Klassen erkannt und geladen werden.
+ **Abhängigkeiten bei der Reihenfolge von JAR-Dateien:** Anwendungen, die sich implizit auf bestimmte JAR-Ladesequenzen ohne explizites Abhängigkeitsmanagement verlassen.
## Auflösung
Um Probleme beim Laden von Java-Klassen in Fargate zu lösen, implementieren Sie deterministische Methoden zum Laden von Klassen:
### Schnellreparatur
Wenn Sie eine sofortige Problemumgehung benötigen:
1. **JAR-Ladereihenfolge erzwingen:** Geben Sie in der Klassenpfadkonfiguration Ihrer Anwendung explizit die Reihenfolge an, in der JAR-Dateien geladen werden sollen.
1. **Verwenden Sie explizites Abhängigkeitsmanagement:** Stellen Sie sicher, dass alle Abhängigkeiten in Ihrer Build-Konfiguration (Maven, Gradle usw.) explizit deklariert sind, anstatt sich auf transitive Abhängigkeiten zu verlassen.
### Langfristige bewährte Methoden
Implementieren Sie diese Methoden, um zukünftige Probleme beim Laden von Klassen zu vermeiden:
1. **Machen Sie das Laden von Klassen deterministisch:**
+ Verwenden Sie explizite Abhängigkeitsdeklarationen in Ihren Build-Dateien.
+ Vermeiden Sie es, sich auf die Reihenfolge beim Scannen von Klassenpfaden zu verlassen.
+ Verwenden Sie Tools zur Abhängigkeitsverwaltung, um Versionskonflikte zu lösen.
+ Verwenden Sie die Optionen der Java Virtual Machine (JVM) wie `-verbose:class`, um Informationen über Klassen abzurufen, die von JVM geladen wurden.
1. **Spring-Boot-Anwendungen:**
+ Verwenden Sie `@ComponentScan` mit expliziten Basispaketen.
+ Vermeiden Sie Autokonfigurationskonflikte, indem Sie Beans explizit konfigurieren.
+ Verwenden Sie `@DependsOn`-Anmerkungen, um die Reihenfolge der Bean-Initialisierung zu steuern.
1. **Konfiguration erstellen:**
+ Verwenden Sie Abschnitte zur Abhängigkeitsverwaltung in Maven oder Gradle.
+ Schließen Sie transitive Abhängigkeiten aus, die Konflikte verursachen.
+ Verwenden Sie Tools wie das Maven Enforcer Plugin, um Abhängigkeitsprobleme zu erkennen.
1. **Testen:**
+ Testen Sie Ihre Anwendung mit verschiedenen JVM-Implementierungen.
+ Führen Sie Integrationstests durch, die verschiedene Bereitstellungsumgebungen simulieren.
+ Verwenden Sie Tools, um Klassenpfadkonflikte während der Entwicklung zu analysieren.
## Prävention
Um Probleme beim Laden von Java-Klassen in zukünftigen Bereitstellungen zu verhindern:
+ **Folgen Sie den deterministischen Methoden zum Laden von Klassen:** Entwerfen Sie Ihre Anwendung so, dass sie nicht von der Reihenfolge abhängt, in der Klassen aus dem Klassenpfad geladen werden.
+ **Verwenden Sie explizites Abhängigkeitsmanagement:** Deklarieren Sie immer explizit alle erforderlichen Abhängigkeiten und ihre Versionen in Ihrer Build-Konfiguration.
+ **Umgebungsübergreifend testen:** Testen Sie Ihre Anwendungen regelmäßig in verschiedenen Umgebungen und Plattformversionen, um potenzielle Probleme frühzeitig zu erkennen.
+ **Überwachen Sie Plattformupdates:** Bleiben Sie über Fargate-Plattformupdates auf dem Laufenden und testen Sie Ihre Anwendungen mit neuen Plattformversionen, bevor sie sich auf Produktions-Workloads auswirken.
# AWS Fargate Drosselung von Kontingenten
AWS Fargate begrenzt die Startraten für Amazon ECS-Aufgaben und Amazon EKS-Pods auf Kontingente (früher als Limits bezeichnet). Dabei wird ein [Token-Bucket-Algorithmus](https://en.wikipedia.org/wiki/Token_bucket) für jedes AWS Konto pro Region verwendet. Mit diesem Algorithmus verfügt Ihr Konto über einen Bucket, der eine bestimmte Anzahl von Tokens enthält. Die Anzahl der Tokens im Bucket entspricht Ihrem Ratenkontingent zu einer bestimmten Sekunde. Jedes Kundenkonto verfügt über einen Token-Bucket für Aufgaben und Pods, der basierend auf der Anzahl der Aufgaben und Pods, die vom Kundenkonto gelauncht werden, erschöpft wird. Dieser Token-Bucket verfügt über ein Bucket-Maximum, mit dem Sie regelmäßig eine höhere Anzahl von Anforderungen stellen können, und eine Nachfüllrate, mit der Sie eine stetige Rate von Anfragen so lange wie nötig aufrechterhalten können.
Zum Beispiel beträgt die Bucket-Größe für Aufgaben und Pods für ein Fargate-Kundenkonto 100 Token und die Nachfüllrate beträgt 20 Token pro Sekunde. Daher können Sie sofort bis zu 100 Amazon-ECS-Aufgaben und Amazon-EKS-Pods pro Kundenkonto launchen, mit einer anhaltenden Launch-Rate von 20 Amazon-ECS-Aufgaben und Amazon-EKS-Pods pro Sekunde.
| Aktionen | Maximale Kapazität des Buckets (oder Burst-Rate) | Nachfüllrate des Buckets (oder konstante Rate) |
| --- | --- | --- |
| Ratenkontingent für Fargate-Ressourcen für On-Demand-Amazon-ECS-Aufgaben und Amazon-EKS-Pods[1](#fargate-throttling-note-1) | 100 | 20 |
| Ratenkontingent für Fargate-Ressourcen für Spot-Amazon-ECS-Aufgaben | 100 | 20 |
1Konten, die nur Amazon-EKS-Pods launchen, haben eine Burst-Rate von 20 mit einer konstanten Pod-Launch-Rate von 20 Pod-Launches pro Sekunde, wenn sie die in den [Amazon-EKS-Plattformversionen](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) aufgerufenen Plattformversionen verwenden.
## Drosselung der `RunTask`-API in Fargate
Darüber hinaus begrenzt Fargate die Anforderungsrate beim Launchen von Aufgaben mit der `RunTask`-API von Amazon ECS unter einem separaten Kontingent. Fargate begrenzt Amazon `RunTask` ECS-API-Anfragen für jedes AWS Konto auf regionaler Basis. Jede Anforderung, die Sie stellen, entfernt ein Token aus dem Bucket. Wir tun dies, um die Leistung des Dienstes zu unterstützen und um eine faire Nutzung für alle Fargate-Kunden sicherzustellen. API-Aufrufe unterliegen den Anforderungs-Kontingenten, unabhängig davon, ob sie von der Konsole von Amazon Elastic Container Service, einem Befehlszeilen-Tool oder einer Anwendung eines Drittanbieters stammen. Das Ratenkontingent für Aufrufe an die `RunTask`-API von Amazon ECS besteht aus 20 Aufrufen pro Sekunde (Burst und konstant). Jeder Aufruf an diese API kann jedoch bis zu 10 Aufgaben launchen. Das bedeutet, dass Sie 100 Aufgaben in einer Sekunde launchen können, indem Sie 10 Aufrufe an diese API tätigen und bei jedem Aufruf den Launch von 10 Aufgaben anfordern. In ähnlicher Weise könnten Sie auch 20 Aufrufe an diese API tätigen und bei jedem Aufruf den Launch von 5 Aufgaben anfordern. Weitere Informationen zur API-Drosselung für die `RunTask`-API von Amazon ECS finden Sie unter [API-Anforderungs-Drosselung](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/request-throttling.html) in der API-Referenz für Amazon ECS.
In der Praxis hängen die Launch-Raten von Aufgaben und Pods auch von anderen Überlegungen ab, wie zum Beispiel herunterzuladende und zu entpackende Container-Images, Zustandsprüfungen und andere aktivierte Integrationen, wie das Registrieren von Aufgaben oder Pods in einem Load Balancer. Kunden werden aufgrund der Features, die sie aktivieren, Schwankungen der Start-Raten von Aufgaben und Pods im Vergleich zu den oben dargestellten Kontingenten feststellen.
## Anpassen der Ratenkontingente in Fargate
Sie können eine Erhöhung der Raten-Drosselungs-Kontingente für Fargate für Ihr AWS -Konto anfordern. Weitere Informationen finden Sie im *Service Quotas -Benutzerhandbuch* unter [Anfordern einer Kontingenterhöhung](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html).
# Fehlerbehebung bei Amazon ECS Managed Instances
Verwenden Sie die folgenden Verfahren, um Amazon ECS Managed Instances zu beheben, einschließlich häufiger Probleme, Diagnosetechniken und Lösungsschritte.
## Voraussetzungen
Stellen Sie vor der Fehlerbehebung bei Amazon ECS Managed Instances sicher, dass Sie die folgenden Anforderungen erfüllen.
+ Das AWS CLI ist mit den entsprechenden Berechtigungen installiert und konfiguriert
Weitere Informationen finden Sie unter [Installieren oder Aktualisieren auf die neueste Version der AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) im *Benutzerhandbuch für AWS Command Line Interface *.
+ Zugriff auf einen Cluster mit dem Kapazitätsanbieter Amazon ECS Managed Instances. Weitere Informationen finden Sie unter [Erstellen eines Clusters für Amazon ECS Managed Instances](create-cluster-managed-instances.md).
## Allgemeine Problembehandlungsszenarien
### Container-Agent-Protokolle für Amazon ECS Managed Instances anzeigen
Sie können diese Amazon ECS-Protokolldateien in Amazon ECS Managed Instances anzeigen, indem Sie eine Verbindung zu einem privilegierten Container herstellen, der in der Instance ausgeführt wird.
#### Diagnoseschritte
**Stellen Sie einen Debug-Container mit Rechten und Linux-Funktionen als Amazon ECS-Aufgabe bereit:**
Legen Sie die folgenden Umgebungsvariablen fest.
Ersetzen Sie die *user-input* durch Ihre Werte.
```
export ECS_CLUSTER_NAME="your-cluster-name"
export AWS_REGION="your-region"
export ACCOUNT_ID="your-account-id"
```
Erstellen Sie eine Aufgabendefinition mit einer CLI JSON-Datei namens`node-debugger.json`.
```
cat << EOF > node-debugger.json
{
"family": "node-debugger",
"taskRoleArn": "arn:aws:iam::${ACCOUNT_ID}:role/ecsTaskExecutionRole",
"executionRoleArn": "arn:aws:iam::${ACCOUNT_ID}:role/ecsTaskExecutionRole",
"cpu": "256",
"memory": "1024",
"networkMode": "host",
"pidMode": "host",
"requiresCompatibilities": ["MANAGED_INSTANCES", "EC2"],
"containerDefinitions": [
{
"name": "node-debugger",
"image": "public.ecr.aws/amazonlinux/amazonlinux:2023",
"essential": true,
"privileged": true,
"command": ["sleep", "infinity"],
"healthCheck": {
"command": ["CMD-SHELL", "echo debugger || exit 1"],
"interval": 30,
"retries": 3,
"timeout": 5
},
"linuxParameters": {
"initProcessEnabled": true
},
"mountPoints": [
{
"sourceVolume": "host-root",
"containerPath": "/host",
"readOnly": false
}
],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/aws/ecs/node-debugger",
"awslogs-create-group": "true",
"awslogs-region": "${AWS_REGION}",
"awslogs-stream-prefix": "ecs"
}
}
}
],
"volumes": [
{
"name": "host-root",
"host": {
"sourcePath": "/"
}
}
]
}
EOF
```
Registrieren Sie sich und führen Sie dann die Aufgabe aus. Führen Sie die folgenden Befehle aus.
```
aws ecs register-task-definition --cli-input-json file://node-debugger.json
TASK_ARN=$(aws ecs run-task \
--cluster $ECS_CLUSTER_NAME \
--task-definition node-debugger \
--enable-execute-command \
--capacity-provider-strategy capacityProvider=managed-instances-default,weight=1 \
--query 'tasks[0].taskArn' --output text)
# Wait for task to be running
aws ecs wait tasks-running --cluster $ECS_CLUSTER_NAME --tasks $TASK_ARN
```
Connect zum Container her. Führen Sie den folgenden Befehl aus.
```
aws ecs execute-command \
--cluster $ECS_CLUSTER_NAME \
--task $TASK_ARN \
--container node-debugger \
--interactive \
--command "/bin/sh"
```
**Überprüfen Sie die Amazon ECS-Agentenprotokolle:**
Führen Sie in der interaktiven Sitzung des Containers die folgenden Befehle aus:
```
# Install required tools
yum install -y util-linux-core
# View ECS agent logs
nsenter -t 1 -m -p cat /var/log/ecs/ecs-agent.log | tail -50
# Check agent registration
nsenter -t 1 -m -p grep "Registered container instance" /var/log/ecs/ecs-agent.log
Example Output:
{"level":"info","time":"2025-10-16T12:39:37.665","msg":"Registered container instance with cluster!"}
# Verify capabilities
nsenter -t 1 -m -p grep "Response contained expected value for attribute" /var/log/ecs/ecs-agent.log
```
**Überprüfen Sie die Agent-Metriken:**
Führen Sie den folgenden Befehl aus, um die Protokolle anzuzeigen.
```
# View metrics logs
nsenter -t 1 -m -p cat /var/log/ecs/metrics.log | tail -20
```
### Probleme bei der Aufgabenplatzierung
Im Folgenden sind Symptome von Problemen mit der Aufgabenverteilung aufgeführt:
+ Aufgaben bleiben im Status AUSSTEHEND hängen
+ Aufgaben konnten auf Amazon ECS Managed Instances nicht gestartet werden
+ Fehler bei unzureichenden Ressourcen
#### Diagnoseschritte
Führen Sie die folgenden Befehle aus, um Probleme mit der Aufgabenplatzierung zu diagnostizieren und Informationen über Clusterkapazität, Container-Instances und Systemdienste zu sammeln:
```
# Check cluster capacity
aws ecs describe-clusters --clusters cluster-name --include STATISTICS
# Check cluster capacity providers
aws ecs describe-clusters --clusters cluster-name --include STATISTICS --query 'clusters[].capacityProviders'
# List container instances
aws ecs list-container-instances --cluster cluster-name
# Check container instance details
aws ecs describe-container-instances --cluster cluster-name --container-instances container-instance-arn
# Check container instance remaining resources CPU/Mem
aws ecs describe-container-instances --cluster $ECS_CLUSTER_NAME --container-instances container-instance-arn --query 'containerInstances[].remainingResources'
# Check container instance Security Group
aws ecs describe-container-instances --cluster $ECS_CLUSTER_NAME --container-instances container-instance-arn --query 'containerInstances[].ec2InstanceId' --output text
aws ec2 describe-instances --instance-ids instance-id --query 'Reservations[0].Instances[0].SecurityGroups'
aws ec2 describe-security-groups --group-ids security-group-id
```
**Überwachung der Systemdienste:**
```
# Check Containerd status
nsenter -t 1 -m -p systemctl status containerd.service
# Check Amazon ECS container agent status
nsenter -t 1 -m -p systemctl status ecs
```
#### Auflösung
Gehen Sie wie folgt vor, um Probleme mit der Aufgabenverteilung zu lösen, um die richtige Konfiguration und Kapazität sicherzustellen:
+ Überprüfen Sie die Ressourcenanforderungen für Aufgaben im Vergleich zur verfügbaren Kapazität
+ Prüfen Sie die Platzierungsbeschränkungen und -strategien
+ Stellen Sie sicher, dass der Kapazitätsanbieter für Amazon ECS Managed Instances konfiguriert ist
+ Stellen Sie sicher, dass die Task- und Container-Instance-Sicherheitsgruppe über eine ausgehende Regel verfügen, die den Datenverkehr für die Amazon ECS-Agentenverwaltungsendpunkte zulässt.
### Netzwerkprobleme
Im Folgenden sind die Symptome von Netzwerkproblemen aufgeführt:
+ Aufgaben können keine externen Dienste erreichen
+ Probleme mit der DNS-Auflösung
#### Diagnoseschritte
**Tests der Netzwerkkonnektivität:**
Führen Sie im Debug-Container die folgenden Befehle aus:
**Anmerkung**
Vergewissern Sie sich, dass die Ihrem Kapazitätsanbieter oder Ihrer Amazon ECS-Aufgabe zugeordnete Sicherheitsgruppe den Datenverkehr zulässt.
```
# Install DNS Utility
yum install bind-utils -y
# Test DNS resolution
nslookup amazon.com
# Test external connectivity
curl -I https://amazon.com
```
### Einschränkungen für Ressourcen
Im Folgenden sind die Symptome von Netzwerkproblemen aufgeführt:
+ Aufgaben wurden aufgrund von Speicherbeschränkungen beendet
+ CPU-Drosselung
+ Probleme mit dem Festplattenspeicher
#### Diagnoseschritte
Führen Sie Befehle aus, um die Ressourcen- und Containerlimits zu überwachen.
**Überwachung der Ressourcen:**
```
# Check memory usage
nsenter -t 1 -m -p free -h
# Check disk usage
nsenter -t 1 -m -p lsblk
# Check disk usage
nsenter -t 1 -m -p df -h
```
**Container-Grenzwerte:**
```
# Check OOM kills
nsenter -t 1 -m -p dmesg | grep -i "killed process"
```
### Problem beim Trennen des Container-Instance-Agenten
Im Folgenden sind die Symptome von Problemen beim Trennen des Container-Instance-Agents aufgeführt:
+ Container-Instances werden in der Amazon ECS-Konsole als getrennt angezeigt
+ Aufgaben, die bestimmten Instances nicht zugewiesen werden konnten
+ Fehler bei der Agentenregistrierung in Protokollen
#### Diagnoseschritte
Wenn auf dem Host bereits eine Privilegien-Task ausgeführt wird, auf die ECS Exec zugreifen kann, führen Sie die folgenden Befehle aus, um Probleme mit der Agenten-Konnektivität zu diagnostizieren:
```
# check service status
nsenter -t 1 -m -p systemctl restart ecs
nsenter -t 1 -m -p systemctl restart containerd
# restart stopped services
nsenter -t 1 -m -p systemctl restart ecs
nsenter -t 1 -m -p systemctl restart containerd
```
Andernfalls erzwingen Sie die Abmeldung der Amazon ECS Managed Instances. Führen Sie den folgenden Befehl aus:
```
# list ECS Managed Instance container
aws ecs list-container-instances --cluster managed-instances-cluster --query 'containerInstanceArns' --output text
# deregister the specific container instance
aws ecs deregister-container-instance \
--cluster $ECS_CLUSTER_NAME \
--container-instance container-instance-arn \
--force
```
#### Auflösung
Gehen Sie wie folgt vor, um Probleme beim Trennen der Agentenverbindung zu lösen:
+ Überprüfen Sie die IAM-Rollenberechtigungen für die Container-Instance
+ Überprüfen Sie, ob die Sicherheitsgruppenregeln ausgehenden HTTPS-Verkehr zu ECS-Endpunkten zulassen
+ Stellen Sie die Netzwerkkonnektivität zu den Diensten sicher AWS
+ Starten Sie den ECS-Agent-Dienst neu, falls erforderlich: `nsenter -t 1 -m -p systemctl restart ecs`
+ Stellen Sie sicher, dass die ECS\$1CLUSTER-Konfiguration in/etc/ecs/ecs.config Ihrem Clusternamen entspricht
## Protokollanalyse in von Amazon ECS verwalteten Instances
### Systemprotokolle
Verwenden Sie die folgenden Befehle, um Systemprotokolle zu untersuchen und mögliche Probleme mit der verwalteten Instanz zu identifizieren:
```
# Check system messages
nsenter -t 1 -m -p journalctl --no-pager -n 50
# Check kernel logs
nsenter -t 1 -m -p dmesg | tail -20
# Check for disk space errors
nsenter -t 1 -m -p journalctl --no-pager | grep -i "no space\|disk full\|enospc"
```
## Verwenden Sie EC2 AWS CLI , um die Konsolenausgabe von einer Amazon ECS Managed Instance abzurufen
Verwenden Sie die Amazon EC2 EC2-Instance-ID, um die Konsolenausgabe abzurufen.
Ersetzen Sie die *user-input* durch Ihre Werte.
```
aws ec2 get-console-output --instance-id instance-id --latest --output text
```
## Bereinigen
Führen Sie den folgenden Befehl aus, um die Debug-Aufgabe zu beenden und die Registrierung der Aufgabendefinition aufzuheben.
```
# Stop debug task
aws ecs stop-task --cluster $ECS_CLUSTER_NAME --task $TASK_ARN
# Deregister task definition (optional)
aws ecs deregister-task-definition --task-definition node-debugger
```
## Weitere Ressourcen
Weitere Informationen zur Fehlerbehebung bei Amazon ECS Managed Instances finden Sie in den folgenden Ressourcen:
+ [Fehlerbehebung bei Fehlern in Amazon ECS Amazon ECS Managed Instances](managed-instances-errors.md)
+ [Amazon-ECS-Fehlersuche](troubleshooting.md)
+ [Konfiguration des Amazon-ECS-Container-Agenten](ecs-agent-config.md)
+ [Überwachen von Amazon-ECS-Containern mit ECS Exec](ecs-exec.md)
# Fehlerbehebung bei Amazon ECS Managed Instances
Beim Starten von Aufgaben mit Amazon ECS Managed Instances versucht Amazon ECS zunächst, Aufgaben auf vorhandener Kapazität zu platzieren, und fordert zusätzliche Kapazität für Aufgaben an, die nicht platziert werden können. Wenn die Instance-Bereitstellung fehlschlägt, ist die Amazon-EC2-Anforderungs-ID in der Aufgabenfehlermeldung enthalten. Sie können diese Anfrage-ID verwenden, um Details zur fehlgeschlagenen Anfrage CloudTrail zur weiteren Fehlerbehebung nachzuschlagen.
**Anmerkung**
Wenn Sie sich dafür entscheiden, Berechtigungen mit den geringsten Rechten anzuwenden und Ihre eigenen Berechtigungen für das Instance-Profil anzugeben, anstatt die `AmazonECSInstanceRolePolicyForManagedInstances` verwaltete Richtlinie zu verwenden, können Sie die folgenden Berechtigungen hinzufügen, um bei der Behebung aufgabenbezogener Probleme mit Amazon ECS Managed Instances zu helfen:
`ecs:StartTelemetrySession`
`ecs:PutSystemLogEvents`
## Die Aufgabendefinition ist nicht mit Amazon ECS Managed Instances kompatibel.
### Häufige Ursache
Dieser Fehler tritt auf, wenn Ihre Aufgabendefinition Parameter oder Konfigurationen enthält, die von Amazon ECS Managed Instances nicht unterstützt werden. Zu den häufigsten Inkompatibilitäten gehören nicht unterstützte Netzwerkmodi, Aufgabenrollen oder Ressourcenanforderungen.
### Auflösung
1. Vergewissern Sie sich, dass Ihre Aufgabendefinition `requiresCompatibilities` auf `MANAGED_INSTANCES` gestellt verwendet.
1. Stellen Sie sicher, dass Ihre Aufgabendefinition den `awsvpc`-Netzwerkmodus verwendet.
1. Stellen Sie sicher, dass die CPU- und Speicherwerte innerhalb der unterstützten Bereiche für Amazon ECS Managed Instances liegen.
1. Einzelheiten zur Inkompatibilität finden Sie in der ausführlichen Fehlermeldung.
## Kapazitätsanbieter ist nicht dem Cluster zugeordneten
### Häufige Ursache
Dieser Fehler tritt auf, wenn der in Ihrer Kapazitätsanbieter-Strategie angegebene Kapazitätsanbieter nicht mit dem Cluster verknüpft ist oder nicht existiert.
### Auflösung
1. Stellen Sie sicher, dass der Kapazitätsanbieter in Ihrem Konto und in Ihrer Region vorhanden ist.
1. Ordnen Sie den Kapazitätsanbieter mithilfe der Amazon-ECS-Konsole oder CLI dem Cluster zu.
1. Stellen Sie sicher, dass sich der Kapazitätsanbieter im `ACTIVE`-Status befindet, bevor Sie ihn verwenden.
## Fehler bei den Berechtigungen für Infrastrukturrollen
### Häufige Ursache
Dieser Fehler tritt auf, wenn der Amazon-ECS-Infrastrukturrolle die erforderlichen Berechtigungen fehlen, um Amazon-EC2-Vorgänge in Ihrem Namen durchzuführen, oder wenn die Rolle aufgrund von Problemen mit der Vertrauensbeziehung nicht übernommen werden kann.
### Auflösung
1. Stellen Sie sicher, dass Ihre Infrastrukturrolle über die richtige Vertrauensbeziehung zu Amazon ECS verfügt.
1. Stellen Sie sicher, dass die Rolle über die erforderlichen Amazon-EC2-Berechtigungen verfügt, einschließlich `ec2:RunInstances`, `ec2:DescribeInstances` und `iam:PassRole`.
1. Genauere Informationen zu den Berechtigungen finden Sie in CloudTrail der verschlüsselten Meldung über einen Autorisierungsfehler.
1. Aktualisieren Sie die Rollenrichtlinie so, dass sie fehlende Berechtigungen enthält, die in der Fehlermeldung identifiziert wurden.
## VcpuLimitExceeded Fehler
### Häufige Ursache
Dieser Fehler tritt auf, wenn Sie Ihr vCPU-Servicekontingent für die Instance-Typfamilie in der aktuellen Region erreicht haben. Amazon ECS Managed Instances kann keine zusätzlichen Instances starten, bis Kapazität verfügbar ist.
### Auflösung
1. Fordern Sie über das AWS Support Center eine Erhöhung des Servicekontingents für die betroffene Instanztypfamilie an.
1. Erwägen Sie die Verwendung verschiedener Instance-Typen, die unter eine andere vCPU-Kontingentkategorie fallen.
1. Beenden Sie ungenutzte Amazon-EC2-Instances, um vCPU-Kapazität freizugeben.
1. Überprüfen Sie die Konfiguration Ihres Kapazitätsanbieters, um Instance-Typen mit niedrigeren vCPU-Anforderungen zu verwenden.
## InsufficientCapacity und damit verbundene Kapazitätsfehler
### Häufige Ursache
Diese Fehler treten auf, wenn die Kapazität AWS nicht ausreicht, um Ihre Instance-Anfrage zu bearbeiten. Dies kann eine unzureichende Instance-Kapazität, Adresskapazität oder Volume-Kapazität in der angeforderten Availability Zone beinhalten.
### Auflösung
1. Versuchen Sie, Instances in verschiedenen Availability Zones zu starten, indem Sie mehrere Subnetze in Ihrem Kapazitätsanbieter konfigurieren.
1. Erwägen Sie die Verwendung verschiedener Instance-Typen, die möglicherweise über mehr verfügbare Kapazität verfügen.
1. Warten Sie und wiederholen Sie den Vorgang, da sich die Kapazitätsverfügbarkeit häufig ändert.
1. Für dauerhaften Kapazitätsbedarf sollten Sie Reserved Instances oder Savings Plans in Betracht ziehen.
## UnauthorizedOperation Fehler
### Häufige Ursache
Dieser Fehler tritt auf, wenn der Amazon-ECS-Service nicht über die erforderlichen Berechtigungen verfügt, um Amazon-EC2-Vorgänge auszuführen oder IAM-Rollen zu übergeben. Zu den häufigsten Szenarien gehören fehlende `ec2:RunInstances`-Berechtigungen oder `iam:PassRole`-Berechtigungen für das Instance-Profil.
### Auflösung
1. Stellen Sie sicher, dass Ihre Amazon-ECS-Infrastrukturrolle über die erforderlichen Berechtigungen zum Starten von Amazon-EC2-Instances verfügt.
1. Stellen Sie sicher, dass die Infrastrukturrolle über `iam:PassRole`-Berechtigungen für das Instance-Profil verfügt, das von Amazon ECS Managed Instances verwendet wird.
1. Spezifische Informationen zu den Berechtigungen finden Sie in der codierten Meldung über CloudTrail einen Autorisierungsfehler.
1. Aktualisieren Sie die Rollenrichtlinie so, dass sie die in der Fehlermeldung identifizierten fehlenden Berechtigungen einbezieht.
## Beim Warten auf Kapazität wurde für die Aufgabe eine Zeitüberschreitung überschritten
### Häufige Ursache
Dieser Fehler tritt auf, wenn der Start und die Registrierung von Instances im Cluster länger als erwartet dauert. Dies kann auf Kapazitätsbeschränkungen von Amazon EC2, Fehler beim Starten von Instances oder Probleme mit der Netzwerkkonnektivität zurückzuführen sein.
### Auflösung
1. Überprüfen Sie den Zustand des Amazon-EC2-Services in Ihrer Region auf aktuelle Probleme.
1. Stellen Sie sicher, dass in Ihren Subnetzen ausreichend IP-Adressen verfügbar sind.
1. Stellen Sie sicher, dass Ihre Sicherheitsgruppen den für die Kommunikation mit Amazon-ECS-Agenten erforderlichen Datenverkehr zulassen.
1. Erwägen Sie die Verwendung mehrerer Availability Zones, um die Kapazitätsverfügbarkeit zu verbessern.
1. Versuchen Sie erneut, die Aufgabe zu starten, da Kapazitätsengpässe häufig nur vorübergehend sind.
## Netzwerkkonfigurationsfehler
### Häufige Ursache
Diese Fehler treten auf, wenn es Diskrepanzen zwischen den Netzwerkanforderungen Ihrer Aufgabe und der Netzwerkkonfiguration des Kapazitätsanbieters gibt, z. B. VPC-Diskrepanzen oder fehlende Netzwerkkonfiguration.
### Auflösung
1. Überprüfen Sie, ob Ihr Kapazitätsanbieter mit der richtigen VPC und den richtigen Subnetzen konfiguriert ist.
1. Stellen Sie sicher, dass Sicherheitsgruppen und Subnetze zur gleichen VPC gehören.
1. Stellen Sie sicher, dass die Netzwerkkonfiguration Ihrer Aufgabendefinition mit dem Kapazitätsanbieter kompatibel ist.
1. Aktualisieren Sie die Konfiguration Ihres Kapazitätsanbieters mit den richtigen Netzwerkeinstellungen.
## Der Kapazitätsanbieter kann aufgrund von festgefahrenen Instanzen nicht gelöscht werden
### Häufige Ursache
Diese Fehler treten auf, wenn Amazon ECS Managed Instances im `DRAINING` Status `ACTIVE` oder feststecken, aber keine laufenden Aufgaben auf den Instances laufen.
### Auflösung
Damit das Löschen des Kapazitätsanbieters fortgesetzt werden kann, können Sie mit dem folgenden Befehl die Abmeldung der festgefahrenen Instances erzwingen.
```
aws ecs deregister-container-instance \
--cluster arn:aws:ecs:us-east-1:111122223333:cluster/MyCluster \
--container-instance arn:aws:ecs:us-east-1:111122223333:container-instance/a1b2c3d4-5678-90ab-cdef-11111EXAMPLE \
--force
```
# Fehlerbehebung bei Fehlern in Amazon ECS Amazon ECS Managed Instances
Im Folgenden finden Sie einige Fehlermeldungen für Amazon ECS Managed Instances und Aktionen, mit denen Sie die Fehler beheben können.
## Der Kapazitätsanbieter von Amazon ECS Managed Instances wird ohne Cluster-Namen nicht unterstützt
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter mit einem Kapazitätsanbieter-Parameter für Amazon ECS Managed Instances zu erstellen, aber kein Cluster-Feld einrichten.
Um dieses Problem zu beheben, geben Sie bei der Erstellung des Kapazitätsanbieters einen gültigen Cluster-Namen an.
## Die Details zum Kapazitätsanbieter von Amazon ECS Managed Instances sind erforderlich, wenn Sie einen Kapazitätsanbieter für Amazon ECS Managed Instances erstellen
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter mit Amazon ECS Managed Instances zu erstellen, aber das eigentliche Objekt nicht bereitstellen.
Um dieses Problem zu beheben, geben Sie gültige Kapazitätsanbieter-Details für Amazon ECS Managed Instances an und versuchen Sie es erneut.
## Der Kapazitätsanbieter für Amazon ECS Managed Instances muss ein Instance-Profil angeben
Dieser Fehler wird angezeigt, wenn Sie versuchen, einen Kapazitätsanbieter mit Amazon ECS Managed Instances zu erstellen, aber den Ec2 InstanceProfile nicht bereitstellen.
Um dieses Problem zu lösen, geben Sie ein gültiges EC2-Instance-Profil für den Kapazitätsanbieter für Amazon ECS Managed Instances an. Weitere Informationen finden Sie unter [Instance-Profil von Amazon ECS Managed Instances](managed-instances-instance-profile.md).
## Der Kapazitätsanbieter für Amazon ECS Managed Instances muss einen angeben InfrastructureRole
Diese Meldung wird angezeigt, wenn Sie versuchen, einen Kapazitätsanbieter mit Amazon ECS Managed Instances zu erstellen, den aber nicht bereitstellen InfrastructureRole.
Um dieses Problem zu lösen, geben Sie eine gültige Infrastrukturrolle für Ihren Kapazitätsanbieter für Amazon ECS Managed Instances an. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md).
## Der Kapazitätsanbieter für Amazon ECS Managed Instances muss eine Netzwerkkonfiguration angeben
Dieser Fehler wird angezeigt, wenn Sie versuchen, einen Kapazitätsanbieter mit Amazon ECS Managed Instances zu erstellen, aber die Netzwerkkonfiguration nicht bereitstellen.
Um dieses Problem zu lösen, geben Sie eine gültige Netzwerkkonfiguration mit nicht leeren Subnetzen für den Kapazitätsanbieter für Amazon ECS Managed Instances an. Weitere Informationen finden Sie unter [Amazon-ECS-Aufgabenvernetzung für Amazon ECS Managed Instances](managed-instance-networking.md).
## Keine Instance-Typen erfüllen die Instance-Anforderungen, die im Kapazitätsanbieter für Amazon ECS Managed Instances angegeben sind.
Dies passiert, wenn Sie versuchen, einen Kapazitätsanbieter mit Amazon ECS Managed Instances zu erstellen, aber kein EC2-Instance-Typ die Instance-Anforderungen erfüllt.
Um dieses Problem zu lösen, überprüfen Sie Ihre Instance-Anforderungen und passen Sie sie an die verfügbaren EC2-Instance-Typen an.
## Der ARN der angegebenen Infrastrukturrolle ist ungültig
Dieser Fehler tritt auf, wenn der InfrastructureRole nicht dem spezifischen ARN-Format entspricht.
Erwartetes Format:. `arn:partition:iam::account-id:role/role-name` Geben Sie einen gültigen Rollen-ARN an und versuchen Sie es erneut. Weitere Informationen finden Sie unter [IAM-Rolle für die Amazon-ECS-Infrastruktur](infrastructure_IAM_role.md).
## Der angegebene Rollen-ARN für das Instance-Profil ist ungültig
Dieser Fehler tritt auf, wenn das Instance-Profil nicht dem spezifischen ARN-Format folgt.
Erwartetes Format:. `arn:partition:iam::account-id:instance-profile/profile-name` Geben Sie einen gültigen Rollen-ARN an und versuchen Sie es erneut. Weitere Informationen finden Sie unter [Instance-Profil von Amazon ECS Managed Instances](managed-instances-instance-profile.md).
## Die angegebene Sicherheitsgruppen-ID ist ungültig
Dieser Fehler tritt auf, wenn die Sicherheitsgruppen-ID nicht dem spezifischen Format folgt.
Erwartetes Format: `sg-xxxxxxxx` oder `sg-xxxxxxxxxxxxxxxxxx` (8 oder 17 Zeichen einschließlich Buchstaben (Kleinbuchstaben) und Zahlen nach 'sg-'). Geben Sie eine Sicherheitsgruppen-ID an und versuchen Sie es erneut.
## Die angegebene Subnetz-ID ist ungültig
Dieser Fehler tritt auf, wenn die Subnetz-ID nicht dem spezifischen Format folgt.
Erwartetes Format: `subnet-xxxxxxxx` oder `subnet-xxxxxxxxxxxxxxxxxx` (8 oder 17 Zeichen einschließlich Buchstaben (Kleinbuchstaben) und Zahlen nach „subnet-“). Geben Sie eine Subnetz-ID an und versuchen Sie es erneut.
## Der Kapazitätsanbieter für Amazon ECS Managed Instances muss eine Netzwerkkonfiguration mit nicht leeren Subnetzen angeben
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter mit Amazon ECS Managed Instances und Netzwerkkonfiguration mit leeren Subnetzen zu erstellen.
Um dieses Problem zu lösen, geben Sie eine gültige Netzwerkkonfiguration mit nicht leeren Subnetzen für den Kapazitätsanbieter für Amazon ECS Managed Instances an.
## Der Kapazitätsanbieter für Amazon ECS Managed Instances darf die maximal zulässige Anzahl von Tags nicht überschreiten
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter mit mehr als der maximal zulässigen Anzahl von Tags (45) zu erstellen.
Um dieses Problem zu beheben, reduzieren Sie die Anzahl der Tags auf 45 oder weniger und versuchen Sie es erneut.
## Ungültiger Wert für propagateTags
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter mit einem ungültigen propagateTags-Wert zu erstellen.
Der Wert muss einer der gültigen propagateTags-Werte sein. Geben Sie einen gültigen Wert an, und versuchen Sie es erneut.
## Der angegebene Kapazitätsanbieter ist bereits im Cluster-Bereich vorhanden
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter für Amazon ECS Managed Instances ohne Cluster-Namen zu erstellen, zu aktualisieren oder zu löschen, aber es gibt einen vorhandenen Cluster-Kapazitätsanbieter.
Um die Konfiguration des Kapazitätsanbieters zu ändern oder zu löschen, aktualisieren oder löschen Sie den Kapazitätsanbieter mit dem Cluster-Parameter.
## Der angegebene Kapazitätsanbieter ist bereits mit einem Konto oder einem anderen Cluster vorhanden
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter für Amazon ECS Managed Instances mit einem Cluster-Feld zu erstellen, zu aktualisieren oder zu löschen, während es einen bestehenden Kapazitätsanbieter mit Kontobereich oder einen vorhandenen Cluster-Kapazitätsanbieter für einen anderen Cluster gibt.
Um dieses Problem zu beheben, verwenden Sie einen anderen Kapazitätsanbieternamen oder verwenden Sie den dem vorhandenen Kapazitätsanbieter.
## Der aktive Cluster-Name des Kapazitätsanbieters stimmt nicht mit dem Cluster-Namen in der Anfrage überein
Dieser Fehler tritt auf, wenn der aktive Cluster-Name des Kapazitätsanbieters nicht mit dem in der Anfrage angegebenen Cluster-Namen übereinstimmt.
Stellen Sie sicher, dass der Cluster-Name in Ihrer Anfrage mit dem Cluster übereinstimmt, der dem Kapazitätsanbieter zugeordnet ist.
## Der Kapazitätsanbieter ist kein Kapazitätsanbieter für Amazon ECS Managed Instances
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter zu verwenden, der kein Kapazitätsanbieter für Amazon ECS Managed Instances ist, in einem Kontext, der einen erfordert.
Stellen Sie sicher, dass Sie einen gültigen Kapazitätsanbieter für Amazon ECS Managed Instances für Ihre Anfrage verwenden.
## CapacityProvider Name darf nicht leer sein
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter zu erstellen, ohne einen Kapazitätsanbieter-Namen anzugeben.
Geben Sie einen gültigen Namen für den Kapazitätsanbieter an und versuchen Sie es erneut.
## Bei der Aktualisierung eines Kapazitätsanbieters ist ein Name erforderlich
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter zu aktualisieren, ohne einen Kapazitätsanbieter-Namen anzugeben.
Geben Sie einen gültigen Namen an und versuchen Sie es erneut.
## Tags dürfen nicht Null sein oder Null-Elemente enthalten
Dieser Fehler tritt auf, wenn Sie versuchen, einen Kapazitätsanbieter mit Nullwerten zu kennzeichnen.
Stellen Sie sicher, dass alle Tag-Werte richtig angegeben sind und nicht Null sind.
# Gründe für das Fehlschlagen der Amazon-ECS-API
Wenn eine API-Aktion, die Sie über die Amazon-ECS-API, die Konsole oder die AWS CLI ausgelöst haben, mit einer `failures`-Fehlermeldung beendet, kann Folgendes bei der Fehlerbehebung der Ursache helfen. Der Fehler gibt einen Grund und den Amazon-Ressourcennamen (ARN) der Ressource zurück, die dem Fehler zugeordnet ist.
Viele Ressourcen sind regionalspezifisch. Achten Sie also darauf, dass die Konsole auf die richtige Region für Ihre Ressourcen gesetzt ist. Stellen Sie bei der AWS CLI Verwendung von sicher, dass Ihre AWS CLI Befehle mit dem `--region region` Parameter an die richtige Region gesendet werden.
Weitere Informationen über die Struktur des `Failure`-Datentyps finden Sie unter [Fehler](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Failure.html) in der *Amazon Elastic Container Service-API-Referenz*.
Im Folgenden finden Sie Beispiele für Fehlermeldungen, die Sie beim Ausführen von API-Befehlen erhalten könnten.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/api_failures_messages.html)
**Anmerkung**
Neben den hier beschriebenen Fehlerszenarien können APIs auch aufgrund von Ausnahmen ausfallen, was zu Fehlerantworten führt. Eine Liste solcher Ausnahmen finden Sie unter [Häufige Fehler](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/CommonErrors.html).
# Problembehandlung mit Amazon Q Developer
Sie können [Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html) in der Amazon ECS-Konsole verwenden, um Probleme mit Ihren Amazon ECS-Ressourcen zu diagnostizieren und zu lösen. Für bestimmte Fehler und Statusmeldungen zu Containern, Aufgaben, Services, Bereitstellungen und Aufgabendefinitionen zeigt die Konsole die Option **Inspect with Amazon Q Developer** an. Wenn Sie diese Option wählen, analysiert Amazon Q Developer das Problem im Kontext und schlägt mögliche Ursachen und Abhilfemaßnahmen vor.
## Erforderliche Berechtigungen
+ Berechtigungen zum Anzeigen der Amazon ECS-Ressourcen, für die Sie Fehler beheben möchten, z. B. Cluster, Services, Aufgaben und Aufgabendefinitionen.
+ [Berechtigungen zur Verwendung von Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/security_iam_permissions.html) in der Konsole.
+ (Empfohlen) Berechtigungen zum Anzeigen verwandter Logs und Metriken, wie z. B.:
+ CloudWatch Logs
+ CloudWatch
## Verfahren
1. Öffnen Sie die Konsole unter[https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).
1. Ermitteln Sie die Ressource, für die Sie eine Fehlerbehebung durchführen möchten.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonECS/latest/developerguide/troubleshooting-with-Q.html)
1. Suchen Sie auf der Seite mit den Ressourcendetails nach dem Status oder der Integritätsursache, die das Problem beschreibt.
1. Klicken Sie auf den Statusgrund, um das Popover zu öffnen.
1. Falls verfügbar, wählen Sie **Inspect with Amazon Q Developer**.
1. Lesen Sie die Erklärung und die vorgeschlagenen Schritte zur Problembehebung, die Amazon Q Developer bereitstellt. Nehmen Sie die für Ihre Umgebung geeigneten Konfigurations- oder Betriebsänderungen vor.
## Überlegungen
Beachten Sie Folgendes, wenn Sie Amazon Q Developer mit Amazon ECS verwenden:
+ **Verfügbarkeit von Schaltflächen — Die Schaltfläche** „Inspect with Amazon Q Developer“ wird nur für Ressourcen angezeigt, bei denen potenzielle Probleme auftreten. Diese Option ist für intakte Ressourcen nicht verfügbar.
+ **Schreibgeschützte Operationen — Die Amazon Q Developer-Integration** führt nur Lesevorgänge durch. Sie führt keine Mutations- oder Schreibaktionen durch.
+ **Regionsübergreifende Verarbeitung** — Amazon Q Developer kann Daten AWS regionsübergreifend verarbeiten, um KI-gestützte Analysen bereitzustellen. Weitere Informationen zur regionsübergreifenden Verarbeitung finden Sie unter [Regionsübergreifende Verarbeitung in Amazon Q](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/cross-region-processing.html) Developer.
+ **Nur Konsole** — Diese Integration ist nur über die Konsole verfügbar. Sie ist nicht über die AWS CLI AWS APIs, oder Infrastructure-as-Code-Tools verfügbar.
## Weitere Informationen
Weitere Informationen zur Verwendung von Amazon Q Developer finden Sie unter [Chatten mit Amazon Q Developer über AWS](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/chat-with-q.html).