Airflow-Triggerprobleme beheben

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Diese Seite enthält Schritte zur Fehlerbehebung und Informationen zu häufigen Problemen mit dem Airflow-Trigger.

Blockieren von Vorgängen im Trigger

Asynchrone Aufgaben können gelegentlich in Triggern blockiert werden. In den meisten Fällen sind die Probleme auf unzureichende Triggerressourcen oder Probleme mit benutzerdefiniertem asynchronem Operatorcode zurückzuführen.

In den Triggerer-Logs werden alle Warnmeldungen angezeigt, die Ihnen helfen können, die Ursachen für eine geringere Triggerer-Leistung zu ermitteln. Es gibt zwei wichtige Warnungen, auf die Sie achten sollten.

  1. Asynchroner Thread blockiert

    Triggerer's async thread was blocked for 1.2 seconds, likely due to the highly utilized environment.
    

    Diese Warnung weist auf Leistungsprobleme aufgrund einer großen Anzahl asynchroner Aufgaben hin.

    Lösung: Um dieses Problem zu beheben, weisen Sie den Triggern mehr Ressourcen zu, reduzieren Sie die Anzahl der gleichzeitig ausgeführten verzögerten Aufgaben oder erhöhen Sie die Anzahl der Trigger in Ihrer Umgebung. Auch wenn Triggerer aufschiebbare Aufgaben verarbeiten, sind die Worker für das Starten und Abschließen der einzelnen Aufgaben verantwortlich. Wenn Sie die Anzahl der Triggerer anpassen, sollten Sie auch die Anzahl Ihrer Worker-Instanzen skalieren.

  2. Eine bestimmte Aufgabe hat den asynchronen Thread blockiert.

    WARNING - Executing <Task finished coro=<TriggerRunner.run_trigger() done, defined at /opt/***/***/jobs/my-custom-code.py:609> result=None> took 0.401 second
    

    Diese Warnung verweist auf einen bestimmten Operatorcode, der von Cloud Composer ausgeführt wird. Trigger sollten standardmäßig die asyncio-Bibliothek verwenden, um Vorgänge im Hintergrund auszuführen. Eine benutzerdefinierte Implementierung eines Triggers kann die asyncio-Verträge nicht richtig einhalten, z. B. aufgrund einer falschen Verwendung der Keywords await und async im Python-Code.

    Lösung: Untersuchen Sie den Code, der in der Warnung gemeldet wird, und prüfen Sie, ob der asynchrone Vorgang richtig implementiert ist.

Zu viele Trigger

Die Anzahl der zurückgestellten Aufgaben wird im Messwert task_count angezeigt, der auch im Monitoring-Dashboard Ihrer Umgebung zu sehen ist. Für jeden Trigger werden einige Ressourcen wie Verbindungen zu externen Ressourcen erstellt, die Arbeitsspeicher belegen.

Auf dem Monitoring-Dashboard angezeigte ausgesetzte Tasks
Abbildung 1. Auf dem Monitoring-Dashboard angezeigte verzögerte Aufgaben (zum Vergrößern klicken)

Die Diagramme zum Arbeitsspeicher- und CPU-Verbrauch zeigen, dass Neustarts durch unzureichende Ressourcen verursacht werden, da der Liveness-Probe aufgrund fehlender Heartbeats fehlschlägt:

Triggerer wird aufgrund unzureichender Ressourcen neu gestartet
Abbildung 2. Triggerer wird aufgrund unzureichender Ressourcen neu gestartet (zum Vergrößern klicken)

Lösung: Um dieses Problem zu beheben, weisen Sie den Triggern mehr Ressourcen zu, reduzieren Sie die Anzahl der gleichzeitig ausgeführten verzögerten Aufgaben oder erhöhen Sie die Anzahl der Trigger in Ihrer Umgebung.

Absturz eines Airflow-Workers während der Callback-Ausführung

Nachdem der Trigger die Ausführung abgeschlossen hat, wird die Steuerung an einen Airflow-Worker zurückgegeben, der eine Callback-Methode über einen Ausführungsslot ausführt. Diese Phase wird vom Celery Executor gesteuert. Daher gelten die entsprechenden Konfigurations- und Ressourcenlimits (z. B. parallelism oder worker_concurrency).

Wenn die Callback-Methode im Airflow-Worker fehlschlägt, der Worker fehlschlägt oder der Worker, der die Methode ausführt, neu gestartet wird, wird die Aufgabe als FAILED markiert. In diesem Fall wird die gesamte Aufgabe noch einmal ausgeführt, nicht nur die Callback-Methode.

Endlosschleife in einem Trigger

Es ist möglich, einen benutzerdefinierten Triggeroperator so zu implementieren, dass er die Haupt-Triggerer-Schleife vollständig blockiert, sodass jeweils nur der eine unterbrochene Trigger ausgeführt wird. In diesem Fall wird nach Abschluss des problematischen Triggers eine Warnung in den Triggerer-Logs generiert.

Trigger-Klasse nicht gefunden

Da der DAGs-Ordner nicht mit dem Airflow-Trigger synchronisiert wird, fehlt der Inline-Triggercode, wenn der Trigger ausgeführt wird. Der Fehler wird in den Logs der fehlgeschlagenen Aufgabe generiert:

ImportError: Module "PACKAGE_NAME" does not define a "CLASS_NAME" attribute/
class

Lösung: Importieren Sie den fehlenden Code von PyPI.

Warnmeldung zum Trigger in der Airflow-Benutzeroberfläche

In einigen Fällen wird nach dem Deaktivieren des Triggers möglicherweise die folgende Warnmeldung in der Airflow-Benutzeroberfläche angezeigt:

The triggerer does not appear to be running. Last heartbeat was received
4 hours ago. Triggers will not run, and any deferred operator will remain
deferred until it times out or fails.

Diese Meldung kann in Airflow angezeigt werden, weil unvollständige Trigger in der Airflow-Datenbank verbleiben. Diese Meldung bedeutet in der Regel, dass der Trigger deaktiviert wurde, bevor alle Trigger in Ihrer Umgebung abgeschlossen waren.

Sie können alle Trigger, die in der Umgebung ausgeführt werden, auf der Seite Durchsuchen > Trigger in der Airflow-UI ansehen (die Rolle Admin ist erforderlich).

Lösungen:

Aufgaben bleiben im Status „Zurückgestellt“, nachdem der Trigger deaktiviert wurde

Wenn der Trigger deaktiviert ist, bleiben Tasks, die sich bereits im Status „Ausgesetzt“ befinden, in diesem Status, bis das Zeitlimit erreicht ist. Dieses Zeitlimit kann je nach Airflow- und DAG-Konfiguration unendlich sein.

Verwenden Sie eine der folgenden Lösungen:

  • Markieren Sie die Aufgaben manuell als fehlgeschlagen.
  • Ermöglichen Sie dem Auslöser, die Aufgaben zu erledigen.

Wir empfehlen, den Trigger nur zu deaktivieren, wenn in Ihrer Umgebung keine verzögerten Vorgänge oder Aufgaben ausgeführt werden und alle verzögerten Aufgaben abgeschlossen sind.

Nächste Schritte