Airflow-Triggerprobleme beheben

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Auf dieser Seite finden Sie Schritte zur Fehlerbehebung und Informationen für häufige Probleme mit dem Airflow-Triggerer.

Vorgänge im Trigger blockieren

Asynchrone Aufgaben werden gelegentlich in Triggern blockiert. In den meisten Fällen sind die Probleme auf unzureichende Triggerer-Ressourcen oder Probleme mit benutzerdefiniertem Code für asynchrone Operatoren zurückzuführen.

Triggerlogs zeigen alle Warnmeldungen an, mit denen Sie Ursachen für eine verminderte Triggerleistung identifizieren können. Sie müssen auf zwei wichtige Warnungen achten.

  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 hin, die auf eine große Anzahl asynchroner Aufgaben zurückzuführen sind.

    Lösung: Zur Behebung dieses Problems weisen Sie den Triggern mehr Ressourcen zu, reduzieren Sie die Anzahl der ausgesetzten Aufgaben, die gleichzeitig ausgeführt werden, oder erhöhen Sie die Anzahl der Trigger in Ihrer Umgebung. Auch wenn Trigger zurückgestellte Aufgaben verarbeiten, sind es die Worker, die dafür verantwortlich sind, jede Aufgabe zu starten und schließlich abzuschließen. Wenn Sie die Anzahl der Trigger 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 verweist auf einen bestimmten Operatorcode, der von Cloud Composer ausgeführt wird. Trigger sollten sich auf die asyncio-Bibliothek verlassen, um Vorgänge im Hintergrund auszuführen. Eine benutzerdefinierte Implementierung eines Triggers kann die asyncio-Verträge nicht ordnungsgemäß einhalten (z. B. aufgrund einer falschen Verwendung der Schlüsselwörter await und async im Python-Code).

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

Zu viele Trigger

Die Anzahl der zurückgestellten Aufgaben ist im Messwert task_count sichtbar, der auch auf dem Monitoring-Dashboard Ihrer Umgebung angezeigt wird. Jeder Trigger erstellt einige Ressourcen, z. B. Verbindungen zu externen Ressourcen, die Arbeitsspeicher belegen.

Zurückgestellte Aufgaben, die im Monitoring-Dashboard angezeigt werden
Abbildung 1. Verzögerte Aufgaben, die auf dem Monitoring-Dashboard angezeigt werden (zum Vergrößern klicken)

Grafiken zur Arbeitsspeicher- und CPU-Nutzung zeigen, dass unzureichende Ressourcen zu Neustarts führen, da die Aktivitätsprüfung aufgrund fehlender Heartbeats fehlschlägt:

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

Lösung: Zur Behebung dieses Problems weisen Sie den Triggern mehr Ressourcen zu, reduzieren Sie die Anzahl der ausgesetzten Aufgaben, die gleichzeitig ausgeführt werden, 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 beendet hat, wird die Steuerung an einen Airflow-Worker zurückgegeben, der mithilfe eines Ausführungsslots eine Callback-Methode ausführt. Diese Phase wird von Celery Executor gesteuert. Daher gelten die entsprechenden Konfigurations- und Ressourcenlimits wie 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 führt der Wiederholungsvorgang die gesamte Aufgabe noch einmal aus, nicht nur die Callback-Methode.

Endlosschleife in einem Trigger

Es ist möglich, einen benutzerdefinierten Triggeroperator so zu implementieren, dass er die Haupttriggerer-Schleife vollständig blockiert, sodass nur der eine ausgefallene Trigger zu diesem Zeitpunkt ausgeführt wird. In diesem Fall wird eine Warnung in den Trigger-Logs generiert, nachdem der problematische Trigger abgeschlossen wurde.

Triggerklasse nicht gefunden

Da der DAGs-Ordner nicht mit dem Airflow-Triggerer 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 aus PyPI.

Warnmeldung zum Triggerer in der Airflow-UI

Nach dem Deaktivieren des Triggers wird in einigen Fällen die folgende Warnmeldung in der Airflow-UI 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, da unvollständige Trigger in der Airflow-Datenbank verbleiben. Diese Meldung bedeutet normalerweise, dass der Trigger deaktiviert wurde, bevor alle Trigger in Ihrer Umgebung ausgeführt wurden.

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

Lösungen:

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

Wenn der Trigger deaktiviert ist, verbleiben Aufgaben, die sich bereits im Status „verzögert“ befinden, in diesem Status, bis das Zeitlimit erreicht ist. Dieses Zeitlimit kann je nach Airflow- und DAG-Konfiguration unbegrenzt sein.

Verwenden Sie eine der folgenden Lösungen:

  • Aufgaben manuell als fehlgeschlagen markieren.
  • Aktivieren Sie den Triggerer, um die Aufgaben auszuführen.

Wir empfehlen, den Trigger nur zu deaktivieren, wenn in Ihrer Umgebung keine zurückgestellten Operatoren oder Aufgaben ausgeführt werden und alle ausgesetzten Aufgaben abgeschlossen sind.

Nächste Schritte