Fichiers journaux par défaut Archiver les fichiers journaux sur Amazon S3 Emplacements des journaux Contrôler le comportement de journalisation S3 (Amazon EMR 7.13.0 et versions ultérieures)

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 des fichiers journaux sur tous les nœuds. Ils sont écrits dans le répertoire /mnt/var/log/. Vous pouvez y accéder en utilisant SSH pour vous connecter à l'un des nœuds, comme décrit dansConnectez-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 ne sont pas enregistrés dans Amazon S3 lors de la fermeture du cluster. Vous ne pouvez donc pas accéder aux fichiers journaux une fois les nœuds terminés. 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é.

Il n'est pas nécessaire d'activer quoi que ce soit pour que les fichiers journaux soient écrits sur tous les nœuds. Il s'agit en effet du comportement par défaut d'Amazon EMR et de Hadoop.

Amazon EMR capture trois catégories de journaux pour la journalisation S3 :

Journaux du système : journaux du démon EMR
Journaux d'applications : journaux du framework provenant de Hadoop, Spark, Hive et d'autres applications exécutées sur le cluster
Journaux d'interface utilisateur persistants : journaux requis pour les applications persistantes UIs telles que Spark History Server et Tez UI

Sur le système de fichiers local, un cluster génère plusieurs types de fichiers journaux/mnt/var/log, notamment :

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-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 de 13 caractères (par exemple, stepId1, stepId2) sont spécifiques à un cluster.
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 /mnt/var/log sur tous les nœuds. 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 tous les nœuds. 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 /mnt/var/log/instance-state/ sur tous les nœuds.

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 tous les nœuds d'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.

Console

Pour archiver les fichiers journaux sur Amazon S3 avec la nouvelle console

Connectez-vous au et ouvrez la AWS Management Console console Amazon EMR à l'adresse /emr. https://console.aws.amazon.com
Sous EMR sur EC2 dans le volet de navigation de gauche, choisissez Clusters, puis Créer un cluster.
Sous Journaux du cluster, cochez la case Publier les journaux spécifiques au cluster sur Amazon S3.
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 instances EC2 du cluster sur Amazon S3. Cela évite que les fichiers journaux ne soient perdus lorsque le cluster se termine et que l'EC2 résilie les instances hébergeant le cluster. Ces journaux sont utiles à des fins de dépannage. Pour plus d'informations, consultez Affichage des fichiers journaux.
Cochez éventuellement la case Chiffrer les journaux spécifiques au cluster. Sélectionnez ensuite une AWS KMS clé dans la liste, entrez un ARN de clé ou créez une nouvelle clé. Cette option n'est disponible qu'avec Amazon EMR version 5.30.0 et ultérieure, à l'exclusion de la version 6.0.0. Pour utiliser cette option, ajoutez une autorisation AWS KMS pour votre profil d'instance EC2 et votre rôle Amazon EMR. Pour de plus amples informations, veuillez consulter Pour chiffrer les fichiers journaux stockés dans Amazon S3 à l'aide d'une clé gérée par le client AWS KMS.
Choisissez toutes les autres options qui s'appliquent à votre cluster.
Pour lancer cluster, choisissez Créer un cluster.

CLI

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

Pour archiver les 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.

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


aws emr create-cluster --name "Test cluster" --release-label emr-7.12.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

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 service Amazon EMR par défaut et le profil d'instance EC2, saisissez aws emr create-default-roles pour les créer avant de taper la sous-commande create-cluster.

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

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'instance Amazon EC2 et votre rôle Amazon EMR doivent répondre aux conditions préalables suivantes :

Le profil d'instance Amazon EC2 utilisé pour votre cluster doit être autorisé à utiliser kms:GenerateDataKey.
Le rôle Amazon EMR utilisé pour votre cluster doit avoir l'autorisation d'utiliser kms:DescribeKey.
Le profil d'instance Amazon EC2 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 :
1. Ouvrez la console AWS Key Management Service (AWS KMS) à l'adresse https://console.aws.amazon.com/kms.
2. Pour modifier la 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 clé KMS à 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'instance Amazon EC2 et votre rôle Amazon EMR.
6. Choisissez Ajouter.

Vous devez également configurer la clé KMS pour autoriser les persistentappui.elasticmapreduce.amazonaws.com et les principaux de elasticmapreduce.amazonaws.com service àkms:GenerateDataKey, kms:GenerateDataKeyWithoutPlaintext etkms:Decrypt. Cela permet à EMR de lire et d'écrire des journaux chiffrés à l'aide de la clé KMS pour accéder au stockage géré. Le rôle utilisateur IAM doit être autorisé à utiliser kms:GenerateDataKey etkms:Decrypt.


{
   "Sid": "Allow User Role to use KMS key",
   "Effect": "Allow",
   "Principal": {
        "AWS": "User Role"
    },
    "Action": [
        "kms:Decrypt", 
        "kms:GenerateDataKey"
   ],
    "Resource": "*",
    "Condition": {
        "StringLike": {
            "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*",
           "kms:ViaService": "elasticmapreduce.region.amazonaws.com"
       }
    }
},
{
    "Sid": "Allow Persistent APP UI to validate KMS key for write",
    "Effect": "Allow",
    "Principal":{
        "Service": [
            "elasticmapreduce.amazonaws.com"
        ]
     },
     "Action": [
       "kms:GenerateDataKeyWithoutPlaintext"
      ],
     "Resource": "*",
     "Condition": {
        "StringLike": {
            "aws:SourceArn": "arn:aws:elasticmapreduce:region:account:cluster/j-*",
            "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*"
        }
     }
},
{
    "Sid": "Allow Persistent APP UI to Write/Read Logs",
    "Effect": "Allow",
    "Principal":{
        "Service": [
            "persistentappui.elasticmapreduce.amazonaws.com",
            "elasticmapreduce.amazonaws.com"
        ]
     },
     "Action": [
       "kms:Decrypt",
       "kms:GenerateDataKey"
     ],
     "Resource": "*",
     "Condition": {
        "StringLike": {
            "aws:SourceArn": "arn:aws:elasticmapreduce:region:account:cluster/j-*",
            "kms:EncryptionContext:aws:elasticmapreduce:clusterId": "j-*",
            "kms:ViaService": "s3.region.amazonaws.com"
        }
     }
}

Pour des raisons de sécurité, nous vous recommandons d'ajouter les aws:SourceArn conditions kms:EncryptionContext et. Ces conditions permettent de garantir que la clé n'est utilisée que par Amazon EMR sur EC2 et uniquement pour les journaux générés par des tâches exécutées dans un cluster spécifique.

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 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 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 myKey par le nom de votre paire de clés EC2. Vous pouvez également remplacer n'importe quel texte rouge par vos propres configurations.
```
aws emr create-cluster --name "Test cluster" \
--release-label emr-7.12.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 service EMR et le profil d'instance EC2 par défaut, exécutez aws emr create-default-roles pour les créer avant d'exécuter la sous-commande create-cluster.

Pour plus d'informations sur l'utilisation des commandes Amazon EMR dans le AWS CLI, consultez AWS CLI Command Reference.

Outils d'autodiagnostic et de dépannage Amazon EMR

Ce runbook permet d'identifier les erreurs lors de l'exécution d'une tâche sur un cluster Amazon EMR. Le runbook analyse une liste de journaux définis sur le système de fichiers et recherche une liste de mots clés prédéfinis. Ces entrées de journal sont utilisées pour créer des CloudWatch événements Amazon Events afin que vous puissiez prendre les mesures nécessaires en fonction de ces événements. Le runbook publie éventuellement des entrées de journal dans le groupe de CloudWatch journaux Amazon Logs de votre choix. AWSSupport-AnalyzeEMRLogs.

Ce runbook permet de diagnostiquer les journaux Amazon EMR sur S3 à l'aide d'Amazon Athena en intégration avec AWS Glue Data Catalog. Amazon Athena est utilisé pour interroger les fichiers journaux Amazon EMR pour les conteneurs, les journaux des nœuds, ou les deux, avec des paramètres facultatifs pour des plages de dates spécifiques ou des recherches basées sur des mots clés. Ce runbook fournit la liste de toutes les erreurs et exceptions fréquemment survenues dans les journaux du cluster Amazon EMR, ainsi que les emplacements des journaux S3 correspondants. Il fournit également un résumé des exceptions connues uniques figurant dans les journaux Amazon EMR, ainsi que des solutions recommandées et des articles du Knowledge Center/Re:Post pour vous aider à résoudre les problèmes. AWSSupport-DiagnoseEMRLogsWithAthena

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 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 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-les var/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é.

Contrôler le comportement de journalisation S3 (Amazon EMR 7.13.0 et versions ultérieures)

À partir d'Amazon EMR 7.13.0, vous pouvez contrôler le comportement de téléchargement via la fonctionnalité S3. LoggingConfiguration Cela vous permet de définir différentes politiques de téléchargement pour différents types de journaux : journaux système, journaux d'applications et journaux d'interface utilisateur persistants.

Politiques de téléchargement

Pour chaque type de journal, vous pouvez définir l'une des politiques de téléchargement suivantes. Les types de journaux non spécifiés adopteront par défaut un comportement standard (géré par emr) :

emr-managed (par défaut): Comportement standard. Les journaux sont chargés sur Amazon S3 conformément à la configuration de votre navigateurLogUri, certains journaux étant conservés par le service à des fins de support opérationnel et de résolution des problèmes.
on-customer-s3 uniquement: Stockage géré par le client uniquement. Les journaux sont chargés uniquement dans le compartiment S3 spécifié par le client. Cela vous oblige à spécifier un LogUri lors de la création du cluster. Persistent-ui-logsne peut pas avoir de politique à on-customer-s 3 uniquement. Les politiques autorisées pour persistent-ui-logs sont gérées par EMR et désactivées.
désactivées: Aucun téléchargement S3 pour ce type de journal.

Exemples de configuration

Vous pouvez configurer la journalisation S3 lors de la création d'un nouveau cluster Amazon EMR via le AWS CLI, ou. AWS SDKs La configuration est spécifiée par le biais du MonitoringConfiguration paramètre.

Exemple : comportement par défaut

Si vous ne spécifiez pas S3LoggingConfiguration, tous les types de journaux adoptent par défaut un comportement géré par emr :


aws emr create-cluster \
--name "MyCluster" \
--release-label emr-7.13.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--log-uri s3://my-bucket/logs/ \
--use-default-roles

Exemple : configuration de journalisation S3 personnalisée

Cet exemple montre comment configurer différentes politiques de téléchargement pour chaque type de journal :


aws emr create-cluster \
--name "MyCluster" \
--release-label emr-7.13.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--log-uri s3://my-bucket/logs/ \
--use-default-roles \
--monitoring-configuration '{
    "S3LoggingConfiguration": {
        "LogTypeUploadPolicy": {
            "application-logs": "on-customer-s3only",
            "persistent-ui-logs": "disabled"
        }
    }
}'

Cette configuration télécharge les journaux d'application uniquement dans le compartiment S3 du client et désactive complètement les téléchargements persistants des journaux de l'interface utilisateur. Le type de journal non spécifié (journaux système) suit le comportement par défaut (géré par EMR).

Considérations

La configuration de journalisation S3 ne peut être définie qu'au moment de la création du cluster et ne peut pas être modifiée pour les clusters en cours d'exécution.
Persistent-ui-logs ne peut pas avoir de politique à on-customer-s 3 uniquement. Les politiques autorisées pour persistent-ui-logs sont gérées par EMR et désactivées.
LogUri Exigence : Lorsque vous utilisez la politique on-customer-s 3only pour les journaux système ou les journaux des applications, vous devez spécifier un paramètre. LogUri Dans le cas contraire LogUri, la création du cluster échouera.
Comportement par défaut : si S3 n'LoggingConfiguration est pas spécifié, tous les types de journaux adoptent par défaut un comportement géré par EMR.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Consignes et bonnes pratiques

Marquer et classer les ressources du cluster Amazon EMR