Come posso risolvere l'errore "Was the task killed externally" in Amazon MWAA?

Breve descrizione

L'errore "Was the task killed externally" si verifica quando lo stato di un'attività è diverso tra il database di metadati Airflow e l'iniziatore dell'attività. Le cause dell'errore sono le seguenti:

• È stato raggiunto il valore task_queued_timeout. Il valore predefinito è 600 secondi. Per le versioni precedenti di Apache Airflow, visualizza il valore task_adoption_timeout. Per ulteriori informazioni, consulta task_queued_timeout_check_interval sul sito web di Apache Airflow.
• L'attività non è riuscita a causa dell'utilizzo elevato delle risorse da parte del worker.

Risoluzione

Controlla i log del pianificatore

Completa i seguenti passaggi:

1. Apri la console Amazon CloudWatch.

2. Nel pannello di navigazione, scegli Log.

3. Scegli Gruppi di log.

4. Scegli il gruppo di log che desideri visualizzare.

5. Scegli Search All LogStream (Cerca in tutto il flusso di log).

6. Per restringere la ricerca all'arco temporale in cui l'attività non è riuscita, aggiorna l'intervallo di tempo. Inoltre, filtra la ricerca con l'ID attività:

   "example-dag-name.example-task-name manual__example-time-202X-XX-XXTXX:XX:XX.758774+00:00"

   Nota: sostituisci example-dag-name con il nome del tuo DAG (Directed Acyclic Graph), example-task-name con il nome della tua attività e example-time con l'arco temporale che desideri utilizzare.

7. Identifica due righe di log nei risultati della ricerca che fanno riferimento all'attività:

   Di seguito è riportato un esempio di attività in coda:

   [[34m**2024-01-17T11:19:07.487+0000**[0m] [34mscheduler_job_runner.py:[0m713 INFO[0m - Setting external_id for <TaskInstance: dag_name.task_name manual__202X-XX-XXTXX:XX:XX.758774+00:00[queued]> to 8b49b168-992d-4db6-bdc7-a143d55720c8[0m

   Di seguito è riportato un esempio di attività arrestata:

   [[34m**2024-01-17T11:30:18.936+0000**[0m] [34mscheduler_job_runner.py:[0m771 ERROR[0m - Executor reports task instance <TaskInstance: dag_name.task_name manual__202X-XX-XXTXX:XX:XX.758774+00:00 [queued]> finished (failed) although the task says it's queued. (Info: None) Was the task killed externally?[0m

Puoi risolvere ulteriormente i problemi nei seguenti scenari.

Attività non riuscita a causa di un task_queued_timeout

Confronta i timestamp della pianificazione dell'attività e dell'arresto dell'attività. Se la differenza è maggiore o uguale al valoretask_queued_timeout, il tempo trascorso in coda dall'attività è eccessivo rispetto al valore impostato.

Per risolvere l’errore, intraprendi le seguenti azioni:

• Aumenta il valore task_queued_timeout in modo che le attività possano attendere più a lungo in coda senza timeout.
• Aggiorna a una classe di ambiente superiore per aumentare il numero di slot di worker Celery in ogni container worker. Il numero di attività concorrenti che possono essere eseguite nell'ambiente è maxWorkers * celery.worker_autoscale.
• Distribuisci il carico di DAG e attività. Non eseguire più DAG contemporaneamente.
• Verifica che il pianificatore non sia sovraccarico. Se il pianificatore è sovraccarico, le attività potrebbero non essere pianificate in tempo.

Nota: un aumento del numero di pianificatori potrebbe influire sull'utilizzo del meta-database e sui tempi di analisi. Un numero maggiore di pianificatori aumenta l'alta disponibilità, ma non aggiunge altre risorse per la pianificazione delle attività. Se il valore task_queued_timeout non è raggiunto, controlla i log dei worker.

Per controllare i log dei worker, completa i seguenti passaggi:

1. Accedi all'interfaccia utente di Apache Airflow.
2. Scegli un DAG.
3. Seleziona Graph (Grafico).
4. Scegli un'attività eseguita.
5. Scegli Instance details (Dettagli dell'istanza). Quindi annota il valore external_executor_id dell'attività.
6. Apri la console Amazon CloudWatch.
7. Nel pannello di navigazione, scegli Log.
8. Scegli Gruppi di log.
9. Scegli il gruppo di log che desideri visualizzare.
10. Scegli Search All LogStream (Cerca in tutto il flusso di log).
11. Per restringere la ricerca all'arco temporale in cui l'attività non è riuscita, aggiorna l'intervallo di tempo.
12. Filtra la ricerca con il valore external_executor_id per visualizzare le righe di log relative all'attività sul worker.
13. Identifica i messaggi di errore correlati all'attività. Per ulteriori informazioni sugli errori, scegli il nome del flusso di log.

Attività non riuscita a causa dell'utilizzo elevato della CPU o della memoria

Se ricevi il seguente messaggio di errore, ciò significa che il worker ha problemi di utilizzo delle risorse (ad esempio, utilizzo elevato della CPU o della RAM). Di conseguenza, il processo del worker eseguito sul container worker ha esito negativo e termina prematuramente.

"[2023-07-26 13](tel:2023072613):00:49,356: ERROR/MainProcess] Task handler raised error: WorkerLostError('Worker exited prematurely: signal 15 (SIGTERM) Job: 1049.')"

Per risolvere l'errore precedente, controlla le metriche CPUUtilization e MemoryUtilization. Se le metriche sono costantemente alte o presentano picchi, i worker Amazon MWAA sono sovraccarichi.

Per risolvere il sovraccarico dei worker, intraprendi le seguenti azioni:

• Diminuisci il valore celery.worker_autoscale per ridurre il numero di attività concorrenti eseguite sul worker.
• Utilizza una classe di istanze Amazon MWAA superiore per più RAM e vCPU.
• Riscrivi i DAG per trasferire il carico di lavoro derivante dall'elaborazione da Amazon MWAA ad altre piattaforme di calcolo.

Informazioni correlate

Best practices (Best practice) sul sito web di Apache Airflow