Esegui il debug dei problemi di DAG relativi a memoria e spazio di archiviazione insufficienti

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Questo tutorial fornisce i passaggi per eseguire il debug di un DAG Airflow non riuscito in Cloud Composer e diagnosticare i problemi relativi alle risorse worker, ad esempio la mancanza di memoria o spazio di archiviazione del worker, con l'aiuto di log e monitoraggio dell'ambiente.

Introduzione

Questo tutorial si concentra sui problemi relativi alle risorse per mostrare i modi per eseguire il debug di un DAG.

La mancanza di risorse worker allocate causa errori DAG. Se una attività Airflow esaurisce la memoria o lo spazio di archiviazione, potresti visualizzare un'eccezione Airflow, ad esempio:

WARNING airflow.exceptions.AirflowException: Task received SIGTERM signal
INFO - Marking task as FAILED.

o

Task exited with return code Negsignal.SIGKILL

In questi casi, il consiglio generale è di aumentare le risorse del worker Airflow o ridurre il numero di attività per worker. Tuttavia, poiché le eccezioni di Airflow possono essere generiche, potrebbe essere difficile identificare la risorsa specifica che causa il problema.

Questo tutorial spiega come diagnosticare il motivo di un errore DAG e identificare il tipo di risorsa che causa problemi eseguendo il debug di due DAG di esempio che non vanno a buon fine a causa della mancanza di memoria e spazio di archiviazione del worker.

Obiettivi

  • Esegui DAG di esempio che non vanno a buon fine per i seguenti motivi:

    • Mancanza di memoria del worker
    • Mancanza di spazio di archiviazione per i worker
  • Diagnosticare i motivi dell'errore

  • Aumentare le risorse dei lavoratori allocate

  • Testa i DAG con i nuovi limiti delle risorse

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Al termine di questo tutorial, puoi evitare l'addebito di ulteriori costi eliminando le risorse create. Per maggiori dettagli, vedi Pulizia.

Prima di iniziare

Questa sezione descrive le azioni necessarie prima di iniziare il tutorial.

Creare e configurare un progetto

Per questo tutorial, è necessario un Google Cloud progetto. Configura il progetto nel seguente modo:

  1. Nella console Google Cloud , seleziona o crea un progetto:

    Vai al selettore di progetti

  2. Verifica che la fatturazione sia attivata per il tuo progetto. Scopri come verificare se la fatturazione è abilitata per un progetto.

  3. Assicurati che l'utente del progetto Google Cloud disponga dei seguenti ruoli per creare le risorse necessarie:

    • Amministratore ambienti e oggetti Storage (roles/composer.environmentAndStorageObjectAdmin)
    • Compute Admin (roles/compute.admin)
    • Editor Monitoring (roles/monitoring.editor)

Abilitare le API per il progetto

Enable the Cloud Composer API.

Enable the API

Crea l'ambiente Cloud Composer

Crea un ambiente Cloud Composer 2.

Durante la creazione dell'ambiente, concedi il ruolo Estensione agente di servizio API Cloud Composer v2 (roles/composer.ServiceAgentV2Ext) all'account agente di servizio Composer. Cloud Composer utilizza questo account per eseguire operazioni nel tuo progetto Google Cloud .

Controllare i limiti delle risorse worker

Controlla i limiti delle risorse dei worker Airflow nel tuo ambiente:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.

  3. Vai alla scheda Configurazione ambiente.

  4. Vai a Risorse > Configurazione dei workload > Worker.

  5. Verifica che i valori siano 0,5 vCPU, 1,875 GB di memoria e 1 GB di spazio di archiviazione. Questi sono i limiti delle risorse worker di Airflow con cui lavorerai nei passaggi successivi di questo tutorial.

Esempio: diagnosticare i problemi di memoria insufficiente

Carica il seguente DAG di esempio nell'ambiente che hai creato nei passaggi precedenti. In questo tutorial, questo DAG si chiama create_list_with_many_strings.

Questo DAG contiene un'attività che esegue i seguenti passaggi:

  1. Crea un elenco vuoto s.
  2. Esegue un ciclo per aggiungere la stringa More all'elenco.
  3. Stampa la quantità di memoria consumata dall'elenco e attende 1 secondo in ogni iterazione di 1 minuto.
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
)

Attiva il DAG di esempio

Attiva il DAG di esempio, create_list_with_many_strings:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nella colonna Server web Airflow, segui il link Airflow per il tuo ambiente.

  3. Nell'interfaccia web di Airflow, nella pagina DAG, nella colonna Link per il tuo DAG, fai clic sul pulsante Attiva DAG.

  4. Fai clic su Trigger.

  5. Nella pagina DAG, fai clic sull'attività che hai attivato e rivedi i log di output per assicurarti che il DAG abbia iniziato a essere eseguito.

Durante l'esecuzione dell'attività, i log di output stampano le dimensioni della memoria in GB utilizzata dal DAG.

Dopo alcuni minuti, l'attività non andrà a buon fine perché supera il limite di memoria del worker Airflow di 1,875 GB.

Esegui la diagnosi del DAG non riuscito

Se al momento dell'errore erano in esecuzione più attività, valuta la possibilità di eseguirne solo una e di diagnosticare la pressione delle risorse durante quel periodo per identificare quali attività causano la pressione delle risorse e quali risorse devi aumentare.

Esamina i log delle attività Airflow

Nota che l'attività del DAG create_list_with_many_strings ha lo stato Failed.

Esamina i log dell'attività. Verrà visualizzata la seguente voce di log:

```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.

Rivedere i workload

Esamina i workload per verificare che il carico dell'attività non causi il superamento del limite di consumo di memoria del nodo in cui viene eseguito il pod:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.

  3. Vai alla scheda Configurazione ambiente.

  4. In Risorse > Cluster GKE > Carichi di lavoro, fai clic su Visualizza carichi di lavoro cluster.

  5. Controlla se alcuni pod del workload hanno stati simili ai seguenti:

    Error with exit code 137 and 1 more issue.
    ContainerStatusUnknown with exit code 137 and 1 more issue
    

    Exit code 137 significa che un container o un pod sta tentando di utilizzare più memoria del consentito. Il processo viene terminato per evitare l'utilizzo della memoria.

Rivedi il monitoraggio dell'integrità dell'ambiente e del consumo di risorse

Rivedi il monitoraggio dell'integrità dell'ambiente e del consumo di risorse:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.

  3. Vai alla scheda Monitoraggio e seleziona Panoramica.

  4. Nel riquadro Panoramica dell'ambiente, individua il grafico Integrità ambiente (DAG di monitoraggio di Airflow). Contiene un'area rossa, che corrisponde al momento in cui i log hanno iniziato a stampare errori.

  5. Seleziona Worker e trova il grafico Utilizzo totale memoria worker. Osserva che la riga Utilizzo della memoria presenta un picco nel momento in cui l'attività era in esecuzione.

La linea Utilizzo di memoria presenta un picco nel momento in cui
    l'attività era in esecuzione
Figura 1. Grafico dell'utilizzo totale della memoria dei worker (fai clic per ingrandire)

Anche se la linea di utilizzo della memoria sul grafico non raggiunge il limite, quando diagnostichi i motivi dell'errore, devi tenere conto dell'utilizzo della memoria da parte dei singoli worker. Ogni worker utilizza una parte della propria memoria per eseguire altri container che eseguono azioni necessarie per il funzionamento del worker, come la sincronizzazione dei file DAG con il bucket dell'ambiente. La quantità effettiva di memoria disponibile per un worker per eseguire le attività di Airflow è inferiore al limite di memoria. Se un worker raggiunge il limite della memoria effettiva disponibile, l'attività eseguita può non riuscire a causa di memoria del worker insufficiente. In questi casi, puoi osservare errori delle attività anche se la linea sul grafico dell'utilizzo della memoria totale dei worker non raggiunge il limite di memoria.

Aumentare il limite di memoria del worker

Alloca memoria worker aggiuntiva affinché il DAG di esempio venga eseguito correttamente:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.

  3. Vai alla scheda Configurazione ambiente.

  4. Trova la configurazione Risorse > Workload e fai clic su Modifica.

  5. Nella sezione Worker, nel campo Memoria, specifica il nuovo limite di memoria per i worker Airflow. In questo tutorial, utilizza 3 GB.

  6. Salva le modifiche e attendi alcuni minuti per il riavvio dei worker Airflow.

Testare il DAG con il nuovo limite di memoria

Attiva di nuovo il DAG create_list_with_many_strings e attendi il completamento dell'esecuzione.

  1. Nei log di output dell'esecuzione del DAG, vedrai Marking task as SUCCESS, e lo stato dell'attività indicherà Riuscito.

  2. Controlla la sezione Panoramica ambiente nella scheda Monitoraggio e assicurati che non ci siano aree rosse.

  3. Fai clic sulla sezione Worker e trova il grafico Utilizzo totale memoria worker. Vedrai che la riga Limite di memoria riflette la modifica del limite di memoria e la riga Utilizzo della memoria è molto al di sotto del limite di memoria allocabile effettivo.

Esempio: diagnostica dei problemi di spazio di archiviazione insufficiente

In questo passaggio, carichi due DAG che creano file di grandi dimensioni. Il primo DAG crea un file di grandi dimensioni. Il secondo DAG crea un file di grandi dimensioni e imita unoperazione a lunga esecuzione.

Le dimensioni del file in entrambi i DAG superano il limite predefinito di 1 GB per lo spazio di archiviazione worker di Airflow, ma il secondo DAG ha un'attività di attesa aggiuntiva per estenderne artificialmente la durata.

Nei passaggi successivi esaminerai le differenze nel comportamento di entrambi i DAG.

Carica un DAG che crea un file di grandi dimensioni

Carica il seguente DAG di esempio nell'ambiente che hai creato nei passaggi precedenti. In questo tutorial, questo DAG si chiama create_large_txt_file_print_logs.

Questo DAG contiene un'attività che esegue i seguenti passaggi:

  1. Scrive un file localfile.txt da 1,5 GB nello spazio di archiviazione worker di Airflow.
  2. Stampa le dimensioni del file creato utilizzando il modulo Python os.
  3. Stampa la durata dell'esecuzione del DAG ogni minuto.
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)

Carica un DAG che crea un file di grandi dimensioni in un'operazione a lunga esecuzione

Per imitare un DAG di lunga durata e analizzare l'impatto della durata dell'attività sullo stato finale, carica il secondo DAG di esempio nel tuo ambiente. In questo tutorial, questo DAG si chiama long_running_create_large_txt_file_print_logs.

Questo DAG contiene un'attività che esegue i seguenti passaggi:

  1. Scrive un file localfile.txt da 1,5 GB nello spazio di archiviazione worker di Airflow.
  2. Stampa le dimensioni del file creato utilizzando il modulo Python os.
  3. Attende 1 ora e 15 minuti per simulare il tempo necessario per le operazioni con il file, ad esempio la lettura dal file.
  4. Stampa la durata dell'esecuzione del DAG ogni minuto.
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)

Attiva DAG di esempio

Attiva il primo DAG, create_large_txt_file_print_logs:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nella colonna Server web Airflow, segui il link Airflow per il tuo ambiente.

  3. Nell'interfaccia web di Airflow, nella pagina DAG, nella colonna Link per il tuo DAG, fai clic sul pulsante Attiva DAG.

  4. Fai clic su Trigger.

  5. Nella pagina DAG, fai clic sull'attività che hai attivato e rivedi i log di output per assicurarti che il DAG abbia iniziato a essere eseguito.

  6. Attendi il completamento dell'attività creata con il DAG create_large_txt_file_print_logs. L'operazione potrebbe richiedere diversi minuti.

  7. Nella pagina DAG, fai clic sull'esecuzione del DAG. Vedrai che l'attività ha lo stato Success, anche se il limite di spazio di archiviazione è stato superato.

Esamina i log Airflow del task:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

    1. Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.

    2. Vai alla scheda Log, poi vai a Tutti i log > Log di Airflow > Worker > Visualizza in Esplora log.

    3. Filtra i log per tipo: mostra solo i messaggi Errore.

Nei log vedrai messaggi simili ai seguenti:

Worker: warm shutdown (Main Process)

o

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.

Questi log indicano che il pod ha avviato il processo di "arresto controllato" perché lo spazio di archiviazione utilizzato ha superato il limite ed è stato rimosso dopo 1 ora. Tuttavia, l'esecuzione del DAG non è andata in errore perché è stata completata entro il periodo di interruzione controllata di Kubernetes, che viene spiegato più nel dettaglio in questo tutorial.

Per illustrare il concetto di periodo di tolleranza per la chiusura, esamina il risultato del secondo DAG di esempio, long_running_create_large_txt_file_print_logs.

Attiva il secondo DAG, long_running_create_large_txt_file_print_logs:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nella colonna Server web Airflow, segui il link Airflow per il tuo ambiente.

  3. Nell'interfaccia web di Airflow, nella pagina DAG, nella colonna Link per il tuo DAG, fai clic sul pulsante Attiva DAG.

  4. Fai clic su Trigger.

  5. Nella pagina DAG, fai clic sull'attività che hai attivato e rivedi i log di output per assicurarti che il DAG abbia iniziato a essere eseguito.

  6. Attendi l'esito negativo dell'esecuzione del DAG long_running_create_large_txt_file_print_logs. L'operazione richiederà circa un'ora.

Esamina i risultati dell'esecuzione del DAG:

  1. Nella pagina DAG, fai clic sull'esecuzione del DAG long_running_create_large_txt_file_print_logs. Vedrai che l'attività ha lo stato Failed e che la durata dell'esecuzione è stata esattamente di 1 ora e 5 minuti, ovvero inferiore al periodo di attesa dell'attività di 1 ora e 15 minuti.

  2. Esamina i log dell'attività. Una volta che il DAG ha creato il file localfile.txt nel container del worker Airflow, il log indica che il DAG ha iniziato l'attesa e la durata dell'esecuzione viene stampata nei log delle attività ogni minuto. In questo esempio, il DAG stampa il log localfile.txt size: e le dimensioni del file localfile.txt saranno pari a 1,5 GB.

Una volta che il file scritto nel container del worker Airflow supera il limite di spazio di archiviazione, l'esecuzione del DAG dovrebbe non riuscire. Tuttavia, l'attività non ha esito negativo immediatamente e continua a essere eseguita finché la sua durata non raggiunge 1 ora e 5 minuti. Ciò accade perché Kubernetes non termina immediatamente l'attività e continua a essere eseguita per consentire un'ora di tempo di ripristino, noto come "periodo di tolleranza per l'interruzione". Quando un nodo esaurisce le risorse, Kubernetes non termina immediatamente il pod per gestire la terminazione in modo controllato, in modo da ridurre al minimo l'impatto sull'utente finale.

Il periodo di tolleranza per la chiusura consente agli utenti di recuperare i file dopo gli errori delle attività, ma può generare confusione durante la diagnosi dei DAG. Quando viene superato il limite di spazio di archiviazione del worker Airflow, lo stato dell'attività finale dipende dalla durata dell'esecuzione del DAG:

  • Se l'esecuzione del DAG supera il limite di spazio di archiviazione del worker, ma viene completata in meno di 1 ora, l'attività viene completata con lo stato Success perché è stata completata entro il periodo di tolleranza per la terminazione. Tuttavia, Kubernetes termina il pod e il file scritto viene eliminato immediatamente dal container.

  • Se il DAG supera il limite di spazio di archiviazione del worker e viene eseguito per più di un'ora, il DAG continua a essere eseguito per un'ora e può superare il limite di spazio di archiviazione di migliaia di punti percentuali prima che Kubernetes elimini il pod e Airflow contrassegni l'attività come Failed.

Esegui la diagnosi del DAG non riuscito

Se al momento dell'errore erano in esecuzione più attività, valuta la possibilità di eseguirne solo una e di diagnosticare la pressione delle risorse durante quel periodo per identificare quali attività causano la pressione delle risorse e quali risorse devi aumentare.

Esamina i log delle attività del secondo DAG, long_running_create_large_txt_file_print_logs:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.

  3. Vai alla scheda Log, poi vai a Tutti i log > Log di Airflow > Worker > Visualizza in Esplora log.

  4. Filtra i log per tipo: mostra solo i messaggi Errore.

Nei log vedrai messaggi simili ai seguenti:

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.

o

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.

Questi messaggi indicano che, man mano che l'attività avanzava, i log di Airflow hanno iniziato a stampare errori quando le dimensioni dei file generati dal DAG hanno superato il limite di spazio di archiviazione del worker ed è iniziato il periodo di tolleranza per l'interruzione. Durante il periodo di tolleranza per la chiusura, il consumo di spazio di archiviazione non è tornato al limite, il che ha comportato l'espulsione del pod al termine del periodo di tolleranza per la chiusura.

Rivedi il monitoraggio dell'integrità dell'ambiente e del consumo di risorse:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.

  3. Vai alla scheda Monitoraggio e seleziona Panoramica.

  4. Nel riquadro Panoramica dell'ambiente, individua il grafico Integrità ambiente (DAG di monitoraggio di Airflow). Contiene un'area rossa, che corrisponde al momento in cui i log hanno iniziato a stampare errori.

  5. Seleziona Worker e individua il grafico Utilizzo totale disco worker. Osserva che la linea Utilizzo disco presenta un picco e supera la linea Limite disco nel momento in cui è stato eseguito il task.

La linea Utilizzo del disco presenta un picco e supera la linea Limite del disco
    nel momento in cui è stato eseguito il tuo task
Figura 2. Grafico dell'utilizzo totale del disco dei worker (fai clic per ingrandire)

Aumentare il limite di spazio di archiviazione del lavoratore

Alloca spazio di archiviazione aggiuntivo per i worker Airflow affinché il DAG di esempio venga eseguito correttamente:

  1. Nella console Google Cloud , vai alla pagina Ambienti.

    Vai ad Ambienti

  2. Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.

  3. Vai alla scheda Configurazione ambiente.

  4. Trova la configurazione Risorse > Workload e fai clic su Modifica.

  5. Nella sezione Worker, nel campo Archiviazione, specifica il nuovo limite di archiviazione per i worker Airflow. In questo tutorial, impostalo su 2 GB.

  6. Salva le modifiche e attendi alcuni minuti per il riavvio dei worker Airflow.

Testare il DAG con il nuovo limite di archiviazione

Attiva di nuovo il long_running_create_large_txt_file_print_logs DAG e attendi 1 ora e 15 minuti fino al termine dell'esecuzione.

  1. Nei log di output dell'esecuzione del DAG, vedrai Marking task as SUCCESS, e lo stato dell'attività indicherà Success, con una durata di 1 ora e 15 minuti, pari al tempo di attesa impostato nel codice DAG.

  2. Controlla la sezione Panoramica ambiente nella scheda Monitoraggio e assicurati che non ci siano aree rosse.

  3. Fai clic sulla sezione Worker e trova il grafico Utilizzo totale disco worker. Vedrai che la riga Limite disco riflette la modifica del limite di spazio di archiviazione e la riga Utilizzo disco rientra nell'intervallo consentito.

Riepilogo

In questo tutorial, hai diagnosticato il motivo di un errore DAG e identificato il tipo di risorsa che causa pressione eseguendo il debug di due DAG di esempio che non vanno a buon fine a causa della mancanza di memoria e spazio di archiviazione del worker. Successivamente, hai eseguito i DAG correttamente dopo aver allocato più memoria e spazio di archiviazione ai worker. Tuttavia, è consigliabile ottimizzare i DAG (flussi di lavoro) per ridurre il consumo di risorse dei worker, perché non è possibile aumentare le risorse oltre una determinata soglia.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina il progetto

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Elimina singole risorse

Se intendi esplorare più tutorial e guide rapide, il riuso dei progetti ti aiuta a non superare i limiti di quota.

Elimina l'ambiente Cloud Composer. Durante questa procedura, elimini anche il bucket dell'ambiente.

Passaggi successivi