Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
Diese Anleitung beschreibt Schritte zum Debuggen eines fehlgeschlagenen Airflow-DAG in Cloud Composer und diagnostizieren ressourcenbezogene Probleme mit Workern, z. B. nicht genügend Worker-Arbeitsspeicher oder Speicherplatz, dank der Logs und der Umgebung, des Monitorings.
Einleitung
In dieser Anleitung geht es vorrangig um ressourcenbezogene Probleme. DAG
Ein Mangel an zugewiesenen Worker-Ressourcen führt zu DAG-Fehlern. Wenn eine Airflow-Aufgabe nicht genügend Arbeitsspeicher oder Speicherplatz, können Airflow-Ausnahmen Beispiele:
WARNING airflow.exceptions.AirflowException: Task received SIGTERM signal
INFO - Marking task as FAILED.
oder
Task exited with return code Negsignal.SIGKILL
In solchen Fällen empfiehlt es sich, den Airflow-Worker zu erhöhen, oder die Anzahl der Aufgaben pro Worker reduzieren. Da Airflow jedoch Ausnahmen können generisch sein, es kann schwierig sein, die das Problem verursacht.
In diesem Tutorial erfahren Sie, wie Sie den Grund für einen DAG-Fehler diagnostizieren und Ermitteln Sie den Ressourcentyp, der Probleme verursacht, indem Sie zwei Beispiel-DAGs beheben die aufgrund von zu wenig Worker-Arbeitsspeichern und -speichern fehlschlagen.
Lernziele
Führen Sie Beispiel-DAGs aus, die aus folgenden Gründen fehlschlagen:
- Fehlender Worker-Arbeitsspeicher
- Fehlender Worker-Speicherplatz
Diagnose der Fehlerursachen
Zugewiesene Worker-Ressourcen erhöhen
DAGs mit neuen Ressourcenlimits testen
Kosten
In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:
Nach Abschluss dieser Anleitung können Sie weitere Kosten durch Löschen von erstellten Ressourcen vermeiden. Weitere Informationen finden Sie unter Bereinigen.
Hinweise
In diesem Abschnitt werden die Aktionen beschrieben, die vor dem Start der Anleitung erforderlich sind.
Projekt erstellen und konfigurieren
Für diese Anleitung benötigen Sie eine Google Cloud Projekt erstellen. Konfigurieren Sie das Projekt so:
Wählen Sie in der Google Cloud Console ein Projekt aus oder erstellen Sie eines:
Die Abrechnung für Ihr Projekt muss aktiviert sein. Hier erfahren Sie, wie Sie prüfen, ob die Abrechnung für ein Projekt aktiviert ist.
Sorgen Sie dafür, dass Ihr Google Cloud-Projektnutzer die folgenden Rollen hat, um die erforderlichen Ressourcen zu erstellen:
- Administrator für Umgebung und Storage-Objekte
(
roles/composer.environmentAndStorageObjectAdmin) - Compute-Administrator (
roles/compute.admin) - Monitoring-Bearbeiter (
roles/monitoring.editor)
- Administrator für Umgebung und Storage-Objekte
(
Die APIs für Ihr Projekt aktivieren
Cloud Composer API aktivieren.
Cloud Composer-Umgebung erstellen
Erstellen Sie eine Cloud Composer 2-Umgebung.
Um die Umgebung zu schaffen,
Sie gewähren die Dienst-Agent-Erweiterung für die Cloud Composer v2 API.
Rolle (roles/composer.ServiceAgentV2Ext) für den Composer-Dienst-Agent
Konto. Cloud Composer verwendet dieses Konto, um Vorgänge auszuführen
in Ihrem Google Cloud-Projekt.
Limits für Worker-Ressourcen prüfen
Prüfen Sie die Airflow-Worker-Ressourcenlimits in Ihrer Umgebung:
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 Umgebungskonfiguration auf.
Rufen Sie Ressourcen > Arbeitslastkonfiguration auf. > Worker.
Die Werte müssen 0,5 vCPUs, 1,875 GB Arbeitsspeicher und 1 GB Speicher lauten. Dies sind die Limits für die Airflow-Worker-Ressourcen, mit denen Sie im nächsten Schritt dieser Anleitung.
Beispiel: Probleme mit unzureichendem Arbeitsspeicher diagnostizieren
Laden Sie den folgenden Beispiel-DAG in die Umgebung hoch.
die Sie in den vorherigen Schritten erstellt haben. In dieser Anleitung heißt dieser DAG
create_list_with_many_strings
Dieser DAG enthält eine Aufgabe, die die folgenden Schritte ausführt:
- Erstellt eine leere Liste
s. - Führt einen Zyklus aus, um den String
Morean die Liste anzufügen. - Gibt an, wie viel Arbeitsspeicher die Liste verbraucht, und wartet in jedem 1-Sekunden-Wert 1 Sekunde Minuten Durchlauf.
import time
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import sys
from datetime import timedelta
default_args = {
'start_date': airflow.utils.dates.days_ago(0),
'retries': 0,
'retry_delay': timedelta(minutes=10)
}
dag = DAG(
'create_list_with_many_strings',
default_args=default_args,
schedule_interval=None)
def consume():
s = []
for i in range(120):
for j in range(1000000):
s.append("More")
print(f"i={i}; size={sys.getsizeof(s) / (1000**3)}GB")
time.sleep(1)
t1 = PythonOperator(
task_id='task0',
python_callable=consume,
dag=dag,
depends_on_past=False,
retries=0
)
Beispiel-DAG auslösen
Lösen Sie den Beispiel-DAG create_list_with_many_strings aus:
Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.
Klicken Sie in der Spalte Airflow-Webserver auf den Link Airflow für Ihre Umgebung.
Klicken Sie in der Airflow-Weboberfläche auf der Seite DAGs in der Spalte Links für Ihren DAG auf die Schaltfläche Trigger DAG.
Klickbasierter Trigger
Klicken Sie auf der Seite DAGs auf die Aufgabe, die Sie ausgelöst haben, und überprüfen Sie die Ausgabe. Logs, um sicherzustellen, dass der DAG ausgeführt wird.
Während die Task ausgeführt wird, geben die Ausgabelogs die Arbeitsspeichergröße in GB aus. das der DAG verwendet.
Nach einigen Minuten schlägt die Aufgabe fehl, da sie den Airflow-Worker überschreitet. 1,875 GB.
Fehlgeschlagenen DAG diagnostizieren
Wenn zum Zeitpunkt des Fehlers mehrere Tasks ausgeführt wurden, sollten Sie erwägen, und die Diagnose des Ressourcendrucks während dieser Zeit welche Aufgaben Ressourcendruck verursachen und welche Ressourcen Sie erhöhen müssen.
Airflow-Aufgabenlogs prüfen
Sie sehen, dass die Aufgabe aus dem DAG create_list_with_many_strings
Failed.
Überprüfen Sie die Logs der Aufgabe. Sie sehen den folgenden Logeintrag:
```none
{local_task_job.py:102} INFO - Task exited with return code
Negsignal.SIGKILL
```
`Netsignal.SIGKILL` might be an indication of your task using more memory
than the Airflow worker is allocated. The system sends
the `Negsignal.SIGKILL` signal to avoid further memory consumption.
Arbeitslasten überprüfen
Überprüfen Sie die Arbeitslasten, um sicherzustellen, dass die Auslastung der Aufgabe nicht den Knoten verursacht, auf dem der Pod ausgeführt wird, um das Limit für die Arbeitsspeichernutzung zu überschreiten:
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 Umgebungskonfiguration auf.
Gehen Sie zu Ressourcen > GKE-Cluster > Arbeitslasten: Klicken Sie auf Clusterarbeitslasten ansehen.
Prüfen Sie, ob einige der Arbeitslast-Pods einen ähnlichen Status wie den folgenden haben:
Error with exit code 137 and 1 more issue. ContainerStatusUnknown with exit code 137 and 1 more issueExit code 137bedeutet, dass ein Container oder Pod versucht, mehr Arbeitsspeicher zu verwenden als zulässig. Der Prozess wird beendet, um eine Arbeitsspeichernutzung zu verhindern.
Monitoring des Umgebungszustands und des Ressourcenverbrauchs prüfen
Prüfen Sie das Monitoring des Umgebungszustands und des Ressourcenverbrauchs:
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.
Wechseln Sie zum Tab Monitoring und wählen Sie Übersicht aus.
Suchen Sie im Bereich Umgebungsübersicht nach dem Diagramm zum Umgebungsstatus (Airflow Monitoring-DAG): Es enthält einen roten Bereich, der dem Zeitpunkt entspricht, zu dem die Protokolle mit dem Drucken von Fehlern begonnen haben.
Wählen Sie Worker aus und gehen Sie zur Grafik Gesamte Arbeitsspeichernutzung der Worker. Beachten Sie, dass die Zeile Arbeitsspeichernutzung zu dem Zeitpunkt, an dem der ausgeführt wurde.
Auch wenn die Linie für die Arbeitsspeichernutzung in der Grafik das Limit nicht erreicht, müssen Sie bei der Diagnose der Fehlerursachen berücksichtigen, nur zuweisbarer Arbeitsspeicher, während die Linie Arbeitsspeicherlimit im Diagramm für den Gesamtarbeitsspeicher steht. einschließlich der von GKE reservierten Kapazitäten.
In diesem Beispiel ist das Worker-Arbeitsspeicherlimit auf 1, 875 GB festgelegt. GKE reserviert 25% der ersten 4 GiB Arbeitsspeicher. GKE reserviert außerdem Bereinigungsschwellenwert: 100 MiB Arbeitsspeicher auf jedem Knoten für die Kubelet-Bereinigung.
Der zuweisbare Arbeitsspeicher wird so berechnet:
ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD
Wenn das Arbeitsspeicherlimit 1,875 GB beträgt, ist der tatsächlich zuweisbare Arbeitsspeicher:
1.75 GiB (1.875GB) - 0.44 (25% GiB reserved) - 0.1 = 1.21 GiB (~1.3 GB).
Wenn Sie dieses tatsächliche Limit an das Diagramm der Arbeitsspeichernutzung anhängen, stellen Sie fest, dass der Anstieg der Arbeitsspeichernutzung der Aufgabe den tatsächlichen Arbeitsspeicher und Sie können daraus schließen, dass die Aufgabe aufgrund unzureichender Worker fehlgeschlagen ist. zu speichern.
Worker-Arbeitsspeicherlimit erhöhen
Weisen Sie zusätzlichen Worker-Arbeitsspeicher zu, damit der Beispiel-DAG erfolgreich ist:
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 Umgebungskonfiguration auf.
Suchen Sie die Konfiguration unter Ressourcen > Arbeitslasten und Klicken Sie auf Bearbeiten.
Geben Sie im Abschnitt Worker im Feld Memory den neuen Arbeitsspeicher an. Limit für Airflow-Worker. Verwenden Sie in dieser Anleitung 3 GB.
Speichern Sie die Änderungen und warten Sie einige Minuten, bis Ihre Airflow-Worker neu starten.
DAG mit neuem Arbeitsspeicherlimit testen
Lösen Sie den DAG create_list_with_many_strings noch einmal aus und warten Sie, bis er
ausgeführt wird.
In den Ausgabelogs der DAG-Ausführung sehen Sie
Marking task as SUCCESS. und der Status der Aufgabe lautet Success.Sehen Sie sich auf dem Tab Monitoring den Abschnitt Umgebungsübersicht an. Stellen Sie sicher, dass keine roten Flächen zu sehen sind.
Klicken Sie auf den Abschnitt Worker und sehen Sie sich die Gesamtspeichernutzung der Worker an. Diagramm. In der Zeile Memory limit (Speicherlimit) wird die Änderung der des Arbeitsspeicherlimits und die Zeile Arbeitsspeichernutzung weit unter dem tatsächlichen Wert Limit des zuweisbaren Arbeitsspeichers.
Beispiel: Probleme mit unzureichendem Speicherplatz diagnostizieren
In diesem Schritt laden Sie zwei DAGs hoch, die große Dateien erstellen. Der erste DAG erstellt eine große Datei. Der zweite DAG erstellt eine große Datei und imitiert einen einen Vorgang mit langer Ausführungszeit.
Die Größe der Datei in beiden DAGs überschreitet den standardmäßigen Airflow-Worker-Speicher Limit von 1 GB, aber der zweite DAG hat eine zusätzliche Warteaufgabe, um seine die Dauer künstlich erhöht.
Die Unterschiede im Verhalten beider DAGs werden Sie in den nächsten Schritte.
DAG hochladen, der eine große Datei erstellt
Laden Sie den folgenden Beispiel-DAG in die Umgebung hoch.
die Sie in den vorherigen Schritten erstellt haben. In dieser Anleitung heißt dieser DAG
create_large_txt_file_print_logs
Dieser DAG enthält eine Aufgabe, die die folgenden Schritte ausführt:
- Schreibt eine 1,5 GB große Datei
localfile.txtin den Airflow-Worker-Speicher. - Gibt die Größe der erstellten Datei mit dem Python-Modul
osaus. - Gibt die Dauer der DAG-Ausführung jede Minute aus.
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time
default_args = {
'start_date': airflow.utils.dates.days_ago(0),
'retries': 0,
'retry_delay': timedelta(minutes=10)
}
dag = DAG(
'create_large_txt_file_print_logs',
default_args=default_args,
schedule_interval=None)
def consume():
size = 1000**2 # bytes in 1 MB
amount = 100
def create_file():
print(f"Start creating a huge file")
with open("localfile.txt", "ab") as f:
for j in range(15):
f.write(os.urandom(amount) * size)
print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")
create_file()
print("Success!")
t1 = PythonOperator(
task_id='create_huge_file',
python_callable=consume,
dag=dag,
depends_on_past=False,
retries=0)
DAG hochladen, der eine große Datei in einem lang andauernden Vorgang erstellt
Imitieren eines lang andauernden DAG und Untersuchung der Auswirkungen der Aufgabendauer
für den Endzustand den zweiten Beispiel-DAG in den Upload
zu verbessern. In dieser Anleitung heißt dieser DAG
long_running_create_large_txt_file_print_logs
Dieser DAG enthält eine Aufgabe, die die folgenden Schritte ausführt:
- Schreibt eine 1,5 GB große Datei
localfile.txtin den Airflow-Worker-Speicher. - Gibt die Größe der erstellten Datei mit dem Python-Modul
osaus. - Warten 1 Stunde und 15 Minuten, um die für Vorgänge mit zum Beispiel durch Lesen aus der Datei.
- Gibt die Dauer der DAG-Ausführung jede Minute aus.
import airflow
from airflow import DAG
from airflow.operators.python_operator import PythonOperator
import os
from datetime import timedelta
import time
default_args = {
'start_date': airflow.utils.dates.days_ago(0),
'retries': 0,
'retry_delay': timedelta(minutes=10)
}
dag = DAG(
'long_running_create_large_txt_file_print_logs',
default_args=default_args,
schedule_interval=None)
def consume():
size = 1000**2 # bytes in 1 MB
amount = 100
def create_file():
print(f"Start creating a huge file")
with open("localfile.txt", "ab") as f:
for j in range(15):
f.write(os.urandom(amount) * size)
print("localfile.txt size:", os.stat("localfile.txt").st_size / (1000**3), "GB")
create_file()
for k in range(75):
time.sleep(60)
print(f"{k+1} minute")
print("Success!")
t1 = PythonOperator(
task_id='create_huge_file',
python_callable=consume,
dag=dag,
depends_on_past=False,
retries=0)
Beispiel-DAGs auslösen
Lösen Sie den ersten DAG create_large_txt_file_print_logs aus:
Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.
Klicken Sie in der Spalte Airflow-Webserver auf den Link Airflow für Ihre Umgebung.
Klicken Sie in der Airflow-Weboberfläche auf der Seite DAGs in der Spalte Links für Ihren DAG auf die Schaltfläche Trigger DAG.
Klickbasierter Trigger
Klicken Sie auf der Seite DAGs auf die Aufgabe, die Sie ausgelöst haben, und überprüfen Sie die Ausgabe. Logs, um sicherzustellen, dass der DAG ausgeführt wird.
Warten Sie, bis die Aufgabe, die Sie mit dem
create_large_txt_file_print_logsDAG wird abgeschlossen. Dies kann mehrere Minuten.Klicken Sie auf der Seite DAGs auf die DAG-Ausführung. Sie sehen Ihre Aufgabe hat den Status
Success, obwohl das Speicherlimit überschritten wurde.
Prüfen Sie die Airflow-Logs der Aufgabe:
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 Logs auf und klicken Sie dann auf Alle Logs > Airflow-Logs > Worker > Im Log-Explorer ansehen
Filtern Sie die Logs nach Typ: Nur Fehlermeldungen werden angezeigt.
Die Protokolle enthalten Nachrichten wie diese:
Worker: warm shutdown (Main Process)
oder
A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.
Diese Logs geben an, dass der Pod das Warm-Herunterfahren gestartet hat. weil die verwendeter Speicherplatz überschreitet das Limit und wurde in 1 Stunde entfernt. Der DAG wird jedoch ist nicht fehlgeschlagen, da er innerhalb des Kubernetes-Kulanzzeitraums für die Beendigung abgeschlossen wurde. definiert, die in diesem Tutorial näher erläutert wird.
Überprüfen Sie das Ergebnis, um das Konzept des Kulanzzeitraums für die Kündigung zu veranschaulichen.
des zweiten Beispiel-DAG, long_running_create_large_txt_file_print_logs.
Lösen Sie den zweiten DAG long_running_create_large_txt_file_print_logs aus:
Rufen Sie in der Google Cloud Console die Seite Umgebungen auf.
Klicken Sie in der Spalte Airflow-Webserver auf den Link Airflow für Ihre Umgebung.
Klicken Sie in der Airflow-Weboberfläche auf der Seite DAGs in der Spalte Links für Ihren DAG auf die Schaltfläche Trigger DAG.
Klickbasierter Trigger
Klicken Sie auf der Seite DAGs auf die Aufgabe, die Sie ausgelöst haben, und überprüfen Sie die Ausgabe. Logs, um sicherzustellen, dass der DAG ausgeführt wird.
Warten Sie, bis der DAG
long_running_create_large_txt_file_print_logsausgeführt wird. schlägt fehl. Dies dauert etwa eine Stunde.
Prüfen Sie die Ergebnisse der DAG-Ausführung:
Klicken Sie auf der Seite DAGs auf den
long_running_create_large_txt_file_print_logsDAG-Ausführung. Sie sehen dass die Aufgabe den StatusFailedhat und die Ausführungsdauer genau 1 Stunde und 5 Minuten, was kürzer als die Wartezeit 1 Stunde und 15 MinutenÜberprüfen Sie die Logs der Aufgabe. Nachdem der DAG die Datei
localfile.txtin des Airflow-Worker-Containers gibt das Log den vom DAG gestarteten DAG aus und die Ausführungsdauer wird jede Minute in den Aufgabenlogs ausgegeben. In diesem Beispiel gibt der DAG daslocalfile.txt size:-Log und die Größe aus der Dateilocalfile.txtbeträgt 1,5 GB.
Sobald die in den Container des Airflow-Workers geschriebene Datei den Speicherplatz überschreitet sollte die DAG-Ausführung fehlschlagen. Die Aufgabe schlägt jedoch nicht fehl. sofort und läuft weiter, bis die Dauer 1 Stunde und 5 Minuten erreicht ist. Dies liegt daran, dass Kubernetes die Aufgabe nicht sofort abbricht wird ausgeführt, um die Wiederherstellung von einer Stunde zu ermöglichen Punkt“. Wenn die Ressourcen eines Knotens ausgehen, beendet Kubernetes den Pod sofort, um die Beendigung ordnungsgemäß zu verarbeiten, damit nur minimale Auswirkungen auf die Endanwendenden.
Der Kulanzzeitraum für die Beendigung hilft Nutzern, Dateien nach fehlgeschlagenen Aufgaben wiederherzustellen. Bei der Diagnose von DAGs kann dies jedoch zu Verwirrung führen. Wenn der Airflow-Worker Speicherlimit überschritten ist, hängt der Status der Endaufgabe von der Dauer der DAG-Ausführung:
Wenn die DAG-Ausführung das Worker-Speicherlimit überschreitet, aber in weniger als 1 abgeschlossen wird Stunde, wird die Aufgabe mit dem Status
Successabgeschlossen, da sie abgeschlossen wurde innerhalb des Kulanzzeitraums für die Kündigung. Kubernetes beendet den Pod jedoch. Die geschriebene Datei wird sofort aus dem Container gelöscht.Wenn der DAG das Worker-Speicherlimit überschreitet und länger als eine Stunde ausgeführt wird, Der DAG wird noch eine Stunde lang ausgeführt und kann das Speicherlimit um bevor Kubernetes die Pod- und Airflow-Markierungen entfernt die Aufgabe als
Failed.
Fehlgeschlagenen DAG diagnostizieren
Wenn zum Zeitpunkt des Fehlers mehrere Tasks ausgeführt wurden, sollten Sie erwägen, und die Diagnose des Ressourcendrucks während dieser Zeit welche Aufgaben Ressourcendruck verursachen und welche Ressourcen Sie erhöhen müssen.
Überprüfen Sie die Aufgabenlogs des zweiten DAG.
long_running_create_large_txt_file_print_logs:
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 Logs auf und klicken Sie dann auf Alle Logs > Airflow-Logs > Worker > Im Log-Explorer ansehen
Filtern Sie die Logs nach Typ: Nur Fehlermeldungen werden angezeigt.
Die Protokolle enthalten Nachrichten wie diese:
Container storage usage of worker reached 155.7% of the limit.
This likely means that the total size of local files generated by your DAGs is
close to the storage limit of worker.
You may need to decrease the storage usage or increase the worker storage limit
in your Cloud Composer environment configuration.
oder
Pod storage usage of worker reached 140.2% of the limit.
A worker pod was evicted at 2023-12-01T12:30:05Z with message: Pod ephemeral
local storage usage exceeds the total limit of containers 1023Mi.
This eviction likely means that the total size of dags and plugins folders plus
local files generated by your DAGs exceeds the storage limit of worker.
Please decrease the storage usage or increase the worker storage limit in your
Cloud Composer environment configuration.
Diese Meldungen zeigen an, dass Airflow-Logs während der Aufgabe gestartet wurden. Druckfehler, wenn die Größe der von Ihrem DAG generierten Dateien die Speicherlimit für Worker und der Kulanzzeitraum für die Kündigung hat begonnen. Während der Kulanzzeitraum für die Beendigung, Speichernutzung ergab nicht wieder das Limit, was nach Ablauf des Kulanzzeitraums für die Beendigung zu einer Pod-Entfernung führte.
Prüfen Sie das Monitoring des Umgebungszustands und des Ressourcenverbrauchs:
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.
Wechseln Sie zum Tab Monitoring und wählen Sie Übersicht aus.
Suchen Sie im Bereich Umgebungsübersicht nach dem Diagramm zum Umgebungsstatus (Airflow Monitoring-DAG): Es enthält einen roten Bereich, der dem Zeitpunkt entspricht, zu dem die Protokolle mit dem Drucken von Fehlern begonnen haben.
Wählen Sie Worker aus und suchen Sie das Diagramm Gesamte Laufwerksnutzung der Worker. Beobachten dass die Zeile Laufwerknutzung einen Anstieg aufweist und das Laufwerkslimit überschreitet. zum Zeitpunkt der Ausführung Ihrer Task.
Worker-Speicherlimit erhöhen
Zusätzlichen Airflow-Worker-Speicher zuweisen, damit der Beispiel-DAG erfolgreich sein können:
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 Umgebungskonfiguration auf.
Suchen Sie die Konfiguration unter Ressourcen > Arbeitslasten und Klicken Sie auf Bearbeiten.
Geben Sie im Abschnitt Worker im Feld Storage den neuen Speicher an. Limit für Airflow-Worker. In dieser Anleitung legen Sie den Wert auf 2 GB fest.
Speichern Sie die Änderungen und warten Sie einige Minuten, bis Ihre Airflow-Worker neu starten.
DAG mit neuem Speicherlimit testen
Lösen Sie den DAG long_running_create_large_txt_file_print_logs noch einmal aus und
Warten Sie 1 Stunde und 15 Minuten, bis die Ausführung abgeschlossen ist.
In den Ausgabelogs der DAG-Ausführung sehen Sie
Marking task as SUCCESS. und der Status der Aufgabe Success (Erfolgreich) mit einer Dauer von 1 Stunde angibt. und 15 Minuten, was der im DAG-Code festgelegten Wartezeit entspricht.Sehen Sie sich auf dem Tab Monitoring den Abschnitt Umgebungsübersicht an. Stellen Sie sicher, dass keine roten Flächen zu sehen sind.
Klicken Sie auf den Abschnitt Worker und suchen Sie die Gesamtzahl der Laufwerksnutzung der Worker. Diagramm. Sie sehen, dass die Zeile Laufwerkslimit die Änderung in der Speicherlimit überschritten und die Zeile Laufwerknutzung im zulässigen Bereich liegt.
Fazit
In dieser Anleitung haben Sie den Grund für einen DAG-Fehler diagnostiziert und den Ressourcentyp, der durch das Debuggen von zwei fehlgeschlagenen Beispiel-DAGs Auslastung verursacht weil der Worker-Arbeitsspeicher und der Speicherplatz fehlt. Anschließend haben Sie die DAGs erfolgreich ausgeführt. nachdem Sie Ihren Workern mehr Arbeitsspeicher und Speicherplatz zugewiesen haben. Es ist jedoch empfohlen für DAGs (Workflows) optimieren den Ressourcenverbrauch der Worker zu reduzieren, um die Ressourcen über einen bestimmten Schwellenwert hinaus zu erhöhen.
Bereinigen
Um zu vermeiden, dass Ihrem Google Cloud-Konto die Ressourcen in Rechnung gestellt werden Löschen Sie entweder das Projekt, das die Ressourcen enthält, oder das Projekt behalten und die einzelnen Ressourcen löschen.
Projekt löschen
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.
Einzelne Ressourcen löschen
Wenn Sie mehrere Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.
Löschen Sie die Cloud Composer-Umgebung. Außerdem löschen Sie den Bucket der Umgebung.