Esegui il debug dei problemi DAG relativi a esaurimento o esaurimento dello spazio di archiviazione

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

Nota: questa pagina non è ancora stata revisionata per Cloud Composer 3 e mostra i contenuti per Cloud Composer 2.

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 dei worker, ad esempio la mancanza di memoria o di spazio di archiviazione dei worker, con l'aiuto dei log e del monitoraggio dell'ambiente.

Introduzione

Questo tutorial è incentrato sui problemi relativi alle risorse per dimostrare come eseguire il debug di un DAG.

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

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 è quello di aumentare le risorse dei worker di Airflow o ridurre il numero di attività per worker. Tuttavia, poiché le eccezioni di Airflow possono essere generiche, potrebbe essere difficile identificare la specifica risorsa che causa il problema.

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

Obiettivi

• Esegui DAG di esempio che non riescono a causa dei seguenti motivi:

  • Mancanza di memoria del worker
  • Mancanza di spazio di archiviazione per il worker

• Diagnostica i motivi dell'errore

• Aumentare le risorse worker allocate

• Testa i DAG con nuovi limiti di risorse

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

• Cloud Composer (vedi i costi aggiuntivi)
• Cloud Monitoring

Al termine di questo tutorial, potrai evitare la fatturazione continua eliminando le risorse che hai creato. 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 progetto Google Cloud. 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 oggetti di ambiente e archiviazione (roles/composer.environmentAndStorageObjectAdmin)
   • Amministratore Compute (roles/compute.admin)
   • Editor di Monitoring (roles/monitoring.editor)

Abilita le API per il progetto

Attiva l'API Cloud Composer.

Abilita l'API

crea il tuo ambiente Cloud Composer

Crea un ambiente Cloud Composer 2.

Importante: assicurati di utilizzare le preimpostazioni di ambiente piccole per riprodurre gli errori quando utilizzi gli esempi forniti più avanti in questo tutorial. Questa è la preimpostazione predefinita quando crei un ambiente tramite la console Google Cloud.

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

Controlla i limiti delle risorse worker

Controlla i limiti delle risorse worker di 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 dell'ambiente. Si apre la pagina Dettagli ambiente.

3. Vai alla scheda Configurazione dell'ambiente.

4. Vai a Risorse > Configurazione carichi di lavoro > Worker.

5. Controlla 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 esaurimento della memoria

Carica il seguente DAG di esempio nell'ambiente che hai creato nei passaggi precedenti. In questo tutorial, questo DAG è denominato 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 utilizzata dall'elenco e attende un secondo per ogni iterazione di 1 minuto.

Avviso: questo DAG simula un problema di esaurimento della memoria, che può interrompere potenzialmente le operazioni nel tuo ambiente.

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 Trigger DAG.

4. Fai clic su Attiva.

5. Nella pagina DAG, fai clic sull'attività attivata ed esamina i log di output per assicurarti che l'esecuzione del DAG sia stata avviata.

Mentre l'attività è in esecuzione, i log di output stamperanno le dimensioni della memoria in GB utilizzate dal DAG.

Dopo diversi minuti, l'attività avrà esito negativo perché supera il limite di memoria dei worker Airflow di 1,875 GB.

Nota: se attivi il DAG che supera il limite di memoria simultaneamente con qualsiasi altro DAG di esempio, vedrai che, se una delle attività supera il limite di memoria e non riesce, anche altre attività in esecuzione avranno esito negativo, anche se non consumano memoria.

Diagnosi del DAG non riuscito

Se eseguivi più attività al momento dell'errore, valuta la possibilità di eseguire una sola attività e di eseguire la diagnostica delle risorse durante questo periodo per identificare le attività che causano pressione e quali di conseguenza devi aumentare.

Rivedi i log delle attività Airflow

Osserva che l'attività del DAG create_list_with_many_strings ha uno 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.

Rivedi i carichi di lavoro

Rivedi i carichi di lavoro per verificare che il carico dell'attività non fa sì che il nodo in cui viene eseguito il pod superi il limite di consumo di memoria:

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

   Vai ad Ambienti

2. Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Dettagli ambiente.

3. Vai alla scheda Configurazione dell'ambiente.

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

5. Controlla se alcuni pod dei carichi di lavoro 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 indica che un container o un pod sta cercando di utilizzare più memoria di quella consentita. Il processo viene interrotto per impedire l'utilizzo di 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 dell'ambiente. Si apre la pagina Dettagli ambiente.

3. Vai alla scheda Monitoring e seleziona Panoramica.

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

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

Figura 1. Grafico totale dell'utilizzo della memoria dei worker (fai clic per ingrandire)

Anche se la riga di utilizzo della memoria nel grafico non raggiunge il limite, durante la diagnosi dei motivi di errore, devi prendere in considerazione solo la memoria allocabile, mentre la riga Limite di memoria sul grafico rappresenta la memoria totale disponibile (compresa la capacità prenotata da GKE).

In questo esempio, il limite di memoria dei worker è impostato su 1,875 GB. GKE riserva il 25% dei primi 4 GiB di memoria. GKE riserva inoltre un'ulteriore soglia di eliminazione: 100 MiB di memoria su ciascun nodo per l'eliminazione di kubelet.

La memoria allocabile viene calcolata nel seguente modo:

ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD

Se il limite di memoria è 1,875 GB, la memoria allocabile effettiva è:

1.75 GiB (1.875GB) - 0.44 (25% GiB reserved) - 0.1 = 1.21 GiB (~1.3 GB).

Quando aggiungi questo limite effettivo al grafico di utilizzo della memoria, vedrai che il picco di utilizzo della memoria dell'attività raggiunge il limite effettivo di memoria e potrai concludere che l'attività non è riuscita a causa di memoria worker insufficiente.

Nota: se il livello di consumo della memoria cresce troppo rapidamente, la riga di utilizzo della memoria potrebbe non acquisire correttamente il livello di consumo delle risorse reale. Il DAG airflow_monitoring è un controllo di integrità dell'attività per ambiente che viene utilizzato per compilare la metrica di monitoraggio environment/healthy. Questo DAG consente di utilizzare le funzionalità di Cloud Monitoring come i grafici delle metriche o l'impostazione di avvisi quando il tuo ambiente non è integro. Viene eseguito ogni 5 minuti e raccoglie le metriche, il che significa che potrebbe non acquisire l'utilizzo delle risorse tra le esecuzioni.

Aumenta il limite di memoria dei worker

Nota: la modifica della CPU o della memoria del worker riavvia i worker, con possibili ripercussioni sulle attività in esecuzione. Ti consigliamo di farlo quando non sono in esecuzione DAG.

Alloca memoria worker aggiuntiva affinché il DAG di esempio vada a buon fine:

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

   Vai ad Ambienti

2. Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Dettagli ambiente.

3. Vai alla scheda Configurazione dell'ambiente.

4. Trova la configurazione Risorse > Carichi di lavoro e fai clic su Modifica.

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

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

Testa il DAG con il nuovo limite di memoria

Attiva di nuovo il DAG create_list_with_many_strings e attendi che termini l'esecuzione.

1. Nei log di output dell'esecuzione del DAG vedrai Marking task as SUCCESS e lo stato dell'attività indicherà Success (Operazione riuscita).

2. Esamina la sezione Panoramica dell'ambiente nella scheda Monitoring e assicurati che non siano presenti 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 nel limite di memoria, mentre la riga Utilizzo memoria è molto inferiore al limite effettivo di memoria allocabile.

Esempio: diagnosticare i problemi di esaurimento dello spazio di archiviazione

In questo passaggio, caricherai 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 un'operazione a lunga esecuzione.

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

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

Nota: i DAG in questo tutorial creano file locali. In un'impostazione di produzione, evita di archiviare qualsiasi file o configurazione nel file system locale, perché è probabile che l'attività successiva venga eseguita su un worker Airflow diverso senza accesso al file.

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 è denominato 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 del worker di Airflow.
2. Stampa la dimensione del file creato utilizzando il modulo os Python.
3. Stampa la durata dell'esecuzione del DAG ogni minuto.

Avviso: questo DAG simula un problema di esaurimento dello spazio di archiviazione, che potrebbe interrompere potenzialmente le operazioni nel tuo ambiente.

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 a lunga esecuzione e esaminare l'impatto della durata dell'attività sullo stato finale, carica il secondo DAG di esempio nel tuo ambiente. In questo tutorial, questo DAG è denominato 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 del worker di Airflow.
2. Stampa la dimensione del file creato utilizzando il modulo os Python.
3. Attende 1 ora e 15 minuti per imitare 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.

Avviso: questo DAG simula un problema di esaurimento dello spazio di archiviazione, che potrebbe interrompere potenzialmente le operazioni nel tuo ambiente.

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 Trigger DAG.

4. Fai clic su Attiva.

5. Nella pagina DAG, fai clic sull'attività attivata ed esamina i log di output per assicurarti che l'esecuzione del DAG sia stata avviata.

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

   Nota: potresti notare che lo spazio di archiviazione worker di Airflow utilizzato è stato reimpostato su zero dopo il completamento dell'attività. Cloud Composer si basa su Autopilot di Google Kubernetes Engine che fornisce le risorse necessarie. La scalabilità automatica in Cloud Composer è basata su metriche e controlla l'allocazione delle risorse tramite la gestione dei pod GKE all'interno di una determinata quota.

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 delle attività Airflow:

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

   Vai ad Ambienti

   1. Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Dettagli ambiente.

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

   3. Filtra i log per tipo: mostra solo i messaggi di errore.

Nei log verranno visualizzati 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 a caldo" perché lo spazio di archiviazione utilizzato ha superato il limite ed è stato rimosso entro un'ora. Tuttavia, l'esecuzione del DAG non ha avuto esito negativo perché è stata completata entro il periodo di tolleranza per la terminazione di Kubernetes, che è spiegato più dettagliatamente 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 Trigger DAG.

4. Fai clic su Attiva.

5. Nella pagina DAG, fai clic sull'attività attivata ed esamina i log di output per assicurarti che l'esecuzione del DAG sia stata avviata.

6. Attendi fino a quando l'esecuzione del DAG long_running_create_large_txt_file_print_logs non va a buon fine. L'operazione richiederà circa un'ora.

Esamina i risultati dell'esecuzione dei DAG:

1. Nella pagina DAG, fai clic su long_running_create_large_txt_file_print_logs Esecuzione del DAG. Vedrai che l'attività ha uno stato Failed e la durata dell'esecuzione è stata esattamente di 1 ora e 5 minuti, 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 stampa che il DAG è stato avviato in 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 la dimensione del file localfile.txt sarà di 1,5 GB.

Una volta che il file scritto nel container del worker di Airflow supera il limite di spazio di archiviazione, l'esecuzione del DAG dovrebbe non riuscire. Tuttavia, l'attività non fallisce immediatamente e continua a essere eseguita fino a quando la sua durata non raggiunge un'ora e 5 minuti. Questo accade perché Kubernetes non termina immediatamente l'attività e continua a essere in esecuzione per consentire un tempo di ripristino di un'ora, noto come "periodo di tolleranza di chiusura". Quando un nodo esaurisce le risorse, Kubernetes non termina immediatamente il pod per gestire agevolmente la terminazione, riducendo al minimo l'impatto sull'utente finale.

Il periodo di tolleranza per la terminazione consente agli utenti di recuperare i file in seguito a errori delle attività; tuttavia, può creare confusione durante la diagnosi dei DAG. Quando viene superato il limite di spazio di archiviazione dei worker di 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 un'ora, l'attività viene completata con lo stato Success perché è stata completata entro il periodo di tolleranza per il termine. 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 in esecuzione per un'ora e può superare il limite di archiviazione per migliaia di percento prima che Kubernetes elimini il pod e Airflow contrassegni l'attività come Failed.

Nota: se attivi uno dei DAG di esempio che superano il limite di spazio di archiviazione contemporaneamente con qualsiasi altro DAG di esempio, vedrai che se una delle attività supera il limite di archiviazione e non riesce, anche tutte le altre attività in esecuzione avranno esito negativo, anche se non richiedono spazio di archiviazione.

Diagnosi del DAG non riuscito

Se eseguivi più attività al momento dell'errore, valuta la possibilità di eseguire una sola attività e di eseguire la diagnostica delle risorse durante questo periodo per identificare le attività che causano pressione e quali di conseguenza 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 dell'ambiente. Si apre la pagina Dettagli ambiente.

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

4. Filtra i log per tipo: mostra solo i messaggi di errore.

Nei log verranno visualizzati 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à procedeva, i log di Airflow hanno iniziato a stampare errori quando la dimensione dei file generati dal DAG ha superato il limite di archiviazione del worker e il periodo di tolleranza per la terminazione è iniziato. Durante il periodo di tolleranza per il termine, il consumo dello spazio di archiviazione non è tornato al limite, il che ha portato all'eliminazione dei 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 dell'ambiente. Si apre la pagina Dettagli ambiente.

3. Vai alla scheda Monitoring e seleziona Panoramica.

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

5. Seleziona Worker e trova il grafico Utilizzo totale del disco dei worker. Osserva che la riga Utilizzo del disco ha un picco e supera la riga Limite del disco nel momento in cui l'attività era in esecuzione.

Figura 2. Grafico di utilizzo totale del disco dei worker (fai clic per ingrandire)

Aumenta il limite di spazio di archiviazione del worker

Nota: la modifica dello spazio di archiviazione dei worker riavvia i worker di Airflow, che potrebbe influire sulle attività in esecuzione. Ti consigliamo di farlo quando non sono in esecuzione DAG.

Alloca ulteriore spazio di archiviazione worker Airflow affinché il DAG di esempio abbia successo:

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

   Vai ad Ambienti

2. Nell'elenco degli ambienti, fai clic sul nome dell'ambiente. Si apre la pagina Dettagli ambiente.

3. Vai alla scheda Configurazione dell'ambiente.

4. Trova la configurazione Risorse > Carichi di lavoro e fai clic su Modifica.

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

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

Testa il tuo DAG con il nuovo limite di spazio di archiviazione

Attiva di nuovo il DAG long_running_create_large_txt_file_print_logs 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 (Operazione riuscita), con una durata di 1 ora e 15 minuti, che equivale al tempo di attesa impostato nel codice DAG.

2. Esamina la sezione Panoramica dell'ambiente nella scheda Monitoring e assicurati che non siano presenti aree rosse.

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

Riepilogo

In questo tutorial hai diagnosticato il motivo di un errore del DAG e identificato il tipo di risorsa che causa pressione eseguendo il debug di due DAG di esempio che non riescono a causa della mancanza di memoria e archiviazione dei worker. Hai quindi eseguito i DAG correttamente dopo aver allocato più memoria e spazio di archiviazione ai worker. Tuttavia, ti consigliamo di ottimizzare i DAG (flussi di lavoro) per ridurre il consumo di risorse dei worker in primo luogo, 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

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Elimina singole risorse

Se prevedi di esplorare più tutorial e guide rapide, riutilizzare i progetti può aiutarti a evitare di superare i limiti di quota.

Eliminare l'ambiente Cloud Composer. Puoi anche eliminare il bucket dell'ambiente durante questa procedura.

Passaggi successivi

• Ambienti di scalabilità
• Risoluzione dei problemi dei DAG