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 Plug-in nach einer Änderung möglicherweise nicht neu.

Wenn ein Plug-in aus vielen Dateien besteht, die andere Module importieren, kann die Airflow-Benutzeroberfläche 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.

• Der 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 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 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 auf dem 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 Herunterskalierungs- 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 anfordern (z. B. Ausgeglichen oder Horizontal skalieren), 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 Managed 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 hochskaliert wird, um die von Cloud SQL-Vorgängen gespeicherten Daten aufzunehmen, 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-Laufwerksgröße verwenden möchten, können Sie als Behelfslösung Managed Airflow-Umgebungen mit Snapshots neu erstellen.

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

In relationalen Datenbanken wie Postgres oder MySQL werden Zeilen nicht physisch entfernt, 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 dieses Problem einen Nutzer betrifft, 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 die Apache Airflow-Anwendung in Managed Airflow nicht explizit zugelassen ist, können Nutzer nicht auf die Airflow-UI 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:

• Wenn kontextsensitive Zugriffsberechtigungen von Chrome Enterprise Premium mit Zugriffsebenen verwendet werden, die auf Geräteattributen basieren, und die Apache Airflow-Anwendung in Managed Airflow nicht ausgenommen ist, kann aufgrund einer Anmeldeschleife nicht auf die Airflow-Benutzeroberfläche zugegriffen werden. Führen Sie die Schritte unter Zugriff auf die Airflow-Benutzeroberfläche in kontextsensitiven Zugriffsberechtigungen zulassen aus, um den Zugriff zu erlauben.

• Wenn Regeln für eingehenden Traffic in einem VPC Service Controls-Perimeter konfiguriert sind, der das Projekt schützt, und die Regel für eingehenden Traffic, die den Zugriff auf den Managed Airflow-Dienst ermöglicht, den Identitätstyp ANY_SERVICE_ACCOUNT oder ANY_USER_ACCOUNT verwendet, können Nutzer nicht auf die Airflow-UI zugreifen und landen in einer Anmeldeschleife. Weitere Informationen zur Behebung dieses Problems finden Sie unter Zugriff auf die Airflow-Benutzeroberfläche in Regeln für eingehenden Traffic von VPC Service Controls zulassen.

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 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 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 Diagramme zur DAG-Analysezeit und DAG-Bag-Größe im Monitoring

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

Abbildung 1. Nicht kontinuierliche DAG-Parsetime- und DAG-Bag-Größendiagramme (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 DAG-Parsing-Zeit zu reduzieren.

Aufgabenlogs werden mit Verzögerung angezeigt

Symptom:

• In Managed Airflow (Gen 3) werden Airflow-Tasklogs nicht sofort angezeigt, sondern erst nach einigen Minuten.
• In den Airflow-Logs finden Sie möglicherweise Logs not found for Cloud Logging filter-Nachrichten.

Ursache:

Wenn in Ihrer Umgebung eine große Anzahl von Aufgaben gleichzeitig ausgeführt wird, können sich die Aufgabenlogs verzögern, 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, wenn möglich (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 dazu führen, dass Ihre Umgebungen nicht wiederhergestellt werden können, sollten Sie Ihre Daten sichern, z. B. durch Erstellen eines Snapshots der 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.

Die Basis-Container-Images für die betroffenen Builds wurden gepatcht, sodass neu erstellte Umgebungen nicht betroffen sind. Nur vorhandene Umgebungen, deren Container-Images seit dem 4. November 2026 nicht aktualisiert wurden, sind weiterhin betroffen.

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

Lösungen:

Um dieses Problem in einer vorhandenen Umgebung zu beheben, führen Sie ein Upgrade auf ein Image durch, das am oder nach dem 6. November 2026 veröffentlicht wurde (enthält google-api-core 2.43.1), führen Sie ein Upgrade auf einen der folgenden Builds durch (enthält google-api-core 2.27.0) oder folgen Sie den Schritten zur Selbsthilfe unter Versionen von 2.30.3 bis 2.43.0 mit Python 3.11:

• 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

Hinweis: Unter Python 3.11 verursachen die google-api-core-Versionen 2.30.3 bis 2.43.0 ab dem 24. Oktober 2026 ebenfalls ein Leistungsproblem bei der Prüfung auf veraltete Versionen. Weitere Informationen finden Sie unter Versionen von 2.30.3 bis 2.43.0 unter Python 3.11.

Versionen von 2.30.3 bis 2.43.0 auf Python 3.11

Ab dem 24. Oktober 2026 wird in den google-api-core-Paketversionen 2.30.3 bis 2.43.0 (sowie 2.28.0 bis 2.30.2) eine Prüfung auf die Einstellung von Python 3.11 durchgeführt. Dabei werden die Metadaten installierter Pakete gescannt, wenn eine Clientbibliothek von Google Cloud 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, insbesondere in Umgebungen mit vielen DAGs, häufigen kurz laufenden Aufgaben oder aktivierter Datenherkunftsintegration.

Status:

• In den Releases vom 6. November 2026 und höher behoben: In den Images composer-3-airflow-3.3.1-build.6, composer-3-airflow-3.2.2-build.10, composer-3-airflow-2.11.1-build.23, composer-2.17.17-airflow-2.11.1 und höher ist google-api-core 2.43.1 vorinstalliert, wodurch dieses Problem behoben wird.
• Gepatchte Basis-Images für frühere Builds: Basis-Container-Images für alle betroffenen Builds, die in diesem Abschnitt aufgeführt sind, wurden in allen Regionen gepatcht. Neu erstellte Umgebungen sind nicht betroffen, auch wenn Sie sie mit einem früheren Build erstellen.
• Vorhandene Umgebungen: Umgebungen, die vor dem 5. November 2026 erstellt wurden, verwenden weiterhin zuvor im Cache gespeicherte Container-Images, bis sie durch geplante Wartungsarbeiten oder einen der Schritte zur Problembehebung in diesem Abschnitt aktualisiert werden.

Zu den Symptomen gehören:

• 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.

Vor der Image-Aktualisierung waren Python 3.11-Umgebungen betroffen, in denen die google-api-core-Version 2.30.3 bis 2.43.0 vorinstalliert oder manuell installiert war, einschließlich der folgenden Builds.

Betroffene 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

Maßnahmen für vorhandene Umgebungen:

• Schneller Pfad in asia-east1, asia-northeast2, europe-central2, me-central1, northamerica-northeast1 und us-south1: Wenn in Ihrer Umgebung bereits ein geplantes Wartungsfenster abgeschlossen wurde, legen Sie eine Platzhalter-Umgebungsvariable fest oder aktualisieren Sie sie, um Airflow-Arbeitslasten auf einer gepatchten Compute-Infrastruktur neu zu starten:

  gcloud composer environments update ENVIRONMENT_NAME \
    --location LOCATION \
    --update-env-variables=COMPOSER_RELOAD=1
  

  Prüfen Sie nach Abschluss des Vorgangs die Umgebungsprotokolle. Wenn FutureWarning-Einträge von google/api_core/_python_version_support.py weiterhin in neu gestarteten Arbeitslasten angezeigt werden (z. B. wenn die geplante Wartung noch nicht ausgeführt wurde oder Ihr Projekt VPC Service Controls verwendet), wenden Sie eine der Optionen für alle Regionen an.

  Hinweis: In europe-north1, europe-west3, us-east1 und us-west2 werden bei der geplanten Wartung automatisch Airflow-Arbeitslasten, die keine Worker sind (z. B. Planer und DAG-Prozessoren), auf gepatchten Images neu gestartet. Wenn Sie Airflow-Worker ebenfalls sofort aktualisieren möchten, wenden Sie eine der folgenden Optionen an.

• Alle Regionen: Wählen Sie eine der folgenden Optionen aus:

  • Option 1: Umgebung aktualisieren Führen Sie ein Upgrade auf einen nicht betroffenen Build wie composer-3-airflow-3.3.1-build.6, composer-3-airflow-3.2.2-build.10, composer-3-airflow-2.11.1-build.23 oder einen neueren gepatchten Build durch.

  • Option 2: PyPI-Paketaktualisierung auslösen (erfordert Zugriff auf das PyPI-Repository). Aktualisieren Sie ein vorhandenes benutzerdefiniertes PyPI-Paket oder installieren Sie ein zusätzliches Paket, um Ihr Umgebungs-Image aus dem gepatchten Basis-Image neu zu erstellen und alle Airflow-Arbeitslasten neu zu starten.

    Auf composer-3-airflow-3.3.1-build.0 bis build.5, composer-3-airflow-3.2.2-build.1 bis build.9 und composer-3-airflow-3.1.8-build.3 bis build.4 können Sie google-api-core>=2.43.1 installieren. Installieren Sie google-api-core>=2.43.1 nicht auf früheren Airflow 3-Builds (3.2.2-build.0, 3.1.8-build.0 bis build.2, 3.1.7, 3.1.0) oder früheren Airflow 2-Builds, da opentelemetry-api>=1.44.0 erforderlich ist und Abhängigkeitskonflikte verursacht. Lösen Sie stattdessen ein weiteres PyPI-Paketupdate aus.

• Option 3 (alternative Problemumgehung ohne Upgrade oder Änderung von PyPI-Paketen): Wenden Sie einen sitecustomize.py-Laufzeitpatch an. Verwenden Sie diese Option, wenn Ihre Umgebung beispielsweise VPC Service Controls ohne Zugriff auf das PyPI-Repository verwendet und Sie nicht sofort ein Upgrade durchführen können:

  1. Laden Sie sitecustomize.py von GitHub herunter.

     Wichtig: Ändern Sie die Datei nicht so, dass sie die Wörter airflow oder dag enthält (auch nicht in Kommentaren), damit sie vom abgesicherten Modus der DAG-Erkennung von Airflow ignoriert wird.

  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: Nachdem Sie ein Upgrade Ihrer Umgebung durchgeführt oder das Image mit den vorherigen Schritten neu erstellt haben, können Sie die Überschreibung 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 den Aufgabenstatus verliert, wenn er neu gestartet wird:

• 409-Konfliktstatus: Eine Race-Bedingung in Planern 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 unerwarteten Neustart eines einzelnen Schedulers verursacht, löst 404- und 409-Fehler 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 festlegen, 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

• Fehlerbehebung beim Erstellen der Umgebung
• Fehlerbehebung bei DAGs
• Fehlerbehebung bei Airflow Scheduler-Problemen