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 Problembehebungen 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 plant, sie von einem Worker ausgeführt zu werden, und wenn der Worker noch nicht die DAG-Datei hat, schlägt die Aufgabenausführung fehl.

Um dieses Problem zu beheben, sind Umgebungen mit Airflow 2 standardmäßig so konfiguriert, dass zwei Wiederholungen für eine fehlgeschlagene Aufgabe ausgeführt werden. Wenn eine Aufgabe fehlschlägt, wird sie zweimal mit Intervallen 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 . Wir sind der Meinung, dass Managed Airflow nicht anfällig für diese Sicherheitslücke ist.

Die Airflow-UI lädt ein Plug-in nach einer Änderung möglicherweise 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-UI

Beim Zugriff auf die Airflow-UI 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-UI 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 auftreten, 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 auftreten, prüfen Sie, ob Ihre Umgebung auf *.composer.cloud.google.com zugreifen kann. Wenn Sie privater Google-Zugriff verwenden und Traffic über virtuelle IP-Adressen von private.googleapis.com senden oder VPC Service Controls verwenden und Traffic über virtuelle IP-Adressen von restricted.googleapis.com senden, prüfen Sie, ob Cloud DNS auch für Domainnamen von *.composer.cloud.google.com konfiguriert ist.

  • Airflow-Webserver reagiert nicht. Wenn der Fehler 504 weiterhin auftritt, Sie aber zu bestimmten Zeiten auf die Airflow-UI 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-UI

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

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

  • Webserver konnte nicht gestartet werden. Zum Starten müssen zuerst die Konfigurationsdateien des Webservers synchronisiert werden. Prüfen Sie die Webserverlogs auf Logeinträge, die 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 diese Fehler auftreten, 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 in Ihrer Umgebung eine neue Umgebungsvariable fest. Sie können einen beliebigen Variablennamen und -wert verwenden.

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

Wenn Sie in der Baumansicht den Mauszeiger auf eine Aufgabeninstanz bewegen, wird ein nicht abgefangener TypeError ausgelöst.

In Airflow 2 funktioniert die Baumansicht in der Airflow-UI manchmal nicht richtig, wenn eine nicht standardmäßige Zeitzone verwendet wird. Als Behelfslösung können Sie die Zeitzone explizit in der Airflow-UI konfigurieren.

Leere Ordner in Planer und Workern

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

Empfehlung: Passen Sie Ihre DAGs so an, dass sie solche leeren Ordner überspringen können.

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 Herunterskalierung 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 für allgemeine Zwecke Compute-Klasse. Das bedeutet, dass das Ausführen von Pods, die andere Compute-Klassen anfordern (z. B. Balanced oder Scale-Out), nicht möglich ist.

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 (siehe Maximale Anfragen für Compute-Klassen).

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

Empfehlung: Verwenden Sie GKEStartPodOperator, um Kubernetes-Pods in 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 sie auch in einem Nicht-Managed Airflow-Cluster ausgeführt werden.

Cloud SQL-Speicher kann nicht verkleinert werden.

In Managed Airflow wird Cloud SQL zum Ausführen der Airflow-Datenbank verwendet. Im Laufe der Zeit kann der Festplattenspeicher für die Cloud SQL-Instanz wachsen, da die Festplatte skaliert wird, um die von Cloud SQL-Vorgängen gespeicherten Daten aufzunehmen, wenn die Airflow-Datenbank wächst.

Die Größe der Cloud SQL-Festplatte kann nicht verkleinert werden.

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

Die Messwert „Database Disk usage“ (Festplattennutzung der Datenbank) wird nach dem Entfernen von Datensätzen aus Cloud SQL nicht reduziert.

In relationalen Datenbanken wie PostgreSQL oder MySQL werden Zeilen beim Löschen oder Aktualisieren nicht physisch entfernt. Stattdessen werden sie als „tote Tupel“ markiert, um die Datenkonsistenz aufrechtzuerhalten und gleichzeitige Transaktionen nicht zu blockieren.

Sowohl MySQL als auch PostgreSQL implementieren Mechanismen zur Freigabe von Speicherplatz nach dem Löschen von Datensätzen.

Es ist zwar möglich, die Datenbank zu zwingen, nicht verwendeten Festplattenspeicher 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 dieses Problem einen Nutzer betrifft, enthält das Dialogfeld Zugriff blockiert: Autorisierungsfehler die Meldung Error 400: admin_policy_enforced.

Wenn in Google Workspace die Option API-Steuerung > Nicht konfigurierte Drittanbieter-Apps > Nutzern den Zugriff auf Drittanbieter-Apps nicht erlauben aktiviert ist und die App „Apache Airflow in Managed Airflow“ nicht explizit zugelassen ist, können Nutzer nicht auf die Airflow-UI zugreifen, es sei denn, sie erlauben die Anwendung explizit.

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

Anmeldeschleife beim Zugriff auf die Airflow-UI

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 eine schreibgeschützte Komponente. In Managed Airflow wird der Ordner data/ nicht mit dieser Komponente synchronisiert.

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

Lösung :

  • Packen Sie die Dateien, die für den Webserver freigegeben 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 der Airflow-Komponenten hinzugefügt und sind für sie verfügbar.

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

Diagramme für nicht kontinuierliche DAG-Parsing-Zeiten und DAG-Bag-Größe im Monitoring

Diagramme für nicht kontinuierliche DAG-Parsing-Zeiten und DAG-Bag-Größe im Überwachungsdashboard weisen auf Probleme mit langen DAG-Parsing-Zeiten hin (mehr als 5 Minuten).

Diagramme für Airflow-DAG-Parsing-Zeiten und DAG-Bag-Größe mit einer Reihe von nicht zusammenhängenden Intervallen
Abbildung 1. Diagramme für nicht kontinuierliche DAG-Parsing-Zeiten und DAG-Bag-Größe (zum Vergrößern klicken)

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

Aufgabenlogs werden mit Verzögerung angezeigt.

Symptom :

  • In Managed Airflow (Gen 3) werden Airflow-Aufgabenlogs nicht sofort angezeigt, sondern mit einer Verzögerung von einigen Minuten.
  • In den Airflow-Logs werden möglicherweise Meldungen wie Logs not found for Cloud Logging filter angezeigt.

Ursache :

Wenn in Ihrer Umgebung eine große Anzahl von Aufgaben gleichzeitig ausgeführt wird, können sich Aufgabenlogs verzögern, da die Infrastrukturgröße der Umgebung nicht ausreicht, um alle Logs schnell genug zu verarbeiten.

Lösungen :

  • Erhöhen Sie die Infrastrukturgröße der Umgebung, um die Leistung zu verbessern.
  • 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, treten längere Startzeiten auf. Das Managed Airflow-Team arbeitet an einer Lösung und wird Sie benachrichtigen, wenn das Problem behoben ist.

Behelfslösungen :

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

Umgebung hat den Status „ERROR“, 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 deaktiviert wurde in dem Projekt, auch wenn sie später aktiviert wurde.

So können Sie das Problem beheben:

  • Sie können weiterhin auf Daten in den Buckets Ihrer Umgebung zugreifen. Die Umgebungen selbst können jedoch nicht mehr verwendet werden. 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 dazu führen, dass Ihre Umgebungen nicht wiederhergestellt werden können, sichern Sie Ihre Daten, z. B. indem Sie einen Snapshot der Umgebung erstellen. Auf diese Weise können Sie eine andere 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.

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

Mögliche Lösung :

  • Entfernen Sie die Überschreibung für diese Konfigurationsoption oder setzen Sie ihren Wert auf False.

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 Behelfslösungen :

Beeinträchtigte Umgebungsleistung in mehreren Versionen des Pakets „google-api-core“

Die vorinstallierten Paketversionen von google-api-core von 2.28.0 bis 2.30.2 können die Umgebungsleistung beeinträchtigen. Dies kann zu längeren Ausführungszeiten für Aufgaben und längeren Zeiten für das Verschieben einer Aufgabe vom Status „In der Warteschlange“ in den Status „Wird ausgeführt“ führen.

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 bis composer-2.16.10-airflow-2.9.3

Wir empfehlen, ein Upgrade Ihrer Umgebung auf die folgenden Versionen durchzuführen, die eine Version des Pakets enthalten, in der das Problem behoben ist oder nicht auftritt:

  • composer-3-airflow-3.1.7-build.7 und höher
  • composer-3-airflow-2.11.1-build.3 und höher
  • composer-3-airflow-2.10.5-build.36 und höher
  • composer-3-airflow-2.9.3-build.54 (enthält 2.27.0)
  • composer-2.17.0-airflow-2.11.1 und höher
  • composer-2.17.0-airflow-2.10.5 und höher
  • composer-2.16.11-airflow-2.11.1 (enthält 2.27.0)
  • composer-2.16.11-airflow-2.10.5 (enthält 2.27.0)
  • composer-2.16.11-airflow-2.9.3 (enthält 2.27.0)

Als Behelfslösung können Sie manuell eine neuere Version des google-api-core Pakets in einer betroffenen Umgebung installieren, indem Sie >=2.30.3 als erforderliche Version angeben.

TI ist nicht mehr im Status „Wird ausgeführt“ und Aufgabe sollte beendet werden. Fehler „Task Not Found“ in Airflow 3

In Airflow 3-Versionen vor 3.3.1 gibt es mehrere Probleme im Zusammenhang mit dem Verlust des Aufgabenstatus durch den Planer:

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

  • 404-Fehler: Airflow-Worker verlieren bei einem regulären Neustart der Planerschleife den Überblick über Aufgabeninstanzen. Dies geschieht, nachdem der Planer [scheduler]max_runs überschritten 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).

Symptome

Der Status der verwaisten Bereinigung des neu gestarteten Planers markiert aktive Aufgaben als FAILED. Dadurch werden die Worker mit dem Status 409 abnormal beendet:

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('...')

Der neu gestartete Planer verliert die Aufgabenstatus und schlägt bei aktiven Worker-Pulstests mit einem 404-Fehler 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=...]

Mögliche Behelfslösungen :

  • Das Problem wurde in Airflow-Version 3.3.1 und höher behoben. Wir arbeiten daran, diese Version in Managed Airflow (Gen 3) bereitzustellen.

  • Es ist nicht möglich, das Problem vollständig zu beheben. In Airflow-Versionen vor 3.3.1 löst jedes externe Ereignis, das einen einzelnen Planer unerwartet neu startet, 404- und 409-Fehler aus. 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 für Race Conditions in Planern behoben.

    Für eine hochverfügbare Umgebung 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 durch den Planer weit unter den verfügbaren Ressourcengrenzen liegt.

Nächste Schritte