Risoluzione dei problemi: DAG, operatori, connessioni e altri problemi in Apache Airflow v1

Testa i tuoi DAG, i plugin personalizzati e le dipendenze Python localmente usando l'opzione aws-mwaa-local-runneronGitHub.

Aggiungi il seguente pacchetto al tuorequirements.txt.

boto

Esplora i modi per specificare le dipendenze Python in unrequirements.txt file, vediGestione delle dipendenze Python in requirements.txt.

Testa i tuoi DAG, i plugin personalizzati e le dipendenze Python localmente usando l'opzione aws-mwaa-local-runneronGitHub.

Aggiungi quanto segue al tuorequirements.txt con la tua versione di Apache Airflow. Ad esempio:

apache-airflow[postgres]==1.10.12

Esplora i modi per specificare le dipendenze Python in unrequirements.txt file, vediGestione delle dipendenze Python in requirements.txt.

Testa i tuoi DAG, i plugin personalizzati e le dipendenze Python localmente usando l'opzione aws-mwaa-local-runneronGitHub.

Aggiungi il seguente pacchetto al tuorequirements.txt e specifica la tua versione di Apache Airflow. Ad esempio:

apache-airflow[slack]==1.10.12

Esplora i modi per specificare le dipendenze Python in unrequirements.txt file, vediGestione delle dipendenze Python in requirements.txt.

Testa i tuoi DAG, i plugin personalizzati e le dipendenze Python localmente usando l'opzione aws-mwaa-local-runneronGitHub.

Aggiungi il seguente pacchetto al tuorequirements.txt.

grpcio==1.27.2
cython==0.29.21
pandas-gbq==0.13.3
cryptography==3.3.2
apache-airflow-backport-providers-amazon[google]

Se non utilizzi provider di backport, puoi utilizzare:

grpcio==1.27.2
cython==0.29.21
pandas-gbq==0.13.3
cryptography==3.3.2
apache-airflow[gcp]==1.10.12

Esplora i modi per specificare le dipendenze Python in unrequirements.txt file, vediGestione delle dipendenze Python in requirements.txt.

Testa i tuoi DAG, i plugin personalizzati e le dipendenze Python localmente usando l'opzione aws-mwaa-local-runneronGitHub.

Aggiungi il seguente pacchetto al tuorequirements.txt.

cython==0.29.21

Le librerie Cython hanno varie versioni di dipendenza pip richieste. Ad esempio, utilizzando requireawswrangler==2.4.0pyarrow<3.1.0,>=2.0.0, pip3 tenta di eseguire l'installazione, ilpyarrow==3.0.0 che causa un errore Broken DAG. Si consiglia di specificare esplicitamente la versione più vecchia accettabile. Ad esempio, se si specifica il valore minimopyarrow==2.0.0 primaawswrangler==2.4.0, l'errore scompare e l'requirements.txtinstallazione viene eseguita correttamente. I requisiti finali dovrebbero apparire come segue:

cython==0.29.21
pyarrow==2.0.0
awswrangler==2.4.0

Esplora i modi per specificare le dipendenze Python in unrequirements.txt file, vediGestione delle dipendenze Python in requirements.txt.

Testa i tuoi DAG, i plugin personalizzati e le dipendenze Python localmente usando l'opzione aws-mwaa-local-runneronGitHub.

Una soluzione alternativa consiste nell'ignorare l'estensione aggiungendo una riga nel DAG da impostare<operator name>.operator_extra_links = None dopo aver importato gli operatori problematici. Ad esempio:

from airflow.contrib.operators.bigquery_operator import BigQueryOperator
BigQueryOperator.operator_extra_links = None

Puoi utilizzare questo approccio per tutti i DAG aggiungendo quanto sopra a un plugin. Per un esempio, consulta Creazione di un plugin personalizzato per Apache Airflow PythonVirtualenvOperator.

Testa i tuoi DAG, i plugin personalizzati e le dipendenze Python localmente usando l'opzione aws-mwaa-local-runneronGitHub.

Aggiungi le seguenti voci a requirements.txt per il tuo ambiente.

asn1crypto == 0.24.0
snowflake-connector-python == 1.7.2

Aggiungi le seguenti importazioni al tuo DAG:

from airflow.contrib.hooks.snowflake_hook import SnowflakeHook
from airflow.contrib.operators.snowflake_operator import SnowflakeOperator

ID di connessione: snowflake_conn

Tipo di connettore: Snowflake

Ospite:<my account>. <my region if not us-west-2>.snowflakecomputing.com

Schema: <my schema>

Accedi: <my user name>

Password: ********

Porta: <port, if any>

Extra:

{
    "account": "<my account>",
    "warehouse": "<my warehouse>",
    "database": "<my database>",
    "region": "<my region if not using us-west-2 otherwise omit this line>"
}

Scopri come creare chiavi segrete per la connessione e le variabili di Apache Airflow inConfigurazione di una connessione Apache Airflow utilizzando un segreto AWS Secrets Manager.

Scopri come usare la chiave segreta per una variabile Apache Airflow (test-variable) inUtilizzo di una chiave segreta AWS Secrets Manager per una variabile Apache Airflow.

Scopri come usare la chiave segreta per una connessione Apache Airflow (myconn) inUtilizzo di una chiave segreta AWS Secrets Manager per una connessione Apache Airflow.

Modifica il gruppo di sicurezza RDS per consentire tutto il traffico proveniente dal gruppo di sicurezza VPC di Amazon MWAA.

Modifica il gruppo di sicurezza VPC di Amazon MWAA per consentire tutto il traffico dal gruppo di sicurezza RDS.

Riesegui nuovamente le attività e verifica se la query SQL ha avuto successo controllando i log di Apache Airflow inCloudWatch Logs.

Gli operatori di Apache Airflow comeBigQueryOperator eQuboleOperator che contengonooperator_extra_links potrebbero causare l'arresto anomalo del server web Apache Airflow. Questi operatori tentano di caricare codice sul tuo server web, cosa non consentita per motivi di sicurezza. Ti consigliamo di applicare le patch agli operatori nel tuo DAG aggiungendo il seguente codice dopo le dichiarazioni di importazione:

BigQueryOperator.operator_extra_links = None

Testa i tuoi DAG, i plugin personalizzati e le dipendenze Python localmente usando l'opzione aws-mwaa-local-runneronGitHub.

Controlla le opzioni di configurazione di Apache Airflow. Verifica che le coppie chiave-valore che hai specificato come opzione di configurazione di Apache Airflow, ad esempioAWS Secrets Manager, siano state configurate correttamente. Per ulteriori informazioni, consulta Non riesco a connettermi a Secrets Manager.

Controlla ilrequirements.txt. Verifica che il pacchetto «extra» di Airflow e le altre librerie elencate nel tuorequirements.txt siano compatibili con la tua versione di Apache Airflow.

Esplora i modi per specificare le dipendenze Python in unrequirements.txt file, vediGestione delle dipendenze Python in requirements.txt.

Verifica che il tuo gruppo di sicurezza VPC consenta l'accesso in entrata alla porta5432. Questa porta è necessaria per connettersi al database di metadati Amazon Aurora PostgreSQL per il tuo ambiente. Dopo aver aggiunto questa regola, concedi ad Amazon MWAA alcuni minuti e l'errore dovrebbe scomparire. Per ulteriori informazioni, consulta Sicurezza nella tua azienda VPC su Amazon MWAA.

Se lo scheduler non è in esecuzione, potrebbe essere dovuto a una serie di fattori come errori di installazione delle dipendenze o un programma di pianificazione sovraccarico. Verifica che i DAG, i plugin e i requisiti funzionino correttamente visualizzando i gruppi di log corrispondenti inCloudWatch Logs. Per ulteriori informazioni, consulta Monitoraggio e parametri per Amazon Managed Workflows for Apache Airflow.

È possibile che sia definito un numero elevato di DAG. Riduci il numero di DAG ed esegui un aggiornamento dell'ambiente (ad esempio modificando un livello di registro) per forzare il ripristino.

1. Airflow analizza i DAG indipendentemente dal fatto che siano abilitati o meno. Se stai utilizzando più del 50% della capacità del tuo ambiente, potresti iniziare a sovraccaricare l'Apache Airflow Scheduler. Ciò comporta un tempo totale di analisi elevato nelleCloudWatch metriche o lunghi tempi di elaborazione DAG neiCloudWatch log. Esistono altri modi per ottimizzare le configurazioni di Apache Airflow che non rientrano nell'ambito di questa guida.

2. Per ulteriori informazioni sulle best practice che consigliamo per ottimizzare le prestazioni del tuo ambiente, consultaOttimizzazione delle prestazioni per Apache Airflow su Amazon MWAA.

È possibile che ci sia un gran numero di attività in coda. Questo appare spesso come un numero elevato e crescente di attività nello stato «Nessuna» o come un numero elevato in Attività in coda e/o Attività in sospesoCloudWatch. Questo può accadere per i seguenti motivi:

1. Se ci sono più attività da eseguire rispetto alla capacità dell'ambiente e/o un numero elevato di attività messe in coda prima della scalabilità automatica ha il tempo di rilevare le attività e distribuire Worker aggiuntivi.

2. Se ci sono più attività da eseguire di quante un ambiente sia in grado di eseguire, si consiglia di ridurre il numero di attività eseguite contemporaneamente dai DAG e/o di aumentare il numero minimo di Apache Airflow Worker.

3. Se ci sono molte attività in coda prima che la scalabilità automatica abbia avuto il tempo di rilevare e distribuire altri lavoratori, consigliamo di scaglionare la distribuzione delle attività e/o aumentare il numero minimo di Apache Airflow Workers.

4. È possibile utilizzare il comando update-environment inAWS Command Line Interface (AWS CLI) per modificare il numero minimo o massimo di Worker eseguiti nel proprio ambiente.

   aws mwaa update-environment --name MyEnvironmentName --min-workers 2 --max-workers 10

5. Per ulteriori informazioni sulle best practice che consigliamo per ottimizzare le prestazioni del tuo ambiente, consultaOttimizzazione delle prestazioni per Apache Airflow su Amazon MWAA.

È possibile che alcune attività vengano eliminate durante l'esecuzione che appaiono come registri delle attività che si interrompono senza ulteriori indicazioni in Apache Airflow. Questo può accadere per i seguenti motivi:

1. Se c'è un breve momento in cui 1) le attività correnti superano la capacità attuale dell'ambiente, seguite da 2) alcuni minuti senza esecuzione o in coda, quindi 3) nuove attività in coda.

2. La scalabilità automatica di Amazon MWAA reagisce al primo scenario aggiungendo altri lavoratori. Nel secondo scenario, rimuove i lavoratori aggiuntivi. Alcune delle attività in coda possono comportare la rimozione dei lavoratori e terminare quando il contenitore viene eliminato.

3. Ti consigliamo di aumentare il numero minimo di lavoratori nel tuo ambiente. Un'altra opzione è modificare la tempistica dei DAG e delle attività per garantire che questi scenari non si verifichino.

4. Puoi anche impostare il numero minimo di lavoratori pari al numero massimo di lavoratori nel tuo ambiente, disattivando in modo efficace la scalabilità automatica. Usa il comando update-environment inAWS Command Line Interface (AWS CLI) per disabilitare la scalabilità automatica impostando lo stesso numero minimo e massimo di lavoratori.

   aws mwaa update-environment --name MyEnvironmentName --min-workers 5 --max-workers 5

5. Per ulteriori informazioni sulle best practice che consigliamo per ottimizzare le prestazioni del tuo ambiente, consultaOttimizzazione delle prestazioni per Apache Airflow su Amazon MWAA.

Se le tue attività sono bloccate nello stato «in esecuzione», puoi anche cancellarle o contrassegnarle come riuscite o non riuscite. Ciò consente al componente di scalabilità automatica del tuo ambiente di ridurre il numero di lavoratori in esecuzione nell'ambiente. La seguente immagina mostra un esempio di operazione bloccata.

1. Scegli il cerchio per l'attività bloccata, quindi seleziona Cancella (come mostrato). Ciò consente ad Amazon MWAA di ridurre il numero di dipendenti; in caso contrario, Amazon MWAA non può determinare quali DAG sono abilitati o disattivati e non può ridimensionare se ci sono ancora attività in coda.

   

Scopri di più sul ciclo di vita delle attività di Apache Airflow in Concepts nella guida di riferimento di Apache Airflow.