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.
Fehlerbehebung mit Amazon ECS-Aktionsprotokollen
Aktionsprotokolle helfen Ihnen bei der Diagnose von Problemen, indem sie detaillierte Aufzeichnungen der vom Amazon ECS-Service initiierten Vorgänge bereitstellen. Jeder Protokolleintrag enthält einen Zeitstempel, eine Protokollebene, einen Ereignisnamen und eine detaillierte Nutzlast mit Informationen darüber, was passiert ist und warum. Dieses Thema behandelt gängige Problembehandlungsszenarien und bietet sofort einsatzbereite CloudWatch Logs Insights-Abfragen.
Grundlegendes zu Protokollebenen
Aktionsprotokolle verwenden drei Protokollebenen, um den Schweregrad jedes Ereignisses anzuzeigen:
INFO-
Normale Vorgänge wie Start der Bereitstellung, Start einer Aufgabe oder Bereitstellung von Ressourcen. Diese Ereignisse deuten darauf hin, dass Amazon ECS die Aktionen erwartungsgemäß ausführt.
WARN-
Non-fatal Probleme, die möglicherweise Aufmerksamkeit erfordern, wie Wiederholungsversuche oder Kapazitätsengpässe. Amazon ECS macht weiterhin Fortschritte, aber der Vorgang könnte länger dauern als erwartet.
ERROR-
Fehler, die Maßnahmen erfordern, wie z. B. eine fehlgeschlagene Bereitstellung, Bereitstellungsfehler oder Probleme beim Start einer Aufgabe. Überprüfen Sie diese Ereignisse, um die Ursache zu ermitteln und Abhilfemaßnahmen zu ergreifen.
Tipp
Filtern Sie zunächst nach Leveln ERROR oder WARN protokollieren Sie diese, um Probleme schnell zu identifizieren. Anschließend können Sie Ihre Suche auf INFO Ereignisse ausweiten, um zusätzlichen Kontext zu erhalten.
Debuggen einer fehlgeschlagenen Servicebereitstellung
Symptome
Die Bereitstellung ist im Gange oder wurde automatisch rückgängig gemacht.
Worauf zu achten ist
Filtert nach ERROR Protokollen, in denen Folgendes eventName enthalten istDEPLOYMENT. Prüfen Sie die detail Nutzlast auf den Bereitstellungs-ARN, den Statusgrund und die Anzahl der fehlgeschlagenen Aufgaben.
Das folgende Beispiel zeigt einen Bereitstellungsfehler, bei dem kein Rollback-Kandidat verfügbar war:
{ "resourceArn": "arn:aws:ecs:us-east-1:111122223333:cluster/my-cluster", "actionSourceId": "service/my-cluster/my-service", "logLevel": "ERROR", "eventTimestamp": 1784573730986, "detail": { "statusReason": "No rollback candidate was found to run the rollback.", "serviceDeploymentArn": "arn:aws:ecs:us-east-1:111122223333:service-deployment/my-cluster/my-service/abc123def456", "status": "FAILED", "eventName": "SERVICE_DEPLOYMENT_ROLLBACK_FAILED" } }
Auflösung
Markieren Sie das detail.statusReason Feld, um zu ermitteln, warum Aufgaben fehlgeschlagen sind. Verwenden Sie die folgende CloudWatch Logs Insights-Abfrage, um alle Bereitstellungsfehler zu finden:
fields @timestamp, detail.statusReason | filter logLevel = "ERROR" and detail.deploymentArn like /my-cluster\/my-service/ | sort @timestamp desc | limit 20
Diagnose von Problemen mit verwalteten Daemons
Symptome
Der Daemon startet nicht auf Instanzen oder die Daemon-Bereitstellung bleibt hängen.
Worauf zu achten ist
Filtern Sie Protokolle nach dem Daemon-ARN, um Ereignisse zu finden, die sich auf Ihren Daemon beziehen. Sie können auch nach filternlogLevel, um die Ergebnisse auf Warnungen oder Fehler einzugrenzen.
Das folgende Beispiel zeigt eine Daemon-Aufgabe, die aufgrund unzureichenden Speichers auf der Zielinstanz nicht gestartet werden konnte:
{ "timestamp": 1719500050000, "logLevel": "WARN", "account": "123456789012", "region": "us-east-1", "resourceArn": "arn:aws:ecs:us-east-1:123456789012:cluster/my-cluster", "actionSourceId": "arn:aws:ecs:us-east-1:123456789012:daemon/my-cluster/my-logging-daemon", "eventName": "DAEMON_TASK_START_IMPAIRED", "detail": { "statusReason": "RESOURCE:MEMORY - Unable to place daemon task on container instance: insufficient memory", "containerInstanceArn": "arn:aws:ecs:us-east-1:123456789012:container-instance/my-cluster/a1b2c3d4" } }
Auflösung
Stellen Sie sicher, dass die Zielinstanzen über ausreichende Ressourcen verfügen, um die Daemon-Aufgabe auszuführen. Wenn die Instanzen überlastet sind, wird der Daemon möglicherweise erst gestartet, wenn neue Instanzen verfügbar sind. Verwenden Sie die folgende Abfrage, um Ereignisse für einen bestimmten Daemon zu filtern:
fields @timestamp, logLevel, detail.statusReason | filter actionSourceId like /my-logging-daemon/ | filter logLevel in ["ERROR", "WARN"] | sort @timestamp desc | limit 20
Die Gründe für das Beenden der Daemon-Aufgabe verstehen
Symptome
Daemon-Aufgaben werden unerwartet beendet.
Worauf zu achten ist
Filter WARN und ERROR Protokolle, die Details zum Ausfall der Daemon-Aufgabe enthalten. Die folgenden Felder in der detail Payload enthalten Informationen darüber, warum eine Daemon-Aufgabe beendet wurde:
detail.stopCode-
Ein maschinenlesbarer Code, der den Grund für das Beenden der Aufgabe kategorisiert.
detail.statusReason-
Eine für Menschen lesbare Beschreibung, warum die Aufgabe beendet wurde. Dieses Feld ist nicht in allen Protokolleinträgen vorhanden.
detail.containerStoppedReason-
Zusätzlicher Kontext zu dem spezifischen Container, der zum Beenden der Aufgabe geführt hat.
Eine vollständige Liste der Task-Stoppcodes und ihrer Beschreibungen finden Sie unterAufgabe-Beendet-Fehlermeldungen in Amazon ECS.
Anmerkung
Erwartete Stopps von Daemon-Tasks, wie z. B.UserInitiated, werden aus den Aktionsprotokollen herausgefiltert. Sie sehen nur unerwartete oder fehlerbedingte Stopps von Daemon-Tasks.
Nützliche Logs & Insights-Abfragen CloudWatch
Verwenden Sie die folgenden CloudWatch Logs Insights-Abfragen, um häufig auftretende Probleme mit Ihren Amazon ECS-Services zu untersuchen.
Alle Fehler der letzten Stunde
fields @timestamp, logLevel, eventName, detail.statusReason | filter logLevel = "ERROR" | sort @timestamp desc | limit 50
Anmerkung
Das detail.statusReason Feld ist nicht in allen Logeinträgen vorhanden. Wenn das Feld in Ihren Ergebnissen leer ist, verwenden Sie die Felder eventName und andere Felder in der detail Nutzlast als Kontext.
Ereignisse für einen bestimmten Dienst
fields @timestamp, logLevel, detail.statusReason | filter @message like /my-service/ | sort @timestamp desc | limit 50
Zeitplan für die Bereitstellung einer bestimmten Bereitstellung
fields @timestamp, logLevel, detail.statusReason | filter detail.deploymentArn like /my-cluster\/my-service\/abc123/ | sort @timestamp asc
Fehler bei Daemon-Aufgaben, gruppiert nach Gründen
filter logLevel = "ERROR" and detail.stopCode != "" | stats count(*) as failureCount by detail.stopCode, detail.statusReason | sort failureCount desc | limit 20
