Comment résoudre les problèmes liés à l'échec d'une tâche Spark dans Amazon EMR ?

Brève description

Pour résoudre les problèmes liés à l'échec des tâches Spark dans Amazon EMR sur Amazon Elastic Compute Cloud (Amazon EC2), procédez comme suit :

• Pour les tâches Spark soumises avec --deploy-mode-client, consultez les journaux des étapes pour identifier la cause première de l'échec de l'étape.
• Pour les tâches Spark soumises avec --deploy-mode-cluster, consultez d'abord les journaux des étapes pour identifier l'ID de l'application. Consultez ensuite les journaux principaux de l'application pour identifier la cause première de l'échec de l'étape.

Pour résoudre les problèmes liés à l'échec des tâches Spark dans Amazon EMR sur Amazon Elastic Kubernetes Service (Amazon EKS), vous devez identifier la cause première de l'échec de la tâche Spark. Pour ce faire, consultez les journaux des pilotes depuis Amazon Simple Storage Service (Amazon S3) ou Amazon CloudWatch.

Pour résoudre les problèmes liés à l'échec des tâches Spark sur Amazon EMR sans serveur, vous devez identifier la cause première de l'échec de la tâche Spark. Pour ce faire, examinez les détails de l'exécution de la tâche depuis la console d'application Amazon EMR sans serveur et les journaux des pilotes.

Résolution

Résolution de problèmes liés à l'échec des tâches Spark dans Amazon EMR sur Amazon EC2

Tâches en mode client
Lorsqu'une tâche Spark est déployée en mode client, les journaux des étapes fournissent les paramètres de la tâche, ainsi que les messages d'erreur liés aux étapes. Ces journaux sont archivés dans Amazon S3.

Pour identifier la cause première de l'échec d'une étape, téléchargez les journaux des étapes sur une instance Amazon EC2. Recherchez ensuite d’éventuels avertissements et erreurs. Procédez comme suit :

Pour décompresser le fichier journal des étapes, exécutez la commande suivante :

find . -type f -exec gunzip {} \;

Pour identifier l'ID d'application YARN à partir du journal du mode cluster, exécutez la commande suivante :

grep "Client: Application report for" * | tail -n 1

L'exemple de fichier suivant indique un problème de mémoire :

« ERROR SparkContext: Error initializing SparkContext.java.lang.IllegalArgumentException: Executor memory 134217728 must be at least 471859200. Please increase executor memory using the --executor-memory option or spark.executor.memory in Spark configuration. »

Pour résoudre l'erreur présentée ci-dessus, exécutez la commande spark-submit afin de soumettre une tâche avec une mémoire accrue. Pour en savoir plus, consultez la page Submitting applications sur le site Web d'Apache Spark.
Exemple :

spark-submit --deploy-mode client --executor-memory 4g --class org.apache.spark.examples.SparkPi /usr/lib/spark/examples/jars/spark-examples.jar

Tâches en mode cluster
Pour identifier l'ID d'application associé à l'échec de l'étape Spark, consultez le journal des étapes stderr. Les journaux des étapes sont archivés dans Amazon S3. Identifiez ensuite les journaux principaux de l'application. Les tâches Spark qui s'exécutent en mode cluster s'exécutent dans le journal principal de l'application. Le journal principal de l'application est le premier conteneur qui s'exécute lorsqu'une tâche Spark démarre. Dans l'exemple suivant, container_1572839353552_0008_01_000001 est le premier conteneur des journaux principaux de l'application.

Exemple :
s3://aws-logs-111111111111-us-east-1/elasticmapreduce/j-35PUYZBQVIJNM/containers/application_1572839353552_0008/container_1572839353552_0008_01_000001/stderr.gz

Après avoir identifié les journaux principaux de l'application, téléchargez-les sur une instance Amazon EC2. Recherchez ensuite d’éventuels avertissements et erreurs.

Pour décompresser le fichier journal des étapes, exécutez la commande suivante :

find . -type f -exec gunzip {} \;

Pour rechercher des avertissements et des erreurs dans les journaux de conteneurs, ouvrez les journaux de conteneurs qui se trouvent dans la sortie de la commande suivante :

egrep -Ril "ERROR|WARN" . | xargs egrep "WARN|ERROR"

Si un journal de conteneurs indique un problème de mémoire, exécutez la commande « spark-submit » suivante pour soumettre une tâche avec une mémoire accrue :

spark-submit --deploy-mode cluster --executor-memory 4g --class org.apache.spark.examples.SparkPi /usr/lib/spark/examples/jars/spark-examples.jar 1000

Résolution de problèmes liés à l'échec des tâches Spark dans Amazon EMR sur Amazon EKS

Remarque : si des erreurs surviennent lorsque vous exécutez des commandes de l’interface de la ligne de commande AWS (AWS CLI), consultez la page Résoudre les erreurs liées à AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l’AWS CLI.

Lorsqu'une tâche Spark est soumise dans Amazon EMR sur Amazon EKS, les journaux peuvent être stockés dans Amazon S3 ou CloudWatch. Vous devez rechercher les échecs de tâches Spark dans les journaux des pilotes. Utilisez également les commandes kubectl pour obtenir plus d’informations sur les journaux du pilote et de l'exécuteur pour la tâche Spark en cours d'exécution.

Remarque : les commandes kubectl fonctionnent uniquement dans le cas de pods actifs. Si les pods sont inactifs, vous ne pouvez pas exécuter de commandes kubectl.

Si vous soumettez une tâche Spark à l'aide de la commande start-job-run, veillez à utiliser les commandes kubectl suivantes :

kubectl get pods -n example-spark-namespace

Remarque : remplacez example-spark-namespace par l'espace de noms Spark utilisé pour lancer la tâche.

kubectl logs spark-example-pod-driver -n example-spark-namespace -c spark-kubernetes-driver

Remarque : remplacez example-spark-namespace par l'espace de noms Spark utilisé pour lancer la tâche et example-pod par le nom du pod.

Si vous soumettez une tâche Spark à l'aide de la commande spark-operator, veillez à utiliser les commandes kubectl suivantes :

kubectl get pods -n example-spark-namespace

Remarque : remplacez example-spark-namespace par l'espace de noms Spark utilisé pour lancer la tâche.

kubectl logs example-pod-driver -n example-spark-namespace

Remarque : remplacez example-pod par le nom du pod et example-spark-namespace par l'espace de noms Spark utilisé pour lancer la tâche.

Si vous soumettez une tâche Spark à l'aide de la commande spark-submit, veillez à utiliser les commandes kubectl suivantes. Pour en savoir plus, consultez la page Submitting applications sur le site Web d'Apache Spark.

kubectl get pods -n example-spark-namespace

Remarque : remplacez example-spark-namespace par l'espace de noms Spark utilisé pour lancer la tâche.

kubectl logs example-pod-driver -n example-spark-namespace

Remarque : example-spark-namespace doit être remplacé par l'espace de noms Spark utilisé pour lancer la tâche et example-pod par le nom du pod.

Résolution de problèmes liés à l'échec des tâches Spark dans Amazon EMR sans serveur

Lorsque vous soumettez une tâche Spark dans Amazon EMR sans serveur, la journalisation est activée par défaut pour toutes les exécutions de tâches. Vous pouvez également activer la journalisation Amazon S3 pour votre compartiment Amazon S3. Pour résoudre les problèmes liés à l'échec de votre tâche Spark, consultez les détails d'exécution de la tâche, puis choisissez l'option Fichiers journaux du pilote. Vous pouvez également consulter les journaux stockés dans CloudWatch pour identifier la cause première de l'échec de la tâche Spark.

Informations connexes

Ajout d’une étape Spark

Exécution de tâches avec Amazon EMR sur EKS

Journalisation et surveillance