Monitorar o desempenho do cluster no Azure HDInsight

Monitorar a integridade e o desempenho de um cluster HDInsight é essencial para manter o desempenho ideal e a utilização de recursos. O monitoramento também pode ajudar a detectar e solucionar erros de configuração de cluster e problemas de código de usuário.

As seções a seguir descrevem como monitorar e otimizar a carga em seus clusters, filas do YARN do Apache Hadoop e detectar problemas de limitação de armazenamento.

Carga de cluster de monitor

Os clusters do Hadoop podem oferecer o desempenho mais ideal quando a carga no cluster é distribuída uniformemente em todos os nós. Isso permite que as tarefas de processamento sejam executadas sem serem restringidas por recursos de RAM, CPU ou disco em nós individuais.

Para obter uma visão de alto nível de nós do cluster e os respectivos carregamentos, entrar para o IU da Web do Ambari, em seguida, selecione a guia Hosts. Os hosts são listados pelos respectivos nomes de domínio totalmente qualificados. O status operacional de cada host é mostrado por um indicador de integridade colorido:

Você também verá colunas mostrando o número de núcleos e a quantidade de RAM para cada host, bem como o uso do disco e a carga média.

Selecione qualquer um dos nomes de host para ter uma visão detalhada dos componentes em execução nesse host, bem como suas métricas. As métricas são mostradas como uma linha do tempo selecionável de uso de CPU, carga, uso do disco, uso de memória, uso de rede e números de processos.

Consulte Gerenciar clusters HDInsight usando a interface do usuário da Web do Apache Ambari para obter detalhes sobre a configuração de alertas e exibição de métricas.

Configuração de fila do YARN

O Hadoop tem vários serviços em execução em sua plataforma distribuída. YARN (Yet Another Resource Negotiator) coordena esses serviços e aloca recursos de cluster para garantir que qualquer carga seja distribuída uniformemente pelo cluster.

O YARN divide as duas responsabilidades do JobTracker, o gerenciamento de recursos e o agendamento / monitoramento de tarefas em dois daemons: um Gerenciador de Recursos global e um ApplicationMaster (AM) por aplicativo.

O Resource Manager é um planejador puro e arbitra unicamente os recursos disponíveis entre todos os aplicativos concorrentes. O Gerenciador de Recursos garante que todos os recursos estejam sempre em uso, otimizando para várias constantes, como SLAs, garantias de capacidade e assim por diante. O ApplicationMaster negocia recursos do Gerenciador de Recursos e trabalha com o NodeManager para executar e monitorar os contêineres e seu consumo de recursos.

Quando vários locatários compartilham um grande cluster, ocorre uma competição pelos recursos do cluster. O CapacityScheduler é um agendador conectável que auxilia no compartilhamento de recurso através do enfileiramento de solicitações. O CapacityScheduler também dá suporte às filas hierárquicas a fim de garantir que os recursos sejam compartilhados entre as subfilas de uma organização, antes que outras filas de aplicativos tenham permissão para usar os recursos livres.

O YARN nos permite alocar recursos para essas filas e mostra se todos os recursos disponíveis estão atribuídos. Para visualizar informações sobre suas filas, entre na interface do usuário do Ambari Web e selecione YARN Queue Manager no menu superior.

A página do Gerenciador de Filas do YARN mostra uma lista de suas filas à esquerda, junto com o percentual da capacidade atribuída a cada uma.

Para obter informações mais detalhada sobre seu filas, no painel do Ambari, selecione o serviço YARN na lista à esquerda. Em seguida, no menu suspenso Links rápidos, selecione Interface do usuário do Gerenciador de Recursos abaixo do nó ativo.

Na interface do usuário do Gerenciador de Recursos, selecione Agendador no menu à esquerda. Você vê uma lista com as suas filas em Filas de Aplicativo. Aqui você pode ver a capacidade usada para cada uma das suas filas, como os trabalhos estão distribuídos entre elas e se algum trabalho está com limitação de recursos.

Limitação de armazenamento

O gargalo do desempenho de um cluster pode ocorrer no nível de armazenamento. Esse tipo de gargalo geralmente é devido ao bloqueio de operações de E/S (entrada/saída), o que ocorre quando as tarefas em execução enviam mais E/S do que o serviço de armazenamento pode manipular. Esse bloqueio cria uma fila de solicitações de E/S aguardando para serem processadas até que as E/Ss atuais sejam processadas. Os bloqueios são devidos à limitação de armazenamento, que não é um limite físico, mas um limite imposto pelo serviço de armazenamento através de um SLA (Contrato de Nível de Serviço). Esse limite serve para garantir que um único cliente ou locatário não monopolize o serviço. O SLA limita o número de IOPS (E/S por segundo) para o Armazenamento do Azure – para obter detalhes, confira Escalabilidade e metas de desempenho de contas de armazenamento Standard.

Caso você esteja usando o Armazenamento do Azure, para obter informações sobre monitoramento de problemas relacionados ao armazenamento, incluindo a limitação, consulte Monitorar, diagnosticar e solucionar problemas do Armazenamento do Microsoft Azure.

Se o repositório de backup do seu cluster for o ADLS (Azure Data Lake Storage), a limitação será provavelmente devida a limites de largura de banda. A limitação, nesse caso, poderia ser identificada pela observação de erros de limitação nos logs de tarefa. Para o ADLS, consulte a seção sobre limitação do serviço apropriado nesses artigos:

• Diretrizes de ajuste do desempenho para o Apache Hive no HDInsight e Azure Data Lake Storage
• Diretrizes de ajuste do desempenho para o MapReduce no HDInsight e Azure Data Lake Storage

Solucionar problemas de desempenho de nó lento

Em alguns casos, a lentidão pode ocorrer devido a pouco espaço em disco no cluster. Investigue com estas etapas:

1. Use o comando ssh para se conectar a cada um dos nós.

2. Verifique o uso do disco executando um dos seguintes comandos:

   df -h
   du -h --max-depth=1 / | sort -h
   

3. Examine a saída do comando e verifique a presença de arquivos grandes na pasta mnt ou em outras pastas. Normalmente, as pastas usercache e appcache (mnt/resource/hadoop/yarn/local/usercache/hive/appcache/) contêm arquivos grandes.

4. A presença de arquivos grandes indica que um trabalho atual está causando o aumento do arquivo, ou um trabalho anterior com falha pode ter contribuído para esse problema. Para verificar se esse comportamento está sendo causado por um trabalho atual, execute o seguinte comando:

   sudo du -h --max-depth=1 /mnt/resource/hadoop/yarn/local/usercache/hive/appcache/
   

5. Se esse comando indicar um trabalho específico, será possível optar por encerrar o trabalho usando um comando semelhante a este:

   yarn application -kill -applicationId <application_id>
   

   Substitua application_id pela ID do aplicativo. Se nenhum trabalho específico for indicado, vá para a próxima etapa.

6. Depois que o comando acima for concluído, ou se nenhum trabalho específico for indicado, exclua os arquivos grandes encontrados executando um comando semelhante ao seguinte:

   rm -rf filecache usercache
   

Para obter mais informações sobre problemas de espaço em disco, confira Sem espaço em disco.

Próximas etapas

Visite os links a seguir para obter mais informações sobre o monitoramento e a solução de problemas dos seus clusters:

• Analisar logs do HDInsight
• Depurar aplicativos com logs do YARN do Apache Hadoop
• Habilitar despejos de heap para serviços do Apache Hadoop no HDInsight baseado em Linux