Problemi noti

Managed Airflow (terza generazione) | Managed Airflow (seconda generazione) | Managed Airflow (prima generazione legacy)

Questa pagina elenca 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 di Airflow e gli scheduler di Airflow dell'ambiente. Se lo scheduler riceve il file DAG e ne pianifica l'esecuzione da parte di un worker e se il worker non ha ancora il file DAG, l'esecuzione dell'attività non va a buon fine.

Per attenuare 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 ritentata due volte con intervalli di 5 minuti.

Managed Airflow non dovrebbe essere interessato dalla vulnerabilità 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 soggetto a questo exploit.

A volte la UI di Airflow potrebbe non ricaricare un plug-in dopo la modifica

Se un plug-in è costituito da molti file che importano altri moduli, la UI di Airflow potrebbe non essere in grado di riconoscere il fatto che un plug-in deve essere ricaricato. In questo caso, riavvia il server web di Airflow del tuo ambiente.

Errore 504 durante l'accesso alla UI di Airflow

Quando accedi alla UI di Airflow, potresti ricevere l'errore 504 Gateway Timeout. Questo errore può avere diverse cause:

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

  • (Solo Managed Airflow di terza generazione) 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 (seconda generazione)) 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 il traffico tramite gli indirizzi IP virtuali private.googleapis.com o i Controlli di servizio VPC e invii il traffico tramite gli indirizzi IP virtuali restricted.googleapis.com, assicurati che Cloud DNS sia configurato anche per i nomi di dominio *.composer.cloud.google.com.

  • Server web di Airflow che non risponde. Se l'errore 504 persiste, ma puoi comunque accedere alla UI di Airflow in determinati momenti, il server web di Airflow potrebbe non rispondere 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 la UI di Airflow non può pubblicare le richieste in entrata. Questo errore può avere diverse cause:

  • Problema di comunicazione temporaneo. Prova ad accedere alla UI di Airflow in un secondo momento.

  • Impossibile avviare il server web. Per l'avvio, il server web richiede che i file di configurazione vengano sincronizzati per primi. Controlla i log del server web per 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 visualizzi questi errori, 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 inesistente.

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

In Airflow 2, la visualizzazione ad albero nella UI di Airflow a volte potrebbe non funzionare correttamente quando viene utilizzato un fuso orario non predefinito. Per risolvere questo problema, configura il fuso orario in modo esplicito nella UI 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.

Consiglio: modifica i DAG in modo che siano pronti a ignorare queste cartelle vuote.

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

Supporto di Kerberos

Managed Airflow non supporta la configurazione Kerberos di Airflow.

Supporto per le classi di calcolo in Managed Airflow (seconda generazione) e Managed Airflow (terza generazione)

Managed Airflow (terza generazione) e Managed Airflow (seconda generazione) supportano solo la classe di calcolo per uso generico . Ciò significa che non è possibile eseguire pod che richiedono altre classi di calcolo (ad esempio Bilanciata 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 della classe di calcolo.

Se vuoi utilizzare l'architettura basata su ARM o hai bisogno di più CPU e memoria, devi utilizzare una classe di calcolo diversa, che non è supportata nei cluster Airflow gestito (terza generazione) e Airflow gestito (seconda generazione).

Consiglio: utilizza GKEStartPodOperator per eseguire pod Kubernetes su un cluster diverso che supporta la classe di calcolo selezionata. Se esegui pod personalizzati che richiedono una classe di calcolo diversa, devono essere eseguiti anche su un cluster Airflow non gestito.

Non è possibile ridurre lo spazio di archiviazione di Cloud SQL

Airflow gestito 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 Cloud SQL quando il database Airflow aumenta.

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

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

La metrica Utilizzo del disco del database non si riduce 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. Al contrario, le contrassegnano come "tuple non valide" per mantenere la coerenza dei dati ed evitare di bloccare le transazioni simultanee.

Sia MySQL sia Postgres implementano meccanismi di recupero dello spazio dopo i record eliminati.

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 affidarti ai 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 ad app di terze parti è abilitata in Google Workspace e l'app Apache Airflow in Airflow gestito non è consentita in modo esplicito, gli utenti non possono accedere alla UI di Airflow a meno che non consentano esplicitamente l'applicazione.

Per consentire l'accesso, segui i passaggi descritti in Consentire l'accesso alla UI di Airflow in Google Workspace.

Ciclo di accesso durante l'accesso alla UI di Airflow

Questo problema potrebbe avere le seguenti cause:

La cartella /data non è disponibile nel server web di Airflow

In Managed Airflow (seconda generazione) e Managed Airflow (terza generazione), il server web di Airflow è progettato per essere un componente per lo più 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 di Airflow, incluso il server web di Airflow.

Soluzione:

  • Inserisci i file da condividere con il server web in un modulo PYPI e installalo come un normale pacchetto PYPI. Dopo l'installazione del modulo PYPI nell'ambiente, i file vengono aggiunti alle immagini dei componenti di Airflow e sono disponibili.

  • Aggiungi i file alla cartella plugins/. Questa cartella viene sincronizzata con il server web di 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 di Airflow e delle dimensioni del bag DAG che mostrano una serie di intervalli non continui
Figura 1. Grafici non continui dei tempi di analisi dei DAG e delle dimensioni del DAG bag (fai clic per ingrandire)

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

I log delle attività vengono visualizzati con ritardi

Sintomo:

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

Causa:

Se il tuo ambiente esegue un numero elevato di attività contemporaneamente, i log delle attività possono essere ritardati 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 aumentati per KubernetesPodOperator e KubernetesExecutor

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

Soluzioni:

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

L'ambiente è in 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 la disattivazione dell'API Cloud Composer nel progetto, anche se è stata attivata 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 Airflow gestito 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 dell'ambiente. In questo modo, puoi creare un altro ambiente e trasferire i relativi dati caricando questo snapshot.

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

Managed Airflow non raccoglie i log delle attività di Airflow se l'opzione di configurazione di 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 più ambienti che condividono lo stesso collegamento di rete vengono eliminati contemporaneamente, alcune operazioni di eliminazione non vanno a buon fine e viene visualizzato 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:

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

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

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

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

Build di Managed Airflow (terza generazione) interessate:

  • composer-3-airflow-3.1.7-build.0 a composer-3-airflow-3.1.7-build.5
  • 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
  • composer-3-airflow-2.10.5-build.22 a composer-3-airflow-2.10.5-build.33
  • composer-3-airflow-2.9.3-build.42 a composer-3-airflow-2.9.3-build.53

Build di Managed Airflow (seconda generazione) interessate:

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

Ti consigliamo di eseguire l'upgrade dell'ambiente alle seguenti versioni, che contengono una versione del pacchetto in cui il problema è stato risolto o non è presente:

  • composer-3-airflow-3.1.7-build.7 e versioni successive
  • composer-3-airflow-2.11.1-build.3 e versioni successive
  • composer-3-airflow-2.10.5-build.36 e versioni successive
  • composer-3-airflow-2.9.3-build.54 (contiene 2.27.0)
  • composer-2.17.0-airflow-2.11.1 e versioni successive
  • composer-2.17.0-airflow-2.10.5 e versioni successive
  • composer-2.16.11-airflow-2.11.1 (contiene 2.27.0)
  • composer-2.16.11-airflow-2.10.5 (contiene 2.27.0)
  • composer-2.16.11-airflow-2.9.3 (contiene 2.27.0)

In alternativa, puoi installare manualmente una versione successiva del google-api-core pacchetto in un ambiente interessato specificando >=2.30.3 come versione richiesta.

TI non è più in stato di esecuzione e l'attività deve essere terminata e gli errori Task Not Found in Airflow 3

Le versioni di Airflow 3 precedenti alla 3.3.1 presentano diversi problemi relativi alla perdita dello stato delle attività da parte dello scheduler:

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

  • Errori 404: i worker di Airflow perdono traccia delle istanze delle attività durante un riavvio regolare del ciclo dello scheduler, che si verifica dopo che lo scheduler supera [scheduler]max_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).

Sintomi

Lo stato di pulizia degli orfani dello scheduler riavviato contrassegna le attività attive come FAILED, causando la terminazione anomala dei worker con stato 409:

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('...')

Lo scheduler appena riavviato perde gli stati delle attività e non riesce a eseguire i controlli di heartbeat dei worker attivi con un errore 404:

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

Possibili soluzioni:

  • Il problema è stato risolto in Airflow 3.3.1 e versioni successive. Stiamo lavorando per fornire questa versione in Managed Airflow (terza generazione).

  • Non è possibile attenuare completamente il problema. Nelle versioni di Airflow precedenti alla 3.3.1, qualsiasi evento esterno che causa il riavvio imprevisto di un singolo scheduler genera errori 404 e 409. Esempi di questi eventi sono gli upgrade automatici dei nodi nel cluster dell'ambiente, le condizioni OOM nei pod o l'elevato consumo di memoria e CPU da parte degli scheduler.

  • La riduzione dell'ambiente a un solo scheduler e l'impostazione dell'opzione di configurazione [scheduler]num_runs su -1 attenua la causa delle race condition negli scheduler.

    Per un ambiente a elevata resilienza (ad alta disponibilità), 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 nei limiti delle risorse disponibili.

Passaggi successivi