Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
Auf dieser Seite werden bekannte Cloud Composer-Probleme aufgeführt. Fehlerbehebungen für diese in Bearbeitung und in folgenden Sprachen verfügbar: zukünftigen Versionen.
Einige Probleme betreffen ältere Versionen und können durch ein Upgrade Ihrer Umgebung behoben werden.
Adressen außerhalb des RFC 1918-Bereichs werden für Pods und Dienste teilweise unterstützt
Cloud Composer ist von GKE abhängig, um Nicht-RFC 1918-Adressen für Pods und Dienste bereitzustellen. Derzeit wird in Cloud Composer nur die folgende Liste mit Nicht-RFC 1918-Bereichen unterstützt:
- 100.64.0.0/10
- 192.0.0.0/24
- 192.0.2.0/24
- 192.88.99.0/24
- 198.18.0.0/15
- 198.51.100.0/24
- 203.0.113.0/24
- 240.0.0.0/4
In der Airflow-Benutzeroberfläche werden keine Aufgabenlogs angezeigt, wenn sich die DAG-Serialisierung in Composer 1.10.2 und Composer 1.10.3 befindet
Durch Aktivieren der DAG-Serialisierung in Umgebungen mit Composer-Versionen 1.10.2 und 1.10.3 werden die Logs nicht im Airflow-Webserver angezeigt. Führen Sie zur Problembehebung ein Upgrade auf Version 1.10.4 oder höher durch.
Inkonsistenter Taskfehler bei der Planung in Cloud Composer
Das Problem tritt in einem Airflow-Scheduler für die Aufgabeninstanz während der Ausführung der Aufgabe auf. Die Protokolle erklären jedoch nicht die Ursache des Aufgabenfehlers und Airflow Worker und Airflow Scheduler sahen relativ gesund aus.
Die Fehlermeldung im Airflow-Scheduler sieht möglicherweise so aus:
Executor reports task instance <TaskInstance: xx.xxxx scheduled__2022-04-21T06:00:00+00:00 [queued]> finished (failed) although the task says its queued. (Info: None) Was the task killed externally?
Möglicherweise gibt es auch einen Fehler beim Airflow-Worker, der dem folgenden ähnelt:
Log file is not found: gs://$BUCKET_NAME/logs/$DAG_NAME/$TASK_NAME/2023-01-25T05:01:17.044759+00:00/1.log.
The task might not have been executed or worker executing it might have finished abnormally (e.g. was evicted).
Um für Robustheit gegenüber solchen Fehlern zu sorgen, die auf ein langjähriges Problem in Airflow zurückzuführen sind, wird dringend empfohlen, proaktiv geeignete Wiederholungsstrategien sowohl auf Aufgaben- als auch auf DAG-Ebene zu implementieren. Durch die Integration dieser Maßnahmen kann das System die Auswirkungen dieser Fehler effektiv mindern und so die Zuverlässigkeit und Robustheit des Workflows insgesamt verbessern.
GKE Workload Identity wird nicht unterstützt
Dieses Problem betrifft nur Cloud Composer 1-Umgebungen. Cloud Composer 2 Umgebungen verwenden Workload Identity.
Sie können Workload Identity für Cluster von Cloud Composer-Umgebungen nicht aktivieren. Daher wird möglicherweise das Ergebnis WORKLOAD_IDENTITY_DISABLED
im Security Command Center angezeigt.
Während einer Aktualisierung hinzugefügte Umgebungslabels werden nicht vollständig übernommen
Aktualisierte Umgebungslabels werden nicht auf Compute Engine-VMs angewendet. Als Behelfslösung können diese Labels manuell angewendet werden.
GKE-Upgrades im Zusammenhang mit Problem CVE-2020-14386
Wir arbeiten an der Behebung des CVE-2020-14386 Sicherheitslücke in allen Cloud Composer-Umgebungen. Im Rahmen des werden alle vorhandenen GKE-Cluster von Cloud Composer auf eine neuere Version.
Kunden, die die Sicherheitslücke sofort beheben möchten, können das Upgrade der Composer-GKE-Cluster mit dieser Anleitung unter Berücksichtigung folgender Überlegungen durchführen:
Schritt 1: Wenn Sie eine Cloud Composer-Version vor Version 1.7.2 ausführen, führen Sie ein Upgrade auf eine neuere Version von Cloud Composer durch. Wenn Sie bereits Version 1.7.2 oder höher haben, fahren Sie mit dem nächsten Punkt fort.
Schritt 2: Aktualisieren Sie die GKE-Cluster (Master und Knoten) auf die neueste 1.15-Patch-Version, die den Fehlerbehebung für diese Sicherheitslücke enthält.
Airflow-Aufgabenlogs sind im Airflow-Webserver nach einem Upgrade von Airflow 1.9.0 auf Airflow 1.10.x nicht verfügbar.
Mit Airflow 1.10.x wurden nicht abwärtskompatible Änderungen an der Benennung für Protokolldateien. Zoneninformationen werden jetzt zu den Lognamen für Airflow-Aufgaben.
Airflow 1.9.0 speichert und erwartet, dass die Log-Namen das folgende Format haben:BUCKET/logs/DAG/2020-03-30T10:29:06/1.log
Airflow 1.10.x speichert und erwartet, dass die Log-Namen das folgende Format haben:BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log
Wenn Sie ein Upgrade von Airflow 1.9.0 auf Airflow 1.10.x durchführen und das Log für eine mit Airflow 1.9.0 ausgeführte Aufgabe lesen möchten, zeigt der Airflow-Webserver die folgende Fehlermeldung an: Unable to read remote log from BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log
Problemumgehung: Benennen Sie die von Airflow 1.9.0 im Cloud Storage-Bucket generierten Logs in folgendem Format um: BUCKET/logs/DAG/2020-03-30T10:29:06+00:00/1.log
Es können keine Cloud Composer-Umgebungen mit der erzwungenen Organisationsrichtlinieneinschränkung /compute.disableSerialPortLogging erstellt werden
Wird constraints/compute.disableSerialPortLogging
für das Zielprojekt erzwungen, so schlägt die Erstellung der Cloud Composer-Umgebung fehl.
Diagnose
So ermitteln Sie, ob Sie von diesem Problem betroffen sind:
Rufen Sie in der Google Cloud Console das GKE-Menü auf. Zum GKE-Menü
Wählen Sie anschließend den neu erstellten Cluster aus. Suchen Sie nach folgendem Fehler:
Not all instances running in IGM after 123.45s.
Expect <number of desired instances in IGM>. Current errors:
Constraint constraints/compute.disableSerialPortLogging violated for
project <target project number>.
Problemumgehungen:
Deaktivieren Sie die Organisationsrichtlinie für das Projekt, in dem die Cloud Composer-Umgebung erstellt werden soll.
Eine Organisationsrichtlinie kann jederzeit auf Projektebene deaktiviert werden, auch wenn sie von den übergeordneten Ressourcen (Organisation oder Ordner) aktiviert ist. Weitere Informationen finden Sie auf der Seite Richtlinien für boolesche Einschränkungen anpassen.
Ausschlussfilter verwenden
Durch Verwendung eines Ausschlussfilters für serielle Portlogs wird das gleiche Ziel wie das Deaktivieren der Organisationsrichtlinie verwendet, da es in Logging serielle Konsolenlogs gibt. Weitere Informationen finden Sie auf der Seite Ausschlussfilter.
Deployment Manager zum Verwalten von Google Cloud-Ressourcen verwenden, die durch VPC Service Controls geschützt sind
Composer verwendet Deployment Manager, um Komponenten von Cloud Composer-Umgebungen zu erstellen.
Im Dezember 2020 haben Sie möglicherweise Informationen erhalten, die Sie unter Umständen zur Konfiguration weiterer VPC Service Controls-Ressourcen benötigen, um Deployment Manager zum Verwalten von Ressourcen zu verwenden, die durch VPC Service Controls geschützt sind.
Wir möchten klarstellen, dass Ihrerseits keine Maßnahmen erforderlich sind. Wenn Sie Composer und nicht Deployment Manager direkt nutzen zum Verwalten von Google Cloud-Ressourcen, die im Deployment Manager erwähnt werden, .
Eine Umgebung kann nicht gelöscht werden, nachdem der GKE-Cluster gelöscht wurde.
Wenn Sie den Cluster der Umgebung vor der Umgebung selbst löschen, führt der Versuch, die Umgebung zu löschen, zu folgendem Fehler:
Got error "" during CP_DEPLOYMENT_DELETING [Rerunning Task. ]
So löschen Sie eine Umgebung, wenn der GKE-Cluster bereits gelöscht ist:
Öffnen Sie in der Google Cloud Console die Seite Deployment Manager.
Alle mit Labels gekennzeichneten Bereitstellungen suchen:
goog-composer-environment:<environment-name>
goog-composer-location:<environment-location>
.
Sie sollten zwei Bereitstellungen sehen, die mit den beschriebenen Labels gekennzeichnet sind:
- Eine Bereitstellung mit dem Namen
<environment-location>-<environment-name-prefix>-<hash>-sd
- Eine Bereitstellung mit dem Namen
addons-<uuid>
Löschen Sie Ressourcen, die noch in diesen beiden Bereitstellungen aufgeführt und im Projekt vorhanden sind (z. B. Pub/Sub-Themen und -Abos). Anleitung:
Wählen Sie die Bereitstellungen aus.
Klicken Sie auf Löschen.
Wählen Sie die Option Zwei Bereitstellungen und alle von ihnen erstellten Ressourcen löschen, z. B. VMs, Load-Balancer und Laufwerke, und klicken Sie auf Alle löschen.
Der Löschvorgang schlägt fehl, die verbleibenden Ressourcen werden jedoch gelöscht.
Löschen Sie die Bereitstellungen mit einer der folgenden Optionen:
Wählen Sie in der Google Cloud Console noch einmal beide Bereitstellungen aus. Klicken Sie auf Löschen und wählen Sie die Option Zwei Bereitstellungen löschen, aber die von ihnen erstellten Ressourcen beibehalten aus.
Führen Sie einen gcloud-Befehl aus, um die Bereitstellungen mit der Richtlinie
ABANDON
zu löschen:gcloud deployment-manager deployments delete addons-<uuid> \ --delete-policy=ABANDON gcloud deployment-manager deployments delete <location>-<env-name-prefix>-<hash>-sd \ --delete-policy=ABANDON
Deployment Manager zeigt Informationen zu einer nicht unterstützten Funktion an.
Im Tab „Deployment Manager“ kann die folgende Warnung angezeigt werden:
The deployment uses actions, which are an unsupported feature. We recommend
that you avoid using actions.
Bei Bereitstellungen von Deployment Manager, die Cloud Composer gehören, können Sie diese Warnung ignorieren.
Warnungen zu doppelten Einträgen der Aufgabe „echo“, die zum DAG „echo-airflow_monitoring“ gehört.
In den Airflow-Logs wird möglicherweise der folgende Eintrag angezeigt:
in _query db.query(q) File "/opt/python3.6/lib/python3.6/site-packages/MySQLdb/
connections.py", line 280, in query _mysql.connection.query(self, query)
_mysql_exceptions.IntegrityError: (1062, "Duplicate entry
'echo-airflow_monitoring-2020-10-20 15:59:40.000000' for key 'PRIMARY'")
Sie können diese Logeinträge ignorieren, da dieser Fehler keine Auswirkungen auf den Airflow-DAG und die Aufgabenverarbeitung hat.
Wir arbeiten an der Verbesserung des Cloud Composer-Dienstes, um diese Warnungen aus Airflow-Logs zu entfernen.
Das Erstellen von Umgebungen in Projekten mit Identity-Aware Proxy APIs, die dem VPC Service Controls-Perimeter hinzugefügt wurden, schlägt fehl
In Projekten mit aktiviertem VPC Service Controls
Das cloud-airflow-prod@system.gserviceaccount.com
-Konto erfordert eine explizite
Zugriff in Ihrem Sicherheitsperimeter, um Umgebungen zu erstellen.
Zum Erstellen von Umgebungen können Sie eine der folgenden Lösungen verwenden:
Fügen Sie dem Sicherheitsperimeter nicht die Cloud Identity-Aware Proxy API und die Identity-Aware Proxy TCP API hinzu.
Fügen Sie das Dienstkonto
cloud-airflow-prod@system.gserviceaccount.com
hinzu als Mitglied Ihres Sicherheitsperimeters indem Sie die folgende Konfiguration in der YAML-Bedingungsdatei verwenden:- members: - serviceAccount:cloud-airflow-prod@system.gserviceaccount.com
Das Erstellen der Cloud Composer 1-Umgebung schlägt fehl, wenn die Richtlinie compute.requireOsLogin
aktiviert ist
Wenn die Richtlinie compute.requireOsLogin
in Ihrem Projekt auf true
gesetzt ist, schlägt das Erstellen der Cloud Composer 1-Umgebung fehl.
Deaktivieren Sie diese Richtlinie in den Projekt arbeiten.
Weitere Informationen zu dieser Organisationsrichtlinie finden Sie unter Einschränkungen für Organisationsrichtlinien.
Erstellen oder Aktualisieren von Cloud Composer-Umgebungen schlägt fehl, wenn compute.vmExternalIpAccess
deaktiviert ist
Cloud Composer-eigene GKE-Cluster, die im Modus für öffentliche IP-Adressen konfiguriert sind, erfordern eine externe Verbindung für ihre VMs. Aus diesem Grund kann die Erstellung von VMs mit externen IP-Adressen in der Richtlinie compute.vmExternalIpAccess
nicht verboten werden. Weitere Informationen zu dieser Organisationsrichtlinie finden Sie unter Einschränkungen für Organisationsrichtlinien.
Wenn die Richtlinie compute.vmCanIpForward
deaktiviert ist, schlägt das Erstellen der Cloud Composer-Umgebung fehl.
In Cloud Composer 1-Umgebungen, die im Modus nicht VPC-nativ (mit Alias-IP) erstellt werden, ist diese Richtlinie erforderlich, um das Erstellen von VMs mit der aktivierten Funktion "IP-Weiterleitung" zu ermöglichen. Weitere Informationen zu dieser Organisationsrichtlinie finden Sie unter Einschränkungen für Organisationsrichtlinien.
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. Diese Synchronisierungen werden unabhängig voneinander durchgeführt. 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.
Als Behelfslösung können Airflow-2-Umgebungen in Cloud Composer 1.17.0-preview.9 und höhere Versionen standardmäßig so konfiguriert werden, 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.
So verwenden Sie die Problemumgehung in Problem 1: Überschreiben Sie die core-default_task_retries
Airflow-Konfigurationsoption und legen Sie sie auf eine Zahl größer oder gleich 2
fest.
Aufgabe schlägt mit „OSError: [Errno 5] Input/output error“ in Airflow 1.10.15 oder früheren Versionen fehl
Ein Programmfehler in Airflow-1-Versionen führt dazu, dass in einigen seltenen Fällen Aufgaben zweimal in die Redis-Warteschlange gestellt werden.
Manchmal kann dies zu einer Race-Bedingung in der Logdatei und einem nachfolgenden Aufgabenfehler führen. Aufgaben schlagen mit OSError: [Errno 5] Input/output error
in Cloud Logging und Task is in the 'running' state which is not a valid state for execution.
im Aufgabenversuchslog fehl.
Dieser Fehler wurde in Airflow 2 behoben. Wenn dieses Problem in Airflow 1 bei einer lang andauernden Aufgabe auftritt, erhöhen Sie den Wert der Airflow-Konfigurationsoption [celery_broker_transport_options]visibility_timeout
(Standardwert ist 604800
für Composer 1.17.0, 21600
für ältere Umgebungen). Erwägen Sie bei kurz laufenden Aufgaben, zusätzliche Wiederholungen zu den betroffenen Aufgaben hinzuzufügen oder Ihre Umgebung zu Airflow 2 zu migrieren.
Dataproc/Dataflow-Operatoren schlagen mit Negsignal.SIGSEGV
fehl.
Dies ist ein vorübergehendes Problem der grcpio
-Bibliothek, wenn sie von einem Celery-Worker verwendet wird. Dieses Problem betrifft Airflow-Versionen ab 1.10.14.
Das Problem lässt sich dadurch umgehen, dass Sie die Abfragestrategie grpcio
ändern. Dazu fügen Sie der Umgebung die folgende Umgebungsvariable hinzu: GRPC_POLL_STRATEGY=epoll1
. Diese Problemumgehung wurde bereits in Cloud Composer 1.17.1 und höheren Versionen angewendet.
Hinweise zur Einstellung der Unterstützung für verworfene Beta APIs aus GKE-Versionen
Cloud Composer verwaltet zugrunde liegende Cloud Composer-Cluster. Sofern Sie diese APIs nicht explizit in Ihren DAGs und Ihrem Code verwenden, können Sie Ankündigungen zu verworfenen GKE APIs ignorieren. Cloud Composer übernimmt bei Bedarf alle Migrationen.
GKE-Upgrades im Zusammenhang mit Sicherheitsproblemen mit CVE-2021-25741
Alle GKE-Cluster von Cloud Composer werden automatisch auf neuere GKE-Versionen aktualisiert, wobei die in CVE-2021-25741 beschriebenen Probleme behoben werden.
Wenn Sie diese Sicherheitslücke sofort beheben möchten, führen Sie ein Upgrade des GKE-Clusters Ihrer Umgebung durch. Folgen Sie dazu der Anleitung zum Upgrade eines Clusters.
Wenn Sie eine Cloud Composer 1-Umgebung und GKE-Version 1.18.x oder früher haben, aktualisieren Sie auf 1.18.20-gke.4501.
Wenn Sie eine Cloud Composer 1-Umgebung und GKE-Version 1.19.x haben, führen Sie ein Upgrade auf 1.19.14-gke.301 durch.
Wenn Sie eine Cloud Composer 2-Umgebung und GKE-Version 1.21.x haben, führen Sie ein Upgrade auf 1.21.4-gke.301 durch.
Cloud Composer sollte von der Apache Log4j 2-Sicherheitslücke (CVE-2021-44228) nicht betroffen sein
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.
Bei Airflow-Workern oder Planern können Probleme beim Zugriff auf den Cloud Storage-Bucket der Umgebung auftreten.
Cloud Composer verwendet gcsfuse, um auf den Ordner /data
im Bucket der Umgebung zuzugreifen und Airflow-Aufgabenprotokolle im Verzeichnis /logs
zu speichern (falls aktiviert). Wenn gcsfuse überlastet oder der Bucket der Umgebung nicht verfügbar ist,
können Instanzen von Airflow-Aufgaben ausfallen
Transport endpoint is not connected
Fehler in Airflow-Logs.
Lösungen:
- Deaktivieren Sie das Speichern von Protokollen im Bucket der Umgebung. Diese Option ist bereits standardmäßig deaktiviert, wenn eine Umgebung mit Cloud Composer 2.8.0 oder höher erstellt wird.
- Führen Sie ein Upgrade auf Cloud Composer 2.8.0 oder höher durch.
- Reduzieren Sie
[celery]worker_concurrency
und erhöhen Sie stattdessen die Anzahl der Airflow-Worker. - Reduzieren Sie die Anzahl der im DAG-Code erstellten Logs.
- Befolgen Sie die Empfehlungen und Best Practices für DAGs implementieren und Aufgabenwiederholungen ermöglichen.
Die Airflow-Benutzeroberfläche lädt ein Plug-in manchmal nicht neu, nachdem es geändert wurde.
Besteht ein Plug-in aus vielen Dateien, die andere Module importieren, Die Airflow-UI erkennt möglicherweise nicht, dass ein Plug-in neu geladen. In einem solchen Fall muss der Airflow-Webserver neu gestartet werden. Dazu können Sie eine Umgebungsvariable hinzufügen oder PYPI-Abhängigkeiten installieren oder deinstallieren. Sie können auch den Airflow-Webserver neu starten.
Zeitweilige Probleme bei der Kommunikation mit der Airflow-Metadatendatenbank
Dieses bekannte Problem tritt nur bei Cloud Composer 1 auf.
Bei einigen älteren Cloud Composer 1-Umgebungen (1.16.3 oder älter), die vor dem 12. August 2021 erstellt wurden, kann es zu vorübergehenden Problemen mit der Kommunikation mit Airflow-Metadatenbanken kommen.
Wenn dieses Problem auftritt, sehen Sie in den Airflow-Aufgabenlogs folgende Fehlermeldung:
"Can't connect to MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"
Das Cloud Composer-Team arbeitet an der Lösung dieses Problems. Wenn Sie der Meinung sind, dass Sie von diesem Problem stark betroffen sind, können Sie in der Zwischenzeit Folgendes tun, um es zu beheben:
- Rufen Sie in der Google Cloud Console die Seite Umgebungskonfiguration auf. der betroffenen Cloud Composer-Umgebungen.
- Klicken Sie auf den Link Clusterdetails aufrufen, um den zugrunde liegenden GKE-Cluster der Umgebung aufzurufen.
Wechseln Sie zum Tab Knoten und klicken Sie im Abschnitt Knotenpools auf den Standardpool.
Klicken Sie oben auf der Seite auf Bearbeiten.
Ändern Sie den Image-Typ in Container-Optimized OS mit containerd und speichern Sie die Konfiguration wie unten gezeigt.
Nachdem die Änderung gesendet wurde, wird der default-pool-Knotenpool neu konfiguriert um "containerd" als Containerlaufzeit zu verwenden. Einige Ihrer Airflow-Aufgaben schlagen möglicherweise fehl während der Knotenpool neu konfiguriert wird. Wenn für diese Aufgaben Wiederholungsversuche konfiguriert sind, werden sie von Airflow noch einmal ausgeführt, sobald der Vorgang am Knotenpool abgeschlossen ist.
Der Cluster der Umgebung hat Arbeitslasten im Status „Nicht planbar“
Dieses bekannte Problem tritt nur bei Cloud Composer 2 auf.
In Cloud Composer 2 bleiben nach dem Erstellen einer Umgebung mehrere Arbeitslasten im Cluster der Umgebung im Status „Nicht planbar“.
Wenn eine Umgebung hochskaliert wird, werden neue Worker-Pods erstellt und Kubernetes versucht, sie auszuführen. Wenn keine freien Ressourcen für die Ausführung verfügbar sind, werden die Worker-Pods als „Nicht planbar“ gekennzeichnet.
In diesem Fall fügt der Cluster Autoscaler weitere Knoten hinzu, was einige Minuten dauern kann. Bis dahin bleiben die Pods im Status „Nicht planbar“ und führen keine Aufgaben aus.
Nicht planbare DaemonSet-Arbeitslasten mit den Namen composer-gcsfuse
und composer-fluentd
, die nicht auf Knoten gestartet werden können, auf denen keine Airflow-Komponenten vorhanden sind, wirken sich nicht auf Ihre Umgebung aus.
Wenn das Problem länger als eine Stunde andauert, können Sie die Cluster Autoscaler-Protokolle prüfen. Sie finden sie in der Loganzeige mit dem folgenden Filter:
resource.type="k8s_cluster"
logName="projects/<project-name>/logs/container.googleapis.com%2Fcluster-autoscaler-visibility"
resource.labels.cluster_name="<cluster-name>"
Es enthält Informationen zu Entscheidungen, die von Cluster Autoscaler getroffen wurden. Maximieren Sie alle „noDecisionStatus“, um den Grund zu sehen, warum der Cluster nicht hoch- oder herunterskaliert werden kann.
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, auf die Airflow-UI zuzugreifen. . Sie können auch Starten Sie den Airflow-Webserver neu.
- (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 Privater Google-Zugriff und Traffic weiterleitenprivate.googleapis.com
Virtuelle IP-Adressen oder VPC Service Controls und Traffic überrestricted.googleapis.com
virtuelle IP-Adressen senden, achten Sie darauf, ist Ihr Cloud DNS auch für*.composer.cloud.google.com
Domainnamen. - 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-UI
Der Fehler 502 Internal server exception
gibt an, dass die Airflow-UI nicht
um eingehende Anfragen zu verarbeiten. Dieser Fehler kann mehrere Ursachen haben:
Vorübergehendes Kommunikationsproblem. Versuchen Sie später noch einmal, auf die Airflow-Benutzeroberfläche zuzugreifen.
Webserver konnte nicht gestartet werden. Damit der Webserver gestartet werden kann, müssen zuerst die Konfigurationsdateien synchronisiert werden. Webserverprotokolle auf Logeinträge, die etwa so aussehen:
GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp
oderGCS 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 erwähnten Dateien noch im Bucket der Umgebung vorhanden sind.Bei versehentlichem Entfernen (z. B. weil eine Aufbewahrungsrichtlinie konfiguriert wurde) können Sie sie so wiederherstellen:
Legen Sie in Ihrer Umgebung eine neue Umgebungsvariable fest. Sie können einen beliebigen Variablennamen und -wert verwenden.
Ü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 möglicherweise nicht. wenn eine nicht standardmäßige Zeitzone verwendet wird. Um das Problem zu umgehen Problem, konfigurieren Sie die Zeitzone explizit auf der Airflow-UI.
Die Airflow-UI in Airflow 2.2.3 oder früheren Versionen ist anfällig für CVE-2021-45229
Wie in CVE-2021-45229 erwähnt,
den „DAG mit Konfiguration auslösen“ Bildschirm war anfällig für XSS-Angriffe
origin
zurück.
Empfehlung: Führen Sie ein Upgrade auf die neueste Cloud Composer-Version durch. die Airflow 2.2.5 unterstützt.
Workers benötigen mehr Arbeitsspeicher als in früheren Airflow-Versionen
Symptome:
In Ihrer Cloud Composer 2-Umgebung haben alle Clusterarbeitslasten der Airflow-Worker den Status
CrashLoopBackOff
und führen keine Aufgaben aus. Außerdem werdenOOMKilling
-Warnungen angezeigt, wenn Sie von diesem Problem betroffen sind.Dadurch können Umgebungsupgrades verhindert werden.
Ursache:
- Wenn Sie einen benutzerdefinierten Wert für die Airflow-Konfigurationsoption
[celery]worker_concurrency
und benutzerdefinierte Arbeitsspeichereinstellungen für Airflow-Worker verwenden, kann dieses Problem auftreten, wenn der Ressourcenverbrauch das Limit erreicht. - Der Arbeitsspeicherbedarf von Airflow-Workern in Airflow 2.6.3 mit Python 3.11 beträgt 10% im Vergleich zu den Workern in früheren Versionen.
- Die Arbeitsspeicheranforderungen von Airflow-Workern in Airflow 2.3 und höher sind 30 % höher als bei Workern in Airflow 2.2 oder Airflow 2.1.
Lösungen:
- Entfernen Sie die Überschreibung für
worker_concurrency
, damit Cloud Composer diesen Wert automatisch berechnet. - Wenn Sie einen benutzerdefinierten Wert für
worker_concurrency
verwenden, legen Sie einen niedrigeren Wert fest. Sie können die automatisch berechneter Wert als Ausgangspunkt. - Alternativ können Sie den für Airflow-Worker verfügbaren Arbeitsspeicher erhöhen.
- Wenn Sie Ihre Umgebung aufgrund dieses Problems nicht auf eine neuere Version aktualisieren können, wenden Sie vor dem Upgrade eine der vorgeschlagenen Lösungen an.
DAG-Triggerung über private Netzwerke mit Cloud Run-Funktionen
Das Auslösen von DAGs mit Cloud Run-Funktionen über private Netzwerke mithilfe des VPC-Connectors wird von Cloud Composer nicht unterstützt.
Empfehlung: Verwenden Sie Cloud Run-Funktionen, um Nachrichten in Pub/Sub zu veröffentlichen. Solche Ereignisse können Pub/Sub-Sensoren zum Auslösen von Airflow-DAGs aktivieren oder einen Ansatz implementieren, der auf zurückstellbaren Operatoren basiert.
Problem mit gcloud composer-Befehlen in Version 410.0.0
In der Version 410.0.0 von gcloud sind die folgenden Cloud Composer-Befehle nicht mehr verfügbar:
gcloud composer environments run
gcloud composer environments list-packages
einen Fehlercode ungleich null zurückgeben und diese Fehlermeldung anzeigen:
(ERROR: gcloud crashed (TypeError): 'NoneType' object is not callable)
Dieses Verhalten tritt zusätzlich zur regulären Ausgabe auf, die durch die gcloud-Befehle generiert wird, und hat keine Auswirkungen auf ihre Funktionalität.
Wenn dieses Problem keine Auswirkungen auf Ihre Vorgänge hat, können Sie weiterhin die Version 410.0.0 verwenden und die inkorrekte Fehlermeldung ignorieren. Wenn Sie die Version 410.0.0 verwenden müssen und den gcloud-Befehl programmatisch verwenden, implementieren Sie bitte zusätzliche Logik, um einen Fehlercode ungleich 0 und Informationen zum Fehler-Stacktrace in der Ausgabe zu ignorieren. Im Abschnitt „Lösung“ finden Sie weitere Behelfslösungen.
Lösung
- Sie sollten kein Upgrade auf die Version 410.0.0 ausführen. Verwenden Sie Version 409.0.0 oder eine frühere Version.
- Falls Sie bereits ein Upgrade durchgeführt haben, führen Sie ein Downgrade auf eine frühere Version aus (z. B. 409.0.0). Weitere Informationen finden Sie unter Versionierte Archive verwenden.
Leere Ordner in Planer und Workern
Cloud Composer entfernt leere Ordner nicht aktiv aus Airflow und Planungstools. Solche Entitäten können durch die Bucket-Synchronisierung 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 den lokalen Speichern von Airflow-Planern und ‑Workern entfernt, wenn diese Komponenten neu gestartet werden (z. B. aufgrund von Downscaling- oder Wartungsvorgängen im Cloud Composer-Cluster).
Unterstützung für Kerberos
Cloud Composer unterstützt noch keine Airflow-Kerberos-Konfiguration.
Unterstützung für Computing-Klassen in Cloud Composer 2
Cloud Composer 2 unterstützt nur die Allzweck-Rechenklasse. Es bedeutet, dass die Ausführung von Pods, die andere Compute-Klassen anfordern (z. B. Ausgeglichen oder Hochskalieren) ist nicht möglich.
Mit der Klasse general-purpose 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 2-Cluster.
Empfehlung: Verwenden Sie GKEStartPodOperator
, um Kubernetes-Pods auszuführen
einen anderen Cluster, der die ausgewählte Compute-Klasse unterstützt. Wenn Sie
Benutzerdefinierte Pods, die eine andere Compute-Klasse erfordern, ausführen, dann müssen sie auch
in einem Nicht-Cloud Composer 2-Cluster.
Unterstützung für Google Campaign Manager 360-Operatoren
Google Campaign Manager-Operator in Cloud Composer-Versionen vor 2.1.13 basieren auf der Campaign Manager 360 v3.5 API, die eingestellt wird und am 1. Mai 2023 eingestellt wird.
Wenn Sie Google Campaign Manager-Operatoren verwenden, führen Sie ein Upgrade Ihrer Umgebung auf Cloud Composer Version 2.1.13 oder höher durch.
Unterstützung für Google Display & Video 360-Betreiber
Google Display & Video 360-Operatoren in Cloud Composer-Versionen Versionen vor 2.1.13 basieren auf der Display & Video 360 v1.1 API, die und das Ablaufdatum ist der 27. April 2023.
Wenn Sie Google Display & Video 360-Operatoren verwenden, führen Sie ein Upgrade Ihrer Umgebung auf Cloud Composer Version 2.1.13 oder höher durch. Außerdem müssen Sie möglicherweise Ihre DAGs ändern, da einige der Google Display & Video 360-Operatoren eingestellt und durch neue ersetzt werden.
GoogleDisplayVideo360CreateReportOperator
ist jetzt eingestellt. StattdessenGoogleDisplayVideo360CreateQueryOperator
verwenden. Dieser Operator gibtquery_id
stattreport_id
.GoogleDisplayVideo360RunReportOperator
wurde verworfen. StattdessenGoogleDisplayVideo360RunQueryOperator
verwenden. Dieser Operator gibtquery_id
undreport_id
anstelle von nurreport_id
zurück und erfordertquery_id
anstelle vonreport_id
als Parameter.- Wenn Sie prüfen möchten, ob ein Bericht fertig ist, verwenden Sie den neuen
GoogleDisplayVideo360RunQuerySensor
-Sensor, derquery_id
undreport_id
-Parameter. Das verworfeneGoogleDisplayVideo360ReportSensor
Sensor nurreport_id
erforderlich. - Für
GoogleDisplayVideo360DownloadReportV2Operator
sind jetzt beidequery_id
erforderlich undreport_id
. - In
GoogleDisplayVideo360DeleteReportOperator
gibt es keine Änderungen, die sich auf Ihre DAGs auswirken können.
Einschränkungen für den Namen des sekundären Bereichs
CVE-2023-29247 (Detailseite der Aufgabeninstanz in der Benutzeroberfläche ist anfällig für gespeicherte XSS.)
Die Airflow-UI in Airflow-Versionen von 2.0.x bis 2.5.x ist anfällig für CVE-2023-29247.
Wenn Sie eine ältere Cloud Composer-Version als 2.4.2 verwenden und vermuten, dass Ihre Umgebung anfällig für den Exploit ist, lesen Sie die folgende Beschreibung und die möglichen Lösungen.
In Cloud Composer wird der Zugriff auf die Airflow-Benutzeroberfläche mit IAM und der Zugriffssteuerung der Airflow-Benutzeroberfläche geschützt.
Um die Airflow-UI-Sicherheitslücke auszunutzen, müssen Sie sich zunächst Zugriff auf Ihr Projekt sowie IAM-Berechtigungen und -Rollen
Lösung:
Prüfen Sie die IAM-Berechtigungen und -Rollen in Ihrem Projekt, einschließlich Einzelnen Nutzern zugewiesene Cloud Composer-Rollen. Achten Sie darauf, dass nur genehmigte Nutzer auf die Airflow-UI zugreifen können.
Überprüfen Sie die Rollen, die Nutzern über die Zugriffssteuerung für Airflow-UI Dies ist ein separater Mechanismus, der eine präzisere Zugriffssteuerung ermöglicht. an die Airflow-UI). Sicherstellen, dass nur genehmigte Nutzer Zugriff haben Airflow-UI und dass alle neuen Nutzer mit einer geeigneten Rolle registriert sind.
Sie können die Sicherheit mit VPC Service Controls weiter erhöhen.
Der Airflow-Monitoring-DAG der Cloud Composer 2-Umgebung wird nach dem Löschen nicht neu erstellt
Der Airflow-Monitoring-DAG wird nicht automatisch neu erstellt, wenn er vom Nutzer gelöscht oder aus dem Bucket in Composer-Umgebungen mit composer-2.1.4-airflow-2.4.3 verschoben wird.
Lösung:
- Dieses Problem wurde in neueren Versionen wie composer-2.4.2-airflow-2.5.3 behoben. Der empfohlene Ansatz besteht darin, Ihre Umgebung auf eine neuere Version zu aktualisieren.
- Eine Alternative oder vorübergehende Lösung für ein Umgebungsupgrade wäre, den DAG „airflow_monitoring“ aus einer anderen Umgebung mit derselben Version zu kopieren.
Upgradevorgänge können fehlschlagen, wenn Sentry aktiviert ist
Das Upgrade für eine Cloud Composer-Umgebung kann fehlschlagen
wenn Sie Sentry in Ihrer Umgebung konfiguriert und den [sentry]sentry_on
festgelegt haben
Einstellung auf true
.
Lösung:
- Deaktivieren Sie Sentry in Ihrer Umgebung, führen Sie das Upgrade aus und konfigurieren Sie Sentry noch einmal.
Es ist nicht möglich, den Cloud SQL-Speicher zu reduzieren
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-Speicherkapazität 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 kleiner
Relationale Datenbanken wie Postgres oder MySQL entfernen Zeilen nicht physisch, wenn gelöscht oder aktualisiert werden. Stattdessen werden sie als „tote Tupel“ gekennzeichnet. zur Aufrechterhaltung Datenkonsistenz zu vermeiden und das Blockieren gleichzeitiger Transaktionen zu vermeiden.
Sowohl MySQL als auch Postgres implementieren Mechanismen zur Rückgewinnung von Speicherplatz nach dem Löschen. Datensätze.
Es ist zwar möglich, die Datenbank zu zwingen, nicht verwendeten Speicherplatz wiederherzustellen, aber dies ist 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.
Aufgabeninstanzen, die in der Vergangenheit erfolgreich waren und als FEHLGESCHLAGEN markiert wurden
In einigen Fällen und seltenen Szenarien können Airflow-Aufgabeninstanzen, die in der Vergangenheit erfolgreich waren, als FAILED
markiert werden.
Wenn dies der Fall ist, wurde es entweder durch ein Umgebungsupdate oder Upgradevorgang oder GKE-Wartung.
Hinweis: Das Problem selbst weist nicht auf ein Problem in der Umgebung hin und führt nicht zu tatsächlichen Fehlern bei der Aufgabenausführung.
Das Problem wurde in Cloud Composer Version 2.6.5 oder höher behoben.
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 Airflow-Komponenten angezeigt: Logs (z. B. Airflow) Planer, Worker oder Webserver):
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
.
Der Ordner „/data“ ist auf dem Airflow-Webserver nicht verfügbar
In Cloud Composer 2 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-Daten 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 ein normales PYPI-Paket. Nach der Installation des PYPI-Moduls in der Umgebung werden die Dateien den Airflow-Images hinzugefügt. Komponenten und zur Verfügung stehen.
Fügen Sie dem Ordner „
plugins/
“ Dateien hinzu. Dieser Ordner wird mit dem Airflow-Webserver synchronisiert.
Diagramme zur nicht kontinuierlichen DAG-Analyse und DAG-Bag-Größe im Monitoring
Diagramme zur nicht kontinuierlichen DAG-Analyse und DAG-Bag-Größe im Monitoring Dashboard auf Probleme mit langen DAG-Parsing-Zeiten (mehr als 5 Minuten) hin.
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 mit Verzögerungen angezeigt
Dieses bekannte Problem betrifft Cloud Composer 3.
Symptom:
- In Cloud Composer 3 werden Airflow-Aufgabenlogs nicht sofort angezeigt. einige Minuten verzögert.
Ursache:
Wenn in Ihrer Umgebung eine große Anzahl von Aufgaben gleichzeitig ausgeführt wird, zu Verzögerungen führen kann, da die Größe der Infrastruktur nicht ausreicht, um alle Logs 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 bestimmten Zeitraum verteilen, sodass Aufgaben nicht zur selben Zeit ausgeführt werden .
Nächste Schritte
- Fehlerbehebung beim Erstellen der Umgebung
- Fehlerbehebung bei DAGs
- Fehlerbehebung bei Airflow Scheduler-Problemen