Etapa 3: examinar os arquivos de log

A próxima etapa é examinar os arquivos de log para localizar um código de erro ou outra indicação do problema que o cluster enfrentou. Para obter informações sobre os arquivos de log disponíveis, onde encontrá-los e como visualizá-los, consulte Exibir arquivos de log do .

Pode ser necessário realizar algum trabalho investigativo para determinar o que aconteceu. O Hadoop executa o trabalho em tentativas de tarefa em múltiplos nós do cluster. O Amazon EMR pode iniciar tentativas de tarefa especulativas, terminado as outras tentativas de tarefa que não foram concluídas primeiro. Isso gera uma atividade considerável que é registrada nos arquivos de log controller, stderr e syslog quando isso acontece. Além disso, várias tentativas de tarefa são executadas simultaneamente, mas um arquivo de log só pode exibir os resultados de forma linear.

Comece verificando os logs de ações de bootstrap em busca de erros ou alterações inesperadas na configuração durante a inicialização do cluster. A partir daí, consulte os logs de etapas para identificar trabalhos do Hadoop iniciados como parte de uma etapa com erros. Examine os logs de trabalhos do Hadoop para identificar as tentativas de tarefa com falha. O logs de tentativas de tarefa conterá detalhes sobre o que causou a falha de uma tentativa de tarefa.

As seções a seguir descrevem como usar os diversos arquivos de log para identificar erros no cluster.

Verificar os logs de ação de bootstrap

As ações de bootstrap executam scripts no cluster quando ele é iniciado. Geralmente são usados para instalar outros softwares no cluster ou para alterar as configurações com base nos valores padrão. Verificar esses logs pode fornecer insights sobre os erros que ocorreram durante a configuração do cluster, bem como das alterações nas configurações que podem afetar a performance.

Verificar os logs de etapa

Há quatro tipos de logs de etapas.

• controller: contém arquivos gerados pelo Amazon EMR (Amazon EMR) que surgem de erros encontrados ao tentar executar a etapa. Se a etapa falhar durante o carregamento, você encontrará o rastreamento da pilha nesse log. Os erros ao carregar ou acessar a aplicação muitas vezes são descritos aqui, assim como os erros ausentes do arquivo do mapeador.

• stderr: contém mensagens de erro que ocorreram durante o processamento da etapa. Os erros de carregamento de aplicações muitas vezes são descritos aqui. Às vezes, esse log contém um rastreamento de pilha.

• stdout: contém o status gerado pelos executáveis do mapeador e do redutor. Os erros de carregamento de aplicações muitas vezes são descritos aqui. Às vezes, o log contém mensagens de erro da aplicação.

• syslog: contém registros de softwares que não são da Amazon, como Apache e Hadoop. Os erros de transmissão muitas vezes são descritos aqui.

Verifique se há erros óbvios em stderr. Se stderr exibe uma pequena lista de erros, a etapa foi interrompida rapidamente com um erro gerado. Isso geralmente é causado por um erro nas aplicações mapeadoras e redutoras que estão sendo executadas no cluster.

Verifique se há em avisos de erros ou falhas nas últimas linhas do controller e do syslog. Siga todos os avisos sobre tarefas que falharam, sobretudo se estiver escrito “Job Failed”.

Verificar os logs de tentativa de tarefas

Se a análise anterior dos logs de etapas retornou uma ou mais tarefas com falha, investigue os logs das tentativas de tarefa correspondentes para obter informações mais detalhadas sobre o erro.

Verificar os logs de daemons do Hadoop

Em casos raros, o Hadoop em si poderá falhar. Para ver se esse é o caso, é necessário examinar os logs do Hadoop. Eles estão localizados em cada nó do /var/log/hadoop/.

Você pode usar os logs do JobTracker para mapear uma tentativa de tarefa com falha do nó em que ela foi executada. Depois de conhecer o nó associado à tentativa de tarefa, verifique a integridade da instância do EC2 que hospeda esse nó para ver se houve algum problema, como falta de CPU ou de memória.