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 enthält Schritte zur Fehlerbehebung und Informationen für gängige Workflows
Probleme.
Viele Probleme bei der DAG-Ausführung werden durch eine nicht optimale Umgebungsleistung verursacht.
Informationen zum Optimieren Ihrer Cloud Composer 2-Umgebung finden Sie im Leitfaden Umgebungsleistung und ‑kosten optimieren.
Einige Probleme bei der DAG-Ausführung können durch eine fehlerhafte oder nicht optimale Funktion des Airflow-Schedulers verursacht werden. Bitte folgen Sie
Anleitung zur Fehlerbehebung für den Planer
um diese Probleme zu lösen.
Löschen Sie in der Airflow-Weboberfläche die vergangenen Status für den DAG.
Setzen Sie den DAG fort oder führen Sie ihn aus.
Fehlerbehebung bei der Aufgabenausführung
Airflow ist ein verteiltes System mit
vielen Entitäten wie Planer, Executor,
Worker, die über eine Aufgabenwarteschlange und den Airflow miteinander kommunizieren
und Signale senden (wie SIGTERM). Das folgende Diagramm zeigt eine Übersicht über die Verbindungen zwischen Airflow-Komponenten.
Abbildung 1. Interaktion zwischen Airflow-Komponenten (zum Vergrößern anklicken)
In einem verteilten System wie Airflow gibt es möglicherweise
oder bei der zugrunde liegenden Infrastruktur zeitweise Probleme auftreten.
kann dies dazu führen, dass Aufgaben fehlschlagen und
oder Aufgaben nicht erfolgreich abgeschlossen werden (z. B. Zombie-
oder Aufgaben, deren Ausführung hängengeblieben ist). Airflow verfügt über Mechanismen,
in solchen Situationen und nimmt automatisch wieder den normalen Betrieb wieder auf. In den folgenden Abschnitten werden häufige Probleme beschrieben, die bei der Ausführung von Aufgaben durch Airflow auftreten: Zombie-Aufgaben, Poison-Pills und SIGTERM-Signale.
Fehlerbehebung bei Zombie-Aufgaben
Airflow erkennt zwei Arten von Abweichungen zwischen einer Aufgabe und einem Prozess, der die Aufgabe ausführt:
Zombie-Aufgaben sind Aufgaben, die eigentlich ausgeführt werden sollten, aber nicht
ausgeführt wird. Dies kann passieren, wenn der Prozess der Aufgabe beendet wurde oder nicht reagiert, wenn der Airflow-Worker aufgrund einer Überlastung nicht rechtzeitig einen Aufgabenstatus meldet oder wenn die VM, auf der die Aufgabe ausgeführt wird, heruntergefahren wurde.
Airflow findet solche Aufgaben regelmäßig und schlägt sie je nach den Einstellungen der Aufgabe fehl oder versucht, sie noch einmal auszuführen.
Untote Aufgaben sind Aufgaben, die normalerweise nicht ausgeführt werden. Airflow findet solche Aufgaben regelmäßig und beendet sie.
Die häufigsten Gründe und Lösungen für Zombie-Aufgaben sind unten aufgeführt.
Airflow-Worker hat nicht genügend Arbeitsspeicher
Jeder Airflow-Worker kann bis zu [celery]worker_concurrency Aufgabeninstanzen gleichzeitig ausführen. Wenn der kumulative Arbeitsspeicherverbrauch dieser Aufgabeninstanzen
das Arbeitsspeicherlimit für einen Airflow-Worker überschreitet, wird ein zufälliger Prozess darauf ausgeführt.
um Ressourcen freizugeben.
Ereignisse mit unzureichendem Arbeitsspeicher für Airflow-Worker ermitteln
resource.type="k8s_node"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
log_id("events")
jsonPayload.message:"Killed process"
jsonPayload.message:("airflow task" OR "celeryd")
Aktualisieren Sie in Cloud Composer 2-Versionen vor 2.6.0
[celery]worker_concurrency unter Verwendung der aktuellen Formel, wenn
ist dieser Wert niedriger.
Pod-Bereinigungen sind ein normaler Teil der Ausführung von Arbeitslasten in Kubernetes.
GKE entfernt Pods, wenn der Speicherplatz aufgebraucht ist oder um Ressourcen für Arbeitslasten mit höherer Priorität freizugeben.
Wenn eine Auslagerung auf einen Mangel an Speicherplatz zurückzuführen ist, können Sie die Speichernutzung reduzieren oder temporäre Dateien entfernen, sobald sie nicht mehr benötigt werden.
Alternativ können Sie
verfügbaren Speicher erweitern oder ausführen
Arbeitslasten in einem dedizierten Pod mithilfe von KubernetesPodOperator.
Airflow-Worker wurde beendet
Airflow-Worker können extern entfernt werden. Wenn derzeit ausgeführte Aufgaben während der ordnungsgemäßen Beendigung nicht abgeschlossen werden, werden sie unterbrochen und können als Zombies erkannt werden.
Sie können Wartungsfenster angeben, um Überschneidungen mit der Ausführung kritischer Aufgaben zu minimieren.
In Cloud Composer 2-Versionen vor 2.4.5: ein beendeter Airflow
kann der Worker das SIGTERM-Signal ignorieren und mit der Ausführung von Aufgaben fortfahren:
Herunterskalieren durch Composer-Autoscaling kennenlernen
Sie können ein Upgrade auf eine neuere Cloud Composer-Version durchführen, bei der diese
wurde behoben.
Airflow-Worker war stark ausgelastet
Die Menge der CPU- und Arbeitsspeicherressourcen, die für einen Airflow-Worker verfügbar sind, wird durch die Konfiguration der Umgebung begrenzt. Wenn sich eine Auslastung den Limits nähert,
Dies würde zu Ressourcenkonflikten und unnötigen Verzögerungen während der Aufgabe führen.
Ausführung. In extremen Situationen, in denen während längerer Zeiträume nicht genügend Ressourcen zur Verfügung stehen
kann dies zu Zombie-Aufgaben führen.
Eine Datenbank wird von verschiedenen Airflow-Komponenten verwendet, um miteinander zu kommunizieren und insbesondere Heartbeats von Aufgabeninstanzen zu speichern. Ressourcenmangel auf der
führen zu längeren Abfragezeiten
und können die Ausführung von Aufgaben beeinträchtigen.
Airflow-Datenbank war vorübergehend nicht verfügbar
Es kann einige Zeit dauern, bis ein Airflow-Worker sporadische Fehler wie vorübergehende Verbindungsprobleme erkennt und ordnungsgemäß verarbeitet. Möglicherweise wird der Standardwert überschritten
Schwellenwert für die Zombie-Erkennung.
Airflow-Heartbeat-Timeouts
resource.type="cloud_composer_environment"
resource.labels.environment_name="ENVIRONMENT_NAME"
log_id("airflow-worker")
textPayload:"Heartbeat time limit exceeded"
Lösungen:
Erhöhen Sie das Zeitlimit für Zombie-Aufgaben und überschreiben Sie
Wert von [scheduler]scheduler_zombie_task_threshold
Airflow-Konfigurationsoption:
Bereich
Schlüssel
Wert
Hinweise
scheduler
scheduler_zombie_task_threshold
Neues Zeitlimit (in Sekunden)
Der Standardwert ist 300.
Fehlerbehebung bei Giftpille
Poison Pill ist ein Mechanismus, mit dem Airflow-Aufgaben beendet werden.
Airflow verwendet Giftpille in folgenden Situationen:
Wenn ein Scheduler eine Aufgabe beendet, die nicht rechtzeitig abgeschlossen wurde.
Wenn bei einer Aufgabe ein Zeitlimit überschritten wird oder sie zu lange ausgeführt wird.
Wenn in Airflow die Poison Pill verwendet wird, sehen Sie in den Logs eines Airflow-Workers, der die Aufgabe ausgeführt hat, die folgenden Logeinträge:
INFO - Subtask ... WARNING - State of this instance has been externally set
to success. Taking the poison pill.
INFO - Subtask ... INFO - Sending Signals.SIGTERM to GPID <X>
INFO - Subtask ... ERROR - Received SIGTERM. Terminating subprocesses.
Mögliche Lösungen:
Prüfen Sie den Aufgabencode auf Fehler, die dazu führen könnten, dass die Ausführung zu lange dauert.
Erhöhen Sie den Wert der
Airflow-Konfiguration für [celery_broker_transport_options]visibility-timeout
Option.
Daher wartet der Planer länger auf den Abschluss einer Aufgabe.
bevor er sie als Zombieaufgabe erachtet. Diese Option eignet sich besonders
nützlich für zeitaufwendige Aufgaben, die viele Stunden dauern. Wenn der Wert zu niedrig ist (z. B. 3 Stunden), betrachtet der Scheduler Aufgaben, die 5 oder 6 Stunden laufen, als „hängend“ (Zombie-Aufgaben).
Erhöhen Sie den Wert der Airflow-Konfigurationsoption [core]killed_task_cleanup_time.
Mit einem längeren Wert haben Airflow-Worker mehr Zeit für die Ausführung ihrer Aufgaben.
anmutig. Wenn der Wert zu niedrig ist, werden Airflow-Aufgaben möglicherweise unterbrochen
abrupt, ohne genug Zeit zu haben, um ihre Arbeit anmutig zu beenden.
Fehlerbehebung bei SIGTERM-Signalen
SIGTERM-Signale werden von Linux verwendet,
Kubernetes, Airflow-Planer und Celery zum Beenden von Prozessen, die für
oder Airflow-Workern oder Airflow-Tasks.
Es kann mehrere Gründe geben, warum SIGTERM-Signale in einer Umgebung gesendet werden:
Eine Aufgabe wurde zur Zombieaufgabe und muss gestoppt werden.
Der Scheduler hat ein Duplikat einer Aufgabe gefunden und sendet der Aufgabe Poison-Pill- und SIGTERM-Signale, um sie zu beenden.
Unter Horizontales Pod-Autoscaling hat die GKE
Die Steuerungsebene sendet SIGTERM-Signale, um nicht mehr vorhandene Pods zu entfernen
erforderlich.
Der Planer kann SIGTERM-Signale an den DagFileProcessorManager-Prozess senden.
Solche SIGTERM-Signale werden vom Scheduler verwendet, um den Lebenszyklus des DagFileProcessorManager-Prozesses zu verwalten, und können ignoriert werden.
Beispiel:
Launched DagFileProcessorManager with pid: 353002
Sending Signals.SIGTERM to group 353002. PIDs of all processes in the group: []
Sending the signal Signals.SIGTERM to group 353002
Sending the signal Signals.SIGTERM to process 353002 as process group is missing.
Race Condition zwischen dem Heartbeat-Callback und den Exit-Callbacks in local_task_job, der die Ausführung der Aufgabe überwacht. Wenn der Herzschlag
erkennt, dass eine Aufgabe als erfolgreich markiert wurde, kann jedoch nicht unterscheiden,
die Aufgabe selbst erfolgreich war oder dass Airflow angewiesen wurde, die Aufgabe
erfolgreich war. Trotzdem wird ein Task-Runner beendet, ohne zu warten.
damit es beendet wird.
Solche SIGTERM-Signale können ignoriert werden. Die Aufgabe befindet sich bereits im
und die Ausführung des gesamten DAG wird nicht
betroffen sind.
Der Logeintrag Received SIGTERM. ist der einzige Unterschied zwischen dem regulären
Exit und Beendigung der Aufgabe im Status „Erfolgreich“.
<ph type="x-smartling-placeholder"></ph>
Abbildung 2: Race Condition zwischen dem Heartbeat und dem Exit-Callback (zum Vergrößern anklicken)
Eine Airflow-Komponente nutzt mehr Ressourcen (CPU, Arbeitsspeicher) als vom
Clusterknoten.
Der GKE-Dienst führt Wartungsvorgänge aus und sendet SIGTERM-Signale an Pods, die auf einem Knoten ausgeführt werden, der gerade aktualisiert wird.
Wenn eine Aufgabeninstanz mit SIGTERM beendet wird, sehen Sie in den Logs eines Airflow-Workers, der die Aufgabe ausgeführt hat, die folgenden Logeinträge:
{local_task_job.py:211} WARNING - State of this instance has been externally
set to queued. Terminating instance. {taskinstance.py:1411} ERROR - Received
SIGTERM. Terminating subprocesses. {taskinstance.py:1703} ERROR - Task failed
with exception
Mögliche Lösungen:
Dieses Problem tritt auf, wenn eine VM, auf der die Aufgabe ausgeführt wird, nicht genügend Arbeitsspeicher hat. Dies hängt nicht mit Airflow-Konfigurationen zusammen, sondern mit der für die VM verfügbaren Arbeitsspeichermenge.
Die Erhöhung des Arbeitsspeichers hängt von der verwendeten Cloud Composer-Version ab. Beispiel:
In Cloud Composer 2 können Sie Airflow weitere CPU- und Arbeitsspeicherressourcen zuweisen
Arbeiter.
Bei Cloud Composer 1 können Sie die Umgebung mithilfe eines
Maschinentyp mit mehr Leistung.
In beiden Versionen von Cloud Composer können Sie den Wert
Die Airflow-Konfigurationsoption für Nebenläufigkeit [celery]worker_concurrency.
Diese Option bestimmt, wie viele Aufgaben gleichzeitig von einer bestimmten
Airflow-Worker
Cloud Logging-Abfragen zur Ermittlung von Gründen für Pod-Neustarts oder -Aussetzungen
In Cloud Composer-Umgebungen werden GKE-Cluster als Recheninfrastrukturebene verwendet. In diesem Abschnitt finden Sie nützliche Abfragen,
Gründe für Neustarts oder Bereinigungen von Airflow-Workern oder Airflow-Planern ermitteln.
Die unten dargestellten Abfragen könnten folgendermaßen optimiert werden:
Sie können in Cloud Logging einen für Sie interessanten Zeitraum angeben, z. B. die letzten 6 Stunden oder 3 Tage. Sie können auch einen benutzerdefinierten Zeitraum festlegen.
Geben Sie die CLUSTER_NAME
Sie können die Suche auch auf einen bestimmten Pod beschränken, indem Sie das Symbol POD_NAME
Neu gestartete Container finden
resource.type="k8s_node"
log_id("kubelet")
jsonPayload.MESSAGE:"will be restarted"
resource.labels.cluster_name="CLUSTER_NAME"
Alternative Abfrage, um die Ergebnisse auf einen bestimmten Pod zu beschränken:
resource.type="k8s_node"
log_id("kubelet")
jsonPayload.MESSAGE:"will be restarted"
resource.labels.cluster_name="CLUSTER_NAME"
"POD_NAME"
Erkennen, dass Container aufgrund eines Ereignisses des unzureichenden Arbeitsspeichers heruntergefahren wurden
resource.type="k8s_node"
log_id("events")
(jsonPayload.reason:("OOMKilling" OR "SystemOOM")
OR jsonPayload.message:("OOM encountered" OR "out of memory"))
severity=WARNING
resource.labels.cluster_name="CLUSTER_NAME"
Alternative Abfrage, um die Ergebnisse auf einen bestimmten Pod zu beschränken:
resource.type="k8s_node"
log_id("events")
(jsonPayload.reason:("OOMKilling" OR "SystemOOM")
OR jsonPayload.message:("OOM encountered" OR "out of memory"))
severity=WARNING
resource.labels.cluster_name="CLUSTER_NAME"
"POD_NAME"
Container ermitteln, die nicht mehr ausgeführt werden
Auswirkungen von Aktualisierungs- oder Upgradevorgängen auf die Ausführung von Airflow-Aufgaben
Durch Aktualisierungs- oder Upgradevorgänge werden
aktuell ausgeführte Airflow-Aufgaben unterbrochen,
es sei denn, eine Aufgabe wird im deferrable-Modus ausgeführt.
Wir empfehlen, diese Vorgänge dann durchzuführen, wenn Sie minimale Auswirkungen erwarten
und richten Sie entsprechende Wiederholungsmechanismen in der
DAGs und Aufgaben.
Fehlerbehebung bei KubernetesExecutor-Aufgaben
CeleryKubernetesExecutor ist ein Executor-Typ in Cloud Composer 3, der CeleryExecutor und KubernetesExecutor gleichzeitig verwenden kann.
Weitere Informationen zur Fehlerbehebung bei Aufgaben, die mit KubernetesExecutor ausgeführt werden, finden Sie auf der Seite CeleryKubernetesExecutor verwenden.
Allgemeine Probleme
In den folgenden Abschnitten werden Symptome und mögliche Lösungen für einige häufig auftretende DAG-Probleme beschrieben.
Airflow-Aufgabe wurde von Negsignal.SIGKILL unterbrochen
Manchmal benötigt Ihre Aufgabe mehr Arbeitsspeicher als dem Airflow-Worker zugewiesen ist.
In diesem Fall wird sie möglicherweise von Negsignal.SIGKILL unterbrochen. Das System
sendet dieses Signal, um einen weiteren
Speicherverbrauch zu vermeiden, der sich auf
anderer Airflow-Aufgaben ausgeführt werden. Im Log des Airflow-Workers sehen Sie
folgenden Logeintrag:
Negsignal.SIGKILL kann auch als Code -9 angezeigt werden.
Mögliche Lösungen:
Verringern Sie worker_concurrency der Airflow-Worker.
Erhöhen Sie im Fall von Cloud Composer 2 den Arbeitsspeicher der Airflow-Worker.
Führen Sie für Cloud Composer 1 ein Upgrade auf einen größeren Maschinentyp aus, der in
Cloud Composer-Cluster.
Optimieren Sie Ihre Aufgaben, um weniger Arbeitsspeicher zu verbrauchen.
Verwalten Sie ressourcenintensive Aufgaben in Cloud Composer mit KubernetesPodOperator oder GKEStartPodOperator für die Aufgabenisolierung und benutzerdefinierte Ressourcenzuweisung.
Aufgabe schlägt fehl, ohne Logs aufgrund von DAG-Parsing-Fehlern auszugeben
Manchmal gibt es subtile DAG-Fehler, die dazu führen, dass ein Airflow-Planer und ein DAG-Prozessor Aufgaben zur Ausführung planen und eine DAG-Datei parsen können, der Airflow-Worker jedoch keine Aufgaben aus einem solchen DAG ausführen kann, da es Programmierfehler in der Python-DAG-Datei gibt. Dies könnte
zu einer Situation führen, in der eine Airflow-Aufgabe als Failed markiert ist
und es gibt kein Protokoll
für die Ausführung.
Lösungen:
Prüfen Sie in den Airflow-Worker-Logs, ob vom Airflow-Worker keine Fehler im Zusammenhang mit fehlenden DAGs oder DAG-Parsing-Fehlern gemeldet werden.
Anzahl der Parameter für das DAG-Parsing erhöhen:
Erhöhung
dagbag-import-timeout
auf mindestens 120 Sekunden (oder länger, falls erforderlich).
Erhöhung
dag-file-processor-timeout
auf mindestens 180 Sekunden (oder mehr, falls erforderlich). Dieser Wert muss größer als dagbag-import-timeout sein.
Aufgabe schlägt aufgrund von Ressourcenmangel fehl, ohne Logs auszugeben
Symptom: Während der Ausführung einer Aufgabe ist der Unterprozess des Airflow-Workers für
für die Airflow-Taskausführung abrupt unterbrochen wird.
Der im Airflow-Worker-Log sichtbare Fehler sieht möglicherweise so aus:
Erstellen Sie in Cloud Composer 1 eine neue Umgebung mit
einen größeren Maschinentyp als die aktuelle Maschine.
Typ. Sie können Ihrer Umgebung weitere Knoten hinzufügen und [celery]worker_concurrency für Ihre Worker senken.
Aufgabe schlägt fehl, ohne Logs auszugeben, da Pod entfernt wurde
Google Kubernetes Engine-Pods unterliegen dem Kubernetes-Pod-Lebenszyklus und der Pod-Bereinigung. Aufgabenspitzen und die gemeinsame Planung von Workern sind zwei häufige Ursachen für die Pod-Bereinigung in Cloud Composer.
Eine Pod-Bereinigung kann auftreten, wenn ein bestimmter Pod Ressourcen eines Knotens relativ zu den konfigurierten Erwartungen in Sachen Ressourcenverbrauch für den Knoten übernutzt. Beispiel: Eine Bereinigung kann auftreten, wenn mehrere speicherintensive Aufgaben in einem Pod ausgeführt werden und ihre kombinierte Last dazu führt, dass der Knoten, auf dem dieser Pod ausgeführt wird, das Limit für den Arbeitsspeicherverbrauch überschreitet.
Wenn ein Airflow-Worker-Pod bereinigt wird, werden alle auf diesem Pod ausgeführten Aufgabeninstanzen unterbrochen und später von Airflow als fehlgeschlagen markiert.
Logs werden zwischengespeichert. Wenn ein Worker-Pod entfernt wird, bevor der Zwischenspeicher geleert wurde, werden keine Logs ausgegeben. Ein Aufgabenfehler ohne Logs ist ein Hinweis darauf, dass die Airflow-Worker aufgrund von zu wenig Arbeitsspeicher neu gestartet werden. In Cloud Logging sind möglicherweise einige Logs vorhanden, obwohl die Airflow-Logs nicht ausgegeben wurden.
So können die Logs angezeigt werden:
Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.
Klicken Sie in der Liste der Umgebungen auf den Namen Ihrer Umgebung.
Die Seite Umgebungsdetails wird geöffnet.
Rufen Sie den Tab Protokolle auf.
Rufen Sie die Logs einzelner Worker unter Alle Logs -> Airflow-Logs -> Worker -> (einzelner Worker) auf.
Die DAG-Ausführung ist arbeitsspeicherbegrenzt. Jede Ausführung einer Aufgabe beginnt mit zwei Airflow-Prozessen: Ausführung und Monitoring. Jeder Knoten kann bis zu 6 Aufgaben gleichzeitig ausführen (ungefähr 12 Prozesse mit Airflow-Modulen).
Je nach Art des DAG wird möglicherweise mehr Arbeitsspeicher belegt.
Symptom:
Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.
Wenn airflow-worker-Pods vorhanden sind, die Evicted anzeigen, klicken Sie auf die einzelnen bereinigten Pods und suchen Sie oben im Fenster nach folgender Meldung: The node was low on resource: memory.
Lösung:
Erstellen Sie in Cloud Composer 1 eine neue Cloud Composer-Umgebung mit
einen größeren Maschinentyp als die aktuelle Maschine.
Typ.
Prüfen Sie die Logs von airflow-worker-Pods auf mögliche Ursachen für die Bereinigung. Weitere Informationen
Informationen zum Abrufen von Logs aus einzelnen Pods finden Sie unter
Fehlerbehebung bei bereitgestellten Arbeitslasten
Achten Sie darauf, dass die Aufgaben im DAG idempotent und abrufbar sind.
Laden Sie keine unnötigen Dateien in das lokale Dateisystem von Airflow-Workern herunter.
Airflow-Worker haben eine begrenzte lokale Dateisystemkapazität. Beispiel:
Cloud Composer 2, ein Worker kann 1 GB bis 10 GB Speicherplatz haben. Wenn der Speicherplatz aufgebraucht ist, wird der Airflow-Worker-Pod von der GKE-Steuerungsebene entfernt. Dadurch schlagen alle Aufgaben fehl, die der entfernte Worker ausgeführt hat.
Beispiele für problematische Vorgänge:
Dateien oder Objekte herunterladen und lokal in einem Airflow speichern
Worker. Speichern Sie diese Objekte stattdessen direkt in einem geeigneten Dienst, z. B. in einem Cloud Storage-Bucket.
Zugriff auf große Objekte im Ordner /data über einen Airflow-Worker
Der Airflow-Worker lädt das Objekt in sein lokales Dateisystem herunter. Implementieren Sie stattdessen Ihre DAGs, damit große Dateien außerhalb des Airflow-Worker-Pods verarbeitet werden.
Zeitüberschreitung beim Laden des DAG
Symptom:
Auf der Airflow-Weboberfläche wird oben auf der Seite mit der Liste der DAGs eine rote Warnung angezeigt.
Feld zeigt Broken DAG: [/path/to/dagfile] Timeout.
In Cloud Monitoring: Die airflow-scheduler-Logs enthalten Einträge
ähnlich wie:
ERROR - Process timed out
ERROR - Failed to import: /path/to/dagfile
AirflowTaskTimeout: Timeout
Lösung:
Überschreiben Sie die Airflow-Konfiguration dag_file_processor_timeout und legen Sie mehr Zeit für das DAG-Parsen fest:
Bereich
Schlüssel
Wert
core
dag_file_processor_timeout
Neuer Wert für die Zeitüberschreitung
DAG-Ausführung endet nicht innerhalb der erwarteten Zeit
Symptom:
Manchmal endet eine DAG-Ausführung nicht, weil Airflow-Aufgaben hängen bleiben und DAG ausgeführt werden
länger dauert als erwartet. Unter normalen Bedingungen bleiben Airflow-Aufgaben nicht unbegrenzt im Status „In der Warteschlange“ oder „Ausgeführt“, da Airflow Zeitüberschreitungen und Bereinigungsverfahren hat, die diese Situation vermeiden helfen.
Lösung:
Verwenden Sie die Methode
dagrun_timeout
-Parameter für die DAGs. Beispiel:
dagrun_timeout=timedelta(minutes=120). Daher muss jede DAG-Ausführung
die innerhalb des Zeitlimits für die DAG-Ausführung abgeschlossen wurden und nicht abgeschlossene Aufgaben
als Failed oder Upstream Failed. Weitere Informationen zu Airflow-Aufgabenstatus finden Sie in der Apache Airflow-Dokumentation.
Mit dem Parameter task execution timeout (Zeitüberschreitung für die Aufgabenausführung) können Sie ein Standardzeitlimit für Aufgaben definieren, die auf Apache Airflow-Operatoren basieren.
DAG-Ausführungen nicht ausgeführt
Symptom:
Wenn ein Planungsdatum für einen DAG dynamisch festgelegt wird, kann dies zu verschiedenen
unerwartete Nebenwirkungen. Beispiel:
Eine DAG-Ausführung liegt immer in der Zukunft und die DAG wird nie ausgeführt.
Frühere DAG-Ausführungen werden als ausgeführt und erfolgreich markiert, obwohl sie
ausgeführt haben.
Legen Sie eine statische start_date für DAGs fest. Optional können Sie catchup=False verwenden
um die Ausführung des DAG für vergangene Zeiträume zu deaktivieren.
Verwenden Sie datetime.now() oder days_ago(<number of days>) nur, wenn Sie sich der Nebenwirkungen dieses Ansatzes bewusst sind.
Erhöhter Netzwerktraffic zur und von der Airflow-Datenbank
Die Menge des Netzwerk-Traffics zwischen dem GKE-Cluster Ihrer Umgebung und der Airflow-Datenbank hängt von der Anzahl der DAGs, der Anzahl der Aufgaben in DAGs und der Art des Zugriffs der DAGs auf Daten in der Airflow-Datenbank ab. Folgende Faktoren können sich auf die Netzwerknutzung auswirken:
Abfragen an die Airflow-Datenbank Wenn Ihre DAGs viele Abfragen ausführen, generieren sie große Mengen an Traffic. Beispiele: Status prüfen, bevor andere Aufgaben ausgeführt werden, XCom-Tabelle abfragen und Inhalt der Airflow-Datenbank auslesen.
Große Anzahl von Aufgaben Je mehr Aufgaben geplant sind, desto mehr Netzwerktraffic wird generiert. Dieser Aspekt gilt sowohl für die Gesamtzahl der Aufgaben in Ihren DAGs als auch für die Planungshäufigkeit. Wenn der Airflow-Planer DAG-Ausführungen plant, sendet er Abfragen an die Airflow-Datenbank und generiert Traffic.
Die Airflow-Weboberfläche generiert Netzwerkverkehr, da sie Abfragen an die Airflow-Datenbank sendet. Die intensive Verwendung von Seiten mit Grafiken, Aufgaben und Diagrammen kann große Mengen an Netzwerkverkehr generieren.
DAG führt zum Absturz des Airflow-Webservers oder verursacht einen 502 gateway timeout-Fehler
Webserverausfälle können aus verschiedenen Gründen auftreten. Prüfen Sie die airflow-webserver-Logs in Cloud Logging, um die Ursache des Fehlers 502 gateway timeout zu ermitteln.
Komplexe Berechnungen
Dieser Abschnitt gilt nur für Cloud Composer 1.
Führen Sie keine komplexen Berechnungen während der DAG-Analyse durch.
Im Gegensatz zu den Worker- und Planerknoten, deren Maschinentypen
größere CPU- und Arbeitsspeicherkapazität haben, verwendet der Webserver einen festen Maschinentyp,
was zu Fehlern beim DAG-Parsing führen kann, wenn die
sehr schwer.
Beachten Sie, dass der Webserver 2 vCPUs und 2 GB Arbeitsspeicher hat.
Der Standardwert für core-dagbag_import_timeout beträgt 30 Sekunden. Dieser Zeitlimitwert ist die Obergrenze für den Zeitraum, den Airflow für das Laden eines Python-Moduls in den Ordner dags/ benötigt.
Falsche Berechtigungen
Dieser Abschnitt gilt nur für Cloud Composer 1.
Der Webserver wird nicht unter demselben Dienstkonto ausgeführt wie die Worker und der Planer. Worker und der Planer können somit gegebenenfalls auf vom Nutzer verwaltete Ressourcen zugreifen, auf die der Webserver keinen Zugriff hat.
Vermeiden Sie den Zugriff auf nicht öffentliche Ressourcen während der DAG-Analyse. Sollte dies nicht möglich sein, müssen Sie dem Dienstkonto des Webservers Berechtigungen erteilen. Der Name des Dienstkontos wird von der Webserverdomain abgeleitet. Wenn beispielsweise die Domain
ist example-tp.appspot.com, das Dienstkonto ist
example-tp@appspot.gserviceaccount.com.
DAG-Fehler
Dieser Abschnitt gilt nur für Cloud Composer 1.
Der Webserver wird in App Engine ausgeführt und ist vom GKE-Cluster Ihrer Umgebung getrennt. Der Webserver parst die DAG-Definitionsdateien. Wenn dabei Fehler im DAG auftreten, kann es zum 502 gateway timeout kommen. Airflow funktioniert normal ohne einen funktionierenden Webserver, wenn der
Der problematische DAG beeinträchtigt keine in GKE ausgeführten Prozesse.
In einem solchen Fall können Sie mit gcloud composer environments run Details aus Ihrer Umgebung abrufen, und so das Problem umgehen, wenn der Webserver nicht mehr verfügbar ist.
In anderen Fällen können Sie die DAG-Analyse in GKE ausführen und nach DAGs suchen, die schwerwiegende Python-Ausnahmen oder eine Zeitüberschreitung auslösen (Standardeinstellung: 30 Sekunden).
Stellen Sie zur Fehlerbehebung eine Verbindung zu einer Remote-Shell in einem Airflow-Worker-Container her und testen Sie, ob Syntaxfehler vorliegen. Weitere Informationen finden Sie unter DAGs testen.
Umgang mit einer großen Anzahl von DAGs und Plug-ins in den Ordnern „DAGs“ und „Plug-ins“
Der Inhalt der Ordner „/dags“ und „/plugins“ wird synchronisiert von
lokalen Dateisysteme von Airflow-Workern und
Planer.
Je mehr Daten in diesen Ordnern gespeichert sind, desto länger dauert es,
Synchronisierung. So gehen Sie in solchen Fällen vor:
Begrenzen Sie die Anzahl der Dateien in den Ordnern „/dags“ und „/plugins“. Nur die
mindestens erforderliche Dateien.
Erhöhen Sie nach Möglichkeit den Speicherplatz für Airflow-Planer und
Arbeiter.
Erhöhen Sie nach Möglichkeit CPU und Arbeitsspeicher von Airflow-Planern und -Workern, damit
dass die Synchronisierung schneller durchgeführt wird.
Bei einer sehr großen Anzahl von DAGs sollten Sie die DAGs in Batches unterteilen, in ZIP-Archive komprimieren und diese Archive im Ordner /dags bereitstellen.
Dieser Ansatz beschleunigt den Synchronisierungsprozess von DAGs. Airflow-Komponenten entpacken ZIP-Archive, bevor DAGs verarbeitet werden.
Auch das Generieren von DAGs in einer programmatischen
Die Anzahl der im Ordner /dags gespeicherten DAG-Dateien.
Lesen Sie den Abschnitt zu programmatischen DAGs, um zu vermeiden,
Probleme bei der Planung und Ausführung von programmatisch generierten DAGs.
Programmatisch generierte DAGs nicht gleichzeitig planen
Das programmatische Generieren von DAG-Objekten aus einer DAG-Datei ist eine effiziente Methode
zum Erstellen vieler ähnlicher DAGs,
die sich nur geringfügig unterscheiden.
Es ist wichtig, nicht alle diese DAGs sofort zur Ausführung zu planen. Es
besteht eine hohe Wahrscheinlichkeit, dass die Airflow-Worker nicht genügend CPU und Arbeitsspeicher haben
Ressourcen zur Ausführung aller zur gleichen Zeit geplanten Aufgaben.
So vermeiden Sie Probleme bei der Planung programmatischer DAGs:
Erhöhen Sie die Nebenläufigkeit der Worker und skalieren Sie Ihre Umgebung, damit sie
um mehr Aufgaben gleichzeitig auszuführen.
DAGs so generieren, dass die Zeitpläne gleichmäßig über einen bestimmten Zeitraum verteilt werden,
müssen Sie nicht Hunderte von Aufgaben gleichzeitig planen, damit die Airflow-Worker
alle geplanten Aufgaben ausführen können.
Die Lost connection to Postgres server during query-Ausnahme wird während der Ausführung der Aufgabe oder unmittelbar danach ausgelöst.
Lost connection to Postgres server during query-Ausnahmen treten häufig auf, wenn folgende Bedingungen erfüllt sind:
Ihr DAG verwendet PythonOperator oder einen benutzerdefinierten Operator.
Ihr DAG stellt Abfragen an die Airflow-Datenbank.
Wenn mehrere Abfragen von einer aufrufbaren Funktion gesendet werden, verweisen Tracebacks möglicherweise fälschlicherweise auf die Zeile self.refresh_from_db(lock_for_update=True) im Airflow-Code. Sie ist die erste Datenbankabfrage nach der Aufgabenausführung. Die tatsächliche Ursache der Ausnahme tritt davor auf, wenn eine SQLAlchemy-Sitzung nicht ordnungsgemäß geschlossen wird.
SQLAlchemy-Sitzungen sind auf einen Thread beschränkt und werden in einer aufrufbaren Funktionssitzung erstellt, die später innerhalb des Airflow-Codes fortgesetzt werden kann. Wenn es innerhalb einer Sitzung zu erheblichen Verzögerungen zwischen Abfragen kommt, wurde die Verbindung möglicherweise bereits vom Postgres-Server geschlossen. Das Zeitlimit für die Verbindung in Cloud Composer-Umgebungen ist auf etwa zehn Minuten festgelegt.
Lösung:
Verwenden Sie den Decorator airflow.utils.db.provide_session. Dieser Decorator stellt eine gültige Sitzung für die Airflow-Datenbank im session-Parameter bereit und schließt die Sitzung am Ende der Funktion ordnungsgemäß.
Verwenden Sie keine einzelne Funktion mit langer Ausführungszeit. Verschieben Sie stattdessen alle Datenbankabfragen in separate Funktionen, sodass es mehrere Funktionen mit dem Decorator airflow.utils.db.provide_session gibt. In diesem Fall werden Sitzungen nach dem Abrufen von Abfrageergebnissen automatisch geschlossen.
Ausführungszeit von DAGs, Aufgaben und parallelen Ausführungen desselben DAG steuern
Wenn Sie steuern möchten, wie lange eine einzelne DAG-Ausführung für einen bestimmten DAG dauert, können Sie dazu den DAG-Parameter dagrun_timeout verwenden. Wenn Sie beispielsweise davon ausgehen, dass eine einzelne DAG-Ausführung (unabhängig davon, ob die Ausführung erfolgreich oder fehlgeschlagen ist) nicht länger als eine Stunde dauern darf, legen Sie diesen Parameter auf 3.600 Sekunden fest.
Sie können auch festlegen, wie lange eine einzelne Airflow-Aufgabe dauern soll. Dazu können Sie execution_timeout verwenden.
Wenn Sie steuern möchten, wie viele aktive DAG-Ausführungen
bestimmten DAG verwenden, können Sie den [core]max-active-runs-per-dagAirflow-Konfigurationsoption dazu.
Wenn nur eine einzige Instanz eines DAG gleichzeitig ausgeführt werden soll, legen Sie
max-active-runs-per-dag-Parameter auf 1.
Probleme bei der Synchronisierung von DAGs und Plug-ins mit Planern, Workern und Webservern
Cloud Composer synchronisiert den Inhalt der Ordner /dags und /plugins
für Planer und Worker. Bestimmte Objekte in den Ordnern /dags und /plugins können diese Synchronisierung verhindern oder zumindest verlangsamen.
Der Ordner „/dags“ wird mit Planern und Workern synchronisiert. Dieser Ordner ist nicht synchronisiert
auf Webserver in Cloud Composer 2 oder wenn Sie DAG Serialization in Cloud Composer 1 aktivieren.
Der Ordner /plugins wird mit Planern, Workern und Webservern synchronisiert.
Die folgenden Probleme können auftreten:
Sie haben mit GZIP komprimierte Dateien hochgeladen, die
Komprimierungstranscodierung in /dags und /plugins
Ordner. Dies geschieht normalerweise, wenn Sie das Flag --gzip-local-all in einer
Befehl gcloud storage cp, um Daten in den Bucket hochzuladen.
Lösung: Löschen Sie das Objekt, das die Komprimierungscodierung verwendet hat, und laden Sie die Datei noch einmal hoch.
in den Bucket verschieben.
Eines der Objekte hat den Namen „.“, das heißt, ein Objekt wird nicht mit
Planungs- und Worker-Instanzen
und beendet möglicherweise die Synchronisierung.
Lösung: Benennen Sie das problematische Objekt um.
Ein Ordner und eine DAG-Python-Datei haben denselben Namen, z. B. a.py.
In diesem Fall wird die DAG-Datei nicht richtig mit den Airflow-Komponenten synchronisiert.
Lösung: Entfernen Sie den Ordner, der denselben Namen wie eine DAG-Python-Datei hat.
Eines der Objekte in den Ordnern /dags oder /plugins enthält das Symbol /
am Ende des Objektnamens hinzu. Solche Objekte können den Synchronisierungsprozess in die Irre führen.
da das Symbol / bedeutet, dass ein Objekt ein Ordner und keine Datei ist.
Lösung: Entfernen Sie das Symbol / aus dem Namen des problematischen Objekts.
Speichern Sie keine unnötigen Dateien in den Ordnern /dags und /plugins.
Manchmal werden von Ihnen implementierte DAGs und Plug-ins
z. B. Dateien, in denen Tests für diese Komponenten gespeichert sind. Diese Dateien werden mit Workern und Planern synchronisiert und beeinflussen die Zeit, die zum Kopieren dieser Dateien auf Planer, Worker und Webserver benötigt wird.
Lösung: Speichern Sie keine zusätzlichen und nicht erforderlichen Dateien in den Ordnern /dags und /plugins.
Done [Errno 21] Is a directory: '/home/airflow/gcs/dags/...'-Fehler wird von Planern und Workern generiert
Dieses Problem tritt auf, weil Objekte
überlappenden Namespace in Cloud Storage
Planer und Worker verwenden
herkömmliche Dateisysteme. So ist es beispielsweise möglich, dem Bucket einer Umgebung sowohl einen Ordner als auch ein Objekt mit demselben Namen hinzuzufügen. Wenn der Bucket mit den Planern und Workern der Umgebung synchronisiert ist,
wird dieser Fehler generiert, was
zu Aufgabenfehlern führen kann.
Um dieses Problem zu beheben, achten Sie darauf, dass sich im
im Bucket der Umgebung. Wenn sich beispielsweise sowohl /dags/misc (eine Datei) als auch /dags/misc/example_file.txt (eine andere Datei) in einem Bucket befinden, wird vom Scheduler ein Fehler generiert.
Vorübergehende Unterbrechungen bei der Verbindung zur Airflow-Metadaten-Datenbank
Cloud Composer wird auf einer verteilten Cloud-Infrastruktur ausgeführt.
Von Zeit zu Zeit können vorübergehende Probleme auftreten,
die Ausführung Ihrer Airflow-Aufgaben unterbrechen.
In solchen Fällen werden möglicherweise die folgenden Fehlermeldungen im Protokolle:
"Can't connect to Postgres server on 'airflow-sqlproxy-service.default.svc.cluster.local' (111)"
oder
"Can't connect to Postgres server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"
Solche vorübergehenden Probleme können auch durch Wartungsvorgänge verursacht werden.
die für Ihre Cloud Composer-Umgebungen durchgeführt wurden.
Normalerweise treten solche Fehler nur sporadisch auf. Wenn Ihre Airflow-Aufgaben idempotent sind und Sie Wiederholungen konfiguriert haben, sollten Sie nicht davon betroffen sein. Sie können auch Wartungsfenster definieren.
Ein weiterer Grund für solche Fehler kann der Mangel an Ressourcen im Cluster Ihrer Umgebung sein. In solchen Fällen können Sie Ihre Umgebung wie in den Anleitungen Umgebungen skalieren oder Umgebung optimieren beschrieben skalieren oder optimieren.
Eine DAG-Ausführung ist als erfolgreich markiert, enthält aber keine ausgeführten Aufgaben
Wenn das execution_date eines DAG-Laufs vor dem start_date des DAG liegt, sehen Sie möglicherweise DAG-Ausführungen, die keine Aufgabenausführungen haben, aber trotzdem als erfolgreich gekennzeichnet sind.
<ph type="x-smartling-placeholder"></ph>
Abbildung 3: Eine erfolgreiche DAG-Ausführung ohne ausgeführte Aufgaben (zum Vergrößern klicken)
Ursache
Diese Situation kann in einem der folgenden Fälle auftreten:
Die Abweichung ist auf die Zeitzonendifferenz zwischen execution_date und start_date des DAG zurückzuführen. Das kann zum Beispiel passieren,
mit pendulum.parse(...), um start_date festzulegen.
Der start_date des DAG ist auf einen dynamischen Wert festgelegt, z. B.
airflow.utils.dates.days_ago(1)
Lösung
Achten Sie darauf, dass für execution_date und start_date dieselbe Zeitzone verwendet wird.
Geben Sie ein statisches start_date an und kombinieren Sie es mit catchup=False, um zu verhindern, dass DAGs mit vergangenen Startdaten ausgeführt werden.
Ein DAG ist in der Airflow-UI oder der DAG-UI nicht sichtbar und wird vom Planer nicht geplant
Der DAG-Prozessor parst jeden DAG, bevor er vom Planer geplant werden kann
und bevor ein DAG in
der Airflow-UI oder der DAG-UI
Mit den folgenden Airflow-Konfigurationsoptionen werden Zeitüberschreitungen für das Parsen von DAGs definiert:
Wenn ein DAG in der Airflow- oder DAG-UI nicht sichtbar ist:
Prüfen Sie in den Logs des DAG-Prozessors, ob der DAG-Prozessor Ihren DAG korrekt verarbeiten kann. Bei Problemen werden möglicherweise die folgenden Logeinträge angezeigt
in den DAG-Prozessor- oder Planerlogs:
[2020-12-03 03:06:45,672] {dag_processing.py:1334} ERROR - Processor for
/usr/local/airflow/dags/example_dag.py with PID 21903 started at
2020-12-03T03:05:55.442709+00:00 has timed out, killing it.
Prüfen Sie die Planerlogs, um festzustellen, ob sie ordnungsgemäß funktionieren. Bei Problemen werden in den Scheduler-Logs möglicherweise die folgenden Logeinträge angezeigt:
DagFileProcessorManager (PID=732) last sent a heartbeat 240.09 seconds ago! Restarting it
Process timed out, PID: 68496
Lösungen:
Beheben Sie alle DAG-Parsing-Fehler. Der DAG-Prozessor parst mehrere DAGs. In seltenen Fällen können Parsingfehler bei einem DAG sich negativ auf das Parsen anderer DAGs auswirken.
Wenn das Parsen Ihres DAG länger als die in [core]dagrun_import_timeout angegebene Anzahl von Sekunden dauert, erhöhen Sie dieses Zeitlimit.
Wenn das Parsen aller DAGs länger als die in [core]dag_file_processor_timeout angegebene Anzahl von Sekunden dauert, erhöhen Sie diese Zeitüberschreitung.
Wenn das Parsen Ihres DAGs lange dauert, kann das auch daran liegen, dass er nicht optimal implementiert ist. Das ist beispielsweise der Fall, wenn viele Umgebungsvariablen gelesen oder externe Dienste oder die Airflow-Datenbank aufgerufen werden. Vermeiden Sie es nach Möglichkeit, solche Vorgänge
globalen Abschnitten von DAGs.
Erhöhen Sie die CPU- und Arbeitsspeicherressourcen für den Scheduler, damit er schneller arbeiten kann.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2024-10-24 (UTC)."],[],[]]
