Service-Ereignismeldungen

Wenn Sie ein Problem mit einem Service beheben möchten, sollten Sie zuerst im Service-Ereignisprotokoll nach Diagnoseinformationen suchen. Sie können Serviceereignisse über die DescribeServices-API AWS CLI, die oder die anzeigen AWS Management Console.

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 Ereignisansicht hilfreich ist, zeigen wir nur die 100 aktuellsten Ereignisse an und doppelte Ereignismeldungen werden weggelassen, bis entweder die Ursache behoben ist oder sechs Stunden vergangen sind. Wenn die Ursache nicht innerhalb von sechs Stunden behoben wird, erhalten Sie eine weitere Service-Ereignismeldung für diese Ursache.

• Service Auto Scaling-Events. Diese Ereignisse haben das Präfix Nachricht . Die 10 letzten Skalierungsereignisse werden angezeigt. Diese Ereignisse treten nur auf, wenn ein Service mit einer Application Auto Scaling-Skalierungsrichtlinie konfiguriert ist.

Gehen Sie wie folgt vor, um Ihre aktuellen Service-Ereignismeldungen anzuzeigen.

Console

1. Öffnen Sie die Konsole unter https://console.aws.amazon.com/ecs/v2.

2. Klicken Sie im Navigationsbereich auf Cluster.

3. Wählen Sie auf der Cluster-Seite den Cluster aus.

4. Wählen Sie den zu untersuchenden Service aus.

5. Wählen Sie Deployments and events (Bereitstellungen und Ereignisse) und zeigen Sie unter Events (Ereignisse) die Meldungen an.

AWS CLI

Verwenden Sie den Befehl describe-services, um die Serviceereignismeldungen für einen angegebenen Service anzuzeigen.

Im folgenden AWS CLI Beispiel wird der Servicename-Service im Standard-Cluster beschrieben, der die neuesten Serviceereignismeldungen bereitstellt.

aws ecs describe-services \
    --cluster default \
    --services service-name \
    --region us-west-2

Service-Ereignismeldungen

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 erreicht und somit einen stabilen Zustand erreicht.

Der Service-Scheduler meldet den Status regelmäßig, sodass Sie diese Nachricht möglicherweise mehrmals erhalten.

Service (Servicename) konnte eine Aufgabe nicht platzieren, da keine Container-Instance alle Anforderungen erfüllt hat.

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:

Es wurden keine Container-Instances in Ihrem Cluster gefunden

Wenn in dem Cluster, in dem Sie versuchen, eine Aufgabe auszuführen, keine Container-Instances registriert sind, erhalten Sie diesen Fehler. Sie sollten Ihrem Cluster Container-Instances hinzufügen. Weitere Informationen finden Sie unter Starten einer Amazon ECS Linux-Container-Instance.

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 nächsten passende Container-Instance für die Aufgabenplatzierung darf das maximal zulässige Limit für reservierte 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 Portzuordnung wie 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.

Anmerkung

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 Verwaltung des Container-Instance-Speichers.

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. Amazon-EC2-Instances haben eine Begrenzung für die Anzahl der ENIs, die an sie angehängt werden können, und es gibt keine Container-Instances mit verfügbarer ENI-Kapazität im Cluster.

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 Netzuwerkschnittstelle pro Instance-Typ im Amazon EC2-Benutzerhandbuch für Linux-Instances.

• Wenn Sie sich für die -awsvpcTrunkingKontoeinstellung angemeldet haben, aber nach der Anmeldung keine neuen Container-Instances mit einem unterstützten Instance-Typ gestartet haben, liegt das ENI-Limit für jede Container-Instance immer noch auf dem Standardwert. Weitere Informationen finden Sie unter IP-Adressen pro Netzuwerkschnittstelle pro Instance-Typ im Amazon EC2-Benutzerhandbuch für Linux-Instances.

• Wenn Sie sich für die awsvpcTrunking-Kontoeinstellung angemeldet haben und Sie haben neue Container-Instances mit einem unterstützten Instance-Typ nach der Anmeldung gestartet, stehen zusätzliche ENIs zur Verfügung. Weitere Informationen finden Sie unter Unterstützte Amazon-EC2-Instance-Typen.

Weitere Informationen zum Aktivieren der awsvpcTrunking-Kontoeinstellung finden Sie unter Elastic-Network-Schnittstellen-Trunking.

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 verfügbaren Container-Instances 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 verwendet, die den -awsvpcNetzwerkmodus und den EC2-Starttyp verwenden. Für den von Ihnen angegebenen Cluster ist keine Container-Instance in demselben Subnetz registriert, das in angegeben wurde, awsvpcConfiguration als der Service erstellt wurde.

Weitere Informationen darüber, welche Attribute für bestimmte Aufgabendefinitionsparameter und Agentenkonfigurationsvariablen erforderlich sind, finden Sie unter Aufgabendefinitionsparameter und Konfiguration des Amazon-ECS-Container-Agenten.

Service (Servicename) konnte eine Aufgabe nicht platzieren, da keine Container-Instance alle Anforderungen erfüllt hat. Für die am nächsten passende Container-Instance container-instance-id sind nicht genügend CPU-Einheiten verfügbar.

Die am nächsten 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 (Servicename) konnte eine Aufgabe nicht platzieren, da keine Container-Instance alle Anforderungen erfüllt hat. Bei der am nächsten übereinstimmenden Container-Instance 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 Amazon-ECS-Container-Agent-Protokoll. 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 (Servicename ) (Instance-Instance-ID ) ist in (elb elb-name ) aufgrund von fehlerhaft (Grund: Instance hat mindestens die UnhealthyThreshold Anzahl der Zustandsprüfungen nacheinander nicht bestanden).

Dieser Service ist mit einem Load Balancer registriert und die Zustandsprüfungen des Load Balancer sind fehlgeschlagen. Weitere Informationen finden Sie unter Fehlerbehebung bei Service-Load Balancers.

Service (service-name) kann nicht alle Aufgaben 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 Amazon-ECS-Service-Drosselungslogik.

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, 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 Tasks während einer Bereitstellung aufgrund der Konfiguration der Dienstbereitstellung nicht anhalten 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 maximumPercent Werten minimumHealthyPercent und , die beim Erstellen des Services definiert werden. Diese Werte können auch für einen vorhandenen Service aktualisiert werden.

stellt die Untergrenze für die Anzahl der Aufgaben minimumHealthyPercent dar, die für einen Service während einer Bereitstellung oder beim Ausgleich einer Container-Instance ausgeführt werden sollen. Dies ist ein Prozentsatz der gewünschten Anzahl von Aufgaben für den Service. Dieser Wert wird aufgerundet. Wenn der minimale fehlerfreie Prozentsatz beispielsweise 50 und die gewünschte Aufgabenanzahl vier ist, kann der Scheduler zwei vorhandene Aufgaben stoppen, 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.

stellt die Obergrenze für die Anzahl der Aufgaben maximumPercent dar, die für einen Service während einer Bereitstellung oder beim Ausgleich einer Container-Instance ausgeführt werden sollen. Dies ist ein Prozentsatz der gewünschten Anzahl von Aufgaben für einen Service. Dieser Wert wird abgerundet. Wenn der maximale Prozentsatz beispielsweise ist 200 und die gewünschte Aufgabenanzahl vier ist, kann der Scheduler vier neue Aufgaben starten, bevor er vier vorhandene Aufgaben stoppt. 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. Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter Anfordern einer Kontingenterhöhung im Benutzerhandbuch zu Service Quotas.

Service (service-name) konnte keine Aufgabe platzieren. Grund: Interner Fehler.

Im Folgenden finden Sie die möglichen Gründe 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.

  Weitere Informationen zum Anzeigen der Subnetz-Availability-Zone finden Sie unter Anzeigen Ihres Subnetzes im Benutzerhandbuch zu Amazon VPC.

• Sie versuchen, eine Aufgabendefinition auszuführen, die die ARM-Architektur auf Fargate Spot verwendet.

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. Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter Anfordern einer Kontingenterhöhung 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. Informationen zum Anfordern einer Kontingenterhöhung finden Sie unter Anfordern einer Kontingenterhöhung im Benutzerhandbuch zu Service Quotas.

Service (service-name) konnte keine Aufgabe platzieren. Grund: Sie haben das Limit für die Anzahl der vCPUs erreicht, die Sie gleichzeitig ausführen können

AWS Fargate wechselt von aufgabenanzahlbasierten Kontingenten zu vCPU-basierten Kontingenten.

Sie können eine Kontingenterhöhung für das vCPU-basierte Kontingent von Fargate anfordern. Weitere Informationen finden Sie unter Amazon-ECS-Service-Kontingente. Informationen zur Erhöhung eines Fargate-Kontingents finden Sie unter Anfordern einer Kontingenterhöhung im Service-Quotas-Benutzerhandbuch.

Der Service (service-name) konnte den stabilen Status nicht erreichen, da der Aufgabensatz (taskSet-ID) nicht abskaliert werden 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.

• Bestimmen Sie, welche Aufgaben gestoppt werden können, und verwenden Sie die UpdateTaskProtection -API mit der protectionEnabled Option false, um den Schutz für diese Aufgaben aufzuheben.

• Erhöhen Sie die Anzahl der gewünschten Aufgaben des Services auf mehr als die Anzahl der geschützten Aufgaben.

Service (service-name) konnte keinen stabilen Zustand 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:

Es wurden keine Container-Instances in Ihrem Cluster gefunden

Wenn in dem Cluster, in dem Sie versuchen, eine Aufgabe auszuführen, keine Container-Instances registriert sind, erhalten Sie diesen Fehler. Sie sollten Ihrem Cluster Container-Instances hinzufügen. Weitere Informationen finden Sie unter Starten einer Amazon ECS Linux-Container-Instance.

Nicht genügend Ports

Wenn Ihre Aufgabe eine feste Host-Port-Zuweisung verwendet (z. B. verwendet Ihre Aufgabe Port 80 auf dem Host für einen Webserver), müssen Sie mindestens eine Container-Instance pro Aufgabe haben. Es kann jeweils nur ein Container einen einzelnen Host-Port 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 nächsten passende Container-Instance für die Aufgabenplatzierung darf das maximal zulässige Limit für reservierte 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 Portzuordnung wie 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.

Anmerkung

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 Verwaltung des Container-Instance-Speichers.

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. Amazon EC2-Instances haben ein Limit für die Anzahl der ENIs, die ihnen zugeordnet werden können, 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 Netzuwerkschnittstelle pro Instance-Typ im Amazon EC2-Benutzerhandbuch für Linux-Instances.

• Wenn Sie sich für die -awsvpcTrunkingKontoeinstellung angemeldet haben, aber nach der Anmeldung keine neuen Container-Instances mit einem unterstützten Instance-Typ gestartet haben, liegt das ENI-Limit für jede Container-Instance immer noch auf dem Standardwert. Weitere Informationen finden Sie unter IP-Adressen pro Netzuwerkschnittstelle pro Instance-Typ im Amazon EC2-Benutzerhandbuch für Linux-Instances.

• Wenn Sie sich für die awsvpcTrunking-Kontoeinstellung angemeldet haben und Sie haben neue Container-Instances mit einem unterstützten Instance-Typ nach der Anmeldung gestartet, stehen zusätzliche ENIs zur Verfügung. Weitere Informationen finden Sie unter Unterstützte Amazon-EC2-Instance-Typen.

Weitere Informationen zum Aktivieren der awsvpcTrunking-Kontoeinstellung finden Sie unter Elastic-Network-Schnittstellen-Trunking.

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 verfügbaren Container-Instances 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 verwendet, die den -awsvpcNetzwerkmodus und den EC2-Starttyp verwenden und für den von Ihnen angegebenen Cluster keine Container-Instance in demselben Subnetz registriert ist, das in angegeben wurde, awsvpcConfiguration als der Service erstellt wurde.

Weitere Informationen darüber, welche Attribute für bestimmte Aufgabendefinitionsparameter und Agentenkonfigurationsvariablen erforderlich sind, finden Sie unter Aufgabendefinitionsparameter und Konfiguration des Amazon-ECS-Container-Agenten.

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.

Bereitstellung des -Service (Servicename): Aufgaben konnten nicht gestartet werden.

Die Aufgaben in Ihrem Service konnten nicht gestartet werden.

Informationen zum Debuggen gestoppter Aufgaben finden Sie unter Fehlercodes für angehaltene Aufgaben.

service (service-name ) Das Warten auf den Start des Amazon-ECS-Agenten ist abgelaufen. 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 über SSH eine Verbindung mit der Container-Instance herstellen können, können Sie die Agentenprotokolle überprüfen. Weitere Informationen finden Sie unter Amazon-ECS-Container-Agent-Protokoll. 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) Aufgabensatz (taskSet -ID ) ist in Zielgruppen (targetGroup -ARN)) aufgrund von nicht fehlerfreiTARGET GROUP IS NOT FOUND.

Der Aufgabensatz für den Service schlägt Zustandsprüfungen fehl, da die Zielgruppe nicht gefunden wird. Sie sollten den Service löschen und neu erstellen. Löschen Sie keine Elastic Load Balancing-Zielgruppe, es sei denn, der entsprechende Amazon ECS-Service ist bereits gelöscht.

Service (service-name) Aufgabensatz (taskSet -ID ) ist in der Zielgruppe (targetGroup -ARN)) aufgrund von nicht fehlerfreiTARGET IS NOT FOUND.

Der Aufgabensatz für den Service schlägt Zustandsprüfungen fehl, da das Ziel nicht gefunden wird.