Solucionar problemas de um trabalho do cluster do HDInsight lento ou com falha

Se um aplicativo processando dados em um cluster do HDInsight está com execução lenta ou falhando com um código de erro, há várias opções para solucionar problemas. Se os trabalhos estão demorando mais tempo do que o esperado ou se os tempos de resposta estão geralmente lentos, pode haver falhas de upstream do seu cluster, como os serviços em que o cluster é executado. No entanto, a causa mais comum desses gargalos é dimensionamento insuficiente. Ao criar um novo cluster do HDInsight, selecione os tamanhos de máquina virtual apropriados.

Para diagnosticar um cluster lento ou com falha, colete informações sobre todos os aspectos do ambiente, como os Serviços do Azure associados, a configuração do cluster e as informações de execução do trabalho. Um diagnóstico útil é tentar reproduzir o estado de erro em outro cluster.

• Etapa 1: colete dados sobre o problema.
• Etapa 2: valide o ambiente do cluster do HDInsight.
• Etapa 3: Exiba a integridade do cluster.
• Etapa 4: revise as versões e a pilha de ambientes.
• Etapa 5: examine os arquivos de log do cluster.
• Etapa 6: verifique as definições de configuração.
• Etapa 7: reproduza a falha em um cluster diferente.

Etapa 1: Coletar dados sobre o problema

O HDInsight fornece várias ferramentas que você pode usar para identificar e solucionar problemas com clusters. As etapas a seguir orientam você com relação a essas ferramentas e fornecem sugestões para identificar o problema.

Identificar o problema

Para ajudar a identificar o problema, considere as seguintes perguntas:

• O que eu esperava que acontecesse? Em vez disso, o que aconteceu?
• Quanto tempo o processo levou para ser executado? Em quanto tempo ele deveria ser executado?
• Minhas tarefas são sempre executadas lentamente neste cluster? A execução foi mais rápida em um outro cluster?
• Quando este problema ocorreu pela primeira vez? Com que frequência isso tem ocorrido?
• Houve alguma alteração na minha configuração do cluster?

Detalhes do cluster

Informações importantes do cluster incluem:

• Nome do cluster.
• Região do cluster – verifique interrupções de região.
• Tipo e versão do cluster HDInsight.
• Tipo e número de instâncias do HDInsight especificado para os nós de cabeçalho e de trabalho.

O Portal do Azure pode fornecer essas informações:

Também é possível usar a CLI do Azure:

az hdinsight list --resource-group <ResourceGroup>
az hdinsight show --resource-group <ResourceGroup> --name <ClusterName>

Outra opção é usar o PowerShell. Para obter mais informações, consulte Gerenciar clusters Apache Hadoop no HDInsight com o Azure PowerShell.

Etapa 2: Validar o ambiente do cluster HDInsight

Cada cluster HDInsight baseia-se em vários serviços do Azure e em softwares de código-fonte aberto como Apache HBase e Apache Spark. Os clusters HDInsight também podem chamar em outros serviços do Azure, como as Redes Virtuais do Azure. Uma falha do cluster pode ser causada por qualquer um dos serviços em execução no cluster ou por um serviço externo. Uma alteração de configuração do serviço do cluster também pode causar falha no cluster.

Detalhes do serviço

• Verifique as versões de lançamento da biblioteca de open-source.
• Verifique se há interrupções no serviço do Azure.
• Verifique os limites de uso do serviço do Azure
• Verifique a configuração de sub-rede da Rede Virtual do Azure.

Exibir definições de configuração do cluster com a interface de usuário do Ambari

O Apache Ambari fornece gerenciamento e monitoramento de um cluster HDInsight com uma interface do usuário da Web e uma API REST. O Ambari está incluído nos clusters HDInsight com base em Linux. Selecione o Painel do Cluster na página do HDInsight no Portal do Azure. Selecione o painel do cluster do HDInsight para abrir a interface do usuário do Ambari e insira as credenciais de logon do cluster.

Para abrir uma lista de modos de exibição do serviço, selecione Modos de exibição do Ambari na página do Portal do Azure. Essa lista depende de quais bibliotecas estão instaladas. Por exemplo, você poderá ver o Gerenciador de Fila do YARN, o Modo de Exibição do Hive e o Modo de Exibição do Tez. Selecione um link de serviço para ver informações de configuração e serviço.

Verificar interrupções de serviço do Azure

O HDInsight depende de vários serviços do Azure. Ele executa servidores virtuais no Azure HDInsight, armazena dados e scripts no Armazenamento de Blobs do Azure ou no Azure Data Lake Storage, e indexa arquivos de log no Armazenamento de Tabelas do Azure. Interrupções nesses serviços, embora raros, podem causar problemas no HDInsight. Se você encontrar lentidão inesperada ou falhas no cluster, verifique o Painel de Status do Azure. O status de cada serviço é listado por região. Verifique a região do seu cluster e também regiões para todos os serviços relacionados.

Verifique os limites de uso do serviço do Azure

Se você estiver iniciando um cluster grande ou tiver iniciado simultaneamente vários clusters, um cluster poderá falhar caso você tenha ultrapassado um limite do serviço do Azure. Os limites de serviço variam, dependendo de sua assinatura do Azure. Para saber mais, confira Assinatura e limites de serviço, cotas e restrições do Azure. Você pode solicitar que a Microsoft aumente o número de recursos de HDInsight disponíveis (por exemplo, núcleos de VMs e instâncias de VM) com uma solicitação de aumento de cota de núcleos do Gerenciador de Recursos.

Verificar a versão de lançamento

Compare a versão de cluster com a versão mais recente do HDInsight. Cada versão do HDInsight inclui aprimoramentos, como novos aplicativos, recursos, patches e correções de bugs. O problema que está afetando o seu cluster pode ter sido corrigido na versão mais recente. Se possível, execute novamente o cluster usando a versão mais recente do HDInsight e de bibliotecas associadas, como Apache HBase e Apache Spark, entre outras.

Reiniciar os serviços de cluster

Se houver lentidão no cluster, considere reiniciar os serviços por meio da interface do usuário do Ambari ou da CLI clássica do Azure. O cluster pode estar encontrando erros transitórios e reiniciar é a maneira mais rápida de estabilizar seu ambiente e possivelmente melhorar o desempenho.

Etapa 3: Verificar a integridade do cluster

Os clusters HDInsight são compostos de tipos diferentes de nós executados em instâncias de máquina virtual. Cada nó pode ser monitorado para privação de recursos, problemas de conectividade de rede e outros problemas que podem reduzir a velocidade do cluster. Cada cluster contém dois nós principais e a maioria dos tipos de cluster contém uma combinação de nós de trabalho e de borda.

Para obter uma descrição dos vários nós que cada tipo de cluster usa, consulte Configurar clusters no HDInsight com Apache Hadoop, Apache Spark, Apache Kafka e muito mais.

As seções a seguir descrevem como verificar a integridade de cada nó e do cluster geral.

Obter um instantâneo da integridade de cluster usando o painel de interface do usuário do Ambari

O painel de interface de usuário do Ambari (https://<clustername>.azurehdinsight.net) fornece uma visão geral da integridade do cluster, como tempo de atividade, memória, rede e uso da CPU, uso do disco HDFS e assim por diante. Use a Seção de hosts do Ambari para exibir recursos em um nível de host. Você também pode interromper e reiniciar serviços.

Verificar seu serviço WebHCat

Um cenário comum para falha nos trabalhos no Apache Hive, Apache Pig ou Apache Sqoop é uma falha com o serviço do WebHCat (ou Templeton). O WebHCat é uma interface REST para execução de trabalho remota, como o Hive, Pig e MapReduce. O WebHCat converte as solicitações de envio de trabalho em aplicativos de YARN do Apache Hadoop e retorna um status derivado do status do aplicativo YARN. As seções a seguir descrevem códigos comuns de status HTTP do WebHCat.

BadGateway (código de status 502)

Esse código é uma mensagem genérica de nós de gateway e é o código de status de falha mais comum. Uma causa possível para isso é o serviço WebHCat estar inativo no nó principal ativo. Para verificar essa possibilidade, use o seguinte comando CURL:

curl -u admin:{HTTP PASSWD} https://{CLUSTERNAME}.azurehdinsight.net/templeton/v1/status?user.name=admin

O Ambari exibe um alerta que mostra os hosts em que o serviço WebHCat está inativo. Você pode tentar fazer backup do serviço WebHCat reiniciando o serviço em seu host.

Se um servidor WebHCat ainda não aparecer, verifique o log de operações de mensagens de falha. Para obter mais informações, verifique os arquivos stderr e stdout referenciados no nó.

Tempo limite do WebHCat

Um Gateway de HDInsight expira respostas que levam mais de dois minutos, retornando 502 BadGateway. O WebHCat consulta serviços do YARN para status de trabalhos, e se o YARN demora mais que dois minutos para responder, a solicitação pode expirar.

Nesse caso, examine os seguintes logs no /var/log/webhcat diretório:

• webhcat.log é o log de Log4j nos quais o servidor grava logs
• webhcat console.log é o stdout do servidor quando iniciado
• webhcat-console-Error.log é o stderr do processo do servidor

Observação

Cada webhcat.log é rodado diariamente, gerando arquivos denominados webhcat.log.YYYY-MM-DD. Selecione o arquivo apropriado para o intervalo de tempo que você está investigando.

As seções a seguir descrevem algumas das possíveis causas de expiração de tempo limite do WebHCat.

Tempo limite do nível do WebHCat

Quando o WebHCat está sob carga, com mais de 10 soquetes abertos, leva mais tempo para estabelecer novas conexões de soquete, o que pode resultar na expiração do tempo limite. Para listar as conexões de rede de e para o WebHCat, use netstat no nó principal ativado atual:

netstat | grep 30111

30111 é a porta em que o WebHCat escuta. O número de soquetes abertos deve ser inferior a 10.

Se não houver nenhum soquete aberto, o comando anterior não produz nenhum resultado. Para verificar se o Templeton está ativo e escutando na porta 30111, use:

netstat -l | grep 30111

Tempo limite do nível de YARN

O Templeton chama o YARN para executar trabalhos, e a comunicação entre o Templeton e o YARN pode fazer com que um tempo limite seja atingido.

No nível do YARN, há dois tipos de tempos limite:

1. Enviar um trabalho do YARN pode levar tempo suficiente para fazer com que um tempo limite expire.

   Se você abrir o arquivo de log /var/log/webhcat/webhcat.log e pesquisar "trabalho em fila", poderá ver várias entradas em que o tempo de execução é excessivamente longo (> 2000 ms), com entradas mostrando tempos de espera crescentes.

   O tempo para os trabalhos em fila continua aumentando porque a taxa de envio de novos trabalhos é maior do que a taxa de conclusão de trabalhos antigos. Quando a memória de YARN atinge o nível de 100% de uso, a joblauncher queue não pode usar emprestada a capacidade da fila padrão. Portanto, nenhum novo trabalho pode ser aceito na fila do inicializador de trabalhos. Esse comportamento pode fazer com que o tempo de espera se torne cada vez maior, causando um erro de tempo limite que é geralmente seguido por muitos outros.

   A imagem a seguir mostra a fila do inicializador de trabalhos com um uso excessivo de 714.4%. Isso é aceitável desde que ainda haja capacidade livre para ser emprestada na fila padrão. No entanto, quando o cluster é totalmente utilizado e a memória do YARN está na capacidade máxima de 100%, novos trabalhos devem aguardar, fazendo com os tempos limite expirem.

   

   Há duas maneiras de resolver esse problema: reduzindo a velocidade de envio de novos trabalhos ou aumentando a velocidade de consumo de trabalhos antigos, aumentando o cluster.

2. O processamento do YARN pode levar algum tempo, o que pode fazer com os tempos limite expirem.

   • Listar todos os trabalhos: Essa é uma chamada demorada. Essa chamada enumera os aplicativos do Resource Manager do YARN e, para cada aplicativo concluído, obtém o status do JobHistoryServer do YARN. Com números maiores de trabalhos, essa chamada pode atingir tempo limite.

   • Listar trabalhos com mais de sete dias: o HDInsight do JobHistoryServer do YARN está configurado para reter informações de trabalhos concluídos por sete dias (mapreduce.jobhistory.max-age-ms valor). Tentar enumerar resultados de trabalhos limpos em um tempo limite.

Para diagnosticar esses problemas:

1. Determine o intervalo de tempo UTC para solucionar problemas
2. Selecione os webhcat.log arquivo(s) apropriado(s)
3. Procure por mensagens de AVISO e ERRO durante esse período

Outras falhas do WebHCat

1. Código de status HTTP 500

   Na maioria dos casos em que o WebHCat retorna o código de status HTTP 500, a mensagem de erro contém detalhes sobre a falha. Caso contrário, examine webhcat.log as mensagens de AVISO e ERRO.

2. Falhas de trabalho

   Pode haver casos onde as interações com o WebHCat são bem-sucedidas, mas os trabalhos estão falhando.

   O Templeton coleta a saída do console de trabalho como stderr em statusdir, o que geralmente é útil para solução de problemas. stderr contém o identificador do aplicativo YARN da consulta real.

Etapa 4: Revisar as versões e a pilha de ambiente

A página da Pilha e Versão da interface de usuário do Ambari fornece informações sobre configuração dos serviços de cluster e histórico de versão do serviço. Versões incorretas da biblioteca de serviço do Hadoop podem ser uma causa de falha no cluster. Na interface do usuário do Ambari, selecione o menu Admin e, em seguida, Pilhas e Versões. Selecione a guia Versões na página para ver as informações de versão do serviço:

Etapa 5: Examinar os arquivos de log

Há muitos tipos de logs que são gerados a partir dos muitos serviços e componentes que compõem um cluster HDInsight. Arquivos de log do WebHCat são descritos anteriormente. Há vários outros arquivos de log úteis que você pode investigar para reduzir problemas com seu cluster, conforme descrito nas seções a seguir.

• Os clusters HDInsight consistem de vários nós, a maioria dos quais é responsável por executar trabalhos enviados. Os trabalhos são executados simultaneamente, mas os arquivos de log só podem exibir os resultados linearmente. O HDInsight executa novas tarefas, encerrando outras que não foram concluídas antes. Todos essa atividade é registrada nos arquivos stderr e syslog.

• Os arquivos de log de ação de script mostram erros ou mudanças inesperadas de configuração durante o processo de criação do cluster.

• Os logs de etapa do Hadoop identificam trabalhos do Hadoop iniciados como parte de uma etapa que contém erros.

Verifique os logs de ação de script

As ações de script do HDInsight executam scripts no cluster manualmente ou quando especificado. Por exemplo, as ações de script podem ser usadas para instalar um software adicional no cluster ou alterar definições de configuração dos valores padrão. Verificar os logs de ações do script pode fornecer insights sobre erros ocorridos durante a instalação e configuração de cluster. Você pode visualizar o status de uma ação de script selecionando o botão ops na interface do usuário do Ambari ou acessando os logs da conta de armazenamento padrão.

Os logs de ação de script permanecem no \STORAGE_ACCOUNT_NAME\DEFAULT_CONTAINER_NAME\custom-scriptaction-logs\CLUSTER_NAME\DATE diretório.

Exibir logs de HDInsight usando os Links Rápidos do Ambari

A interface do usuário do HDInsight Ambari inclui uma série de seções de Links rápidos. Para acessar os links de log para um serviço específico em seu cluster HDInsight, abra a interface de usuário do Ambari para seu cluster e, em seguida, selecione o link do serviço na lista à esquerda. Selecione o menu suspenso Links rápidos, em seguida, o nó de interesse do HDInsight e, por fim, selecione o link para seu log associado.

Por exemplo, para logs HDFS:

Exibir arquivos de log gerados no Hadoop

Um cluster HDInsight gera logs que são gravados nas tabelas do Azure e no Armazenamento de Blobs do Azure. O YARN cria seus próprios logs de execução. Para obter mais informações, consulte Gerenciar logs para um cluster HDInsight.

Examinar os despejos de heap

Os despejos de heap contêm um instantâneo da memória do aplicativo, incluindo os valores das variáveis no momento, que são úteis para diagnosticar problemas que ocorrem no runtime. Para obter mais informações, consulte Habilitar despejos de heap para serviços de Apache Hadoop em HDInsight com base em Linux.

Etapa 6: Verificar as definições de configuração

Os clusters HDInsight são pré-configurados com configurações padrão para serviços relacionados como Hadoop, Hive, HBase e assim por diante. Dependendo do tipo do cluster, de sua configuração de hardware, do número de nós, dos tipos de trabalhos que você está executando e dos dados com que você está trabalhando (e de como esses dados estão sendo processados), talvez você precise otimizar sua configuração.

Para obter instruções detalhadas de como otimizar configurações de desempenho para a maioria dos cenários, consulte Otimizar configurações de cluster com o Apache Ambari. Ao usar o Spark, consulte Otimizar desempenho de trabalhos do Apache Spark.

Etapa 7: Reproduzir a falha em um cluster diferente

Para ajudar a diagnosticar a origem de um erro do cluster, inicie um novo cluster com a mesma configuração e reenvie uma por uma as etapas do trabalho. Verifique os resultados de cada etapa antes de processar a próxima. Esse método oferece a oportunidade de corrigir e executar novamente uma única etapa com falha. Esse método também tem a vantagem de carregar os dados de entrada apenas uma vez.

1. Crie um novo cluster de teste com a mesma configuração do cluster com falha.
2. Envie a primeira etapa de trabalho para o cluster de teste.
3. Quando a etapa concluir o processamento, verifique se há erros nos arquivos de log de etapa. Conecte-se ao nó principal do cluster de teste e visualize os arquivos de log. Os arquivos de log de etapa aparecem somente depois que a etapa é executada por algum tempo, é concluída ou falha.
4. Se a primeira etapa for bem-sucedida, execute a próxima etapa. Se houver erros, investigue o erro nos arquivos de log. Se foi um erro no código, faça a correção e execute novamente a etapa.
5. Continue até que todas as etapas sejam executadas sem erros.
6. Quando você terminar a depuração do cluster de teste, exclua-o.

Próximas etapas

• Gerenciar clusters HDInsight usando a interface do usuário da Web do Apache Ambari
• Analisar Logs do HDInsight
• Acessar a conexão do aplicativo YARN do Apache Hadoop no HDInsight baseado em Linux
• Habilitar despejos de heap para serviços do Apache Hadoop no HDInsight baseado em Linux
• Problemas conhecidos para o cluster do Apache Spark no HDInsight