Fehlerbehebung bei DAGs

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Diese Seite enthält Schritte zur Fehlerbehebung und Informationen zu häufigen Workflow-Problemen.

Viele Probleme bei der DAG-Ausführung werden durch eine nicht optimale Umgebungsleistung verursacht. Sie können Ihre Cloud Composer 2-Umgebung optimieren, indem Sie der Anleitung Optimize Leitfaden zu Umgebungsleistung und -kosten.

Einige Probleme bei der DAG-Ausführung können durch eine fehlerhafte oder nicht optimale Funktion des Airflow-Schedulers verursacht werden. Folgen Sie der Anleitung zur Fehlerbehebung für den Zeitplaner, um diese Probleme zu beheben.

Fehlerbehebung beim Workflow

So beginnen Sie mit der Fehlerbehebung:

1. Prüfen Sie die Airflow-Logs.

   Sie können die Logging-Ebene von Airflow erhöhen, indem Sie die folgende Airflow-Konfigurationsoption überschreiben.

   Airflow 2

   Bereich	Schlüssel	Wert
   logging	logging_level	Der Standardwert ist INFO. Legen Sie DEBUG fest, um detailliertere Protokollmeldungen zu erhalten.

   Airflow 1

   Bereich	Schlüssel	Wert
   core	logging_level	Der Standardwert ist INFO. Legen Sie DEBUG fest, um detailliertere Protokollmeldungen zu erhalten.

2. Prüfen Sie das Monitoring-Dashboard.

3. Cloud Monitoring ansehen

4. Suchen Sie in der Google Cloud Console nach Fehlern auf den Seiten für die Komponenten Ihrer Umgebung.

5. Auf der Airflow-Weboberfläche in der Graph View des DAG fehlgeschlagenen Aufgabeninstanzen.

   Bereich	Schlüssel	Wert
   webserver	dag_orientation	LR, TB, RL oder BT

Fehlerbehebung bei Operatorfehlern

So beheben Sie Operatorfehler:

1. Suchen Sie nach aufgabenspezifischen Fehlern.
2. Prüfen Sie die Airflow-Logs.
3. Machen Sie sich mit Cloud Monitoring vertraut.
4. Prüfen Sie dieoperatorspezifischen Logs.
5. Beheben Sie die Fehler.
6. Laden Sie den DAG in den Ordner dags/ hoch.
7. In der Airflow-Weboberfläche löschen Sie die vergangenen Status für den DAG.
8. 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 Verbindungen zwischen Airflow-Komponenten.

In einem verteilten System wie Airflow kann es zu Netzwerkverbindungsproblemen oder zu zeitweiligen Problemen mit der zugrunde liegenden Infrastruktur kommen. Dies kann dazu führen, dass Aufgaben fehlschlagen und neu geplant werden oder nicht erfolgreich abgeschlossen werden (z. B. Zombie-Aufgaben oder Aufgaben, die bei der Ausführung hängen geblieben sind). Airflow bietet Mechanismen, um mit solchen Situationen umzugehen und den normalen Betrieb automatisch wieder aufzunehmen. Folge ich werden häufige Probleme bei der Ausführung von Aufgaben mit Airflow erläutert: Zombie-Aufgaben, Giftpillen und SIGTERM-Signale.

Fehlerbehebung bei Zombie-Aufgaben

Airflow erkennt zwei Arten von Diskrepanzen zwischen einer Aufgabe und einem Prozess, der ausgeführt wird die Aufgabe:

• 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 antworten, wenn der Airflow-Worker den Aufgabenstatus nicht rechtzeitig gemeldet hat weil sie überlastet ist oder die VM, auf der die Aufgabe ausgeführt wird, heruntergefahren wurde. Airflow findet solche Aufgaben regelmäßig und schlägt entweder fehl oder wiederholt die Aufgabe. je nach den Einstellungen der Aufgabe.

  Entdecke die Zombie-Aufgaben

  resource.type="cloud_composer_environment"
  resource.labels.environment_name="ENVIRONMENT_NAME"
  log_id("airflow-scheduler")
  textPayload:"Detected zombie job"

• Untote Aufgaben sind Aufgaben, die normalerweise nicht ausgeführt werden. Airflow findet solche Aufgaben regelmäßig und beendet sie.

Im Folgenden finden Sie die häufigsten Gründe und Lösungen für Zombie-Aufgaben.

Airflow-Worker hat nicht genügend Arbeitsspeicher

Jeder Airflow-Worker könnte bis zu [celery]worker_concurrency Aufgabeninstanzen ausführen gleichzeitig. 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.

resource.type="k8s_node"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
log_id("events")
jsonPayload.message:"Killed process"
jsonPayload.message:("airflow task" OR "celeryd")

Lösungen:

• Aufgaben so optimieren, dass weniger Arbeitsspeicher benötigt wird, z. B. durch Vermeidung von Code auf oberster Ebene

• In Cloud Composer 2-Versionen vor 2.6.0 aktualisieren Sie [celery]worker_concurrency mit der aktuellen Formel, wenn dieser Wert niedriger ist.

• Verwenden Sie in Cloud Composer 2 Airflow-Konfigurationsüberschreibungen. um [celery]worker_concurrency und Speicher für Airflow-Worker erhöhen

• In Cloud Composer 1: Upgrade auf einen größeren Maschinentyp

• Verringern Sie [celery]worker_concurrency.

Airflow-Worker wurde entfernt

Pod-Bereinigungen sind ein normaler Teil der Ausführung von Arbeitslasten in Kubernetes. GKE entfernt Pods, wenn kein Speicherplatz mehr vorhanden ist oder sie freigegeben werden. und Ressourcen für Arbeitslasten mit höherer Priorität bereitstellen.

resource.type="k8s_pod"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
resource.labels.pod_name:"airflow-worker"
log_id("events")
jsonPayload.reason="Evicted"

Lösungen:

• Wenn eine Bereinigung durch zu wenig Speicherplatz verursacht wird, können Sie den Speicherplatz reduzieren verwenden 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 nach einer ordnungsgemäßen Kündigung beendet werden, werden sie unterbrochen und als Zombies erkannt werden.

resource.type="k8s_cluster"
resource.labels.cluster_name="GKE_CLUSTER_NAME"
protoPayload.methodName:"pods.delete"
protoPayload.response.metadata.name:"airflow-worker"

Mögliche Szenarien und Lösungen:

• Airflow-Worker werden bei Umgebungsänderungen neu gestartet, z. B. Upgrades oder Paketinstallation:

  Änderungen an Composer-Umgebungen erkennen

  resource.type="cloud_composer_environment"
  resource.labels.environment_name="ENVIRONMENT_NAME"
  log_id("cloudaudit.googleapis.com%2Factivity")

  Sie können solche Vorgänge ausführen, wenn keine kritischen Aufgaben ausgeführt werden, oder Wiederholungsversuche von Aufgaben.

• Während der Wartungsarbeiten sind verschiedene Komponenten möglicherweise vorübergehend nicht verfügbar:

  GKE-Wartungsvorgänge entdecken

  resource.type="gke_nodepool"
  resource.labels.cluster_name="GKE_CLUSTER_NAME"
  protoPayload.metadata.operationType="UPGRADE_NODES"

  Sie können Wartungsfenster angeben, um sich mit der Ausführung der kritischen Aufgaben überschneidet.

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

  Herunterskalierung durch Composer-Autoscaling

  resource.type="cloud_composer_environment"
  resource.labels.environment_name="ENVIRONMENT_NAME"
  log_id("airflow-worker-set")
  textPayload:"Workers deleted"

  Sie können ein Upgrade auf eine neuere Cloud Composer-Version durchführen, in der dieses Problem behoben ist.

Airflow-Worker war stark ausgelastet

Die für einen Airflow-Worker verfügbare Menge an CPU- und Arbeitsspeicherressourcen ist begrenzt der Umgebungskonfiguration. Wenn die Auslastung näher an den Grenzwerten liegt, kommt es zu Ressourcenkonflikten und unnötigen Verzögerungen bei der Ausführung der Aufgabe. In extremen Fällen, wenn über einen längeren Zeitraum hinweg Ressourcen fehlen, kann dies zu Zombie-Aufgaben führen.

Lösungen:

• CPU- und Arbeitsspeichernutzung der Worker überwachen und bei Bedarf anpassen über 80 % liegt.

Airflow-Datenbank war stark ausgelastet

Eine Datenbank wird von verschiedenen Airflow-Komponenten verwendet, um miteinander zu kommunizieren. um Heartbeats von Aufgabeninstanzen zu speichern. Ein Ressourcenmangel in der Datenbank führt zu längeren Abfragezeiten und kann sich auf die Ausführung einer Aufgabe auswirken.

Lösungen:

• CPU- und Arbeitsspeichernutzung der Datenbank überwachen

Airflow-Datenbank 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.

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 den Wert der Airflow-Konfigurationsoption [scheduler]scheduler_zombie_task_threshold:

  Bereich	Schlüssel	Wert	Hinweise
  scheduler	scheduler_zombie_task_threshold	Neu Zeitlimit (in Sekunden)	Standardeinstellung Wert ist 300

Fehlerbehebung bei Poison Pill

Poison Pill ist ein Mechanismus, mit dem Airflow-Aufgaben beendet werden.

Airflow verwendet Giftpille in folgenden Situationen:

• Wenn ein Planer eine Aufgabe beendet, die nicht rechtzeitig abgeschlossen wurde.
• Wenn eine Aufgabe das Zeitlimit überschreitet oder zu lange ausgeführt wird.

Wenn Airflow Poison Pill verwendet, können Sie in den Logs eines Airflow-Workers, der die Aufgabe ausgeführt hat, die folgenden Logeinträge sehen:

  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.
• (Cloud Composer 2) Sie können die CPU und den Arbeitsspeicher für Airflow-Worker erhöhen, damit Aufgaben schneller ausgeführt werden.

• Erhöhen Sie den Wert der Airflow-Konfiguration für [celery_broker_transport_options]visibility-timeout Option.

  Daher wartet der Scheduler länger, bis eine Aufgabe abgeschlossen ist, bevor er sie als Zombie-Aufgabe betrachtet. 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).

• Wert von [core]killed_task_cleanup_time-Airflow erhöhen Konfigurationsoption.

  Ein längerer Wert gibt Airflow-Workern mehr Zeit, ihre Aufgaben ordnungsgemäß abzuschließen. 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 ist zu einer Zombie-Aufgabe geworden und muss beendet 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“.

  

• Eine Airflow-Komponente nutzt mehr Ressourcen (CPU, Arbeitsspeicher) als vom Clusterknoten.

• Der GKE-Dienst führt Wartungsvorgänge sendet SIGTERM-Signale an Pods, die auf einem Knoten ausgeführt werden, der demnächst 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 einer VM, auf der die Aufgabe ausgeführt wird, nicht genügend Arbeitsspeicher zur Verfügung steht. Dies ist nicht die auf die Airflow-Konfigurationen, sondern auf den verfügbaren Arbeitsspeicher VM:

Die Erhöhung des Arbeitsspeichers hängt von der verwendeten Cloud Composer-Version ab. Beispiel:

• In Cloud Composer 2 können Sie Airflow-Workern mehr CPU- und Arbeitsspeicherressourcen zuweisen.

• 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

Weitere Informationen zum Optimieren Ihrer Cloud Composer 2-Umgebung finden Sie unter Umgebungsleistung und ‑kosten optimieren.

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 aufgeführten Abfragen könnten so optimiert werden:

• können Sie einen für Sie interessanten Zeitplan in Cloud Logging festlegen. 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 den Parameter POD_NAME

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"will be restarted"
    resource.labels.cluster_name="CLUSTER_NAME"
  

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"will be restarted"
    resource.labels.cluster_name="CLUSTER_NAME"
    "POD_NAME"
  

    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"
    

    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"
    

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"ContainerDied"
    severity=DEFAULT
    resource.labels.cluster_name="CLUSTER_NAME"
    

    resource.type="k8s_node"
    log_id("kubelet")
    jsonPayload.MESSAGE:"ContainerDied"
    severity=DEFAULT
    resource.labels.cluster_name="CLUSTER_NAME"
    "POD_NAME"
    

Auswirkungen von Aktualisierungs- oder Upgradevorgängen auf die Ausführung von Airflow-Aufgaben

Aktualisierungs- oder Upgradevorgänge unterbrechen derzeit ausgeführte Airflow-Aufgaben, es sei denn, eine Aufgabe wird im Modus mit verzögerbarer Ausführung ausgeführt.

Wir empfehlen, diese Vorgänge auszuführen, wenn Sie mit minimalen Auswirkungen auf die Ausführung von Airflow-Aufgaben rechnen, und entsprechende Wiederholungsmechanismen in Ihren DAGs und Aufgaben einzurichten.

Fehlerbehebung bei KubernetesExecutor-Aufgaben

CeleryKubernetesExecutor ist ein Executor-Typ in Cloud Composer 3 die CeleryExecutor und KubernetesExecutor gleichzeitig verwenden können, .

Weitere Informationen finden Sie auf der Seite CeleryKubernetesExecutor verwenden. Informationen zur Fehlerbehebung bei Aufgaben, die mit KubernetesExecutor ausgeführt werden.

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:

{local_task_job.py:102} INFO - Task exited with return code Negsignal.SIGKILL

Negsignal.SIGKILL kann auch als Code -9 angezeigt werden.

Mögliche Lösungen:

• Niedrigere worker_concurrency von Airflow-Workern.

• Erhöhen Sie bei 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 Aufgabenisolierung und benutzerdefinierte Ressourcenzuweisung.

Aufgabe schlägt aufgrund von Fehlern beim DAG-Parsen fehl, ohne Logs auszugeben

Manchmal können subtile DAG-Fehler auftreten, Ein Airflow-Planer und DAG-Prozessor können Aufgaben für die Ausführung planen und eine DAG-Datei zu parsen, aber der Airflow-Worker kann Aufgaben nicht ausführen aus einem solchen DAG, da die Python-DAG-Datei Programmierfehler enthält. 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, dass keine Fehler auftreten, Airflow-Worker im Zusammenhang mit fehlenden DAG- oder DAG-Parsing-Fehlern.

• Anzahl der Parameter für das DAG-Parsing erhöhen:

  • Erhöhen Sie dagbag-import-timeout auf mindestens 120 Sekunden (bei Bedarf auch mehr).

  • Erhöhung dag-file-processor-timeout auf mindestens 180 Sekunden (oder mehr, falls erforderlich). Dieser Wert muss größer als dagbag-import-timeout sein.

• Siehe auch DAG-Prozessorlogs prüfen

Aufgabe schlägt fehl, ohne dass Logs aufgrund von Ressourcenmangel ausgegeben werden

Symptom: Während der Ausführung einer Aufgabe wird der für die Ausführung der Airflow-Aufgabe zuständige Unterprozess des Airflow-Workers abrupt unterbrochen. Der im Airflow-Worker-Log sichtbare Fehler sieht möglicherweise so aus:

...
File "/opt/python3.8/lib/python3.8/site-packages/celery/app/trace.py", line 412, in trace_task    R = retval = fun(*args, **kwargs)  File "/opt/python3.8/lib/python3.8/site-packages/celery/app/trace.py", line 704, in __protected_call__    return self.run(*args, **kwargs)  File "/opt/python3.8/lib/python3.8/site-packages/airflow/executors/celery_executor.py", line 88, in execute_command    _execute_in_fork(command_to_exec)  File "/opt/python3.8/lib/python3.8/site-packages/airflow/executors/celery_executor.py", line 99, in _execute_in_fork
raise AirflowException('Celery command failed on host: ' + get_hostname())airflow.exceptions.AirflowException: Celery command failed on host: airflow-worker-9qg9x
...

Lösung:

• Erstellen Sie in Cloud Composer 1 eine neue Umgebung mit einem größeren Maschinentyp als dem aktuellen Maschinentyp. Sie können Ihrer Umgebung weitere Knoten hinzufügen und [celery]worker_concurrency für Ihre Worker senken.
• Speicherlimits in Cloud Composer 2 erhöhen für Airflow-Worker.
• Falls Ihre Umgebung auch Zombie-Aufgaben generiert, lesen Sie Fehlerbehebung bei Zombie-Aufgaben
• Eine Anleitung zum Beheben von Problemen mit unzureichendem Arbeitsspeicher finden Sie unter Fehlerbehebung bei DAG-Problemen aufgrund von unzureichendem Arbeitsspeicher oder Speicherplatz.

Aufgabe schlägt fehl, ohne Logs auszugeben, da Pod entfernt wurde

Google Kubernetes Engine-Pods unterliegen den Kubernetes-Pod-Lebenszyklus und Pod-Entfernung Aufgabe Spitzen und eine gemeinsame Planung von Workern sind zwei der häufigsten Ursachen für die Bereinigung von Pods 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. Für z. B. wenn mehrere speicherintensive Aufgaben in einem Pod ausgeführt werden, und ihre kombinierte Last führt dazu, dass der Knoten, auf dem dieser Pod ausgeführt wird, die Arbeitsspeichernutzungsgrenze.

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:

1. Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.

   Zur Seite Umgebungen

2. Klicken Sie in der Liste der Umgebungen auf den Namen Ihrer Umgebung. Die Seite Umgebungsdetails wird geöffnet.

3. Rufen Sie den Tab Protokolle auf.

4. 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:

1. Rufen Sie in der Google Cloud Console die Seite Arbeitslasten auf.

   Zu Arbeitslasten

2. 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 einem größeren Maschinentyp als dem aktuellen Maschinentyp.
• Erhöhen Sie in Cloud Composer 2 die Arbeitsspeicherlimits für Airflow-Worker.
• Prüfen Sie die Logs von airflow-worker-Pods auf mögliche Ursachen für die Entfernung. Weitere Informationen zum Abrufen von Logs aus einzelnen Pods finden Sie unter Probleme mit bereitgestellten Arbeitslasten beheben.
• Achten Sie darauf, dass die Aufgaben im DAG idempotent und wiederholbar sind.

• Laden Sie keine unnötigen Dateien in das lokale Dateisystem von Airflow-Workern herunter.

  Airflow-Worker haben eine begrenzte Kapazität des lokalen Dateisystems. In Cloud Composer 2 kann ein Worker beispielsweise 1 bis 10 GB Speicher 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.
  • Über einen Airflow-Worker auf große Objekte im Ordner /data zugreifen 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:

dag_file_processor_timeout-Airflow überschreiben Konfigurationsoption und lassen Sie mehr Zeit für das DAG-Parsing:

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 den Parameter dagrun_timeout 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 unerwarteten Nebenwirkungen führen. 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.

Weitere Informationen finden Sie in der Apache Airflow-Dokumentation.

Lösung:

• Folgen Sie den Empfehlungen in der Apache Airflow-Dokumentation.

• 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 sich der Nebenwirkungen dieses Ansatzes bewusst.

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 Worker- und Planerknoten, deren Maschinentypen für eine höhere CPU- und Arbeitsspeicherkapazität angepasst werden können, verwendet der Webserver einen festen Maschinentyp. Dieser kann zu Fehlern beim DAG-Parsen führen, wenn dabei komplexe Berechnungen ausgeführt werden.

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. Lautet die Domain beispielsweise example-tp.appspot.com, hat das Dienstkonto die Bezeichnung 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.

Eine große Anzahl von DAGs und Plug-ins in dags- und Plug-in-Ordnern verarbeiten

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 die Synchronisierung. Gehen Sie dazu folgendermaßen vor:

• Begrenzen Sie die Anzahl der Dateien in den Ordnern „/dags“ und „/plugins“. Speichern Sie nur die minimal erforderlichen 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 können Sie DAGs in Batches aufteilen, in ZIP-Archiven und 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. Im Abschnitt zu programmatischen DAGs finden Sie Informationen dazu, wie Sie Probleme beim Planen und Ausführen programmatisch generierter DAGs vermeiden.

Programmatisch generierte DAGs nicht gleichzeitig planen

Das programmgesteuerte Generieren von DAG-Objekten aus einer DAG-Datei ist eine effiziente Methode, um viele ähnliche DAGs mit nur kleinen Unterschieden zu erstellen.

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 Arbeitsspeicherressourcen haben, um alle gleichzeitig geplanten Aufgaben auszuführen.

So vermeiden Sie Probleme beim Planen programmatischer DAGs:

• Erhöhen Sie die Nebenläufigkeit der Worker und skalieren Sie Ihre Umgebung, damit mehr Aufgaben gleichzeitig ausgeführt werden können.
• 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.

Fehler 504 beim Zugriff auf den Airflow-Webserver

Weitere Informationen finden Sie unter Fehler 504 beim Zugriff auf die Airflow-Benutzeroberfläche.

Die Lost connection to Postgres / MySQL server during query-Ausnahme wird während der Ausführung der Aufgabe oder unmittelbar danach ausgelöst.

Lost connection to Postgres / MySQL 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- oder MySQL-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 darf. Aufgabe Sie können also 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-dag Airflow-Konfigurationsoption dazu.

Wenn zu einem bestimmten Zeitpunkt nur eine einzige Instanz eines DAG ausgeführt werden soll, legen Sie den Parameter max-active-runs-per-dag auf 1 fest.

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“ kann diese Synchronisierung verhindern, dass sie richtig funktioniert, oder sie 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 gzip-komprimierte Dateien mit Komprimierungs-Transcodierung in die Ordner /dags und /plugins hochgeladen. 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ösche das Objekt, für das die Komprimierungstranscodierung verwendet wurde, und lade es noch einmal in den Bucket hoch.

• Eines der Objekte heißt „.“. Ein solches Objekt wird nicht mit Schedulern und Workers synchronisiert und die Synchronisierung wird möglicherweise vollständig beendet.

  Lösung: Benennen Sie das problematische Objekt um.

• Ein Ordner und eine Python-Datei in DAG 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 irreführen, da das Symbol / bedeutet, dass es sich bei einem Objekt um einen Ordner und nicht um eine Datei handelt.

  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 sind DAGs und Plug-ins, die Sie implementieren, mit zusätzlichen Dateien verbunden, 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 unnötigen Dateien in /dags und /plugins Ordner.

Done [Errno 21] Is a directory: '/home/airflow/gcs/dags/...' Fehler wird von Planern und Workern generiert

Dieses Problem tritt auf, weil Objekte in Cloud Storage einen sich überschneidenden Namespace haben können, während Scheduler und Worker gleichzeitig traditionelle Dateisysteme verwenden. Zum Beispiel ist es möglich, um einen Ordner und ein Objekt mit demselben Namen zum Bucket. Wenn der Bucket mit den Planern und Workern der Umgebung synchronisiert ist, wird dieser Fehler generiert, was zu Aufgabenfehlern führen kann.

Achten Sie darauf, dass sich im Bucket der Umgebung keine überlappenden Namespaces befinden, um dieses Problem zu beheben. Wenn beispielsweise sowohl /dags/misc (eine Datei) als auch /dags/misc/example_file.txt (eine andere Datei) befinden sich in einem Bucket, wird folgender Fehler ausgegeben: die vom Planer generiert wurden.

Vorübergehende Unterbrechungen beim Herstellen einer Verbindung zur Airflow-Metadatendatenbank

Cloud Composer wird auf einer verteilten Cloud-Infrastruktur ausgeführt. Das bedeutet, dass gelegentlich vorübergehende Probleme auftreten können, die die Ausführung Ihrer Airflow-Aufgaben unterbrechen.

In solchen Fällen werden in den Logs der Airflow-Worker möglicherweise die folgenden Fehlermeldungen angezeigt:

"Can't connect to Postgres / MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (111)"

oder

"Can't connect to Postgres / MySQL server on 'airflow-sqlproxy-service.default.svc.cluster.local' (104)"

Solche sporadischen Probleme können auch durch Wartungsarbeiten an Ihren Cloud Composer-Umgebungen verursacht werden.

Normalerweise treten solche Fehler zeitweise auf und wenn Ihre Airflow-Aufgaben idempotent sind und Sie Wiederholungsversuche konfiguriert haben, sollten Sie dagegen immun 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 gekennzeichnet, es wurden aber keine Aufgaben ausgeführt

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.

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 beispielsweise passieren, wenn Sie pendulum.parse(...) verwenden, um start_date festzulegen.

• start_date der DAG ist auf einen dynamischen Wert festgelegt, z. B. airflow.utils.dates.days_ago(1).

Lösung

• Achten Sie darauf, dass execution_date und start_date dieselbe Zeitzone verwenden.

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

• [core]dagrun_import_timeout definiert, wie viel Zeit der DAG-Prozessor zum Parsen eines einzelnen DAG hat.

• [core]dag_file_processor_timeout definiert die Gesamtzeit, die der DAG-Prozessor für das Parsen aller DAGs aufwenden kann.

Wenn ein DAG nicht in der Airflow-UI oder DAG-UI angezeigt wird:

• Prüfen Sie die DAG-Prozessorlogs, ob der DAG-Prozessor in der Lage ist, Ihren DAG. 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 Scheduler-Logs, um festzustellen, ob der Scheduler ordnungsgemäß funktioniert. 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 mehr als die festgelegte Anzahl von Sekunden dauert in [core]dag_file_processor_timeout, erhöhen Sie dieses Zeitlimit.

• Wenn das Parsen des DAG lange dauert, kann dies auch bedeuten, optimal implementiert werden. 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 arbeitet.

• Anzahl der Planer anpassen

• Erhöhen Sie die Anzahl der DAG-Prozessorprozesse, damit das Parsen schneller erfolgen kann. Dazu erhöhen Sie den Wert [scheduler]parsing_process

• Verringern Sie die Häufigkeit des DAG-Parsings.

• Belastung der Airflow-Datenbank verringern

Symptome einer stark ausgelasteten Airflow-Datenbank

Weitere Informationen finden Sie unter Symptome für eine überlastete Airflow-Datenbank.

Nächste Schritte

• Fehlerbehebung bei der Installation von PyPI-Paketen
• Fehlerbehebung bei Umgebungsupdates und -upgrades