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.

Blockierende Vorgänge im Trigger

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

Triggerprotokolle enthalten Warnmeldungen, anhand derer Sie die Ursachen für eine geringere Triggerleistung ermitteln können. Es gibt zwei wichtige Warnungen, auf die Sie achten sollten.

  1. Async-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 von asynchronen Aufgaben hin.

    Lösung: Um dieses Problem zu beheben, weisen Sie den Auslösern mehr Ressourcen zu, reduzieren Sie die Anzahl der gleichzeitig ausgeführten verschobenen Aufgaben oder erhöhen Sie die Anzahl der Auslöser in Ihrer Umgebung. Beachten Sie, dass die Auslöser zwar für verschiebbare Aufgaben zuständig sind, die einzelnen Aufgaben aber von den Workern gestartet und schließlich abgeschlossen werden. Wenn Sie die Anzahl der Auslöser anpassen, sollten Sie auch die Anzahl der 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 bezieht sich auf einen bestimmten Operatorcode, der von Cloud Composer ausgeführt wird. Aus Gründen des Designs sollten Trigger die asyncio-Bibliothek für die Ausführung von Vorgängen im Hintergrund verwenden. Eine benutzerdefinierte Implementierung eines Triggers kann nicht ordnungsgemäß den asyncio-Verträgen entsprechen, z. B. aufgrund einer falschen Verwendung der Keywords await und async im Python-Code.

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

Zu viele Trigger

Die Anzahl der verschobenen Aufgaben ist im Messwert task_count zu sehen, der auch im Monitoring-Dashboard Ihrer Umgebung angezeigt wird. Jeder Trigger erzeugt Ressourcen wie Verbindungen zu externen Ressourcen, die Speicherplatz verbrauchen.

Ausgesetzte Aufgaben, die im Monitoring-Dashboard angezeigt werden
Abbildung 1. Ausgesetzte Aufgaben, die im Monitoring-Dashboard angezeigt werden (zum Vergrößern anklicken)

Die Diagramme für Arbeitsspeicher- und CPU-Verbrauch zeigen, dass unzureichende Ressourcen zu Neustarts führen, weil der Liveness-Test aufgrund fehlender Heartbeats fehlschlägt:

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

Lösung: Um dieses Problem zu beheben, weisen Sie den Auslösern mehr Ressourcen zu, reduzieren Sie die Anzahl der gleichzeitig ausgeführten verschobenen Aufgaben oder erhöhen Sie die Anzahl der Auslöser in Ihrer Umgebung.

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

Nachdem der Trigger die Ausführung beendet hat, kehrt die Steuerung zu einem Airflow-Worker zurück, der eine Rückrufmethode mit einem 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 gekennzeichnet. In diesem Fall wird bei der Wiederholung der gesamte Vorgang, nicht nur die Rückrufmethode, noch einmal ausgeführt.

Endlosschleife in einem Trigger

Es ist möglich, einen benutzerdefinierten Triggeroperator so zu implementieren, dass er die Hauptschleife des Triggerers vollständig blockiert, sodass jeweils nur der fehlerhafte Trigger ausgeführt wird. In diesem Fall wird in den Trigger-Logs eine Warnung generiert, nachdem der fehlerhafte Trigger beendet wurde.

Triggerklasse nicht gefunden

Da der DAGs-Ordner nicht mit dem Airflow-Trigger synchronisiert ist, fehlt der Inline-Triggercode bei der Ausführung des Triggers. Der Fehler wird in den Protokollen der fehlgeschlagenen Aufgabe generiert:

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

Lösung: Fehlender Code von PyPI importieren

Warnmeldung zum Trigger in der Airflow-Benutzeroberfläche

In einigen Fällen wird nach dem Deaktivieren des Auslösers 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.

Airflow kann diese Meldung anzeigen, weil unvollständige Trigger in der Airflow-Datenbank verbleiben. Diese Meldung bedeutet in der Regel, dass der Auslöser deaktiviert wurde, bevor alle Trigger in Ihrer Umgebung abgeschlossen wurden.

Alle Trigger, die in der Umgebung ausgeführt werden, finden Sie auf der Seite Durchsuchen > Trigger in der Airflow-Benutzeroberfläche. Sie benötigen dazu die Rolle Admin.

Lösungen:

Aufgaben bleiben im Status „Verschoben“, nachdem der Auslöser deaktiviert wurde

Wenn der Auslöser deaktiviert ist, bleiben Aufgaben, 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.
  • Aktivieren Sie den Auslöser, um die Aufgaben auszuführen.

Wir empfehlen, den Auslöser nur zu deaktivieren, wenn in Ihrer Umgebung keine verzögerten Operatoren oder Aufgaben ausgeführt werden und alle verzögerten Aufgaben abgeschlossen sind.

Nächste Schritte