Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Configurazione del logging e del debug dei cluster Amazon EMR
Quando pianifichi il cluster, devi determinare la quantità di supporto di debug che vuoi rendere disponibile. Durante lo sviluppo iniziale dell'applicazione di elaborazione dati, ti consigliamo di testare l'applicazione su un cluster che elabora un piccolo, ma rappresentativo, sottoinsieme dei tuoi dati. È probabile che per eseguire questa operazione tu intenda utilizzare tutti gli strumenti di debug forniti da Amazon EMR, come l'archiviazione dei file di log in Amazon S3.
Una volta terminata la fase di sviluppo dell'applicazione di elaborazione dati e avviata quella di produzione, puoi scegliere di ridurre il debug. In questo modo, azzeri il costo relativo all'archiviazione degli archivi di file di log in Amazon S3 e riduci il carico di elaborazione sul cluster in quanto non è più necessario scrivere lo stato su Amazon S3. L'inconveniente di questa scelta è che in caso di problemi avrai a disposizione un minor numero di strumenti per gestirli.
File di log di default
Per impostazione predefinita, ogni cluster scrive file di log sul nodo primario. Questi file sono scritti nella directory /mnt/var/log/. Puoi accedervi utilizzando SSH per la connessione al nodo primario come descritto in Connect al nodo primario del cluster Amazon EMR tramite SSH. Amazon EMR raccoglie determinati log di sistema e applicazioni generati dai daemon Amazon EMR e da altri processi Amazon EMR per garantire operazioni di servizio efficaci.
Nota
Se utilizzi Amazon EMR versione 6.8.0 o precedenti, i file di log vengono salvati in Amazon S3 durante la terminazione del cluster, quindi non puoi accedere ai file di log una volta terminato il nodo primario. Amazon EMR versione 6.9.0 e successive archiviano i log in Amazon S3 durante la riduzione del cluster, cosicché i file di log generati sul cluster persistono anche dopo la terminazione del nodo.
Non è necessario attivare alcuna opzione affinché i file di log siano scritti sul nodo primario. In effetti, questo è il comportamento predefinito di Amazon EMR e Hadoop.
Un cluster genera vari tipi di file di log, tra cui:
-
Step logs (Log di fase): questi log sono generati dal servizio Amazon EMR e contengono informazioni sul cluster e i risultati di ogni fase. I file di log sono archiviati nella directory
/mnt/var/log/hadoop/steps/nel nodo primario. Ogni fase registra i risultati a essa relativi in una sottodirectory numerata distinta:/mnt/var/log/hadoop/steps/s-per la prima fase,stepId1//mnt/var/log/hadoop/steps/s-, per la seconda e così via. Gli identificatori di fase a 13 caratteri (ad esempio stepId1, stepId2) sono esclusivi di un cluster.stepId2/ -
Registri dei componenti Hadoop e YARN: i log dei componenti associati sia ad Apache YARN che, ad esempio, sono contenuti in cartelle separate in. MapReduce
/mnt/var/logLe posizioni dei file di log per i componenti Hadoop in/mnt/var/logsono le seguenti: hadoop-hdfs, hadoop-mapreduce, hadoop-httpfs e hadoop-yarn. La hadoop-state-pusher directory serve per l'output del processo Hadoop state pusher. -
Bootstrap action logs (Log delle operazioni di bootstrap): se il processo utilizza operazioni di bootstrap, i risultati di queste operazioni sono registrati. I file di registro sono memorizzati in/mnt/var/log/bootstrap-actions/ sul nodo primario. Ogni operazione di bootstrap registra i risultati a essa relativi in una sottodirectory numerata distinta:
/mnt/var/log/bootstrap-actions/1/per la prima operazione di bootstrap,/mnt/var/log/bootstrap-actions/2/per la seconda e così via. -
Instance state logs (Log di stato dell'istanza): forniscono informazioni su CPU, stato della memoria e thread del garbage collector del nodo. I file di log sono archiviati in
/mnt/var/log/instance-state/nel nodo primario.
Archiviazione di file di log in Amazon S3
Nota
Non è al momento possibile utilizzare l'aggregazione dei log in Amazon S3 con l'utility yarn logs.
Amazon EMR rilascio 6.9.0 e successivi archiviano i log in Amazon S3 durante la riduzione del cluster, cosicché i file di log generati sul cluster persistono anche dopo la terminazione del nodo. Questo comportamento è abilitato automaticamente, quindi non devi fare nulla per attivarlo. Per Amazon EMR rilascio 6.8.0 e precedenti, è possibile configurare un cluster per archiviare periodicamente i file di log presenti nel nodo primario in Amazon S3. In questo modo, i file di log saranno disponibili anche dopo la terminazione del cluster, indipendentemente dalla causa della stessa (arresto normale, errore, ecc.). Amazon EMR archivia i file di log in Amazon S3 ogni 5 minuti.
Per Amazon EMR rilascio 6.8.0 e successivi, per archiviare i file di log in Amazon S3 devi abilitare tale caratteristica all'avvio del cluster. Puoi eseguire tale operazione mediante la console, la CLI o l'API. Per impostazione predefinita, l'archiviazione dei log è abilitata per i cluster avviati utilizzando la console. Per i cluster avviati mediante la CLI o l'API, la registrazione in Amazon S3 deve essere abilitata manualmente.
Crittografia dei file di log archiviati in Amazon S3 con una chiave gestita dal cliente di AWS KMS
Con Amazon EMR versione 5.30.0 e successive (eccetto Amazon EMR 6.0.0), puoi crittografare i file di log archiviati in Amazon S3 con una chiave gestita dal cliente KMS. AWS Per abilitare questa opzione nella console, segui le fasi in Archiviazione di file di log in Amazon S3. Il tuo profilo di EC2 istanza Amazon e il tuo ruolo Amazon EMR devono soddisfare i seguenti prerequisiti:
-
Il profilo di EC2 istanza Amazon utilizzato per il tuo cluster deve essere autorizzato all'uso
kms:GenerateDataKey. -
Il ruolo Amazon EMR utilizzato per il cluster deve disporre dell'autorizzazione per utilizzare
kms:DescribeKey. -
Il profilo dell' EC2 istanza Amazon e il ruolo Amazon EMR devono essere aggiunti all'elenco degli utenti chiave per la chiave gestita dal cliente AWS KMS specificata, come dimostrano i seguenti passaggi:
-
Per cambiare la AWS regione, usa il selettore della regione nell'angolo in alto a destra della pagina.
-
Seleziona l'alias della chiave KMS da modificare.
-
Nella pagina dei dettagli della chiave, in Key Users (Utenti di chiavi), scegli Add (Aggiungi).
-
Nella finestra di dialogo Aggiungi utenti chiave, seleziona il tuo profilo di EC2 istanza Amazon e il ruolo Amazon EMR.
-
Scegli Aggiungi.
È inoltre necessario configurare la chiave KMS per consentire a
persistentappui---elasticmapreduce.amazonaws.com.rproxy.govskope.caandelasticmapreduce.amazonaws.com.rproxy.govskope.caService Principal di, e.kms:GenerateDataKeykms:GenerateDataKeyWithoutPlaintextkms:DecryptCiò consente a EMR di leggere e scrivere registri crittografati con la chiave KMS per lo storage gestito. L'utente IAM Role deve disporre dell'autorizzazione per utilizzare e.kms:GenerateDataKeykms: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" } } }Come best practice di sicurezza, ti consigliamo di aggiungere le
aws:SourceArncondizionikms:EncryptionContextand. Queste condizioni aiutano a garantire che la chiave venga utilizzata solo da Amazon EMR su EC2 e solo per i log generati dai lavori in esecuzione in un cluster specifico.
Per ulteriori informazioni, consulta i ruoli del servizio IAM utilizzati da Amazon EMR e Utilizzo delle politiche chiave nella guida per sviluppatori di AWS Key Management Service.
Aggregazione di log in Amazon S3 mediante la AWS CLI
Nota
Non è al momento possibile utilizzare l'aggregazione dei log con l'utility yarn logs. È possibile utilizzare soltanto l'aggregazione supportata da questa procedura.
L'aggregazione di log (Hadoop 2.x) compila i log di tutti i container di una singola applicazione in un unico file. Per abilitare l'aggregazione dei log su Amazon S3 utilizzando AWS CLI il, è necessario utilizzare un'azione bootstrap all'avvio del cluster per abilitare l'aggregazione dei log e specificare il bucket in cui archiviare i log.
-
Per abilitare l'aggregazione di log, crea il file di configurazione denominato
myConfig.json, che contiene quanto segue:[ { "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" } } ]Digita il comando seguente e
sostituiscilo con il nome della tua EC2 key pair. Puoi inoltre sostituire il testo in rosso con le configurazioni desiderate.myKeyaws emr create-cluster --name "Test cluster" \ --release-labelemr-7.10.0\ --applications Name=Hadoop\ --use-default-roles \ --ec2-attributes KeyName=myKey\ --instance-typem5.xlarge\ --instance-count3\ --configurations file://./myConfig.jsonQuando si specifica il numero di istanze senza utilizzare il parametro
--instance-groups, viene avviato un singolo nodo primario e le istanze rimanenti vengono avviate come nodi core. Tutti i nodi utilizzeranno il tipo di istanza specificato nel comando.Nota
Se in precedenza non sono stati creati il ruolo e il profilo di EC2 istanza del servizio EMR predefiniti, esegui
aws emr create-default-rolesper crearli prima di eseguire ilcreate-clustersottocomando.
Per ulteriori informazioni sull'utilizzo dei comandi Amazon EMR in AWS CLI, consulta AWS CLI Command Reference.
Strumenti di autodiagnostica e risoluzione dei problemi di Amazon EMR
Questo runbook aiuta a identificare gli errori durante l'esecuzione di un job su un cluster Amazon EMR. Il runbook analizza un elenco di log definiti sul file system e cerca un elenco di parole chiave predefinite. Queste voci di registro vengono utilizzate per creare CloudWatch eventi Amazon Events in modo da poter intraprendere tutte le azioni necessarie in base agli eventi. Facoltativamente, il runbook pubblica le voci di registro nel gruppo di log Amazon CloudWatch Logs di tua scelta. AWSSupport-AnalyzeEMRLogs.
Questo runbook aiuta a diagnosticare i log di Amazon EMR su S3 utilizzando Amazon Athena in integrazione con Glue Data Catalog. AWS Amazon Athena viene utilizzato per interrogare i file di log di Amazon EMR per contenitori, log dei nodi o entrambi, con parametri opzionali per intervalli di date specifici o ricerche basate su parole chiave. Questo runbook fornisce un elenco di tutti gli errori e le eccezioni ricorrenti presenti nei log del cluster Amazon EMR, insieme alle posizioni dei log S3 corrispondenti. Fornisce inoltre un riepilogo delle eccezioni note uniche riportate nei log di Amazon EMR, insieme alle risoluzioni consigliate e agli articoli del Knowledge Center/re:post per facilitare la risoluzione dei problemi. AWSSupport-DiagnoseEMRLogsWithAthena
Posizione dei log
L'elenco seguente include tutti i tipi di log e le relative posizioni in Amazon S3. Puoi utilizzarli per risolvere i problemi di Amazon EMR.
- Log delle fasi
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/steps/<step-id>/ - Log di applicazioni
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/containers/Questa posizione include i log del container
stderrestdout,directory.info,prelaunch.outelaunch_container.sh. - Log del gestore delle risorse
-
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/Questa posizione include, e i log YARN. NameNode DataNode TimelineServer
- Log del gestore dei nodi
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<all-instance-id>/applications/hadoop-yarn/ - Log degli stati istanza
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<all-instance-id>/daemons/instance-state/ - Log di provisioning di Amazon EMR
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<leader-instance-id>/provision-node/* - Log Hive
-
s3://DOC-EXAMPLE-LOG-BUCKET/<cluster-id>/node/<leader-instance-id>/applications/hive/*-
Per trovare i log di Hive sul tuo cluster, rimuovi l'asterisco (
*) e aggiungi/var/log/hive/al link precedente. -
Per trovare HiveServer 2 log, rimuovi l'asterisco (
*) evar/log/hive/hiveserver2.logaggiungilo al link precedente. -
Per trovare i log HiveCLI, rimuovi l'asterisco (
*) e aggiungi/var/log/hive/user/hadoop/hive.logal link precedente. -
Per trovare i log di Hive Metastore Server, rimuovi l'asterisco (
*) e aggiungi/var/log/hive/user/hive/hive.logal link precedente.
Se l'errore si trova nel nodo primario o nel nodo attività dell'applicazione Tez, fornisci i log del container Hadoop appropriato.
-