Problemi noti

Managed Airflow (3ª gen.) | Managed Airflow (2ª gen.) | Managed Airflow (legacy, 1ª gen.)

In questa pagina sono elencati i problemi noti di Managed Airflow. Per informazioni sulle correzioni dei problemi, consulta le note di rilascio.

La prima esecuzione del DAG per un file DAG caricato presenta diverse attività non riuscite

Quando carichi un file DAG, a volte le prime attività della prima esecuzione del DAG non vanno a buon fine e viene visualizzato l'errore Unable to read remote log.... Questo problema si verifica perché il file DAG viene sincronizzato tra il bucket dell'ambiente, i worker Airflow e gli scheduler Airflow dell'ambiente. Se lo scheduler riceve il file DAG e ne pianifica l'esecuzione da parte di un worker, ma quest'ultimo non ha ancora il file DAG, l'esecuzione dell'attività non va a buon fine.

Per mitigare questo problema, gli ambienti con Airflow 2 sono configurati per eseguire due nuovi tentativi per un'attività non riuscita per impostazione predefinita. Se un'attività non va a buon fine, viene ripetuta due volte a intervalli di 5 minuti.

Managed Airflow non dovrebbe essere interessato dalla vulnerabilità di Apache Log4j 2 (CVE-2021-44228)

In risposta alla vulnerabilità Apache Log4j 2 (CVE-2021-44228), Managed Airflow ha condotto un'indagine dettagliata e riteniamo che Managed Airflow non sia vulnerabile a questo exploit.

A volte l'interfaccia utente di Airflow potrebbe non ricaricare un plug-in dopo che è stato modificato

Se un plug-in è composto da molti file che importano altri moduli, l'interfaccia utente di Airflow potrebbe non essere in grado di riconoscere che un plug-in deve essere ricaricato. In questo caso, riavvia il server web Airflow del tuo ambiente.

Errore 504 durante l'accesso all'interfaccia utente di Airflow

Puoi ricevere l'errore 504 Gateway Timeout quando accedi all'interfaccia utente di Airflow. Questo errore può avere diverse cause:

  • Problema di comunicazione temporaneo. In questo caso, prova ad accedere all'interfaccia utente di Airflow in un secondo momento. Puoi anche riavviare il server web Airflow.

  • (Solo Managed Airflow (Gen 3)) Problema di connettività. Se la UI di Airflow non è disponibile in modo permanente e vengono generati errori di timeout o 504, assicurati che il tuo ambiente possa accedere a *.composer.googleusercontent.com.

  • (Solo Managed Airflow (2ª gen.)) Problema di connettività. Se la UI di Airflow non è disponibile in modo permanente e vengono generati errori di timeout o 504, assicurati che il tuo ambiente possa accedere a *.composer.cloud.google.com. Se utilizzi l'accesso privato Google e invii traffico su IP virtuali private.googleapis.com o Controlli di servizio VPC e invii traffico su IP virtuali restricted.googleapis.com, assicurati che Cloud DNS sia configurato anche per i nomi di dominio *.composer.cloud.google.com.

  • Server web Airflow non reattivo. Se l'errore 504 persiste, ma riesci comunque ad accedere all'interfaccia utente di Airflow in determinati momenti, è possibile che il server web Airflow non risponda perché è sovraccarico. Prova ad aumentare i parametri di scalabilità e prestazioni del server web.

Errore 502 durante l'accesso alla UI di Airflow

L'errore 502 Internal server exception indica che l'interfaccia utente di Airflow non può gestire le richieste in entrata. Questo errore può avere diverse cause:

  • Problema di comunicazione temporaneo. Prova ad accedere all'interfaccia utente di Airflow più tardi.

  • Impossibile avviare il server web. Per l'avvio, il server web richiede prima la sincronizzazione dei file di configurazione. Controlla i log del server web per individuare voci di log simili a: GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/airflow.cfg /home/airflow/gcs/airflow.cfg.tmp o GCS sync exited with 1: gcloud storage cp gs://<bucket-name>/env_var.json.cfg /home/airflow/gcs/env_var.json.tmp. Se trovi questi messaggi di errore, controlla se i file menzionati nei messaggi di errore sono ancora presenti nel bucket dell'ambiente.

    In caso di rimozione accidentale (ad esempio, perché è stata configurata una policy di conservazione), puoi ripristinarli:

    1. Imposta una nuova variabile di ambiente nel tuo ambiente. Puoi utilizzare qualsiasi nome e valore di variabile.

    2. Esegui l'override di un'opzione di configurazione di Airflow. Puoi utilizzare un'opzione di configurazione di Airflow non esistente.

Errore 500 durante l'accesso alla UI di Airflow dopo l'override di [webserver]analytics_tool

Negli ambienti con Airflow 2, se esegui l'override dell'opzione di configurazione di Airflow [webserver]analytics_tool per instradare i dati anonimi sull'utilizzo dell'interfaccia utente di Airflow a un servizio di analisi (come Google Analytics, Segment, MetaRouter o Matomo), l'accesso all'interfaccia utente di Airflow dopo l'aggiornamento dell'ambiente potrebbe restituire una risposta (500) Internal Server Error, con uno dei seguenti errori nei log del server web Airflow:

airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_id] not found in config
airflow.exceptions.AirflowConfigException: section/key [webserver/analytics_url] not found in config

Quando [webserver]analytics_tool è impostato in Airflow 2, il server web Airflow richiede che anche le opzioni di analisi complementari nella sezione [webserver] siano definite durante il rendering della UI di Airflow.

In Airflow 3, le opzioni di configurazione [webserver]analytics_tool, [webserver]analytics_id e [webserver]analytics_url sono state rimosse.

Soluzioni:

  • Rimuovi l'override per l'opzione di configurazione di Airflow [webserver]analytics_tool oppure
  • Specifica tutte le opzioni di configurazione di Airflow richieste insieme:
    • [webserver]analytics_tool
    • [webserver]analytics_id
    • [webserver]analytics_url (obbligatorio in Airflow 2.9 e versioni successive, anche se lo strumento di analisi non utilizza un URL personalizzato)

Il passaggio del mouse sopra l'istanza dell'attività nella visualizzazione ad albero genera un TypeError non rilevato

In Airflow 2, la visualizzazione ad albero nell'interfaccia utente di Airflow potrebbe non funzionare correttamente se viene utilizzato un fuso orario non predefinito. Per risolvere questo problema, configura esplicitamente il fuso orario nell'interfaccia utente di Airflow.

Cartelle vuote in Scheduler e Worker

Managed Airflow non rimuove attivamente le cartelle vuote dai worker e dagli scheduler di Airflow. Queste entità potrebbero essere create come risultato del processo di sincronizzazione del bucket dell'ambiente quando queste cartelle esistevano nel bucket e sono state rimosse.

Suggerimento: modifica i DAG in modo che siano pronti a saltare queste cartelle vuote.

Queste entità vengono infine rimosse dagli spazi di archiviazione locali degli scheduler e dei worker Airflow quando questi componenti vengono riavviati (ad esempio, in seguito a operazioni di scale down o manutenzione nel cluster dell'ambiente).

Supporto per Kerberos

Managed Airflow non supporta la configurazione di Airflow Kerberos.

Supporto delle classi di computing in Managed Airflow (Gen 2) e Managed Airflow (Gen 3)

Managed Airflow (Gen 3) e Managed Airflow (Gen 2) supportano solo la classe di computing per uso generico. Ciò significa che non è possibile eseguire pod che richiedono altre classi di computing (come Balanced o Scale-Out).

La classe per uso generico consente di eseguire pod che richiedono fino a 110 GB di memoria e fino a 30 CPU (come descritto in Richieste massime per la classe di computing.

Se vuoi utilizzare un'architettura basata su ARM o hai bisogno di più CPU e memoria, devi utilizzare una classe di computing diversa, che non è supportata nei cluster Managed Airflow (Gen 3) e Managed Airflow (Gen 2).

Suggerimento: utilizza GKEStartPodOperator per eseguire i pod Kubernetes su un cluster diverso che supporti la classe di computing selezionata. Se esegui pod personalizzati che richiedono una classe di computing diversa, anche questi devono essere eseguiti su un cluster Managed Airflow non gestito.

Non è possibile ridurre lo spazio di archiviazione di Cloud SQL

Managed Airflow utilizza Cloud SQL per eseguire il database Airflow. Nel tempo, lo spazio di archiviazione su disco per l'istanza Cloud SQL potrebbe aumentare perché il disco viene scalato per adattarsi ai dati archiviati dalle operazioni di Cloud SQL quando il database Airflow cresce.

Non è possibile fare lo scale down delle dimensioni del disco di Cloud SQL.

Come soluzione alternativa, se vuoi utilizzare le dimensioni più piccole del disco di Cloud SQL, puoi ricreare gli ambienti Managed Airflow con gli snapshot.

La metrica Utilizzo disco del database non diminuisce dopo la rimozione dei record da Cloud SQL

I database relazionali, come Postgres o MySQL, non rimuovono fisicamente le righe quando vengono eliminate o aggiornate. Invece, le contrassegna come "tuple inattive" per mantenere la coerenza dei dati ed evitare di bloccare le transazioni simultanee.

Sia MySQL che Postgres implementano meccanismi di recupero dello spazio dopo l'eliminazione dei record.

Sebbene sia possibile forzare il database a recuperare lo spazio su disco inutilizzato, si tratta di un'operazione che richiede molte risorse e che blocca anche il database, rendendo Managed Airflow non disponibile. Pertanto, ti consigliamo di fare affidamento sui meccanismi di creazione per recuperare lo spazio inutilizzato.

Accesso bloccato: errore di autorizzazione

Se questo problema riguarda un utente, la finestra di dialogo Accesso bloccato: errore di autorizzazione contiene il messaggio Error 400: admin_policy_enforced.

Se l'opzione Controlli API > App di terze parti non configurate > Non consentire agli utenti di accedere alle app di terze parti è attivata in Google Workspace e l'app Apache Airflow in Managed Airflow non è consentita esplicitamente, gli utenti non possono accedere all'interfaccia utente di Airflow, a meno che non consentano esplicitamente l'applicazione.

Per consentire l'accesso, segui i passaggi descritti in Consenti l'accesso all'interfaccia utente di Airflow in Google Workspace.

Loop di accesso durante l'accesso alla UI di Airflow

Questo problema potrebbe essere dovuto alle seguenti cause:

La cartella /data non è disponibile nel server web Airflow

In Managed Airflow (Gen 2) e Managed Airflow (Gen 3), il server web Airflow è un componente di sola lettura e Managed Airflow non sincronizza la cartella data/ con questo componente.

A volte, potresti voler condividere file comuni tra tutti i componenti Airflow, incluso il server web Airflow.

Soluzione:

  • Inserisci i file da condividere con il server web in un modulo PYPI e installalo come un normale pacchetto PYPI. Dopo aver installato il modulo PyPI nell'ambiente, i file vengono aggiunti alle immagini dei componenti Airflow e sono disponibili per questi ultimi.

  • Aggiungi file alla cartella plugins/. Questa cartella è sincronizzata con il server web Airflow.

Diagrammi non continui dei tempi di analisi dei DAG e delle dimensioni del DAG bag nel monitoraggio

I diagrammi non continui dei tempi di analisi dei DAG e delle dimensioni del DAG bag nella dashboard di monitoraggio indicano problemi con tempi di analisi dei DAG lunghi (più di 5 minuti).

Grafici dei tempi di analisi dei DAG Airflow e delle dimensioni del DAG bag che mostrano una serie di intervalli non continui
Figura 1. Grafici dei tempi di analisi dei DAG non continui e delle dimensioni del DAG bag (fai clic per ingrandire)

Soluzione: ti consigliamo di mantenere il tempo totale di analisi del DAG al di sotto dei 5 minuti. Per ridurre il tempo di analisi del DAG, segui le linee guida per la scrittura dei DAG.

I log delle attività vengono visualizzati con ritardi

Sintomo:

  • In Managed Airflow (Gen 3), i log delle attività di Airflow non vengono visualizzati immediatamente e sono ritardati di alcuni minuti.
  • Potresti trovare Logs not found for Cloud Logging filter messaggi nei log di Airflow

Causa:

Se il tuo ambiente esegue un numero elevato di attività contemporaneamente, i log delle attività possono subire ritardi perché le dimensioni dell'infrastruttura dell'ambiente non sono sufficienti per elaborare tutti i log abbastanza rapidamente.

Soluzioni:

  • Valuta la possibilità di aumentare le dimensioni dell'infrastruttura dell'ambiente per migliorare le prestazioni.
  • Distribuisci le esecuzioni dei DAG nel tempo, in modo che le attività non vengano eseguite contemporaneamente.

Tempi di avvio più lunghi per KubernetesPodOperator e KubernetesExecutor

I pod creati con KubernetesPodOperator e le attività eseguite con KubernetesExecutor registrano tempi di avvio più lunghi. Il team di Managed Airflow sta lavorando a una soluzione e annuncerà quando il problema sarà risolto.

Soluzioni temporanee:

  • Avvia i pod con più CPU.
  • Se possibile, ottimizza le immagini (meno livelli, dimensioni inferiori).

L'ambiente è nello stato di errore dopo l'eliminazione o la disattivazione dell'account di fatturazione del progetto o la disattivazione dell'API Cloud Composer

Gli ambienti Managed Airflow interessati da questi problemi non sono recuperabili:

  • Dopo l'eliminazione o la disattivazione dell'account di fatturazione del progetto, anche se in un secondo momento è stato collegato un altro account.
  • Dopo che l'API Cloud Composer è stata disabilitata nel progetto, anche se è stata abilitata in un secondo momento.

Per risolvere il problema, puoi procedere nel seguente modo:

  • Puoi comunque accedere ai dati archiviati nei bucket dell'ambiente, ma gli ambienti stessi non sono più utilizzabili. Puoi creare un nuovo ambiente Managed Airflow e poi trasferire i DAG e i dati.

  • Se vuoi eseguire una delle operazioni che rendono gli ambienti non recuperabili, assicurati di eseguire il backup dei dati, ad esempio creando uno snapshot di un ambiente. In questo modo, puoi creare un altro ambiente e trasferire i relativi dati caricando questo snapshot.

I log per le attività Airflow non vengono raccolti se [core]execute_tasks_new_python_interpreter è impostato su True

Managed Airflow non raccoglie i log per le attività Airflow se l'opzione di configurazione Airflow [core]execute_tasks_new_python_interpreter è impostata su True.

Possibile soluzione:

  • Rimuovi l'override per questa opzione di configurazione o imposta il relativo valore su False.

Errore durante la rimozione del collegamento di rete quando viene eliminato un ambiente

Se vengono eliminati contemporaneamente più ambienti che condividono lo stesso collegamento di rete, alcune operazioni di eliminazione non vanno a buon fine e viene generato un errore.

Sintomi:

Viene generato il seguente errore:

Got error while removing Network Attachment: <error code>

Il codice di errore segnalato può essere Bad request: <resource> is not ready o Precondition failed: Invalid fingerprint.

Possibili soluzioni alternative:

  • Elimina uno alla volta gli ambienti che utilizzano lo stesso collegamento di rete.

  • Disattiva la connessione a una rete VPC per i tuoi ambienti prima di eliminarli. Ti consigliamo questa soluzione alternativa per l'eliminazione automatica dell'ambiente.

Prestazioni dell'ambiente ridotte in diverse versioni del pacchetto google-api-core

Versioni dalla 2.28.0 alla 2.30.2

Le versioni del pacchetto preinstallato google-api-core dalla 2.28.0 alla 2.30.2 potrebbero causare un peggioramento delle prestazioni dell'ambiente, il che può comportare tempi più lunghi per l'esecuzione di un'attività e per lo spostamento di un'attività dallo stato in coda allo stato in esecuzione.

Build di Managed Airflow (3ª gen.) interessate:

  • Da composer-3-airflow-3.1.7-build.0 a composer-3-airflow-3.1.7-build.5
  • Da composer-3-airflow-3.1.0-build.5 a composer-3-airflow-3.1.0-build.10
  • composer-3-airflow-2.11.1-build.0
  • Da composer-3-airflow-2.10.5-build.22 a composer-3-airflow-2.10.5-build.33
  • Da composer-3-airflow-2.9.3-build.42 a composer-3-airflow-2.9.3-build.53

Build di Managed Airflow (2ª gen.) interessate:

  • composer-2.16.10-airflow-2.11.1
  • Da composer-2.16.0-airflow-2.10.5 a composer-2.16.10-airflow-2.10.5
  • Da composer-2.16.0-airflow-2.9.3 a composer-2.16.10-airflow-2.9.3

Esegui l'upgrade dell'ambiente a una delle seguenti build, che includono google-api-core versione 2.27.0 preinstallata e non sono interessate da questo problema:

  • composer-3-airflow-2.11.1-build.1
  • composer-3-airflow-2.10.5-build.34
  • composer-3-airflow-2.9.3-build.54
  • composer-2.16.11-airflow-2.11.1
  • composer-2.16.11-airflow-2.10.5
  • composer-2.16.11-airflow-2.9.3

In alternativa, esegui l'upgrade a un'immagine che includa google-api-core 2.43.1 o versioni successive oppure installa manualmente una versione compatibile.

In Python 3.11, le versioni di google-api-core dalla 2.30.3 alla 2.43.0 causano un problema di prestazioni separato a partire dal 24 ottobre 2026. Se il tuo ambiente esegue Python 3.11, applica una delle soluzioni alternative elencate in Versioni dalla 2.30.3 alla 2.43.0 su Python 3.11.

Versioni dalla 2.30.3 alla 2.43.0 su Python 3.11

A partire dal 24 ottobre 2026, le versioni del pacchetto google-api-core dalla 2.30.3 alla 2.43.0 eseguono un controllo di ritiro di Python 3.11 che analizza i metadati del pacchetto installato ogni volta che una libreria client Google Cloud viene importata in un nuovo sottoprocesso Python.

Negli ambienti Managed Airflow che eseguono Python 3.11, questo comportamento può ridurre le prestazioni. Questo problema è più grave negli ambienti con molti DAG, attività frequenti di breve durata o integrazione della derivazione dei dati abilitata.

I sintomi includono:

  • Tempi di analisi dei DAG più lunghi e utilizzo della CPU più elevato sui processori DAG di Airflow.
  • Tempi di esecuzione delle attività più lunghi e utilizzo della CPU più elevato sui worker di Airflow.
  • Voci di log FutureWarning frequenti da google/api_core/_python_version_support.py che indicano che il supporto di Python 3.11 termina il 24/10/2027.

Questo problema interessa qualsiasi ambiente Python 3.11 in cui la versione di google-api-core dalla 2.30.3 alla 2.43.0 è preinstallata o installata manualmente, incluse le build seguenti.

Questo problema interessa le seguenti build di Managed Airflow (Gen 3):

  • Da composer-3-airflow-3.3.1-build.0 a composer-3-airflow-3.3.1-build.5
  • Da composer-3-airflow-3.2.2-build.0 a composer-3-airflow-3.2.2-build.9
  • Da composer-3-airflow-3.1.8-build.0 a composer-3-airflow-3.1.8-build.4
  • Da composer-3-airflow-3.1.7-build.7 a composer-3-airflow-3.1.7-build.13
  • Da composer-3-airflow-2.11.1-build.3 a composer-3-airflow-2.11.1-build.22
  • Da composer-3-airflow-2.10.5-build.36 a composer-3-airflow-2.10.5-build.52

Build di Managed Airflow (2ª gen.) interessate:

  • Da composer-2.17.0-airflow-2.11.1 a composer-2.17.16-airflow-2.11.1
  • Da composer-2.17.0-airflow-2.10.5 a composer-2.17.13-airflow-2.10.5

Soluzioni:

Scegli una delle seguenti opzioni in base alla versione immagine del tuo ambiente:

  • Opzione 1. Build Managed Airflow (Gen 3) compatibili solo con Airflow 3: installa il pacchetto PyPI google-api-core con il vincolo di versione >=2.43.1.

    Build di Managed Airflow (3ª gen.) compatibili:

    • Da composer-3-airflow-3.3.1-build.0 a composer-3-airflow-3.3.1-build.5
    • Da composer-3-airflow-3.2.2-build.1 a composer-3-airflow-3.2.2-build.9
    • Da composer-3-airflow-3.1.8-build.3 a composer-3-airflow-3.1.8-build.4

    Non utilizzare questa opzione nelle build di Airflow 2 o Airflow 3 precedenti, tra cui composer-3-airflow-3.2.2-build.0 e da composer-3-airflow-3.1.8-build.0 a build.2. In queste build, google-api-core 2.43.1 causa conflitti di dipendenza perché richiede opentelemetry-api>=1.44.0. Per queste build, utilizza l'Opzione 2.

  • Opzione 2. Tutte le build di Managed Airflow (Gen 3) e Managed Airflow (Gen 2) interessate: applica una patch di runtime sitecustomize.py.

    1. Scarica sitecustomize.py da GitHub.

    2. Carica sitecustomize.py nella cartella dags/patches nel bucket del tuo ambiente.

    3. Imposta la variabile di ambiente PYTHONPATH su /home/airflow/gcs/dags/patches.

      Se PYTHONPATH è già impostato, anteponi /home/airflow/gcs/dags/patches: al valore esistente. Esempio: /home/airflow/gcs/dags/patches:PREVIOUS_PYTHONPATH_VALUE

    Pulizia dopo un upgrade: nelle prossime release di Managed Airflow, la versione 2.43.1 o successive del pacchetto google-api-core verrà preinstallata. Dopo aver eseguito l'upgrade a un'immagine con google-api-core 2.43.1 o versioni successive, puoi rimuovere l'override di PYTHONPATH ed eliminare dags/patches/sitecustomize.py.

TI non è più in stato di esecuzione e l'attività dovrebbe terminare, con errori Task Not Found in Airflow 3

Airflow 3 presenta due problemi relativi alla perdita dello stato delle attività da parte dello scheduler durante i riavvii dello scheduler:

  • Stato 409 Conflict: una race condition negli scheduler causa la pianificazione di istanze di attività duplicate (#59378, risolto in #60330).

    Questo problema è stato risolto in Airflow 3.2.2.

  • Errore 404 - Non trovato: i worker Airflow perdono traccia delle istanze delle attività durante un riavvio regolare del loop dello scheduler, che si verifica dopo che lo scheduler raggiunge [scheduler]num_runs. In questo modo, gli ID delle istanze delle attività esistenti vengono modificati e vengono generati errori 404 successivi da un worker che non è a conoscenza della modifica (#53140, #60330, risolto in #61631).

    Questo problema è stato risolto in Airflow 3.3.1.

Sintomi

  • 409 Conflict: lo stato di pulizia degli elementi orfani di uno scheduler riavviato contrassegna le attività attive come FAILED, causando l'interruzione anomala dei worker:

    Server indicated the task shouldn't be running anymore [supervisor]
    detail={'detail': {'reason': 'not_running', 'message': 'TI is no longer in
    the running state and task should terminate', 'current_state': 'scheduled'}} status_code=409 ti_id=UUID('...')
    
  • 404 - Non trovato: uno scheduler riavviato perde gli stati delle attività e non supera i controlli di attività dei worker attivi:

    Server indicated the task shouldn't be running anymore [detail={'detail':
    {'reason': 'not_found', 'message': 'Task Instance not found'}}]
    [status_code=404] [ti_id=...]
    

Soluzione:

  • Entrambi i problemi sono stati risolti in Airflow versione 3.3.1 e successive. Esegui l'upgrade dell'ambiente a una versione che utilizza Airflow 3.3.1.

Possibili soluzioni alternative:

  • Non è possibile mitigare completamente il problema nelle versioni di Airflow precedenti alla 3.3.1. Qualsiasi evento esterno che causa il riavvio imprevisto di un singolo scheduler attiverà gli errori 404 e 409 (nelle versioni di Airflow precedenti alla 3.2.2). Esempi di questi eventi sono gli upgrade automatici dei nodi nel cluster dell'ambiente, le condizioni di memoria esaurita nei pod o l'elevato consumo di memoria e CPU da parte degli scheduler.

  • Se riduci l'ambiente a un solo scheduler e imposti l'opzione di configurazione [scheduler]num_runs su -1, riduci la causa delle race condition negli scheduler.

    Per un ambiente ad alta resilienza (alta affidabilità), non è possibile ridurre il numero di scheduler a uno. Puoi comunque impostare [scheduler]num_runs su -1.

  • Assicurati che il consumo di memoria e CPU da parte dello scheduler rientri ampiamente nei limiti delle risorse disponibili.

Passaggi successivi