Questo tutorial fornisce i passaggi per eseguire il debug di un DAG Airflow non riuscito in Managed Airflow e diagnosticare i problemi relativi alle risorse dei 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 task 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 riescono 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 del worker allocate
Testa i DAG con nuovi limiti delle risorse
Costi
Questo tutorial utilizza i seguenti componenti fatturabili di Cloud de Confiance by S3NS:
Al termine di questo tutorial, puoi evitare l'addebito di ulteriori costi eliminando le risorse create. Per maggiori dettagli, vedi Liberare spazio.
Prima di iniziare
Questa sezione descrive le azioni richieste prima di iniziare il tutorial.
Creare e configurare un progetto
Per questo tutorial, è necessario un Cloud de Confiance by S3NS progetto. Configura il progetto nel seguente modo:
Nella console Cloud de Confiance , seleziona o crea un progetto:
Verifica che la fatturazione sia attivata per il tuo progetto. Scopri come verificare se la fatturazione è abilitata per un progetto.
Assicurati che l'utente del Cloud de Confiance by S3NS progetto disponga dei seguenti ruoli per creare le risorse necessarie:
- Environment and Storage Object Administrator
(
roles/composer.environmentAndStorageObjectAdmin) - Compute Admin (
roles/compute.admin) - Editor Monitoring (
roles/monitoring.editor)
- Environment and Storage Object Administrator
(
Abilitare le API per il progetto
Abilita l'API Managed Airflow, se non è già abilitata.
Ruoli richiesti per abilitare le API
Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable. Se hai creato il progetto, probabilmente disponi già di questa autorizzazione tramite il ruolo Proprietario (roles/owner). In caso contrario, puoi ottenere questa autorizzazione tramite il ruolo Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin). Scopri come concedere i ruoli.
Crea l'ambiente Managed Airflow
Crea un ambiente Managed Airflow (Gen 2).
Durante la creazione dell'ambiente,
concedi il ruolo Cloud Composer v2 API Service Agent Extension
(roles/composer.ServiceAgentV2Ext) al service agent Composer. Managed Airflow utilizza questo account per eseguire operazioni
nel tuo progetto Cloud de Confiance by S3NS .
Controllare i limiti delle risorse del worker
Controlla i limiti delle risorse dei worker Airflow nel tuo ambiente:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.
Vai alla scheda Configurazione dell'ambiente.
Vai a Risorse > Configurazione dei workload > Worker.
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:
- Crea un elenco vuoto
s. - Esegue un ciclo per aggiungere la stringa
Moreall'elenco. - 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=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:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nella colonna Server web Airflow, segui il link Airflow per il tuo ambiente.
Nell'interfaccia utente di Airflow, nella pagina DAG, fai clic sul pulsante Attiva DAG per il tuo DAG.
Fai clic su Trigger.
Nella pagina DAG, fai clic sull'attività che hai attivato ed esamina i log di output per assicurarti che il DAG sia stato avviato.
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 riuscirà perché supera il limite di memoria del worker Airflow di 1,875 GB.
Diagnostica il 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 questo 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.
Esamina i workload
Esamina i workload per verificare che il carico dell'attività non superi il limite di consumo di memoria del nodo in cui viene eseguito il pod:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.
Vai alla scheda Configurazione dell'ambiente.
In Risorse > Cluster GKE > Workload, fai clic su Visualizza workload cluster.
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 issueExit code 137significa che un container o un pod sta tentando di utilizzare più memoria del consentito. Il processo viene terminato per evitare la memoria utilizzata.
Rivedi il monitoraggio dell'integrità dell'ambiente e del consumo di risorse
Esamina il monitoraggio dell'integrità dell'ambiente e del consumo di risorse:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.
Vai alla scheda Monitoraggio e seleziona Panoramica.
Nel riquadro Panoramica 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.
Seleziona Worker e trova il grafico Utilizzo totale memoria worker. Nota che la riga Memoria utilizzata presenta un picco nel momento in cui l'attività era in esecuzione.
Anche se la linea di memoria utilizzata sul grafico non raggiunge il limite, quando diagnostichi i motivi dell'errore, devi tenere conto della memoria utilizzata dai 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 effettivamente disponibile, l'attività eseguita può non riuscire a causa di memoria insufficiente. In questi casi, puoi osservare errori delle attività anche se la linea nel grafico della memoria utilizzata totale dei worker non raggiunge il limite di memoria.
Aumentare il limite di memoria del worker
Alloca memoria worker aggiuntiva per consentire l'esecuzione del DAG di esempio:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.
Vai alla scheda Configurazione dell'ambiente.
Trova la configurazione Risorse > Workloads e fai clic su Modifica.
Nella sezione Worker, nel campo Memoria, specifica il nuovo limite di memoria per i worker Airflow. In questo tutorial, utilizza 3 GB.
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.
Nei log di output dell'esecuzione del DAG, vedrai
Marking task as SUCCESSe lo stato dell'attività indicherà Success.Esamina la sezione Panoramica dell'ambiente nella scheda Monitoraggio e assicurati che non ci siano aree rosse.
Fai clic sulla sezione Worker e individua il grafico Utilizzo totale memoria worker. Vedrai che la linea Limite di memoria riflette la modifica del limite di memoria e la linea Memoria utilizzata è molto al di sotto del limite di memoria allocabile effettivo.
Esempio: diagnosticare i 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 simula un'operazione a lunga esecuzione.
La dimensione del file in entrambi i DAG supera il limite predefinito di 1 GB dello spazio di archiviazione dei worker 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.
Caricare 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:
- Scrive un file
localfile.txtda 1,5 GB nello spazio di archiviazione worker di Airflow. - Stampa le dimensioni del file creato utilizzando il modulo Python
os. - 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=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:
- Scrive un file
localfile.txtda 1,5 GB nello spazio di archiviazione worker di Airflow. - Stampa le dimensioni del file creato utilizzando il modulo Python
os. - Attende 1 ora e 15 minuti per simulare il tempo necessario per le operazioni con il file, ad esempio la lettura.
- 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=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:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nella colonna Server web Airflow, segui il link Airflow per il tuo ambiente.
Nell'interfaccia utente di Airflow, nella pagina DAG, fai clic sul pulsante Attiva DAG per il tuo DAG.
Fai clic su Trigger.
Nella pagina DAG, fai clic sull'attività che hai attivato ed esamina i log di output per assicurarti che il DAG sia stato avviato.
Attendi il completamento dell'attività creata con il DAG
create_large_txt_file_print_logs. L'operazione potrebbe richiedere alcuni minuti.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 dell'attività:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.
Vai alla scheda Log, quindi vai a Tutti i log > Log di Airflow > Worker > Visualizza in Esplora log.
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 la procedura 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 tolleranza di terminazione 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:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nella colonna Server web Airflow, segui il link Airflow per il tuo ambiente.
Nell'interfaccia utente di Airflow, nella pagina DAG, fai clic sul pulsante Attiva DAG per il tuo DAG.
Fai clic su Trigger.
Nella pagina DAG, fai clic sull'attività che hai attivato ed esamina i log di output per assicurarti che il DAG sia stato avviato.
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:
Nella pagina DAG, fai clic sull'esecuzione DAG
long_running_create_large_txt_file_print_logs. Vedrai che l'attività ha lo statoFailede 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.Esamina i log dell'attività. Una volta che il DAG ha creato il file
localfile.txtnel 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 loglocalfile.txt size:e la dimensione del filelocalfile.txtsarà di 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 fino a quando 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
Successperché è 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.
Diagnostica il 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 questo 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:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.
Vai alla scheda Log, quindi vai a Tutti i log > Log di Airflow > Worker > Visualizza in Esplora log.
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 terminazione, 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 terminazione.
Esamina il monitoraggio dell'integrità dell'ambiente e del consumo di risorse:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.
Vai alla scheda Monitoraggio e seleziona Panoramica.
Nel riquadro Panoramica 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.
Seleziona Worker e trova il grafico Utilizzo totale disco worker. Osserva che la linea Utilizzo del disco presenta un picco e supera la linea Limite disco nel momento in cui è stato eseguito il task.
Aumentare il limite di spazio di archiviazione del lavoratore
Alloca spazio di archiviazione aggiuntivo per i worker Airflow affinché il DAG di esempio vada a buon fine:
Nella console Cloud de Confiance , vai alla pagina Ambienti.
Nell'elenco degli ambienti, fai clic sul nome del tuo ambiente. Viene visualizzata la pagina Dettagli ambiente.
Vai alla scheda Configurazione dell'ambiente.
Trova la configurazione Risorse > Workloads e fai clic su Modifica.
Nella sezione Worker, nel campo Archiviazione, specifica il nuovo limite di archiviazione per i worker Airflow. In questo tutorial, impostalo su 2 GB.
Salva le modifiche e attendi alcuni minuti per il riavvio dei worker Airflow.
Testare il 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.
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.Esamina la sezione Panoramica dell'ambiente nella scheda Monitoraggio e assicurati che non ci siano aree rosse.
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 innanzitutto 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 Cloud de Confiance by S3NS 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
- Nella console Cloud de Confiance , vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona quello che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID progetto, quindi fai clic su Chiudi per eliminare il progetto.
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 Managed Airflow. Durante questa procedura, elimini anche il bucket dell'ambiente.