Configuration de la journalisation et du débogage du cluster - Amazon EMR

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

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. Dans ce cas, vous souhaiterez probablement tirer parti de tous les outils de débogage proposés par AmazonEMR, tels que l'archivage des fichiers journaux sur 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 en vous SSH connectant au nœud principal, comme décrit dansConnectez-vous au nœud principal à l'aide de SSH. Amazon EMR collecte certains journaux du système et des applications générés par les EMR démons Amazon et d'autres EMR processus Amazon afin de garantir l'efficacité des opérations de service.

Note

Si vous utilisez Amazon 6.8.0 ou une EMR version antérieure, les fichiers journaux sont enregistrés dans Amazon S3 lors de la fermeture du cluster. Vous ne pouvez donc pas accéder aux fichiers journaux une fois le nœud principal arrêté. Amazon EMR publie la version 6.9.0 et les versions ultérieures archivent les journaux sur Amazon S3 lors de la réduction de la taille du cluster, de sorte que les fichiers journaux générés sur le cluster sont conservés même après la fermeture du nœud.

Vous n'avez pas besoin d'activer d'options pour que les fichiers journaux soient écrits sur le nœud primaire. Il s'agit 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'étapes : ces journaux sont générés par le EMR service Amazon 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-stepId1/ pour la première étape, /mnt/var/log/hadoop/steps/s-stepId2/ pour la deuxième étape, et ainsi de suite. Les identifiants d'étape à 13 caractères (par exemple stepId 1, stepId 2) sont uniques à un cluster.

  • Journaux Hadoop et des YARN composants : 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 primaire. 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.

  • Journaux d'état de l'instance : ces journaux fournissent des informations sur les threads du nœudCPU, sur l'état de la mémoire et sur le ramassage des déchets. 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.

Amazon EMR publie la version 6.9.0 et les versions ultérieures archivent les journaux sur Amazon S3 lors de la réduction de la taille du cluster, de sorte que les fichiers journaux générés sur le cluster sont conservés même après la fermeture du nœud. Ce comportement étant activé automatiquement, vous n'avez rien à faire pour l'activer. Pour les EMR versions 6.8.0 et antérieures d'Amazon, vous pouvez configurer un cluster pour archiver régulièrement les fichiers journaux stockés sur le nœud principal 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 les EMR versions 6.8.0 et antérieures d'Amazon, vous devez activer cette fonctionnalité lorsque vous lancez le cluster. Vous pouvez le faire à l'aide de la console, duCLI, ou duAPI. Par défaut, l'archivage des fichiers est activé pour les clusters lancés à l'aide de la console. Pour les clusters lancés à l'aide du CLI ouAPI, la connexion à Amazon S3 doit être activée manuellement.

Console
Pour archiver les fichiers journaux sur Amazon S3 avec la nouvelle console
  1. Connectez-vous au AWS Management Console, et ouvrez la EMR console Amazon à l'adresse https://console.aws.amazon.com/emr.

  2. Sous EMREC2Activé dans le volet de navigation de gauche, choisissez Clusters, puis Create cluster.

  3. Sous Journaux du cluster, cochez la case Publier les journaux spécifiques au cluster sur Amazon S3.

  4. Dans le champ Emplacement Amazon S3, saisissez (ou naviguez jusqu'à) un chemin Amazon S3 pour stocker vos journaux. Si vous tapez le nom d'un dossier qui n'existe pas dans le compartiment S3, Amazon S3 le crée.

    Lorsque vous définissez cette valeur, Amazon EMR copie les fichiers journaux des EC2 instances du cluster vers Amazon S3. Cela empêche la perte des fichiers journaux lorsque le cluster se termine et que les EC2 instances hébergeant le cluster sont supprimées. Ces journaux sont utiles à des fins de dépannage. Pour plus d'informations, consultez Affichage des fichiers journaux.

  5. Cochez éventuellement la case Chiffrer les journaux spécifiques au cluster. Ensuite, sélectionnez un AWS KMS tapez une clé dans la liste, entrez une clé ARN ou créez-en une nouvelle. Cette option n'est disponible qu'avec les EMR versions 5.30.0 et ultérieures d'Amazon, à l'exception de la version 6.0.0. Pour utiliser cette option, ajoutez l'autorisation de AWS KMS pour votre profil d'EC2instance et votre EMR rôle Amazon. Pour de plus amples informations, veuillez consulter Pour chiffrer les fichiers journaux stockés dans Amazon S3 à l'aide d'un AWS KMSclé gérée par le client.

  6. Choisissez toutes les autres options qui s'appliquent à votre cluster.

  7. Pour lancer cluster, choisissez Créer un cluster.

CLI
Pour archiver des fichiers journaux sur Amazon S3 à l'aide du AWS CLI

Pour archiver des fichiers journaux sur Amazon S3 à l'aide du AWS CLI, tapez la create-cluster commande et spécifiez le chemin du journal Amazon S3 à l'aide du --log-uri paramètre.

  1. Pour enregistrer des fichiers dans Amazon S3, tapez la commande suivante et remplacez myKey avec le nom de votre paire de EC2 clés.

    aws emr create-cluster --name "Test cluster" --release-label emr-7.2.0 --log-uri s3://DOC-EXAMPLE-BUCKET/logs --applications Name=Hadoop Name=Hive Name=Pig --use-default-roles --ec2-attributes KeyName=myKey --instance-type m5.xlarge --instance-count 3
  2. Lorsque 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 EMR service Amazon et le profil d'EC2instance par défaut, entrez aws emr create-default-roles pour les créer avant de taper la create-cluster sous-commande.

Pour chiffrer les fichiers journaux stockés dans Amazon S3 à l'aide d'un AWS KMSclé gérée par le client

Avec les EMR versions 5.30.0 et ultérieures d'Amazon (sauf Amazon EMR 6.0.0), vous pouvez chiffrer les fichiers journaux stockés dans Amazon S3 avec un AWS KMSclé gérée par le client. Pour activer cette option dans la console, suivez les étapes de la section Archiver les fichiers journaux sur Amazon S3. Votre profil d'EC2instance Amazon et votre EMR rôle Amazon doivent répondre aux conditions préalables suivantes :

  • Le profil d'EC2instance Amazon utilisé pour votre cluster doit être autorisé à être utilisékms:GenerateDataKey.

  • Le EMR rôle Amazon utilisé pour votre cluster doit être autorisé à être utilisékms:DescribeKey.

  • Le profil d'EC2instance Amazon et EMR le rôle Amazon doivent être ajoutés à la liste des utilisateurs clés pour le AWS KMSclé gérée par le client, comme le montrent les étapes suivantes :

    1. Ouvrez le fichier AWS Key Management Service (AWS KMS) console à l'adresse https://console.aws.amazon.com/kms.

    2. Pour modifier le AWS Région, utilisez le sélecteur de région dans le coin supérieur droit de la page.

    3. Sélectionnez l'alias de la KMS clé à modifier.

    4. Sur la page de détails de la clé, sous Key Users (Utilisateurs de clés), choisissez Add (Ajouter).

    5. Dans la boîte de dialogue Ajouter des utilisateurs clés, sélectionnez votre profil d'EC2instance Amazon et votre EMR rôle Amazon.

    6. Choisissez Ajouter.

Pour plus d'informations, consultez les IAMsections Rôles de service utilisés par Amazon EMR et Utilisation des politiques clés dans le AWS Guide du développeur du service de gestion des clés.

Pour agréger les journaux dans Amazon S3 à l'aide du 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 du AWS CLI, vous utilisez une action bootstrap au lancement du cluster pour activer l'agrégation des journaux et pour 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 myKey avec le nom de votre paire de EC2 clés. Vous pouvez également remplacer n'importe quel texte rouge par vos propres configurations.

    aws emr create-cluster --name "Test cluster" \ --release-label emr-7.2.0 \ --applications Name=Hadoop \ --use-default-roles \ --ec2-attributes KeyName=myKey \ --instance-type m5.xlarge \ --instance-count 3 \ --configurations file://./myConfig.json

    Lorsque 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 EMR service et le profil d'EC2instance par défaut, aws emr create-default-roles lancez-les avant d'exécuter la create-cluster sous-commande.

Pour plus d'informations sur l'utilisation EMR des commandes Amazon dans AWS CLI, voir AWS CLI Référence de commande.

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 EMR liés à Amazon.

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 et stdout, directory.info, prelaunch.out, et les journaux launch_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 YARN TimelineServer journaux.

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 EMR provisionnement Amazon

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-les var/log/hive/hiveserver2.log au lien ci-dessus.

  • Pour trouver les CLI journaux Hive, supprimez l'astérisque (*) et ajoutez-les /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é.