Risoluzione dei problemi: DAG, operatori, connessioni e altri problemi in Apache Airflow v2 - Amazon Managed Workflows for Apache Airflow
ConnessioniServer WebProcessiCLIOperatori

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

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

Gli argomenti di questa pagina descrivono le risoluzioni alle dipendenze di Apache Airflow v2 Python, ai plug-in personalizzati, ai DAG, agli operatori, alle connessioni, alle attività e ai problemi del server Web che potresti riscontrare in un ambiente Amazon Managed Workflow for Apache Airflow.

Connessioni

L'argomento seguente descrive gli errori che potresti ricevere quando usi una connessione Apache Airflow o usi un altroAWS database.

Non riesco a connettermi a Secrets Manager

È consigliabile eseguire le operazioni seguenti:

  1. 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.

  2. 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.

  3. 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.

Come posso configurare le condizioni disecretsmanager:ResourceTag/<tag-key> Secrets Manager o una limitazione delle risorse nella mia politica del ruolo di esecuzione?

Nota

Si applica ad Apache Airflow versione 2.0 e precedenti.

Attualmente, non è possibile limitare l'accesso ai segreti di Secrets Manager utilizzando chiavi di condizione o altre restrizioni di risorse nel ruolo di esecuzione del proprio ambiente, a causa di un problema noto in Apache Airflow.

Non riesco a connettermi a Snowflake

È consigliabile eseguire le operazioni seguenti:

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

  2. Aggiungi le seguenti voci al file requirements.txt per il tuo ambiente.

    apache-airflow-providers-snowflake==1.3.0

  3. Aggiungi le seguenti importazioni al tuo DAG:

    from airflow.providers.snowflake.operators.snowflake import SnowflakeOperator

Assicurati che l'oggetto di connessione Apache Airflow includa le seguenti coppie chiave-valore:

  1. ID di connessione: snowflake_conn

  2. Tipo di connettore: Snowflake

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

  4. Schema: <my schema>

  5. Accedi: <my user name>

  6. Password: ********

  7. Porta: <port, if any>

  8. Supplementare:

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

Ad esempio:

>>> import json
>>> from airflow.models.connection import Connection
>>> myconn = Connection(
...    conn_id='snowflake_conn',
...    conn_type='Snowflake',
...    host='YOUR_ACCOUNT.YOUR_REGION.snowflakecomputing.com',
...    schema='YOUR_SCHEMA'
...    login='YOUR_USERNAME',
...    password='YOUR_PASSWORD',
...    port='YOUR_PORT'
...    extra=json.dumps(dict(account='YOUR_ACCOUNT', warehouse='YOUR_WAREHOUSE', database='YOUR_DB_OPTION', region='YOUR_REGION')),
... )

Non riesco a vedere la mia connessione nell'interfaccia utente di Airflow

Apache Airflow fornisce modelli di connessione nell'interfaccia utente di Apache Airflow. Lo usa per generare la stringa URI di connessione, indipendentemente dal tipo di connessione. Se un modello di connessione non è disponibile nell'interfaccia utente di Apache Airflow, è possibile utilizzare un modello di connessione alternativo per generare una stringa URI di connessione, ad esempio utilizzando il modello di connessione HTTP.

È consigliabile eseguire le operazioni seguenti:

  1. Visualizza i tipi di connessione forniti da Amazon MWAA nell'interfaccia utente di Apache Airflow all'indirizzoPacchetti del provider Apache Airflow installati in ambienti Amazon MWAA.

  2. Visualizza i comandi per creare una connessione Apache Airflow nella CLI all'indirizzoRiferimento ai comandi CLI di Apache Airflow.

  3. Scopri come utilizzare i modelli di connessione nell'interfaccia utente di Apache Airflow in modo intercambiabile per i tipi di connessione che non sono disponibili nell'interfaccia utente di Apache Airflow su Amazon MWAA all'indirizzoPanoramica dei tipi di connessione.

Server Web

L'argomento seguente descrive gli errori che potresti ricevere per il tuo server Web Apache Airflow su Amazon MWAA.

Vedo un errore 5xx durante l'accesso al server Web

È consigliabile eseguire le operazioni seguenti:

  1. 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.

  2. 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.

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

Viene visualizzato l'errore «Lo scheduler sembra non essere in esecuzione»

Se lo scheduler non sembra essere in esecuzione o l'ultimo «battito cardiaco» è stato ricevuto diverse ore fa, i DAG potrebbero non essere visualizzati in Apache Airflow e le nuove attività non verranno pianificate.

È consigliabile eseguire le operazioni seguenti:

  1. 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 nel tuo VPC su Amazon MWAA.

    Nota

    • Il metadatabase Aurora PostgreSQL fa parte dell'architettura del servizio Amazon MWAA e non è visibile nel tuoAccount AWS.

    • Gli errori relativi al database sono in genere un sintomo di un errore dello scheduler e non la causa principale.

  2. 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.

Processi

L'argomento seguente descrive gli errori che potresti ricevere per le attività di Apache Airflow in un ambiente.

Vedo che le mie attività sono bloccate o non vengono completate

Se le tue attività di Apache Airflow sono «bloccate» o non vengono completate, ti consigliamo i seguenti passaggi:

  1. È 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 tempi di analisi totali elevati 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.

  2. È 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.

  3. È 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.

  4. 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.

    Questa è un'immagine con un compito bloccato.

    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.

      Azioni Apache Airflow

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

CLI

L'argomento seguente descrive gli errori che potresti ricevere quando esegui i comandi della CLI di Airflow inAWS Command Line Interface.

Vedo un errore '503' quando si attiva un DAG nella CLI

L'interfaccia a riga di comando di Airflow viene eseguita sul server Web Apache Airflow, che ha una concorrenza limitata. In genere è possibile eseguire contemporaneamente un massimo di 4 comandi CLI.

Perché il comando CLI didags backfill Apache Airflow fallisce? C'è una soluzione alternativa?

Nota

Quanto segue si applica solo agli ambienti Apache Airflow v2.0.2.

Ilbackfill comando, come altri comandi CLI di Apache Airflow, analizza tutti i DAG localmente prima che i DAG vengano elaborati, indipendentemente dal DAG a cui si applica l'operazione CLI. Negli ambienti Amazon MWAA che utilizzano Apache Airflow v2.0.2, poiché i plug-in e i requisiti non sono ancora installati sul server Web al momento dell'esecuzione del comando CLI, l'operazione di analisi fallisce e l'backfilloperazione non viene richiamata. Se non aveste requisiti né plugin nel vostro ambiente, l'backfilloperazione avrebbe esito positivo.

Per poter eseguire il comandobackfill CLI, consigliamo di richiamarlo in un operatore bash. In un operatore bash,backfill viene avviato dal lavoratore, consentendo ai DAG di analizzare correttamente quando tutti i requisiti e i plugin necessari sono disponibili e installati. L'esempio seguente mostra come è possibile creare un DAG con unBashOperator da eseguirebackfill. 

from airflow import DAG
from airflow.operators.bash_operator import BashOperator
from airflow.utils.dates import days_ago

with DAG(dag_id="backfill_dag", schedule_interval=None, catchup=False, start_date=days_ago(1)) as dag:
    cli_command = BashOperator(
        task_id="bash_command",
        bash_command="airflow dags backfill my_dag_id"
    )

Operatori

L'argomento seguente descrive gli errori che potresti ricevere quando usi gli operatori.

Ho ricevuto unPermissionError: [Errno 13] Permission denied errore utilizzando l'operatore S3Transform

Ti consigliamo i seguenti passaggi se stai tentando di eseguire uno script di shell con l'operatore S3Transform e ricevi unPermissionError: [Errno 13] Permission denied errore. I passaggi seguenti presuppongono che tu abbia un file plugins.zip esistente. Se stai creando un nuovo plugins.zip, vediInstallazione di plugin personalizzati.

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

  2. Crea il tuo script di «trasformazione».

    #!/bin/bash
cp $1 $2

  3. (opzionale) Gli utenti macOS e Linux potrebbero dover eseguire il seguente comando per assicurarsi che lo script sia eseguibile.

    chmod 777 transform_test.sh

  4. Aggiungi lo script al tuo file plugins.zip. 

    zip plugins.zip transform_test.sh

  5. Segui i passaggi indicati in Caricare il file plugins.zip su Amazon S3.

  6. Segui i passaggi indicati in Specificare la versione di plugins.zip sulla console Amazon MWAA.

  7. Utilizza i seguenti file DAG.

    from airflow import DAG
from airflow.providers.amazon.aws.operators.s3_file_transform import S3FileTransformOperator
from airflow.utils.dates import days_ago
import os

DAG_ID = os.path.basename(__file__).replace(".py", "")

with DAG (dag_id=DAG_ID, schedule_interval=None, catchup=False, start_date=days_ago(1)) as dag:
    file_transform = S3FileTransformOperator(
        task_id='file_transform',
        transform_script='/usr/local/airflow/plugins/transform_test.sh',
        source_s3_key='s3://YOUR_S3_BUCKET/files/input.txt',
        dest_s3_key='s3://YOUR_S3_BUCKET/files/output.txt'
    )

  8. Segui i passaggi descritti in Caricare il codice DAG su Amazon S3.