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.
Configuration de la journalisation et du débogage du cluster Amazon EMR
Lorsque vous planifiez votre cluster, vous devez déterminer la quantité de support de débogage que vous souhaitez rendre disponible. Lorsque vous commencez à développer votre application de traitement des données, nous vous recommandons de tester l'application sur un cluster traitant un petit sous-ensemble représentatif de vos données. Lorsque vous procédez ainsi, il est probable que vous souhaitiez tirer parti de tous les outils de débogage que propose Amazon EMR, comme l'archivage des fichiers journaux dans Amazon S3.
Lorsque vous avez terminé la phase de développement et que votre application de traitement des données passe en production, vous pouvez décider de réduire le débogage. Vous pouvez ainsi économiser le coût de stockage des archives de fichiers journaux dans Amazon S3 et réduire la charge de traitement sur le cluster, qui n'a plus besoin d'écrire les états dans Amazon S3. En revanche, en cas de problèmes, vous aurez moins d'outils disponibles pour les traiter.
Fichiers journaux par défaut
Par défaut, chaque cluster écrit les fichiers journaux sur le nœud primaire. Ils sont écrits dans le répertoire /mnt/var/log/
. Vous pouvez y accéder à l'aide de SSH pour vous connecter au nœud primaire, comme décrit dans Connectez-vous au nœud principal du cluster Amazon EMR à l'aide de SSH. Amazon EMR collecte certains journaux du système et des applications générés par les démons Amazon EMR et d'autres processus Amazon EMR afin de garantir l'efficacité des opérations de service.
Note
Si vous utilisez Amazon EMR version 6.8.0 ou antérieure, les fichiers journaux sont enregistrés sur Amazon S3 lors de la résiliation du cluster. Vous ne pouvez donc pas accéder aux fichiers journaux une fois le nœud primaire résilié. Les versions 6.9.0 et ultérieures d'Amazon EMR archivent les journaux sur Amazon S3 pendant la réduction de la taille du cluster, de sorte que les fichiers journaux générés sur le cluster persistent même après que le nœud a été résilié.
Vous n'avez pas besoin d'activer d'options pour que les fichiers journaux soient écrits sur le nœud primaire. Il s'agit en effet du comportement par défaut d'Amazon EMR et de Hadoop.
Un cluster génère plusieurs types de fichiers journaux, y compris :
-
Journaux d'étape – Ces journaux sont générés par le service Amazon EMR et contiennent des informations sur le cluster et les résultats de chaque étape. Les fichiers journaux sont stockés dans le répertoire
/mnt/var/log/hadoop/steps/
sur le nœud primaire. Chaque étape enregistre ses résultats dans un sous-répertoire distinct numéroté :/mnt/var/log/hadoop/steps/s-
pour la première étape,stepId1
//mnt/var/log/hadoop/steps/s-
pour la deuxième étape, et ainsi de suite. Les identifiants d'étape de 13 caractères (par exemple, stepId1, stepId2) sont spécifiques à un cluster.stepId2
/ -
Journaux des composants Hadoop et YARN — Les journaux des composants associés à la fois à Apache YARN et MapReduce, par exemple, sont contenus dans des dossiers distincts dans.
/mnt/var/log
Les emplacements des fichiers journaux pour les composants Hadoop dans/mnt/var/log
sont les suivants : hadoop-hdfs, hadoop-mapreduce, hadoop-httpfs et hadoop-yarn. Le hadoop-state-pusher répertoire est destiné à la sortie du processus Hadoop State Pusher. -
Les journaux des actions d'amorçage – Si votre travail utilise des actions d'amorçage, les résultats de ces actions sont enregistrés. Les fichiers journaux sont stockés dans/mnt/var/log/bootstrap-actions/ sur le nœud principal. Chaque étape enregistre ses résultats dans un sous-répertoire distinct numéroté :
/mnt/var/log/bootstrap-actions/1/
pour la première action d'amorçage,/mnt/var/log/bootstrap-actions/2/
pour la deuxième action d'amorçage, et ainsi de suite. -
Les journaux d'état de l'instance – Ces journaux fournissent des informations sur l'UC, l'état de la mémoire et les threads de nettoyage de mémoire du nœud. Les fichiers journaux sont stockés dans
/mnt/var/log/instance-state/
sur le nœud primaire.
Archiver les fichiers journaux sur Amazon S3
Note
Vous ne pouvez pas actuellement utiliser l'agrégation des journaux vers Amazon S3 avec l'utilitaire yarn logs
.
Les versions 6.9.0 et ultérieures d'Amazon EMR archivent les journaux sur Amazon S3 pendant la réduction de la taille du cluster, de sorte que les fichiers journaux générés sur le cluster persistent même après que le nœud a été résilié. Ce comportement étant activé automatiquement, vous n'avez rien à faire pour l'activer. Pour les versions 6.8.0 et antérieures d'Amazon EMR, vous pouvez configurer un cluster pour archiver régulièrement les fichiers journaux stockés sur le nœud primaire vers Amazon S3. Vous avez ainsi la garantie que les fichiers journaux sont disponibles une fois que le cluster est résilié, qu'il s'agisse d'une fermeture normale ou d'une erreur. Amazon EMR archive les fichiers journaux sur Amazon S3 toutes les 5 minutes.
Pour que les fichiers journaux soient archivés dans Amazon S3 pour Amazon EMR versions 6.8.0 et antérieures, vous devez activer cette fonctionnalité lorsque vous lancez le cluster. Vous pouvez effectuer cette opération à l'aide de la console, de l'interface de ligne de commande ou de l'API. Par défaut, l'archivage des fichiers est activé pour les clusters lancés à l'aide de la console. Il doit être activé manuellement pour les clusters lancés dans Amazon S3 à l'aide de l'interface de ligne de commande ou de l'API.
Pour chiffrer les fichiers journaux stockés dans Amazon S3 avec une clé AWS KMS gérée par le client
Avec Amazon EMR version 5.30.0 et versions ultérieures (sauf Amazon EMR 6.0.0), vous pouvez chiffrer les fichiers journaux stockés dans Amazon S3 à l'aide d'une clé gérée par le client KMS. AWS Pour activer cette option dans la console, suivez les étapes de la section Archiver les fichiers journaux sur Amazon S3. Votre profil d' EC2 instance Amazon et votre rôle Amazon EMR doivent répondre aux conditions préalables suivantes :
-
Le profil d' EC2 instance Amazon utilisé pour votre cluster doit être autorisé à être utilisé
kms:GenerateDataKey
. -
Le rôle Amazon EMR utilisé pour votre cluster doit avoir l'autorisation d'utiliser
kms:DescribeKey
. -
Le profil d' EC2 instance Amazon et le rôle Amazon EMR doivent être ajoutés à la liste des utilisateurs clés pour la clé gérée par le client AWS KMS spécifiée, comme le montrent les étapes suivantes :
-
Ouvrez la console AWS Key Management Service (AWS KMS) à l'adresse https://console.aws.amazon.com/kms.
-
Pour modifier la AWS région, utilisez le sélecteur de région dans le coin supérieur droit de la page.
-
Sélectionnez l'alias de la clé KMS à modifier.
-
Sur la page de détails de la clé, sous Key Users (Utilisateurs de clés), choisissez Add (Ajouter).
-
Dans la boîte de dialogue Ajouter des utilisateurs clés, sélectionnez votre profil d' EC2 instance Amazon et votre rôle Amazon EMR.
-
Choisissez Ajouter.
-
Pour plus d'informations, consultez les rôles de service IAM utilisés par Amazon EMR et l'utilisation de politiques clés dans AWS le guide du développeur du service de gestion des clés.
Pour regrouper les journaux dans Amazon S3 à l'aide du fichier de configuration AWS CLI.
Note
Actuellement, vous ne pouvez pas utiliser l'agrégation des journaux avec l'utilitaire yarn logs
. Vous pouvez uniquement utiliser l'agrégation prise en charge par cette procédure.
L'agrégation de journaux (Hadoop 2.x) compile les journaux de tous les conteneurs d'une application individuelle en un seul fichier. Pour activer l'agrégation des journaux vers Amazon S3 à l'aide de AWS CLI, vous devez utiliser une action bootstrap au lancement du cluster afin d'activer l'agrégation des journaux et de spécifier le compartiment dans lequel les journaux seront stockés.
-
Pour activer le regroupement des journaux, créez le fichier de configuration suivant, appelé
myConfig.json
, qui contient les éléments suivants :[ { "Classification": "yarn-site", "Properties": { "yarn.log-aggregation-enable": "true", "yarn.log-aggregation.retain-seconds": "-1", "yarn.nodemanager.remote-app-log-dir": "s3:\/\/
DOC-EXAMPLE-BUCKET
\/logs" } } ]Tapez la commande suivante et
remplacez-la par le nom de votre paire de EC2 clés. Vous pouvez également remplacer n'importe quel texte rouge par vos propres configurations.myKey
aws emr create-cluster --name "
Test cluster
" \ --release-labelemr-7.6.0
\ --applications Name=Hadoop
\ --use-default-roles \ --ec2-attributes KeyName=myKey
\ --instance-typem5.xlarge
\ --instance-count3
\ --configurations file://./myConfig.jsonLorsque vous spécifiez le nombre d'instances sans utiliser le paramètre
--instance-groups
, un seul nœud primaire est lancé et les instances restantes sont lancées en tant que nœuds principaux. Tous les nœuds utiliseront le type d'instance spécifié dans la commande.Note
Si vous n'avez pas encore créé le rôle de service EMR et le profil d'EC2 instance par défaut, lancez-les avant
aws emr create-default-roles
d'exécuter lacreate-cluster
sous-commande.
Pour plus d'informations sur l'utilisation des commandes Amazon EMR dans le AWS CLI, consultez AWS CLI Command Reference.
Emplacements des journaux
La liste suivante inclut tous les types de journaux et leur emplacement dans Amazon S3. Vous pouvez les utiliser pour résoudre les problèmes liés à Amazon EMR.
- Journaux d'étapes
-
s3://
DOC-EXAMPLE-LOG-BUCKET
/<cluster-id>
/steps/<step-id>
/ - Journaux d'application
-
s3://
DOC-EXAMPLE-LOG-BUCKET
/<cluster-id>
/containers/Cet emplacement inclut le conteneur
stderr
etstdout
,directory.info
,prelaunch.out
, et les journauxlaunch_container.sh
. - Journaux du gestionnaire de ressources
-
s3://
DOC-EXAMPLE-LOG-BUCKET
/<cluster-id>
/node/<leader-instance-id>
/applications/hadoop-yarn/ - Hadoop HDFS
-
s3://
DOC-EXAMPLE-LOG-BUCKET
/<cluster-id>
/node/<all-instance-id>
/applications/hadoop-hdfs/Cet emplacement inclut NameNode DataNode, et les TimelineServer journaux YARN.
- Journaux du gestionnaire de nœuds
-
s3://
DOC-EXAMPLE-LOG-BUCKET
/<cluster-id>
/node/<all-instance-id>
/applications/hadoop-yarn/ - Journaux d'état de l'instance
-
s3://
DOC-EXAMPLE-LOG-BUCKET
/<cluster-id>
/node/<all-instance-id>
/daemons/instance-state/ - Journaux de provisionnement d'Amazon EMR
-
s3://
DOC-EXAMPLE-LOG-BUCKET
/<cluster-id>
/node/<leader-instance-id>
/provision-node/* - Journaux de la ruche
-
s3://
DOC-EXAMPLE-LOG-BUCKET
/<cluster-id>
/node/<leader-instance-id>
/applications/hive/*-
Pour trouver les journaux Hive sur votre cluster, supprimez l'astérisque (
*
) et ajoutez/var/log/hive/
au lien ci-dessus. -
Pour trouver HiveServer 2 journaux, supprimez l'astérisque (
*
) et ajoutez-lesvar/log/hive/hiveserver2.log
au lien ci-dessus. -
Pour trouver les journaux HiveCLI, supprimez l'astérisque (
*
) et ajoutez/var/log/hive/user/hadoop/hive.log
au lien ci-dessus. -
Pour trouver les journaux Hive Metastore Server, supprimez l'astérisque (
*
) et ajoutez/var/log/hive/user/hive/hive.log
au lien ci-dessus.
Si votre échec se situe dans le nœud principal ou le nœud de tâche de votre application Tez, fournissez les journaux du conteneur Hadoop approprié.
-