Comment résoudre l'erreur « Was the task killed externally » (La tâche a-t-elle été désactivée en externe ?) dans Amazon MWAA ?

Brève description

L'erreur « Was the task killed externally » (La tâche a-t-elle été désactivée en externe ?) se produit lorsque l'état d'une tâche est différent entre la base de données de métadonnées Airflow et l'initiateur de la tâche. Les causes de l'erreur sont les suivantes :

• La valeur de task_queued_timeout est atteinte. La valeur par défaut est de 600 secondes. Pour les versions antérieures d'Apache Airflow, consultez la valeur de task_adoption_timeout. Pour plus d'informations, consultez la page task_queued_timeout_check_interval sur le site Web d'Apache Airflow.
• La tâche a échoué en raison d'une forte utilisation des ressources dans l’environnement de travail.

Résolution

Vérifier les journaux de votre planificateur

Procédez comme suit :

1. Ouvrez la console Amazon CloudWatch.

2. Dans le volet de navigation, sélectionnez Journaux.

3. Sélectionnez Groupe de journaux.

4. Choisissez le groupe de journaux que vous souhaitez consulter.

5. Choisissez Rechercher dans tout le flux de journaux.

6. Pour rechercher la période pendant laquelle votre tâche a échoué, mettez à jour l'intervalle de temps. Filtrez également la recherche à l'aide de votre ID de tâche :

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

   Remarque : Remplacez example-dag-name par le nom de votre code Directed Acyclic Graph (DAG), example-task-name par le nom de votre tâche et example-time par la période que vous souhaitez utiliser.

7. Identifiez deux lignes de journal dans les résultats de recherche qui font référence à votre tâche :

   Un exemple de tâche en file d'attente est présenté ci-dessous :

   [[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

   Un exemple de tâche interrompue est présenté ci-dessous :

   [[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

Vous pouvez résoudre les problèmes de manière plus approfondie dans les scénarios suivants.

La tâche a échoué en raison d'une erreur task_queued_timeout

Comparez les horodatages du moment auquel vous avez planifié votre tâche et de la date à laquelle elle a été interrompue. Si la différence est supérieure ou égale à la valeur de task_queued_timeout, cela signifie que votre tâche est en file d'attente trop longtemps.

Pour résoudre ce problème, prenez les mesures suivantes :

• Augmentez la valeur de task_queued_timeout afin que les tâches puissent attendre plus longtemps dans la file d'attente sans délai d'attente.
• Passez à une classe d'environnement supérieure pour augmenter le nombre d'emplacements d’environnements de travail Celery dans chaque conteneur d’environnement de travail. Le nombre de tâches simultanées pouvant être exécutées dans l'environnement est maxWorkers * celery.worker_autoscale.
• Répartissez la charge des DAG et des tâches. N'exécutez pas plusieurs DAG à la fois.
• Vérifiez que votre planificateur n'est pas surchargé. Si votre planificateur est surchargé, il est possible que les tâches ne soient pas planifiées à temps.

Remarque : Une augmentation du nombre de planificateurs peut affecter l'utilisation des bases de métadonnées et les temps d'analyse. Un nombre plus important de planificateurs accroît la haute disponibilité (HA), mais n'ajoute pas de ressources supplémentaires pour la planification des tâches. Si la valeur de task_queued_timeout n'est pas atteinte, vérifiez les journaux de vos environnements de travail.

Pour consulter les journaux de vos environnements de travail, procédez comme suit :

1. Accédez à votre interface utilisateur Apache Airflow.
2. Choisissez un DAG.
3. Sélectionnez Graphique.
4. Choisissez une tâche à exécuter.
5. Choisissez Détails de l'instance. Puis, notez la valeur de external_executor_id de votre tâche.
6. Ouvrez la console Amazon CloudWatch.
7. Dans le volet de navigation, sélectionnez Journaux.
8. Sélectionnez Groupe de journaux.
9. Choisissez le groupe de journaux que vous souhaitez consulter.
10. Choisissez Rechercher dans tout le flux de journaux.
11. Pour rechercher la période pendant laquelle votre tâche a échoué, mettez à jour l'intervalle de temps.
12. Filtrez la recherche à l'aide de la valeur de external_executor_id pour afficher les lignes de journal liées à votre tâche dans l’environnement de travail.
13. Identifiez les messages d'erreur liés à votre tâche. Pour plus d'informations sur les erreurs, choisissez le nom du flux de journaux.

La tâche a échoué en raison d'une utilisation élevée du processeur ou de la mémoire

Si le message d'erreur suivant s'affiche, cela signifie que votre environnement de travail rencontre des problèmes d'utilisation des ressources, tels qu'un processeur ou une mémoire RAM élevés. Par conséquent, le processus de travail qui s'exécute sur le conteneur de travail échoue et se termine prématurément.

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

Pour résoudre le message d'erreur précédent, vérifiez les métriques CPUUtilization et MemoryUtilization. Si les métriques sont constamment élevées ou présentent des pics, cela signifie que vos environnements de travail Amazon MWAA sont surchargés.

Pour résoudre le problème de surcharge des environnements de travail, prenez les mesures suivantes :

• Diminuez la valeur de celery.worker_autoscale pour réduire le nombre de tâches exécutées simultanément dans votre environnement de travail.
• Utilisez une classe d'instance Amazon MWAA supérieure pour augmenter la quantité de RAM et de vCPU.
• Réécrivez vos DAG pour transférer la charge de travail de calcul d'Amazon MWAA vers d'autres plateformes de calcul.

Informations connexes

Bonnes pratiques sur le site Web d'Apache Airflow