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
Die Bereitstellung ist im Gange oder wurde automatisch rückgängig gemacht.
Filtert nach `ERROR` Protokollen, in denen Folgendes `eventName` enthalten ist`DEPLOYMENT`. 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"
}
}
```
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
Der Daemon startet nicht auf Instanzen oder die Daemon-Bereitstellung bleibt hängen.
Filtern Sie Protokolle nach dem Daemon-ARN, um Ereignisse zu finden, die sich auf Ihren Daemon beziehen. Sie können auch nach filtern`logLevel`, 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"
}
}
```
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
Daemon-Aufgaben werden unerwartet beendet.
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 unter[Aufgabe-Beendet-Fehlermeldungen in Amazon ECS](stopped-task-error-codes.md).
**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
```