Cloud Composer 1 befindet sich im Modus nach der Wartung. Google veröffentlicht keine weiteren Updates für Cloud Composer 1, einschließlich neuer Versionen von Airflow, Fehlerkorrekturen und Sicherheitsupdates. Wir empfehlen die Migration zu Cloud Composer 2.

Diese Seite wurde von der Cloud Translation API übersetzt.

Bekannte Probleme

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Auf dieser Seite werden bekannte Cloud Composer-Probleme aufgeführt. Informationen zu Fehlerkorrekturen 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 minimieren, sind Umgebungen mit Airflow 2 standardmäßig so konfiguriert, dass bei einer fehlgeschlagenen Aufgabe zwei Wiederholungen ausgeführt werden. Wenn eine Aufgabe fehlschlägt, wird sie zweimal mit Intervallen von 5 Minuten wiederholt.

Cloud Composer ist von der Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) nicht betroffen

Wir haben Cloud Composer auf die Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) hin untersucht und sind zu dem Schluss gekommen, dass Cloud Composer nicht anfällig für diese Ausnutzung ist.

Die Airflow-Benutzeroberfläche lädt ein Plug-in manchmal nicht neu, nachdem es geändert wurde.

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 sollte. Starten Sie in diesem Fall den Airflow-Webserver Ihrer Umgebung neu.

Fehler 504 beim Zugriff auf die Airflow-Benutzeroberfläche

Der Fehler 504 Gateway Timeout kann beim Zugriff auf die Airflow-Benutzeroberfläche 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 Cloud Composer 3) Verbindungsproblem. Wenn die Airflow-Benutzeroberfläche dauerhaft nicht verfügbar ist und Zeitüberschreitungen oder 504-Fehler auftreten, prüfen Sie, ob Ihre Umgebung auf *.composer.googleusercontent.com zugreifen kann.
(Nur Cloud Composer 2) Verbindungsproblem. Wenn die Airflow-Benutzeroberfläche dauerhaft nicht verfügbar ist und Zeitüberschreitungen oder 504-Fehler auftreten, prüfen Sie, ob Ihre Umgebung auf *.composer.cloud.google.com zugreifen kann. Wenn Sie den privaten Google-Zugriff verwenden und Traffic über private.googleapis.com-virtuelle IP-Adressen senden oder VPC Service Controls und Traffic über restricted.googleapis.com-virtuelle 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 weiterhin 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 keine eingehenden Anfragen bedienen kann. Dieser Fehler kann mehrere Ursachen haben:

Vorübergehendes Kommunikationsproblem. Versuchen Sie später noch einmal, 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 Webserverprotokolle auf Einträge, die 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.

Bei versehentlichem Entfernen (z. B. weil eine Aufbewahrungsrichtlinie konfiguriert wurde) können Sie sie so 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 der Mauszeiger in der Baumansicht auf eine Aufgabeninstanz bewegt wird, wird der Fehler „uncaught TypeError“ ausgegeben.

In Airflow 2 funktioniert die Baumansicht in der Airflow-Benutzeroberfläche manchmal nicht richtig, wenn eine andere Zeitzone als die Standardzeitzone verwendet wird. Als Behelfslösung für dieses Problem können Sie die Zeitzone explizit in der Airflow-Benutzeroberfläche konfigurieren.

Leere Ordner im Scheduler und in den Workern

Cloud Composer entfernt keine leeren Ordner aktiv aus Airflow-Workern und -Planern. Solche Entitäten können durch den Bucket-Synchronisierungsprozess der Umgebung erstellt werden, wenn diese Ordner im Bucket vorhanden waren und später entfernt wurden.

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

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

Unterstützung für Kerberos

Cloud Composer unterstützt die Kerberos-Konfiguration von Airflow nicht.

Unterstützung für Compute-Klassen in Cloud Composer 2 und Cloud Composer 3

Cloud Composer 3 und Cloud Composer 2 unterstützen nur Compute-Klassen für Allgemeine Zwecke. 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 Allgemein können Pods mit bis zu 110 GB Arbeitsspeicher und bis zu 30 CPUs ausgeführt werden (wie unter Maximale Anforderungen an Compute-Klassen beschrieben).

Wenn Sie eine ARM-basierte Architektur verwenden oder mehr CPU und Arbeitsspeicher benötigen, müssen Sie eine andere Compute-Klasse verwenden, die in Cloud Composer 3- und Cloud Composer 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, für die eine andere Compute-Klasse erforderlich ist, müssen sie auch in einem Cluster ausgeführt werden, der nicht zu Cloud Composer gehört.

Cloud SQL-Speicherplatz kann nicht reduziert werden

Cloud Composer verwendet Cloud SQL, um die Airflow-Datenbank auszuführen. Mit der Zeit kann der Laufwerkspeicher für die Cloud SQL-Instanz anwachsen, da das Laufwerk skaliert wird, um die von Cloud SQL-Vorgängen gespeicherten Daten aufzunehmen, wenn die Airflow-Datenbank wächst.

Die Größe des Cloud SQL-Laufwerks kann nicht verringert werden.

Wenn Sie die kleinste Cloud SQL-Speicherplatzgröße verwenden möchten, können Sie Cloud Composer-Umgebungen mit Snapshots neu erstellen.

Der Messwert „Datenplattennutzung der Datenbank“ wird nach dem Entfernen von Einträgen 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“ gekennzeichnet, um die Datenkonsistenz aufrechtzuerhalten und das Blockieren gleichzeitiger Transaktionen zu vermeiden.

Sowohl MySQL als auch Postgres implementieren Mechanismen zur Wiederverwendung von Speicherplatz nach dem Löschen von Einträgen.

Es ist zwar möglich, die Datenbank zu zwingen, nicht verwendeten Speicherplatz zurückzufordern, dies ist jedoch ein ressourcenintensiver Vorgang, der die Datenbank zusätzlich sperrt und Cloud Composer nicht verfügbar macht. Daher wird empfohlen, die Gebäudemechanismen zu verwenden, um den nicht verwendeten Speicherplatz wiederherzustellen.

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-Steuerungen > Nicht konfigurierte Drittanbieter-Apps > Nutzer dürfen nicht auf Drittanbieter-Apps zugreifen in Google Workspace aktiviert ist und die Apache Airflow-App in Cloud Composer nicht explizit zugelassen ist, können Nutzer nicht auf die Airflow-Benutzeroberfläche zugreifen, es sei denn, sie erlauben die Anwendung explizit.

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

Dieses Problem kann folgende Ursachen haben:

Wenn bindungen für den kontextbezogenen Zugriff von Chrome Enterprise Premium mit Zugriffsebenen verwendet werden, die auf Geräteattributen basieren, und die Apache Airflow-App in Cloud Composer nicht ausgenommen ist, ist aufgrund einer Anmeldeschleife kein Zugriff auf die Airflow-Benutzeroberfläche möglich. Führen Sie die Schritte unter Zugriff auf die Airflow-Benutzeroberfläche in Bindungen für den kontextsensitiven Zugriff zulassen aus, um den Zugriff zuzulassen.
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 Cloud Composer-Dienst ermöglicht, den Identitätstyp ANY_SERVICE_ACCOUNT oder ANY_USER_ACCOUNT verwendet, können Nutzer nicht auf die Airflow-Benutzeroberfläche zugreifen und werden in eine Anmeldeschleife geleitet. Weitere Informationen zur Lösung dieses Szenarios finden Sie unter Zugriff auf die Airflow-Benutzeroberfläche in VPC Service Controls-Eingangsregeln zulassen.

Airflow-Komponenten haben Probleme bei der Kommunikation mit anderen Teilen der Cloud Composer-Konfiguration

In sehr seltenen Fällen kann die langsame Kommunikation mit dem Compute Engine-Metadatenserver dazu führen, dass Airflow-Komponenten nicht optimal funktionieren. So kann es beispielsweise vorkommen, dass der Airflow-Planer neu gestartet wird, Airflow-Aufgaben noch einmal versucht werden müssen oder die Startzeit der Aufgabe länger ist.

Symptome:

Die folgenden Fehler werden in den Logs von Airflow-Komponenten wie Airflow-Planern, Workern oder dem Webserver angezeigt:

Authentication failed using Compute Engine authentication due to unavailable metadata server

Compute Engine Metadata server unavailable on attempt 1 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 2 of 3. Reason: timed out
...
Compute Engine Metadata server unavailable on attempt 3 of 3. Reason: timed out

Lösung

Legen Sie die folgende Umgebungsvariable fest: GCE_METADATA_TIMEOUT=30.

In Cloud Composer 2 und Cloud Composer 3 ist der Airflow-Webserver eine weitgehend schreibgeschützte Komponente. Cloud Composer synchronisiert den Ordner data/ nicht mit dieser Komponente.

Manchmal möchten Sie gemeinsame 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 einem PYPI-Modul und installieren Sie es als reguläres PYPI-Paket. Nachdem das PYPI-Modul in der Umgebung installiert wurde, werden die Dateien den Bildern der 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.

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

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

Diagramme mit Airflow-DAG-Parsingzeiten und DAG-Bag-Größen, die eine Reihe von nicht zusammenhängenden Intervallen zeigen — **Abbildung 1**: Diagramme für nicht kontinuierliche DAG-Parsingzeiten und DAG-Bag-Größen (zum Vergrößern anklicken)

Lösung:Wir empfehlen, die Gesamtzeit für die DAG-Analyse unter 5 Minuten zu halten. Um die DAG-Parsingzeit zu verkürzen, folgen Sie den Richtlinien zum Schreiben von DAGs.

Aufgabenlogs werden verzögert angezeigt

Symptom:

In Cloud Composer 3 werden Airflow-Task-Logs nicht sofort angezeigt, sondern mit einer Verzögerung von einigen Minuten.

Ursache:

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

Lösungen:

Sie können die Infrastrukturgröße der Umgebung erhöhen, um die Leistung zu steigern.
DAG-Ausführungen über einen längeren Zeitraum verteilen, damit Aufgaben nicht gleichzeitig ausgeführt werden.

Längere Startzeiten für KubernetesPodOperator und KubernetesExecutor

Pods, die mit KubernetesPodOperator erstellt und Aufgaben, die mit KubernetesExecutor ausgeführt werden, haben längere Startzeiten. Das Cloud Composer-Team arbeitet an einer Lösung und wird bekannt geben, sobald das Problem behoben ist.

Problemumgehungen:

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

Die Umgebung hat den Status „FEHLER“, nachdem das Rechnungskonto des Projekts gelöscht oder deaktiviert wurde oder die Cloud Composer API deaktiviert wurde

Von diesen Problemen betroffene Cloud Composer-Umgebungen 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.

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 Cloud Composer-Umgebung erstellen und dann Ihre DAGs und Daten übertragen.
Wenn Sie einen der Vorgänge ausführen möchten, durch den Ihre Umgebungen nicht wiederhergestellt werden können, sollten Sie Ihre Daten sichern, z. B. indem Sie einen Snapshot einer Umgebung erstellen. So können Sie eine weitere Umgebung erstellen und die Daten übertragen, indem Sie diesen Snapshot laden.