Fase 3: Analisi dei file di log

Il passaggio successivo consiste nell'esaminare i file di log per individuare un codice di errore o altra indicazione relativa al problema riscontrato dal cluster. Per informazioni sui file di log disponibili, su dove trovarli e su come visualizzarli, consulta Visualizzare file di log di .

Potrebbe essere necessaria qualche indagine per determinare l'accaduto. Hadoop esegue il lavoro dei processi nei tentativi di attività su vari nodi del cluster. Amazon EMR può avviare tentativi di attività speculativi, interrompendo gli altri tentativi di attività che non vengono completati per primi. Questo genera un'attività significativa che viene registrata nei file di log del controller, stderr e syslog mentre si verifica. Inoltre, anche se più tentativi di attività vengono eseguiti contemporaneamente, un file di log può visualizzare i risultati solo in modo lineare.

Inizia controllando i log delle operazioni di bootstrap per individuare errori o modifiche impreviste alla configurazione durante l'avvio del cluster. Successivamente, cerca nei log di fase per identificare i processi Hadoop avviati come parte di una fase con errori. Esamina i log dei processi Hadoop per identificare i tentativi di attività non riusciti. Il log dei tentativi di attività conterrà dettagli su ciò che ha causato l'esito negativo di un tentativo di attività.

Le sezioni seguenti descrivono come utilizzare i vari file di log per identificare gli errori nel cluster.

Controllo dei log delle operazioni di bootstrap

Le operazioni di bootstrap eseguono script sul cluster mentre quest'ultimo viene avviato. Vengono comunemente utilizzate per installare software aggiuntivi nel cluster o per modificare le impostazioni di configurazione rispetto ai valori predefiniti. Il controllo di questi log può fornire informazioni dettagliate sugli errori verificatisi durante la configurazione del cluster e sulle modifiche alle impostazioni di configurazione che potrebbero influire sulle prestazioni.

Controllo dei log della fase

Esistono quattro tipi di log di fase.

• controller: contiene file generati da Amazon EMR (AmazonEMR) che derivano da errori riscontrati durante l'esecuzione del passaggio. Se la fase ha esito negativo durante il caricamento, è possibile trovare la traccia di stack in questo log. Gli errori che si verificano durante il caricamento o l'accesso all'applicazione sono spesso descritti nel log, mentre mancano gli errori relativi ai file del mappatore.

• stderr: contiene messaggi di errore che si sono presentati durante l'elaborazione della fase. Gli errori di caricamento delle applicazioni sono spesso descritti in questo log. Talvolta, questo log contiene una traccia di stack.

• stdout: contiene lo stato generato dagli eseguibili del mappatore e del riduttore. Gli errori di caricamento delle applicazioni sono spesso descritti in questo log. Talvolta, questo log contiene messaggi di errore dell'applicazione.

• syslog: contiene log generati da software non Amazon, come Apache e Hadoop. Gli errori di streaming sono spesso descritti in questo log.

Controlla stderr per rilevare errori evidenti. Se stderr visualizza un breve elenco di errori, la fase è giunta a un rapido arresto generando un errore. Questo è spesso causato da un errore nelle applicazioni di mappatore e riduttore eseguite nel cluster.

Esamina le ultime righe di controller e syslog per cercare avvisi di errore o guasti. Segui tutte le notifiche relative alle attività non riuscite, in particolare "Job Failed (Processo non riuscito)".

Controllo dei log del tentativo di attività

Se l'analisi precedente dei log di fase ha rilevato una o più attività non riuscite, esamina i log dei tentativi di attività corrispondenti per ottenere informazioni più dettagliate sugli errori.

Verifica dei log dei daemon Hadoop

In rari casi, Hadoop stesso potrebbe non funzionare. Per comprendere la natura del problema, è necessario esaminare i log di Hadoop. Questi log si trovano all'indirizzo /var/log/hadoop/ su ogni nodo.

È possibile utilizzare JobTracker i log per mappare un tentativo di operazione non riuscito al nodo su cui è stato eseguito. Una volta che conosci il nodo associato al tentativo di operazione, puoi controllare lo stato dell'EC2istanza che ospita quel nodo per vedere se si sono verificati problemi come l'esaurimento della CPU memoria.