Bekannte Probleme

Managed Airflow (Gen 3) | Managed Airflow (Gen 2) | Managed Airflow (Legacy Gen 1)

Auf dieser Seite sind bekannte Probleme mit Managed Airflow aufgeführt. Informationen zu Fehlerbehebungen finden Sie in den Versionshinweisen.

Der erste DAG wird für eine hochgeladene DAG-Datei mit mehreren fehlgeschlagenen Aufgaben ausgeführt.

Wenn Sie eine DAG-Datei hochladen, schlagen manchmal die ersten Aufgaben des ersten DAG mit dem Fehler Unable to read remote log... fehl. Dieses Problem tritt auf, weil die DAG-Datei zwischen dem Bucket Ihrer Umgebung, den Airflow-Workern und den Airflow-Planern Ihrer Umgebung synchronisiert wird. Wenn der Planer die DAG-Datei abruft und sie für die Ausführung durch einen Worker plant und der Worker die DAG-Datei noch nicht hat, schlägt die Ausführung der Aufgabe fehl.

Um dieses Problem zu beheben, sind Umgebungen mit Airflow 2 standardmäßig so konfiguriert, dass zwei Wiederholungsversuche für eine fehlgeschlagene Aufgabe ausgeführt werden. Wenn eine Aufgabe fehlschlägt, wird sie zweimal im Abstand von 5 Minuten wiederholt.

Managed Airflow sollte nicht von der Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) betroffen sein.

Als Reaktion auf die Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) hat Managed Airflow eine detaillierte Untersuchung durchgeführt und wir glauben, dass Managed Airflow nicht anfällig für diesen Exploit ist.

Die Airflow-Benutzeroberfläche lädt ein geändertes Plug-in manchmal nicht neu.

Wenn ein Plug-in aus vielen Dateien besteht, die andere Module importieren, kann die Airflow-UI möglicherweise nicht erkennen, dass ein Plug-in neu geladen werden muss. Starten Sie in diesem Fall den Airflow-Webserver Ihrer Umgebung neu.

Fehler 504 beim Zugriff auf die Airflow-Benutzeroberfläche

Beim Zugriff auf die Airflow-Benutzeroberfläche kann der Fehler 504 Gateway Timeout auftreten. Dieser Fehler kann mehrere Ursachen haben:

  • Vorübergehendes Kommunikationsproblem. Versuchen Sie in diesem Fall, später auf die Airflow-Benutzeroberfläche zuzugreifen. Sie können auch den Airflow-Webserver neu starten.

  • (Nur Managed Airflow (Gen 3)) Verbindungsproblem. Wenn die Airflow-UI dauerhaft nicht verfügbar ist und Zeitüberschreitungs- oder 504-Fehler generiert werden, prüfen Sie, ob Ihre Umgebung auf *.composer.googleusercontent.com zugreifen kann.

  • (Nur Managed Airflow (Gen 2)) Verbindungsproblem. Wenn die Airflow-UI dauerhaft nicht verfügbar ist und Zeitüberschreitungs- oder 504-Fehler generiert werden, prüfen Sie, ob Ihre Umgebung auf *.composer.cloud.google.com zugreifen kann. Wenn Sie den privater Google-Zugriff verwenden und Traffic über virtuelle private.googleapis.com-IP-Adressen senden oder VPC Service Controls verwenden und Traffic über virtuelle restricted.googleapis.com-IP-Adressen senden, muss Ihr Cloud DNS auch für *.composer.cloud.google.com-Domainnamen konfiguriert sein.

  • Airflow-Webserver reagiert nicht. Wenn der Fehler 504 weiterhin auftritt, Sie aber zu bestimmten Zeiten auf die Airflow-Benutzeroberfläche zugreifen können, reagiert der Airflow-Webserver möglicherweise nicht, weil er überlastet ist. Versuchen Sie, die Skalierungs- und Leistungsparameter des Webservers zu erhöhen.

Fehler 502 beim Zugriff auf die Airflow-Benutzeroberfläche

Der Fehler 502 Internal server exception gibt an, dass die Airflow-Benutzeroberfläche eingehende Anfragen nicht verarbeiten kann. Dieser Fehler kann mehrere Ursachen haben:

  • Vorübergehendes Kommunikationsproblem. Versuchen Sie später, auf die Airflow-Benutzeroberfläche zuzugreifen.

  • Der Webserver konnte nicht gestartet werden. Damit der Webserver gestartet werden kann, müssen zuerst die Konfigurationsdateien synchronisiert werden. Prüfen Sie die Webserver-Logs auf Logeinträge, die in etwa so aussehen: GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp oder GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. Wenn Sie diese Fehler sehen, prüfen Sie, ob die in den Fehlermeldungen genannten Dateien noch im Bucket der Umgebung vorhanden sind.

    Wenn sie versehentlich entfernt wurden (z. B. weil eine Aufbewahrungsrichtlinie konfiguriert wurde), können Sie sie wiederherstellen:

    1. Legen Sie eine neue Umgebungsvariable in Ihrer Umgebung fest. Sie können einen beliebigen Variablennamen und -wert verwenden.

    2. Airflow-Konfigurationsoption überschreiben. Sie können eine nicht vorhandene Airflow-Konfigurationsoption verwenden.

Fehler 500 beim Zugriff auf die Airflow-Benutzeroberfläche nach dem Überschreiben von [webserver]analytics_tool

Wenn Sie in Umgebungen mit Airflow 2 die Airflow-Konfigurationsoption [webserver]analytics_tool überschreiben, um anonyme Nutzungsdaten der Airflow-Benutzeroberfläche an einen Analysedienst (z. B. Google Analytics, Segment, MetaRouter oder Matomo) weiterzuleiten, kann der Zugriff auf die Airflow-Benutzeroberfläche nach dem erfolgreichen Umgebungsupdate eine (500) Internal Server Error-Antwort mit einem der folgenden Fehler in den Airflow-Server-Logs zurückgeben:

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

Wenn [webserver]analytics_tool in Airflow 2 festgelegt ist, müssen für den Airflow-Webserver auch die zugehörigen Analyseoptionen im Abschnitt [webserver] definiert werden, wenn die Airflow-UI gerendert wird.

In Airflow 3 werden die Konfigurationsoptionen [webserver]analytics_tool, [webserver]analytics_id und [webserver]analytics_url entfernt.

Lösungen:

  • Entfernen Sie die Überschreibung für die Airflow-Konfigurationsoption [webserver]analytics_tool oder
  • Geben Sie alle erforderlichen Airflow-Konfigurationsoptionen zusammen an:
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • [webserver]analytics_url (erforderlich in Airflow 2.9 und höher, auch wenn Ihr Analysetool keine benutzerdefinierte URL verwendet)

Wenn Sie den Mauszeiger in der Strukturansicht auf eine Aufgabeninstanz bewegen, wird ein nicht abgefangener TypeError ausgegeben.

In Airflow 2 funktioniert die Strukturansicht in der Airflow-UI manchmal nicht richtig, wenn eine nicht standardmäßige Zeitzone verwendet wird. Als Behelfslösung für dieses Problem können Sie die Zeitzone explizit in der Airflow-Benutzeroberfläche konfigurieren.

Leere Ordner in Scheduler und Workers

Managed Airflow entfernt leere Ordner nicht aktiv aus Airflow-Workern und -Planern. Solche Entitäten können im Rahmen der Synchronisierung des Umgebungs-Buckets erstellt werden, wenn diese Ordner im Bucket vorhanden waren und schließlich entfernt wurden.

Empfehlung: Passen Sie Ihre DAGs so an, dass solche leeren Ordner übersprungen werden.

Solche Entitäten werden schließlich aus den lokalen Speichern von Airflow-Planern und -Workern entfernt, wenn diese Komponenten neu gestartet werden (z. B. aufgrund von Skalierungs- oder Wartungsvorgängen im Cluster Ihrer Umgebung).

Unterstützung für Kerberos

Managed Airflow unterstützt die Airflow-Kerberos-Konfiguration nicht.

Unterstützung für Compute-Klassen in Managed Airflow (Gen 2) und Managed Airflow (Gen 3)

Managed Airflow (Gen 3) und Managed Airflow (Gen 2) unterstützen nur die Compute-Klasse für allgemeine Zwecke. Das bedeutet, dass Pods, die andere Compute-Klassen (z. B. Balanced oder Scale-Out) anfordern, nicht ausgeführt werden können.

Mit der Klasse Für allgemeine Zwecke können Pods ausgeführt werden, die bis zu 110 GB Arbeitsspeicher und bis zu 30 CPUs anfordern (wie unter Maximale Anfragen für Compute-Klassen beschrieben).

Wenn Sie eine ARM-basierte Architektur verwenden möchten oder mehr CPU und Arbeitsspeicher benötigen, müssen Sie eine andere Compute-Klasse verwenden, die in Managed Airflow-Clustern (Gen 3) und Managed Airflow-Clustern (Gen 2) nicht unterstützt wird.

Empfehlung: Verwenden Sie GKEStartPodOperator, um Kubernetes-Pods auf einem anderen Cluster auszuführen, der die ausgewählte Compute-Klasse unterstützt. Wenn Sie benutzerdefinierte Pods ausführen, die eine andere Compute-Klasse erfordern, müssen diese ebenfalls auf einem nicht verwalteten Airflow-Cluster ausgeführt werden.

Es ist nicht möglich, den Cloud SQL-Speicher zu reduzieren

Managed Airflow verwendet Cloud SQL zum Ausführen der Airflow-Datenbank. Im Laufe der Zeit kann der Speicherplatz für die Cloud SQL-Instanz zunehmen, da das Laufwerk so skaliert wird, dass es die von Cloud SQL-Vorgängen gespeicherten Daten aufnehmen kann, wenn die Airflow-Datenbank wächst.

Es ist nicht möglich, die Größe des Cloud SQL-Laufwerks zu verringern.

Wenn Sie die kleinste Cloud SQL-Laufwerkgröße verwenden möchten, können Sie als Behelfslösung Managed Airflow-Umgebungen mit Snapshots neu erstellen.

Der Messwert für die Datenbank-Speicherplatznutzung wird nach dem Entfernen von Datensätzen aus Cloud SQL nicht reduziert

Relationale Datenbanken wie Postgres oder MySQL entfernen Zeilen nicht physisch, wenn sie gelöscht oder aktualisiert werden. Stattdessen werden sie als „tote Tupel“ markiert, um die Datenkonsistenz zu wahren und das Blockieren gleichzeitiger Transaktionen zu vermeiden.

Sowohl MySQL als auch Postgres implementieren Mechanismen, um Speicherplatz nach gelöschten Datensätzen freizugeben.

Es ist zwar möglich, die Datenbank zu zwingen, ungenutzten Speicherplatz freizugeben, aber dies ist ein ressourcenintensiver Vorgang, der die Datenbank zusätzlich sperrt und Managed Airflow nicht verfügbar macht. Daher wird empfohlen, sich auf die integrierten Mechanismen zur Freigabe des nicht verwendeten Speicherplatzes zu verlassen.

Zugriff blockiert: Autorisierungsfehler

Wenn ein Nutzer von diesem Problem betroffen ist, enthält das Dialogfeld Zugriff blockiert: Autorisierungsfehler die Meldung Error 400: admin_policy_enforced.

Wenn die Option API-Steuerung > Nicht konfigurierte Drittanbieter-Apps > Nutzer dürfen nicht auf Drittanbieter-Apps zugreifen in Google Workspace aktiviert ist und Apache Airflow in der Managed Airflow-Anwendung nicht explizit zugelassen ist, können Nutzer nicht auf die Airflow-Benutzeroberfläche zugreifen, es sei denn, sie lassen die Anwendung explizit zu.

Führen Sie die Schritte unter Zugriff auf die Airflow-Benutzeroberfläche in Google Workspace zulassen aus, um den Zugriff zu erlauben.

Anmeldeschleife beim Zugriff auf die Airflow-Benutzeroberfläche

Dieses Problem kann folgende Ursachen haben:

Der Ordner „/data“ ist auf dem Airflow-Webserver nicht verfügbar

In Managed Airflow (Gen 2) und Managed Airflow (Gen 3) ist der Airflow-Webserver hauptsächlich als schreibgeschützte Komponente gedacht. Managed Airflow synchronisiert den Ordner data/ nicht mit dieser Komponente.

Manchmal möchten Sie gängige Dateien für alle Airflow-Komponenten freigeben, einschließlich des Airflow-Webservers.

Lösung:

  • Verpacken Sie die Dateien, die mit dem Webserver geteilt werden sollen, in ein PYPI-Modul und installieren Sie es als reguläres PYPI-Paket. Nachdem das PYPI-Modul in der Umgebung installiert wurde, werden die Dateien den Images von Airflow-Komponenten hinzugefügt und stehen ihnen zur Verfügung.

  • Fügen Sie dem Ordner plugins/ Dateien hinzu. Dieser Ordner wird mit dem Airflow-Webserver synchronisiert.

Nicht kontinuierliche DAG-Parseverarbeitungszeiten und DAG-Bag-Größendiagramme im Monitoring

Nicht kontinuierliche DAG-Parseverarbeitungszeiten und Diagramme zur DAG-Bag-Größe im Monitoring-Dashboard weisen auf Probleme mit langen DAG-Parseverarbeitungszeiten (mehr als 5 Minuten) hin.

Diagramme zu Airflow-DAG-Parsezeiten und DAG-Bag-Größe mit einer Reihe von nicht kontinuierlichen Intervallen
Abbildung 1. Diagramme zu nicht kontinuierlichen DAG-Analysezeiten und zur DAG-Bag-Größe (zum Vergrößern klicken)

Lösung: Wir empfehlen, die Gesamtzeit für das DAG-Parsing unter 5 Minuten zu halten. Folgen Sie den Richtlinien zum Schreiben von DAGs, um die Zeit für das Parsen von DAGs zu verkürzen.

Aufgabenlogs werden mit Verzögerung angezeigt

Symptom:

  • In Managed Airflow (Gen 3) werden Airflow-Tasklogs nicht sofort angezeigt, sondern sind um einige Minuten verzögert.
  • Möglicherweise finden Sie Logs not found for Cloud Logging filter-Nachrichten in den Airflow-Logs.

Ursache:

Wenn in Ihrer Umgebung eine große Anzahl von Aufgaben gleichzeitig ausgeführt wird, kann es zu Verzögerungen bei den Aufgabenlogs kommen, da die Infrastrukturgröße der Umgebung nicht ausreicht, um alle Logs schnell genug zu verarbeiten.

Lösungen:

  • Erwägen Sie, die Infrastrukturgröße der Umgebung zu erhöhen, um die Leistung zu steigern.
  • Verteilen Sie DAG-Ausführungen über die Zeit, damit Aufgaben nicht gleichzeitig ausgeführt werden.

Längere Startzeiten für KubernetesPodOperator und KubernetesExecutor

Bei Pods, die mit KubernetesPodOperator erstellt wurden, und Aufgaben, die mit KubernetesExecutor ausgeführt werden, verlängern sich die Startzeiten. Das Managed Airflow-Team arbeitet an einer Lösung und wird bekannt geben, wenn das Problem behoben ist.

Behelfslösungen:

  • Pods mit mehr CPU starten.
  • Optimieren Sie Bilder nach Möglichkeit (weniger Ebenen, kleinere Größe).

Die Umgebung befindet sich im Fehlerstatus, nachdem das Rechnungskonto des Projekts gelöscht oder deaktiviert oder die Cloud Composer API deaktiviert wurde.

Managed Airflow-Umgebungen, die von diesen Problemen betroffen sind, können nicht wiederhergestellt werden:

  • Nachdem das Rechnungskonto des Projekts gelöscht oder deaktiviert wurde, auch wenn später ein anderes Konto verknüpft wurde.
  • Nachdem die Cloud Composer API im Projekt deaktiviert wurde, auch wenn sie später wieder aktiviert wurde.

Sie können Folgendes tun, um das Problem zu beheben:

  • Sie können weiterhin auf Daten zugreifen, die in den Buckets Ihrer Umgebung gespeichert sind, aber die Umgebungen selbst sind nicht mehr nutzbar. Sie können eine neue Managed Airflow-Umgebung erstellen und dann Ihre DAGs und Daten übertragen.

  • Wenn Sie Vorgänge ausführen möchten, die Ihre Umgebungen unwiederbringlich machen, sollten Sie Ihre Daten sichern, z. B. durch Erstellen eines Snapshots einer Umgebung. So können Sie eine weitere Umgebung erstellen und ihre Daten übertragen, indem Sie diesen Snapshot laden.

Logs für Airflow-Aufgaben werden nicht erfasst, wenn [core]execute_tasks_new_python_interpreter auf „True“ gesetzt ist

Managed Airflow erfasst keine Logs für Airflow-Aufgaben, wenn die Airflow-Konfigurationsoption [core]execute_tasks_new_python_interpreter auf True gesetzt ist.

Mögliche Lösung:

  • Entfernen Sie die Überschreibung für diese Konfigurationsoption oder legen Sie den Wert auf False fest.

Fehler beim Entfernen des Netzwerkanhangs, wenn eine Umgebung gelöscht wird

Wenn mehrere Umgebungen, die denselben Netzwerkanhang verwenden, gleichzeitig gelöscht werden, schlagen einige Löschvorgänge mit einem Fehler fehl.

Symptome:

Der folgende Fehler wird generiert:

Got error while removing Network Attachment: <error code>

Der gemeldete Fehlercode kann Bad request: <resource> is not ready oder Precondition failed: Invalid fingerprint sein.

Mögliche Problemumgehungen:

  • Löschen Sie Umgebungen, die denselben Netzwerkanhang verwenden, nacheinander.

  • Deaktivieren Sie die Verbindung zu einem VPC-Netzwerk für Ihre Umgebungen, bevor Sie sie löschen. Wir empfehlen diese Problemumgehung für das automatisierte Löschen von Umgebungen.

Beeinträchtigte Umgebungsleistung in mehreren google-api-core-Paketversionen

Versionen von 2.28.0 bis 2.30.2

Die vorinstallierten google-api-core-Paketversionen von 2.28.0 bis 2.30.2 können zu einer verminderten Leistung der Umgebung führen. Dies kann dazu führen, dass die Ausführung einer Aufgabe länger dauert und es länger dauert, eine Aufgabe vom Status „In der Warteschlange“ in den Status „Wird ausgeführt“ zu verschieben.

Betroffene Managed Airflow (Gen 3)-Builds:

  • composer-3-airflow-3.1.7-build.0 bis composer-3-airflow-3.1.7-build.5
  • composer-3-airflow-3.1.0-build.5 bis composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • composer-3-airflow-2.10.5-build.22 bis composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 bis composer-3-airflow-2.9.3-build.53

Betroffene Managed Airflow (Gen 2)-Builds:

  • composer-2.16.10-airflow-2.11.1
  • composer-2.16.0-airflow-2.10.5 bis composer-2.16.10-airflow-2.10.5
  • composer-2.16.0-airflow-2.9.3 zu composer-2.16.10-airflow-2.9.3

Führen Sie ein Upgrade Ihrer Umgebung auf einen der folgenden Builds durch, die die vorinstallierte google-api-core-Version 2.27.0 enthalten und nicht von diesem Problem betroffen sind:

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

Alternativ können Sie ein Upgrade auf ein Image mit google-api-core 2.43.1 oder höher ausführen oder manuell eine kompatible Version installieren.

In Python 3.11 verursachen die google-api-core-Versionen 2.30.3 bis 2.43.0 ab dem 24. Oktober 2026 ein separates Leistungsproblem. Wenn in Ihrer Umgebung Python 3.11 ausgeführt wird, wenden Sie eine der Problemumgehungen an, die unter Versionen von 2.30.3 bis 2.43.0 in Python 3.11 aufgeführt sind.

Versionen von 2.30.3 bis 2.43.0 in Python 3.11

Ab dem 24. Oktober 2026 führen die google-api-core-Paketversionen 2.30.3 bis 2.43.0 eine Prüfung auf die Einstellung von Python 3.11 durch. Dabei werden die Metadaten installierter Pakete gescannt, wenn eine Google Cloud Clientbibliothek in einen neuen Python-Unterprozess importiert wird.

In Managed Airflow-Umgebungen, in denen Python 3.11 ausgeführt wird, kann dieses Verhalten die Leistung beeinträchtigen. Dieses Problem ist in Umgebungen mit vielen DAGs, häufigen kurz laufenden Aufgaben oder aktivierter Datenherkunftsintegration schwerwiegender.

Die Symptome sind folgende:

  • Längere DAG-Parsing-Zeiten und höhere CPU-Auslastung auf Airflow-DAG-Prozessoren.
  • Längere Taskausführungszeiten und höhere CPU-Auslastung bei Airflow-Workern.
  • Häufige FutureWarning-Logeinträge von google/api_core/_python_version_support.py, die darauf hinweisen, dass der Support für Python 3.11 am 24.10.2027 endet.

Dieses Problem betrifft alle Python 3.11-Umgebungen, in denen die google-api-core-Version 2.30.3 bis 2.43.0 entweder vorinstalliert oder manuell installiert ist, einschließlich der folgenden Builds.

Dieses Problem betrifft die folgenden Managed Airflow (Gen 3)-Builds:

  • composer-3-airflow-3.3.1-build.0 bis composer-3-airflow-3.3.1-build.5
  • composer-3-airflow-3.2.2-build.0 bis composer-3-airflow-3.2.2-build.9
  • composer-3-airflow-3.1.8-build.0 bis composer-3-airflow-3.1.8-build.4
  • composer-3-airflow-3.1.7-build.7 bis composer-3-airflow-3.1.7-build.13
  • composer-3-airflow-2.11.1-build.3 bis composer-3-airflow-2.11.1-build.22
  • composer-3-airflow-2.10.5-build.36 bis composer-3-airflow-2.10.5-build.52

Betroffene Managed Airflow (Gen 2)-Builds:

  • composer-2.17.0-airflow-2.11.1 bis composer-2.17.16-airflow-2.11.1
  • composer-2.17.0-airflow-2.10.5 bis composer-2.17.13-airflow-2.10.5

Problemumgehungen:

Wählen Sie je nach Image-Version Ihrer Umgebung eine der folgenden Optionen aus:

  • Option 1 Nur kompatible Managed Airflow-Builds (Gen 3) mit Airflow 3: Installieren Sie das PyPI-Paket google-api-core mit der Versionsbeschränkung >=2.43.1.

    Kompatible Managed Airflow-Builds (Gen 3):

    • composer-3-airflow-3.3.1-build.0 bis composer-3-airflow-3.3.1-build.5
    • composer-3-airflow-3.2.2-build.1 bis composer-3-airflow-3.2.2-build.9
    • composer-3-airflow-3.1.8-build.3 bis composer-3-airflow-3.1.8-build.4

    Verwenden Sie diese Option nicht für Airflow 2-Builds oder frühere Airflow 3-Builds, einschließlich composer-3-airflow-3.2.2-build.0 und composer-3-airflow-3.1.8-build.0 bis build.2. In diesen Builds verursacht google-api-core 2.43.1 Abhängigkeitskonflikte, da opentelemetry-api>=1.44.0 erforderlich ist. Verwenden Sie für diese Builds Option 2.

  • Option 2. Alle betroffenen Managed Airflow (Gen 3)- und Managed Airflow (Gen 2)-Builds: Wenden Sie einen sitecustomize.py-Laufzeitpatch an.

    1. Laden Sie sitecustomize.py von GitHub herunter.

    2. Laden Sie sitecustomize.py in den Ordner dags/patches im Bucket Ihrer Umgebung hoch.

    3. Setzen Sie die Umgebungsvariable PYTHONPATH auf /home/airflow/gcs/dags/patches.

      Wenn PYTHONPATH bereits festgelegt ist, stellen Sie /home/airflow/gcs/dags/patches: dem vorhandenen Wert voran. Beispiel: /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    Bereinigung nach einem Upgrade: In zukünftigen Managed Airflow-Releases wird die google-api-core-Paketversion 2.43.1 oder höher vorinstalliert sein. Nach dem Upgrade auf ein Image mit google-api-core 2.43.1 oder höher können Sie die Überschreibung von PYTHONPATH entfernen und dags/patches/sitecustomize.py löschen.

TI befindet sich nicht mehr im Status „Wird ausgeführt“, die Aufgabe sollte beendet werden und es treten „Task Not Found“-Fehler in Airflow 3 auf

In Airflow 3 gibt es zwei Probleme, bei denen der Planer beim Neustart den Aufgabenstatus verliert:

  • 409-Konfliktstatus: Eine Race-Bedingung in Schedulern führt zu einer doppelten Planung von Aufgabeninstanzen (#59378, behoben in #60330).

    Dieses Problem wurde in Airflow 3.2.2 behoben.

  • Fehler „404 Nicht gefunden“: Airflow-Worker verlieren während eines regulären Neustarts der Planerschleife den Überblick über Aufgabeninstanzen. Dies geschieht, nachdem der Planer [scheduler]num_runs erreicht hat. Dadurch werden die vorhandenen Aufgabeninstanz-IDs geändert und es werden nachfolgende 404-Fehler von einem Worker generiert, der die Änderung nicht kennt (#53140, #60330, behoben in #61631).

    Dieses Problem wurde in Airflow 3.3.1 behoben.

Symptome

  • 409 Conflict: Der Status der Bereinigung verwaister Aufgaben eines neu gestarteten Schedulers markiert aktive Aufgaben als FAILED, was dazu führt, dass die Worker abnormal beendet werden:

    Server indicated the task shouldn't be running anymore [supervisor]
detail={'detail': {'reason': 'not_running', 'message': 'TI is no longer in
the running state and task should terminate', 'current_state': 'scheduled'}} status_code=409 ti_id=UUID('...')

  • 404 Nicht gefunden: Ein neu gestarteter Planer verliert Aufgabenstatus und schlägt bei aktiven Worker-Pulsprüfungen fehl:

    Server indicated the task shouldn't be running anymore [detail={'detail':
{'reason': 'not_found', 'message': 'Task Instance not found'}}]
[status_code=404] [ti_id=...]

Lösung:

  • Beide Probleme wurden in Airflow-Version 3.3.1 und höher behoben. Aktualisieren Sie Ihre Umgebung auf eine Version, die Airflow 3.3.1 verwendet.

Mögliche Problemumgehungen:

  • In Airflow-Versionen vor 3.3.1 ist es nicht möglich, das Problem vollständig zu beheben. Jedes externe Ereignis, das einen einzelnen Planer unerwartet neu startet, löst 404 und 409 aus (in Airflow-Versionen vor 3.2.2). Beispiele für solche Ereignisse sind automatische Upgrades von Knoten im Cluster Ihrer Umgebung, OOM-Bedingungen in Pods oder ein hoher Arbeitsspeicher- und CPU-Verbrauch durch Planer.

  • Wenn Sie Ihre Umgebung auf einen Planer herunterskalieren und die Konfigurationsoption [scheduler]num_runs auf -1 setzen, wird die Ursache von Race-Bedingungen in Planern minimiert.

    In einer Umgebung mit extrem hoher Ausfallsicherheit (Hochverfügbarkeit) ist es nicht möglich, die Anzahl der Planer auf einen zu reduzieren. Sie können [scheduler]num_runs weiterhin auf -1 setzen.

  • Achten Sie darauf, dass der Arbeitsspeicher- und CPU-Verbrauch des Schedulers innerhalb der verfügbaren Ressourcenlimits liegt.

Nächste Schritte