Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résoudre les problèmes liés à un cluster Amazon EMR défaillant avec un code d'erreur
Cette section vous guide tout au long du processus de dépannage d'un cluster qui a échoué. Cela signifie que le cluster s'est arrêté avec un code d'erreur.
**Note**
Lorsqu'un cluster EMR se termine avec une erreur, les `DescribeCluster` et `ListClusters` APIs renvoient un code d'erreur et un message d'erreur. Pour certaines erreurs de cluster, le tableau de données `ErrorDetail` peut également vous aider à résoudre le problème. Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md).
Si votre cluster s'exécute mais met du temps à renvoyer des résultats, consultez [Résoudre les problèmes liés à la lenteur d'un cluster Amazon EMR](emr-troubleshoot-slow.md).
**Topics**
+ [
# Étape 1 : recueillir des données sur le problème lié au cluster Amazon EMR
](emr-troubleshoot-failed-1.md)
+ [
# Étape 2 : Vérifier l'environnement
](emr-troubleshoot-failed-2.md)
+ [
# Étape 3 : Examiner le dernier changement d'état
](emr-troubleshoot-failed-3.md)
+ [
# Étape 4 : examiner les fichiers journaux Amazon EMR
](emr-troubleshoot-failed-4.md)
+ [
# Étape 5 : tester le cluster Amazon EMR étape par étape
](emr-troubleshoot-failed-5-test-steps.md)
# Étape 1 : recueillir des données sur le problème lié au cluster Amazon EMR
La première étape du dépannage d'un cluster consiste à recueillir des informations sur le problème rencontré, ainsi que sur l'état actuel et la configuration du cluster. Ces informations seront utilisées dans les étapes suivantes pour confirmer ou exclure les causes possibles du problème.
## Définition du problème
Définir clairement le problème est la première étape de résolution. Quelques questions à vous poser :
+ Quel était l'effet attendu ? Que s'est-il passé à la place ?
+ Quand ce problème s'est-il produit pour la première fois ? Combien de fois cela s'est-il produit depuis ?
+ Est-ce que quelque chose a changé dans la façon dont je configure ou gère mon cluster ?
## Détails du cluster
Les détails du cluster suivants sont utiles pour détecter les problèmes. Pour plus d'informations sur la manière de spécifier ces informations, consultez [Afficher l'état et les détails du cluster Amazon EMR](emr-manage-view-clusters.md).
+ Identifiant du cluster. (Également appelé identifiant de flux de travail.)
+ Région AWS et la zone de disponibilité dans laquelle le cluster a été lancé.
+ État du cluster, y compris les détails du dernier changement d'état.
+ Type et nombre d'instances EC2 spécifiées pour les nœuds principaux et de tâche.
# Étape 2 : Vérifier l'environnement
Amazon EMR opère dans le cadre d'un écosystème de services Web et de logiciels open source. Des éléments affectant ces dépendances peuvent attribuer les performances d'Amazon EMR.
**Topics**
+ [
## Recherche d'interruptions de service
](#emr-troubleshoot-failed-2-outages)
+ [
## Recherche des limites d'utilisation
](#emr-troubleshoot-failed-2-limits)
+ [
## Vérification de la version
](#emr-troubleshoot-failed-2-ami)
+ [
## Vérifiez la configuration du sous-réseau Amazon VPC
](#emr-troubleshoot-failed-2-vpc)
## Recherche d'interruptions de service
Amazon EMR utilise plusieurs services Web Amazon en interne. Il exécute des serveurs virtuels sur Amazon EC2, stocke des données et des scripts sur Amazon S3 et transmet des métriques à. CloudWatch Les événements qui perturbent ces services sont rares, mais lorsqu'ils se produisent, ils peuvent entraîner des problèmes dans Amazon EMR.
Avant d'aller plus loin, consultez le [Tableau de bord de l'état des services](https://status.aws.amazon.com/). Vérifiez la région dans laquelle vous avez lancé votre cluster pour voir s'il y a des interruptions dans l'un de ces services.
## Recherche des limites d'utilisation
Si vous lancez un cluster de grande taille, si vous avez lancé plusieurs clusters simultanément ou si vous êtes un utilisateur partageant un cluster Compte AWS avec d'autres utilisateurs, le cluster a peut-être échoué car vous avez dépassé une limite de AWS service.
Amazon EC2 limite le nombre d'instances de serveurs virtuels exécutées dans une même AWS région à 20 instances réservées ou à la demande. Si vous lancez un cluster comportant plus de 20 nœuds, ou si vous lancez un cluster dont le nombre total d'instances EC2 actives dépasse 20, le cluster ne sera pas en mesure de lancer toutes les instances EC2 dont il a besoin et risque d'échouer. Compte AWS Dans ce cas, Amazon EMR renvoie une erreur `EC2 QUOTA EXCEEDED`. Vous pouvez demander à AWS augmenter le nombre d'instances EC2 que vous pouvez exécuter sur votre compte en soumettant une [demande d'augmentation de la limite d'instance Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/).
Le délai entre la fermeture d'un cluster et le moment où il libère toutes ses ressources peut également vous faire dépasser vos limites d'utilisation. Selon sa configuration, il peut s'écouler entre 5 et 20 minutes avant que le cluster ne se termine complètement et ne libère les ressources qui lui ont été allouées. Si vous obtenez une erreur `EC2 QUOTA EXCEEDED` lorsque vous tentez de lancer un cluster, il est possible que des ressources provenant d'un cluster récemment arrêté n'aient pas encore été libérées. Dans ce cas, vous pouvez soit [demander à ce que votre quota Amazon EC2 soit augmenté](https://aws.amazon.com/contact-us/ec2-request/), soit attendre 20 minutes et relancer le cluster.
Amazon S3 limite le nombre de compartiments créés sur un compte à 100. Si votre cluster crée un nouveau compartiment qui dépasse cette limite, la création du compartiment échouera et peut entraîner l'échec du cluster.
## Vérification de la version
Comparez le libellé de la version que vous avez utilisée pour lancer le cluster avec la dernière version d'Amazon EMR. Chaque version d'Amazon EMR inclut des améliorations telles que de nouvelles applications et fonctions, des correctifs et des correctifs de bogues. Le problème qui affecte votre cluster a peut-être déjà été corrigé dans la dernière version. Si possible, réexécutez votre cluster à l'aide de la dernière version.
## Vérifiez la configuration du sous-réseau Amazon VPC
Si votre cluster a été lancé dans un sous-réseau Amazon VPC, celui-ci doit être configuré comme décrit dans [Configuration de la mise en réseau dans un VPC pour Amazon EMR](emr-plan-vpc-subnet.md). Vérifiez également que le sous-réseau dans lequel vous lancez le cluster possède suffisamment d'adresses IP élastiques libres pour en attribuer une à chaque nœud du cluster.
# Étape 3 : Examiner le dernier changement d'état
Le dernier changement d'état fournit des informations sur ce qui s'est passé la dernière fois que le cluster a changé d'état. Il contient souvent des informations explicitant les problèmes qui se sont posés lorsque l'état d'un cluster change et devient `FAILED`. Par exemple, si vous lancez un cluster de streaming et spécifiez un emplacement de sortie qui existe déjà dans Amazon S3, le cluster échoue avec un dernier changement d'état de « Le répertoire de sortie de streaming existe déjà ».
Vous pouvez localiser la valeur du dernier changement d'état dans la console en affichant le volet de détails pour le cluster, à partir de l'interface de ligne de commande à l'aide des arguments `list-steps` ou `describe-cluster`, ou à partir de l'API à l'aide des actions `DescribeCluster` et `ListSteps`. Pour de plus amples informations, veuillez consulter [Afficher l'état et les détails du cluster Amazon EMR](emr-manage-view-clusters.md).
# Étape 4 : examiner les fichiers journaux Amazon EMR
L'étape suivante consiste à examiner les fichiers journaux afin de trouver un code d'erreur ou une autre indication du problème rencontré par votre cluster. Pour plus d'informations sur les fichiers journaux disponibles, où les trouver et comment les consulter, consultez [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
Il faudra peut-être effectuer un certain travail d'enquête pour déterminer ce qui s'est passé. Hadoop exécute le travail des tâches lors de tentatives de tâches sur différents nœuds du cluster. Amazon EMR peut lancer des tentatives de tâches spéculatives, mettant fin aux autres tentatives de tâches qui n'aboutissent pas. Cela génère une activité importante qui est enregistrée au fur et à mesure dans les fichiers journaux du contrôleur : stderr et syslog. En outre, plusieurs tentatives de tâches sont exécutées simultanément, mais un fichier journal ne peut afficher les résultats que de manière linéaire.
Commencez par vérifier les journaux d'actions d'amorçage pour détecter les erreurs ou les modifications de configuration inattendues lors du lancement du cluster. À partir de là, consultez les journaux d'étapes pour identifier les tâches Hadoop lancées dans le cadre d'une étape comportant des erreurs. Examinez les journaux des tâches Hadoop pour identifier les tentatives de tâches qui ont échoué. Le journal des tentatives de tâche contiendra des détails sur la cause de l'échec d'une tentative de tâche.
Les sections suivantes décrivent comment utiliser les différents fichiers journaux pour identifier les erreurs dans votre cluster.
## Vérification des journaux d'actions d'amorçage
Les actions d'amorçage exécutent des scripts sur le cluster lors de son lancement. Elles servent généralement à installer des logiciels supplémentaires sur le cluster ou à modifier les paramètres de configuration par rapport aux valeurs par défaut. La vérification des journaux peut fournir un aperçu des erreurs survenues lors de la configuration du cluster ainsi que des modifications des paramètres de configuration susceptibles d'attribuer les performances.
## Vérification des journaux d'étape
Il existe quatre types de journaux d'étapes.
+ **Contrôleur :** contient les fichiers générés par Amazon EMR (Amazon EMR) à la suite d'erreurs rencontrées lors de l'exécution de votre étape. Si votre étape échoue lors du chargement, vous pouvez trouver la trace de la pile dans ce journal. Les erreurs de chargement ou d'accès à votre application sont souvent décrites ici, tout comme les erreurs manquantes dans les fichiers de mappage.
+ **stderr :** contient les messages d'erreur survenus lors du traitement de l'étape. Les erreurs de chargement des applications sont souvent décrites ici. Ce journal contient parfois une trace de pile.
+ **stdout :** contient le statut généré par les exécutables de votre mappeur et de votre réducteur. Les erreurs de chargement des applications sont souvent décrites ici. Ce journal contient parfois des messages d'erreur d'application.
+ **syslog :** contient des journaux provenant de logiciels autres qu'Amazon, tels qu'Apache et Hadoop. Les erreurs de diffusion sont souvent décrites ici.
Vérifiez stderr pour détecter les erreurs évidentes. Si stderr affiche une courte liste d'erreurs, l'étape s'est arrêtée rapidement et une erreur a été renvoyée. Cela est le plus souvent dû à une erreur dans les applications de mappage et de réduction exécutées dans le cluster.
Examinez les dernières lignes du contrôleur et du syslog pour détecter les erreurs ou les défaillances. Suivez toutes les instructions concernant les tâches ayant échoué, en particulier si le message « Échec de la tâche » s'affiche.
## Vérification des journaux de tentatives de tâche
Si l'analyse précédente des journaux d'étapes a révélé l'échec d'une ou de plusieurs tâches, examinez les journaux des tentatives de tâches correspondantes pour obtenir des informations plus détaillées sur les erreurs.
# Étape 5 : tester le cluster Amazon EMR étape par étape
Une technique utile lorsque vous essayez de déceler la source d'une erreur consiste à redémarrer le cluster et à lui soumettre les étapes une par une. Cela vous permet de vérifier les résultats de chaque étape avant de traiter la suivante, et vous donne l'occasion de corriger et de réexécuter une étape qui a échoué. Cela présente également l'avantage de vous faire charger une seule fois les données d'entrée.
**Pour tester un cluster étape par étape**
1. Lancez un nouveau cluster avec les deux options keep-alive et protection contre l'arrêt activées. L'option keep-alive maintient le cluster actif après qu'il a traité toutes ses étapes en suspens. La protection contre l'arrêt empêche un cluster de s'arrêter en cas d'erreur. Pour plus d’informations, consultez [Configuration d'un cluster Amazon EMR pour qu'il continue ou s'arrête après l'exécution de l'étape](emr-plan-longrunning-transient.md) et [Utilisation de la protection contre la résiliation pour protéger vos clusters Amazon EMR d'un arrêt accidentel](UsingEMR_TerminationProtection.md).
1. Soumettez une étape au cluster. Pour de plus amples informations, veuillez consulter [Soumettre un travail à un cluster Amazon EMR](emr-work-with-steps.md).
1. À la fin du traitement de l'étape, recherchez les erreurs dans les fichiers journaux d'étape. Pour de plus amples informations, veuillez consulter [Étape 4 : examiner les fichiers journaux Amazon EMR](emr-troubleshoot-failed-4.md). Le moyen le plus rapide de localiser ces fichiers journaux est de se connecter au nœud maître et d'y afficher les fichiers journaux. Les fichiers journaux d'étape n'apparaissent pas tant que l'étape ne s'est pas exécutée assez longtemps, ne s'est pas terminée ou n'a pas échoué.
1. Si l'étape a réussi sans erreur, exécutez l'étape suivante. Si des erreurs se sont produites, enquêtez sur l'erreur dans les fichiers journaux. Si l'erreur se situe dans votre code, effectuez la correction et réexécutez l'étape. Continuez jusqu'à ce que toutes les étapes s'exécutent sans erreur.
1. Lorsque vous avez terminé le débogage du cluster et souhaitez arrêter ce dernier, vous devez l'arrêter manuellement. Cela est nécessaire car le cluster a été lancé avec la protection contre l'arrêt activée. Pour de plus amples informations, veuillez consulter [Utilisation de la protection contre la résiliation pour protéger vos clusters Amazon EMR d'un arrêt accidentel](UsingEMR_TerminationProtection.md).