Wie behebe ich den Fehler „Was the task killed externally“ in Amazon MWAA?

Kurzbeschreibung

Der Fehler „Wurde die Aufgabe extern beendet“ tritt auf, wenn der Status einer Aufgabe zwischen der Airflow-Metadatendatenbank und dem Aufgabeninitiator unterschiedlich ist. Die folgenden Ursachen sind für den Fehler aufgeführt:

• Der Wert task_queued_timeout ist erreicht. Der Standardwert ist 600 Sekunden. Für frühere Versionen von Apache Airflow sieh dir den Wert task_adoption_timeout an. Weitere Informationen findest du unter task_queued_timeout_check_interval auf der Apache Airflow-Website.
• Die Aufgabe ist aufgrund einer hohen Ressourcenauslastung des Workers fehlgeschlagen.

Lösung

Scheduler-Protokolle überprüfen

Führe die folgenden Schritte aus:

1. Öffne die Amazon-CloudWatch-Konsole.

2. Wähle im Navigationsbereich Protokolle.

3. Wähle Protokollgruppen.

4. Wähle die SNS-Protokollgruppe, die du anzeigen möchtest.

5. Wähle Alle LogStream durchsuchen.

6. Um nach dem Zeitraum zu suchen, in dem die Aufgabe fehlgeschlagen ist, aktualisiere das Zeitintervall. Filtere die Suche auch mit der Aufgaben-ID:

   "example-dag-name.example-task-name manual__example-time-202X-XX-XXTXX:XX:XX.758774+00:00"

   Hinweis: Ersetze example-dag-name durch den Namen des Directed Acylic Graph (DAG), example-task-name durch den Aufgabennamen und example-time durch den Zeitraum, den du verwenden möchtest.

7. Identifiziere zwei Protokollzeilen in den Suchergebnissen, die auf die Aufgabe verweisen:

   Das Folgende ist ein Beispiel für die Aufgabe in der Warteschlange:

   [[34m**2024-01-17T11:19:07.487+0000**[0m] [34mscheduler_job_runner.py:[0m713 INFO[0m - Setting external_id for <TaskInstance: dag_name.task_name manual__202X-XX-XXTXX:XX:XX.758774+00:00[queued]> to 8b49b168-992d-4db6-bdc7-a143d55720c8[0m

   Das Folgende ist ein Beispiel für die gestoppte Aufgabe:

   [[34m**2024-01-17T11:30:18.936+0000**[0m] [34mscheduler_job_runner.py:[0m771 ERROR[0m - Executor reports task instance <TaskInstance: dag_name.task_name manual__202X-XX-XXTXX:XX:XX.758774+00:00 [queued]> finished (failed) although the task says it's queued. (Info: None) Was the task killed externally?[0m

In den folgenden Szenarien kannst du weitere Fehler beheben.

Die Aufgabe ist aufgrund von task_queued_timeout fehlgeschlagen

Vergleiche die Zeitstempel, wann du die Aufgabe geplant hast und wann die Aufgabe beendet wurde. Wenn die Differenz größer oder gleich dem Wert task_queued_timeout ist, befindet sich die Aufgabe in einer zu langen Warteschlange.

Gehe wie folgt vor, um dieses Problem zu beheben:

• Erhöhe den Wert task_queued_timeout, sodass die Aufgaben ohne Timeout länger in der Warteschlange warten können.
• Steige in eine höhere Umgebungsklasse auf, um die Anzahl der Slots für Celery Worker in jedem Worker-Container zu erhöhen. Die Anzahl der gleichzeitigen Aufgaben, die in der Umgebung ausgeführt werden können, ist maxWorkers * celery.worker_autoscale.
• Verteile die Menge an DAGs und Aufgaben. Führe nicht mehrere DAGs gleichzeitig aus.
• Vergewissere dich, dass der Scheduler nicht überlastet ist. Wenn du einen überlasteten Scheduler hast, werden Aufgaben möglicherweise nicht rechtzeitig geplant.

Hinweis: Eine Erhöhung der Scheduler-Anzahl kann sich auf die Auslastung der Metadatenbank und die Parsing-Zeiten auswirken. Mehr Scheduler erhöhen die High Availability (HA, Hochverfügbarkeit), fügen aber nicht mehr Ressourcen für die Aufgabenplanung hinzu. Wenn der Wert von task_queued_timeout nicht erreicht wird, überprüfe die Worker-Protokolle.

Gehe wie folgt vor, um die Protokolle der Mitarbeiter zu überprüfen:

1. Greife auf die Apache Airflow-Benutzeroberfläche zu.
2. Wähle eine DAG.
3. Wähle Graph aus.
4. Wähle eine Aufgabenausführung.
5. Wähle Instance-Details. Notiere dir dann den Wert externen_executor_id der Aufgabe.
6. Öffne die Amazon-CloudWatch-Konsole.
7. Wähle im Navigationsbereich Protokolle.
8. Wähle Protokollgruppen.
9. Wähle die SNS-Protokollgruppe, die du anzeigen möchtest.
10. Wähle Alle LogStream durchsuchen.
11. Um nach dem Zeitraum zu suchen, in dem die Aufgabe fehlgeschlagen ist, aktualisiere das Zeitintervall.
12. Filtere die Suche mit dem Wert external_executor_id, um Protokollzeilen anzuzeigen, die sich auf die Aufgabe auf dem Worker beziehen.
13. Identifiziere Fehlermeldungen, die sich auf die Aufgabe beziehen. Für weitere Informationen zu den Fehlern wähle den Namen des Protokollstreams.

Die Aufgabe ist aufgrund einer hohen CPU- oder Speicherauslastung fehlgeschlagen

Wenn du die folgende Fehlermeldung erhältst, hat der Worker Probleme mit der Ressourcenauslastung, z. B. hohe CPU- oder RAM-Werte. Infolgedessen schlägt der Worker-Prozess, der auf dem Worker-Container ausgeführt wird, fehl und wird vorzeitig beendet.

"[2023-07-26 13](tel:2023072613):00:49,356: ERROR/MainProcess] Task handler raised error: WorkerLostError('Worker exited prematurely: signal 15 (SIGTERM) Job: 1049.')"

.Um die vorherige Fehlermeldung zu beheben, überprüfe die Metriken CPUUtilization und MemoryUtilisation. Wenn die Metriken konstant hoch sind oder Spitzenwerte aufweisen, sind die Amazon MWAA-Worker überlastet.

Gehe wie folgt vor, um überlastete Worker abzulösen:

• Verringere den Wert celery.worker_autoscale, um die Anzahl der Aufgaben zu reduzieren, die gleichzeitig auf dem Worker ausgeführt werden.
• Verwende eine höhere Amazon MWAA-Instance-Klasse für mehr RAM und vCPUs.
• Schreibe die DAGs neu, um die Rechenlast von Amazon MWAA auf andere Rechenplattformen auszulagern.

Ähnliche Informationen

Bewährte Methoden auf der Apache Airflow-Website