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

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

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

Questo tutorial illustra 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 spazio di archiviazione dei worker, con l'aiuto dei log e del monitoraggio dell'ambiente.

Introduzione

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

La mancanza di risorse dei worker allocate causa errori nei DAG. Se un'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 dei worker Airflow o di 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 di DAG e identificare il tipo di risorsa che causa i problemi eseguendo il debug di due DAG di esempio che non funzionano a causa della mancanza di memoria e spazio di archiviazione dei worker.

Obiettivi

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

  • Mancanza di memoria del worker
  • Spazio di archiviazione insufficiente per i worker

• Diagnostica i motivi dell'errore

• Aumentare le risorse dei lavoratori allocate

• Testa i DAG con i nuovi limiti di risorse

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

• Cloud Composer (vedi costi aggiuntivi)
• Cloud Monitoring

Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per maggiori dettagli, consulta la sezione Pulizia.

Prima di iniziare

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

Creare e configurare un progetto

Per questo tutorial, hai bisogno di 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 è attivata per un progetto.

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

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

Abilita le API per il tuo progetto

Enable the Cloud Composer API.

Enable the API

Crea l'ambiente Cloud Composer

Crea un ambiente Cloud Composer 2.

Importante: assicurati di utilizzare l'ambiente preimpostato Piccolo per riprodurre gli errori quando utilizzi gli esempi forniti più avanti in questo tutorial. Si tratta del preset predefinito quando crei un ambiente tramite la console Google Cloud.

Durante la creazione dell'ambiente, devi concedere 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 Google Cloud progetto.

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 dell'ambiente. Viene visualizzata la pagina Dettagli dell'ambiente.

3. Vai alla scheda Configurazione dell'ambiente.

4. Vai a Risorse > Configurazione dei carichi di lavoro > 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 dei worker 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 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 accodare la stringa More all'elenco.
3. Stampa la quantità di memoria utilizzata dall'elenco e attende 1 secondo in ogni evoluzione di 1 minuto.

Avviso: questo DAG simula un problema di esaurimento della memoria, che può potenzialmente interrompere 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 Collegamenti per il DAG, fai clic sul pulsante Attiva DAG.

4. Fai clic su Attiva.

5. Nella pagina DAG, fai clic sull'attività che hai attivato ed esamina i log di output per assicurarti che il DAG abbia iniziato a funzionare.

Durante l'esecuzione dell'attività, i log di output stamperanno le dimensioni in GB della memoria 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.

Nota: se attivi il DAG che supera il limite di memoria contemporaneamente a qualsiasi altro DAG di esempio, noterai che, se una delle attività supera il limite di memoria e non va a buon fine, anche le altre attività in esecuzione non andranno a buon fine, anche se non consumano memoria.

Diagnostica il DAG non riuscito

Se al momento dell'errore erano in esecuzione più attività, ti consigliamo di eseguire solo un'attività e di diagnosticare la pressione sulle risorse durante questo periodo per identificare le attività che causano la pressione sulle risorse e le risorse che devi aumentare.

Esamina i log delle attività Airflow

Nota che l'attività del DAG create_list_with_many_strings ha un 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 workload

Esamina i carichi di lavoro per verificare che il carico dell'attività non causi il superamento del limite di consumo di memoria del nodo su 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 dell'ambiente. Viene visualizzata la pagina Dettagli dell'ambiente.

3. Vai alla scheda Configurazione dell'ambiente.

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

5. Controlla se alcuni dei pod del carico 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 tentando di utilizzare più memoria di quella consentita. Il processo viene terminato per evitare l'utilizzo della memoria.

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

Esamina 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. Viene visualizzata la pagina Dettagli dell'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 memoria worker. Nota che la riga Utilizzo della memoria presenta un picco al momento dell'esecuzione della task.

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 prendere in considerazione solo la memoria allocabile, mentre la linea Limite memoria sul grafico rappresenta la memoria totale disponibile (inclusa la capacità riservata da GKE).

In questo esempio, il limite di memoria del worker è impostato su 1,875 GB. GKE prenota il 25% dei primi 4 GB di memoria. GKE riserva inoltre un'altra soglia-espulsione: 100 MiB di memoria su ogni nodo per l'espulsione di kubelet.

La memoria allocatile 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 dell'utilizzo della memoria, vedrai che l'aumento dell'utilizzo della memoria della task raggiunge il limite di memoria effettivo e puoi concludere che l'attività non è riuscita a causa di una memoria del worker insufficiente.

Nota: se il livello di consumo di memoria aumenta troppo rapidamente, la riga relativa all'utilizzo della memoria potrebbe non rilevare correttamente il livello di consumo di risorse reale. Il DAG airflow_monitoring è un controllo di integrità di attivazione 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 di impostare avvisi quando l'ambiente non è più in stato di salute. Viene eseguito ogni 5 minuti e raccoglie le metriche, il che significa che potrebbe non acquisire l'utilizzo delle risorse tra un'esecuzione e l'altra.

Aumentare il limite di memoria del worker

Nota: la modifica della CPU o della memoria del worker ne comporta il riavvio, il che potrebbe influire sulle attività in esecuzione. Ti consigliamo di farlo quando non sono in esecuzione DAG.

Alloca memoria aggiuntiva per i worker 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. Viene visualizzata la pagina Dettagli dell'ambiente.

3. Vai alla scheda Configurazione dell'ambiente.

4. Individua 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 Airflow. In questo tutorial, utilizza 3 GB.

6. Salva le modifiche e attendi alcuni 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 il completamento dell'esecuzione.

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

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

3. Fai clic sulla sezione Worker e individua 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 allocato effettivo.

Esempio: diagnostica dei problemi di spazio di archiviazione esaurito

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 simula un'operazione di lunga durata.

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

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

Nota: i DAG in questo tutorial creano file locali. In un ambiente di produzione, evita di memorizzare file o configurazioni nel file system locale perché la prossima attività verrà probabilmente eseguita su un altro worker Airflow senza accesso al file.

Caricare un DAG che crea un file di grandi dimensioni

Carica il seguente DAG di esempio nell'ambiente 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 di 1,5 GB nello spazio di archiviazione del worker Airflow.
2. Stampa le dimensioni del file creato utilizzando il modulo Python os.
3. Stampa la durata dell'esecuzione del DAG ogni 1 minuto.

Avviso: questo DAG simula un problema di spazio di archiviazione insufficiente, che può potenzialmente interrompere 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 di lunga durata

Per simulare un DAG di lunga durata 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 di 1,5 GB nello spazio di archiviazione del worker 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.
4. Stampa la durata dell'esecuzione del DAG ogni 1 minuto.

Avviso: questo DAG simula un problema di spazio di archiviazione insufficiente, che può potenzialmente interrompere 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)

Attivare 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 Collegamenti per il DAG, fai clic sul pulsante Attiva DAG.

4. Fai clic su Attiva.

5. Nella pagina DAG, fai clic sull'attività che hai attivato ed esamina i log di output per assicurarti che il DAG abbia iniziato a funzionare.

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

   Nota: potresti notare che lo spazio di archiviazione dell'operatore Airflow utilizzato è stato reimpostato su zero al termine dell'attività. Cloud Composer si basa su Google Kubernetes Engine Autopilot che fornisce le risorse necessarie. La scalabilità automatica in Cloud Composer si basa 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 la tua attività ha lo stato Success, anche se il limite di spazio di archiviazione è stato superato.

Esamina i log di Airflow della task:

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

   Vai ad Ambienti

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

   2. Vai alla scheda Log, poi 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 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 caldo" perché lo spazio di archiviazione utilizzato ha superato il limite ed è stato eliminato in un'ora. Tuttavia, l'esecuzione del DAG non è andata a buon fine perché è stata completata entro il periodo di tolleranza per la chiusura di Kubernetes, che viene spiegato più dettagliatamente in questo tutorial.

Per illustrare il concetto del periodo di tolleranza per la risoluzione, 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 Collegamenti per il DAG, fai clic sul pulsante Attiva DAG.

4. Fai clic su Attiva.

5. Nella pagina DAG, fai clic sull'attività che hai attivato ed esamina i log di output per assicurarti che il DAG abbia iniziato a funzionare.

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

Esamina i risultati dell'esecuzione del DAG:

1. Nella pagina DAG, fai clic sulla long_running_create_large_txt_file_print_logs esecuzione del DAG. 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 contenuto del contenitore del worker di Airflow, il log stampa che il DAG ha iniziato a attendere e la durata dell'esecuzione viene stampata nei log delle attività ogni 1 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.

Quando il file scritto nel contenitore del worker Airflow supera il limite di spazio di archiviazione, l'esecuzione del DAG dovrebbe non riuscire. Tuttavia, l'attività non termina immediatamente e continua a essere eseguita fino a quando la sua durata non raggiunge 1 ora e 5 minuti. Questo accade perché Kubernetes non termina immediatamente l'attività e continua a eseguirla per consentire 1 ora di tempo di recupero, 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 corretto, in modo da avere un impatto minimo sull'utente finale.

Il periodo di tolleranza per l'interruzione consente agli utenti di recuperare i file dopo gli errori delle attività, ma può creare confusione durante la diagnostica dei DAG. Quando viene superato il limite di archiviazione del 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 la terminazione. Tuttavia, Kubernetes termina il pod e il file scritto viene eliminato immediatamente dal contenitore.

• Se il DAG supera il limite di spazio di archiviazione del worker ed è in esecuzione da più di un'ora, rimane in esecuzione per un'ora e può superare il limite di spazio 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 a un altro DAG di esempio, noterai che, se una delle attività supera il limite di spazio di archiviazione e non riesce, anche le altre attività in esecuzione non riusciranno, anche se non richiedono spazio di archiviazione.

Diagnostica il DAG non riuscito

Se al momento dell'errore erano in esecuzione più attività, ti consigliamo di eseguire solo un'attività e di diagnosticare la pressione sulle risorse durante questo periodo per identificare le attività che causano la pressione sulle risorse e le risorse che 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. Viene visualizzata la pagina Dettagli dell'ambiente.

3. Vai alla scheda Log, poi 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 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, con il progredire dell'attività, 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 la chiusura. Durante il periodo di tolleranza per la risoluzione del contratto, 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 risoluzione del contratto.

Esamina 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. Viene visualizzata la pagina Dettagli dell'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. Nota che la riga Utilizzo disco presenta un picco e supera la riga Limite disco al momento dell'esecuzione dell'attività.

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

Aumentare il limite di spazio di archiviazione dell'operatore

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

Alloca spazio di archiviazione aggiuntivo per i worker Airflow 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. Viene visualizzata la pagina Dettagli dell'ambiente.

3. Vai alla scheda Configurazione dell'ambiente.

4. Individua la configurazione Risorse > Carichi di lavoro 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.

Testa il DAG con il nuovo limite 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à Successo, con una durata di 1 ora e 15 minuti, pari al tempo di attesa impostato nel codice DAG.

2. Esamina la sezione Panoramica dell'ambiente nella scheda Monitoraggio e assicurati che non siano presenti 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 del DAG e identificato il tipo di risorsa che causa la 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 dei worker. Dopo aver allocato più memoria e spazio di archiviazione ai tuoi worker, hai eseguito correttamente i DAG. Tuttavia, è consigliabile ottimizzare i DAG (workflow) per ridurre il consumo di risorse dei worker, in quanto non è possibile aumentare le risorse oltre una determinata soglia.

Esegui la pulizia

Per evitare che al tuo Google Cloud account vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse o 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à descritte in questo documento, quando lo elimini elimini anche tutto il 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, il riuso dei progetti può aiutarti a non superare i limiti di quota.

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. Inoltre, durante questa procedura viene eliminato il bucket dell'ambiente.

Passaggi successivi

• Scala gli ambienti
• Risoluzione dei problemi dei DAG