As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Solução de problemas em clusters do Amazon EMR
Um cluster EMR é executado em um ecossistema complexo que inclui software de código aberto, código de aplicativo personalizado e. Serviços da AWS Quando ocorre um problema com qualquer uma dessas partes, o cluster pode falhar ou levar mais tempo do que o esperado para conclusão. Os tópicos a seguir podem ajudar a identificar problemas com o cluster e como corrigi-los.
**Topics**
+ [Que ferramentas estão disponíveis para a solução de problemas com um cluster do Amazon EMR?](emr-troubleshoot-tools.md)
+ [Visualizar e reiniciar processos do Amazon EMR e de aplicações (daemons)](emr-process-restart-stop-view.md)
+ [Coleções de erros comuns do Amazon EMR](emr-troubleshoot-errors.md)
+ [Solucionar problemas de um cluster do Amazon EMR que falhou com um código de erro](emr-troubleshoot-failed.md)
+ [Solucionar problemas com um cluster lento do Amazon EMR](emr-troubleshoot-slow.md)
+ [Solucione problemas comuns ao usar o Amazon EMR AWS com o Lake Formation](emr-troubleshoot-lf.md)
Orientação sobre solução de problemas com [aplicações Spark no EMR](https://aws.github.io/aws-emr-best-practices/docs/bestpractices/Applications/Spark/troubleshooting/).
Ao desenvolver uma nova aplicação Hadoop, é recomendável habilitar a depuração e processar um subconjunto pequeno, mas representativo, de seus dados para testar a aplicação. Talvez você também queira executar o aplicativo step-by-step para testar cada etapa separadamente. Para obter mais informações, consulte [Configuração de registro em log e depuração do cluster do Amazon EMR](emr-plan-debugging.md) e [Etapa 5: testar o cluster do Amazon EMR passo a passo](emr-troubleshoot-failed-5-test-steps.md).
# Que ferramentas estão disponíveis para a solução de problemas com um cluster do Amazon EMR?
Para identificar e corrigir erros de cluster, use as ferramentas descritas nesta página. Talvez seja necessário inicializar algumas ferramentas ao iniciar o cluster. Outras ferramentas estão disponíveis para todos os clusters por padrão.
**Topics**
+ [Visualizar detalhes do cluster do EMR](#emr-troubleshoot-tools-details)
+ [Visualizar detalhes do erro do cluster do EMR](#emr-troubleshoot-errordetail)
+ [Executar scripts e configurar processos do Amazon EMR](#emr-troubleshoot-tools-commands)
+ [Exibir arquivos de log do](#emr-troubleshoot-tools-logs)
+ [Monitorar a performance do cluster do EMR](#emr-troubleshoot-tools-performance)
## Visualizar detalhes do cluster do EMR
Você pode usar a API Console de gerenciamento da AWS AWS CLI, ou EMR para recuperar informações detalhadas sobre um cluster do EMR e a execução de trabalhos. Para obter mais informações sobre como usar o Console de gerenciamento da AWS e AWS CLI, consulte[Exibição de status e detalhes do cluster do Amazon EMR](emr-manage-view-clusters.md).
### Painel de detalhes do console do Amazon EMR
Na lista **Clusters** no console do Amazon EMR, você pode ver informações de alto nível sobre o status de cada cluster em sua conta e Região da AWS. A lista exibe todos os clusters ativos e terminados que você iniciou nos últimos dois meses. Na lista **Clusters**, você pode selecionar um **Name (Nome)** de cluster para visualizar detalhes do cluster. Essas informações são organizadas em diferentes categorias para facilitar a navegação.
As **interfaces do usuário da aplicação** disponíveis na página de detalhes do cluster podem ser para solucionar problemas de cluster. Ele fornece o status de aplicações do YARN e, para algumas, como aplicações Spark, você pode se aprofundar em diferentes métricas e facetas, como trabalhos, preparação e executores. Para obter mais informações, consulte [Como exibir o histórico da aplicação do Amazon EMR](emr-cluster-application-history.md). Esse atributo está disponível somente no Amazon EMR 5.8.0 e versões posteriores.
### Interface de linha de comando do Amazon EMR
Você pode localizar detalhes sobre um cluster usando o `--describe` argumento AWS CLI with the.
### API do Amazon EMR
Você pode localizar detalhes sobre um cluster na API usando a ação `DescribeJobFlows`.
## Visualizar detalhes do erro do cluster do EMR
Quando um cluster do EMR termina com um erro, o `DescribeCluster` e `ListClusters` APIs retorna um código de erro e uma mensagem de erro. Para erros de cluster selecionados, a matriz de dados `ErrorDetail` pode ajudar a solucionar a falha.
Para obter uma lista de códigos de erro que incluam dados `ErrorDetail`, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md).
**nota**
Refinamos continuamente nossas mensagens de erro para você receber as informações mais recentes e pertinentes. Não é recomendável analisar o texto de `ErrorMessage` porque ele está sujeito a alterações.
## Executar scripts e configurar processos do Amazon EMR
Como parte do processo de solução de problemas, talvez seja útil executar scripts personalizados no cluster ou visualizar e configurar processos de cluster.
### Visualizar e reiniciar processos da aplicação
Pode ser útil visualizar os processos em execução no cluster para diagnosticar possíveis problemas. Você pode interromper e reiniciar os processos do cluster conectando-se ao nó principal do cluster. Para obter mais informações, consulte [Visualizar e reiniciar processos do Amazon EMR e de aplicações (daemons)](emr-process-restart-stop-view.md).
### Executar comandos e scripts sem uma conexão SSH
Para executar um comando ou script no cluster como uma etapa, você pode usar as ferramentas `command-runner.jar` ou `script-runner.jar` sem estabelecer uma conexão SSH com o nó principal. Para obter mais informações, consulte [Run commands and scripts on an Amazon EMR cluster](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-commandrunner.html).
## Exibir arquivos de log do
Tanto o Amazon EMR como o Hadoop geram arquivos de log conforme o cluster é executado. Você pode acessar esses arquivos de log de várias ferramentas diferentes, dependendo da configuração especificada ao iniciar o cluster. Para obter mais informações, consulte [Configuração de registro em log e depuração do cluster do Amazon EMR](emr-plan-debugging.md).
### Arquivos de log no nó principal
Cada cluster publica arquivos de registros no diretório/mnt/var/log/no nó principal. Esses arquivos de log estão disponíveis apenas enquanto o cluster está em execução.
### Arquivos de log arquivados no Amazon S3
Se você iniciar o cluster e especificar um caminho de log do Amazon S3, o cluster copiará os arquivos de log armazenados em/mnt/var/log/no nó principal para o Amazon S3 em intervalos de 5 minutos. Isso garante que você terá acesso aos arquivos de log, mesmo depois que o cluster for encerrado. Como os arquivos são arquivados em intervalos de 5 minutos, os últimos minutos de um cluster repentinamente encerrado podem não estar disponíveis.
## Monitorar a performance do cluster do EMR
O Amazon EMR fornece várias ferramentas para monitorar a performance do cluster.
### Interfaces Web do Hadoop
Cada cluster publica um conjunto de interfaces Web no nó principal que contêm informações sobre o cluster. Você pode acessar essas páginas da Web usando um túnel SSH para conectá-las ao nó principal. Para obter mais informações, consulte [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md).
### CloudWatch métricas
Cada cluster reporta métricas para CloudWatch. CloudWatch é um serviço da web que rastreia métricas e que você pode usar para definir alarmes sobre essas métricas. Para obter mais informações, consulte [Monitorando métricas do Amazon EMR com CloudWatch](UsingEMR_ViewingMetrics.md).
# Visualizar e reiniciar processos do Amazon EMR e de aplicações (daemons)
Ao solucionar problemas em um cluster, você pode relacionar os processos em execução. Também pode ser útil interromper ou reiniciar processos. Por exemplo, você pode reiniciar os processos após alterar uma configuração ou observar um problema com um determinado processo após a análise de arquivos de log e mensagens de erro.
Há dois tipos de processos que são executados em um cluster: processos do Amazon EMR (por exemplo, controlador de instância e Log Pusher) e processos associados aos aplicativos instalados no cluster (por exemplo, e). hadoop-hdfs-namenode hadoop-yarn-resourcemanager
Para trabalhar com os processos diretamente em um cluster, primeiro é necessário conectar-se ao nó principal. Para obter mais informações, consulte [Conectar-se a um cluster do Amazon EMR](emr-connect-master-node.md).
## Visualizar processos em execução
O método que você usa para visualizar os processos que estão em execução em um cluster difere de acordo com a versão do Amazon EMR utilizada.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : Listar todos os processos em execução**
O exemplo a seguir usa `systemctl` e especifica `--type` para visualizar todos os processos.
```
systemctl --type=service
```
**Example : Listar processos específicos**
O exemplo a seguir lista todos os processos com nomes que contenham `hadoop`.
```
systemctl --type=service | grep -i hadoop
```
Resultado do exemplo:
```
hadoop-hdfs-namenode.service loaded active running Hadoop namenode
hadoop-httpfs.service loaded active running Hadoop httpfs
hadoop-kms.service loaded active running Hadoop kms
hadoop-mapreduce-historyserver.service loaded active running Hadoop historyserver
hadoop-state-pusher.service loaded active running Daemon process that processes and serves EMR metrics data.
hadoop-yarn-proxyserver.service loaded active running Hadoop proxyserver
hadoop-yarn-resourcemanager.service loaded active running Hadoop resourcemanager
hadoop-yarn-timelineserver.service loaded active running Hadoop timelineserver
```
**Example : Ver um relatório de status detalhado de um processo específico**
O exemplo a seguir exibe um relatório de status detalhado do serviço `hadoop-hdfs-namenode`.
```
sudo systemctl status hadoop-hdfs-namenode
```
Resultado do exemplo:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-18 21:01:46 UTC; 26min ago
Main PID: 9733 (java)
Tasks: 0
Memory: 1.1M
CGroup: /system.slice/hadoop-hdfs-namenode.service
‣ 9733 /etc/alternatives/jre/bin/java -Dproc_namenode -Xmx1843m -server -XX:OnOutOfMemoryError=kill -9 %p ...
Aug 18 21:01:37 ip-172-31-20-123 systemd[1]: Starting Hadoop namenode...
Aug 18 21:01:37 ip-172-31-20-123 su[9715]: (to hdfs) root on none
Aug 18 21:01:37 ip-172-31-20-123 hadoop-hdfs-namenode[9683]: starting namenode, logging to /var/log/hadoop-hdfs/ha...out
Aug 18 21:01:46 ip-172-31-20-123 hadoop-hdfs-namenode[9683]: Started Hadoop namenode:[ OK ]
Aug 18 21:01:46 ip-172-31-20-123 systemd[1]: Started Hadoop namenode.
Hint: Some lines were ellipsized, use -l to show in full.
```
------
#### [ EMR 4.x - 5.29.0 ]
**Example : Listar todos os processos em execução**
O exemplo a seguir lista todos os processos que estão em execução.
```
initctl list
```
------
#### [ EMR 2.x - 3.x ]
**Example : Listar todos os processos em execução**
O exemplo a seguir lista todos os processos que estão em execução.
```
ls /etc/init.d/
```
------
## Interromper e reiniciar processos
Depois de determinar quais processos estão em execução, você pode interrompê-los e reiniciá-los, se necessário.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : Interromper um processo**
O exemplo a seguir interrompe o processo `hadoop-hdfs-namenode`.
```
sudo systemctl stop hadoop-hdfs-namenode
```
Consulte o `status` para verificar se o processo foi interrompido.
```
sudo systemctl status hadoop-hdfs-namenode
```
Resultado do exemplo:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2021-08-18 21:37:50 UTC; 8s ago
Main PID: 9733 (code=exited, status=143)
```
**Example : Iniciar um processo**
O exemplo a seguir inicia o processo `hadoop-hdfs-namenode`.
```
sudo systemctl start hadoop-hdfs-namenode
```
Consulte o status para verificar se o processo está em execução.
```
sudo systemctl status hadoop-hdfs-namenode
```
Resultado do exemplo:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-18 21:38:24 UTC; 2s ago
Process: 13748 ExecStart=/etc/init.d/hadoop-hdfs-namenode start (code=exited, status=0/SUCCESS)
Main PID: 13800 (java)
Tasks: 0
Memory: 1.1M
CGroup: /system.slice/hadoop-hdfs-namenode.service
‣ 13800 /etc/alternatives/jre/bin/java -Dproc_namenode -Xmx1843m -server -XX:OnOutOfMemoryError=kill -9 %p...
```
------
#### [ EMR 4.x - 5.29.0 ]
**Example : Interromper um processo em execução**
O exemplo a seguir interrompe o serviço `hadoop-hdfs-namenode`.
```
sudo stop hadoop-hdfs-namenode
```
**Example : Reiniciar um processo interrompido**
O exemplo a seguir reinicia o serviço `hadoop-hdfs-namenode`. Você deve usar o comando `start` em vez de `restart`.
```
sudo start hadoop-hdfs-namenode
```
**Example : Verificar o status do processo**
O exemplo a seguir busca o status de `hadoop-hdfs-namenode`. Você pode usar o comando `status` para verificar se o processo foi interrompido ou iniciado.
```
sudo status hadoop-hdfs-namenode
```
------
#### [ EMR 2.x - 3.x ]
**Example : Interromper um processo da aplicação**
O exemplo a seguir interrompe o serviço `hadoop-hdfs-namenode`, que está associado à versão do Amazon EMR instalada no cluster.
```
sudo /etc/init.d/hadoop-hdfs-namenode stop
```
**Example : Reiniciar um processo da aplicação**
O exemplo de comando a seguir reinicia o processo `hadoop-hdfs-namenode`:
```
sudo /etc/init.d/hadoop-hdfs-namenode start
```
**Example : Interromper um processo do Amazon EMR**
O exemplo a seguir interrompe um processo, como instance-controller, que não esteja associado à versão do Amazon EMR no cluster.
```
sudo /sbin/stop instance-controller
```
**Example : Reiniciar um processo do Amazon EMR**
O exemplo a seguir reinicia um processo, como instance-controller, que não esteja associado à versão do Amazon EMR no cluster.
```
sudo /sbin/start instance-controller
```
**nota**
Os comandos `/sbin/start, stop` e `restart` são symlinks para `/sbin/intictl`. Para obter mais informações sobre `initctl`, consulte a página do manual do initctl digitando `man initctl` no prompt de comando.
------
# Coleções de erros comuns do Amazon EMR
Às vezes, os clusters falham ou demoram para processar os dados. As seções a seguir listam problemas comuns de cluster. Os erros incluem falhas de bootstrap e erros de validação, com sugestões sobre como resolvê-los.
**Topics**
+ [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md)
+ [Erros de recursos durante as operações de cluster do Amazon EMR](emr-troubleshoot-error-resource.md)
+ [Erros de entrada e saída do cluster durante as operações do Amazon EMR](emr-troubleshoot-errors-io.md)
+ [Erros de permissões durante as operações de cluster do Amazon EMR](emr-troubleshoot-error-permissions.md)
+ [Erros de cluster do Hive](emr-troubleshoot-error-hive.md)
+ [Erros da VPC durante as operações de cluster do Amazon EMR](emr-troubleshoot-error-vpc.md)
+ [Erros em clusters de streaming no Amazon EMR](emr-troubleshoot-error-streaming.md)
+ [Amazon EMR: erros de cluster com JAR personalizado](emr-troubleshoot-error-custom-jar.md)
+ [Erros do Amazon EMR AWS GovCloud (Oeste dos EUA)](emr-troubleshoot-error-govcloud.md)
+ [Encontrar um cluster ausente](#w2aac36c21c47)
# Códigos de erro com ErrorDetail informações no Amazon EMR
Quando um cluster do EMR termina com um erro, o `DescribeCluster` e `ListClusters` APIs retorna um código de erro e uma mensagem de erro. Para alguns erros de cluster, a matriz de dados `ErrorDetail` pode ajudar a solucionar a falha.
Os erros que incluem uma matriz `ErrorDetail` fornecem os seguintes detalhes:
**`ErrorCode`**
Um código de erro exclusivo que pode ser usado para acesso programático.
**`ErrorData`**
Uma lista de identificadores em pares de chave-valor que podem ser usados para programação ou pesquisa manual. Para obter descrições dos valores de `ErrorData` que um código de erro inclui, consulte a página de solução de problemas do código de erro.
**`ErrorMessage`**
Descrição do erro com um link para mais informações na documentação do Amazon EMR.
Não é recomendável analisar o texto de `ErrorMessage` porque está sujeito a alterações.
**Topics**
+ [Falhas de bootstrap](emr-troubleshoot-error-errordetail-bootstrap.md)
+ [Erros internos](emr-troubleshoot-error-errordetail-internal.md)
+ [Falhas de validação](emr-troubleshoot-error-errordetail-validation.md)
# Códigos de erro de falha de bootstrap no Amazon EMR
As seções a seguir fornecem informações sobre solução de problemas para códigos de erro de falha de bootstrap.
**Topics**
+ [BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE](BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE.md)
+ [BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY](BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY](BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER.md)
# BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE
## Visão geral do
Quando um cluster é terminado com um erro `BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE`, uma ação de bootstrap falhou na instância primária. Para obter mais informações sobre ações de bootstrap, consulte [Como criar ações de bootstrap para instalar softwares adicionais com um cluster do Amazon EMR](emr-plan-bootstrap.md).
## Resolução
Para resolver esse erro, revise os detalhes retornados no erro da API, modifique o script de ação de bootstrap e crie um novo cluster com a ação de bootstrap atualizada.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`primary-instance-id`**
O ID da instância primária em que a ação de bootstrap falhou.
**`bootstrap-action`**
O número ordinal da ação de bootstrap com falha. Um script com um valor `bootstrap-action` de `1` é a primeira ação de bootstrap a ser executada na instância.
**`return-code`**
O código de retorno para a ação de bootstrap com falha.
**`amazon-s3-path`**
O local da ação de bootstrap com falha no Amazon S3.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Execute as etapas a seguir para identificar e corrigir a causa raiz do erro de ação de bootstrap. Em seguida, inicie um novo cluster.
1. Analise os arquivos de log de ações de bootstrap no Amazon S3 para identificar a causa raiz da falha. Para saber mais sobre como visualizar os logs do Amazon EMR, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
1. Se você ativou os logs do cluster ao criar a instância, consulte o log `stdout` para obter mais informações. Você encontra o log `stdout` da ação de bootstrap neste local do Amazon S3:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
Para obter mais informações sobre logs de clusters, consulte [Configuração de registro em log e depuração do cluster do Amazon EMR](emr-plan-debugging.md).
1. Para determinar a falha na ação de bootstrap, revise as exceções nos logs `stdout` e o valor `return-code` em `ErrorData`.
1. Use suas descobertas da etapa anterior para revisar a ação de bootstrap para que ela evite exceções ou consiga lidar com exceções normalmente quando elas ocorrerem.
1. Inicie um novo cluster com a ação de bootstrap atualizada.
# BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY
## Visão geral do
Um cluster é encerrado com o erro `BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY` quando a instância primária não consegue baixar um script de ação de bootstrap no local do Amazon S3 especificado. As possíveis causas incluem:
+ O arquivo de script de ação de bootstrap não está no local especificado do Amazon S3.
+ O perfil de serviço para instâncias do Amazon EC2 no cluster (também chamada de *perfil de instância do EC2 para o Amazon EMR*) não tem permissões para acessar o bucket do Amazon S3 onde o script de ação de bootstrap reside. Para obter mais informações sobre perfis de serviço, consulte [Perfil de serviço para instâncias do EC2 do cluster (perfil de instância do EC2)](emr-iam-role-for-ec2.md).
Para obter mais informações sobre ações de bootstrap, consulte [Como criar ações de bootstrap para instalar softwares adicionais com um cluster do Amazon EMR](emr-plan-bootstrap.md).
## Resolução
Para resolver esse erro, certifique-se de que a instância primária tem o devido acesso ao script de ação de bootstrap.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`primary-instance-id`**
O ID da instância primária em que a ação de bootstrap falhou.
**`bootstrap-action`**
O número ordinal da ação de bootstrap com falha. Um script com um valor `bootstrap-action` de `1` é a primeira ação de bootstrap a ser executada na instância.
**`amazon-s3-path`**
O local da ação de bootstrap com falha no Amazon S3.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Execute as etapas a seguir para identificar e corrigir a causa raiz do erro de ação de bootstrap. Em seguida, inicie um novo cluster.
**Etapas de solução de problemas**
1. Use o valor `amazon-s3-path` da matriz `ErrorData` para encontrar o script de ação de bootstrap relevante no Amazon S3.
1. Se você ativou os logs do cluster ao criar a instância, consulte o log `stdout` para obter mais informações. Você encontra o log `stdout` da ação de bootstrap neste local do Amazon S3:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
Para obter mais informações sobre logs de clusters, consulte [Configuração de registro em log e depuração do cluster do Amazon EMR](emr-plan-debugging.md).
1. Para determinar a falha na ação de bootstrap, revise as exceções nos logs `stdout` e o valor `return-code` em `ErrorData`.
1. Use suas descobertas da etapa anterior para revisar a ação de bootstrap para que ela evite exceções ou consiga lidar com exceções normalmente quando elas ocorrerem.
1. Inicie um novo cluster com a ação de bootstrap atualizada.
# BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY
## Visão geral do
O erro `BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY` indica que a instância primária não consegue encontrar o script de ação de bootstrap que a instância acabou de baixar no bucket do Amazon S3 especificado.
## Resolução
Para resolver esse erro, confirme se a instância primária tem o devido acesso ao script de ação de bootstrap.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`primary-instance-id`**
O ID da instância primária em que a ação de bootstrap falhou.
**`bootstrap-action`**
O número ordinal da ação de bootstrap com falha. Um script com um valor `bootstrap-action` de `1` é a primeira ação de bootstrap a ser executada na instância.
**`amazon-s3-path`**
O local da ação de bootstrap com falha no Amazon S3.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Execute as etapas a seguir para identificar e corrigir a causa raiz do erro de ação de bootstrap. Em seguida, inicie um novo cluster.
1. Para encontrar o script de ação de bootstrap relevante no Amazon S3, use o valor `amazon-s3-path` da matriz `ErrorData`.
1. Analise os arquivos de log de ações de bootstrap no Amazon S3 para identificar a causa raiz da falha. Para saber mais sobre como visualizar os logs do Amazon EMR, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
**nota**
Se você não ativou os logs do cluster, será necessário criar um novo cluster com as mesmas configurações e ações de bootstrap. Para verificar se os logs do cluster estão ativados, consulte [Configuração de registro em log e depuração do cluster do Amazon EMR](emr-plan-debugging.md).
1. Analise o logs `stdout` de suas ações de bootstrap e confirme se não há processos personalizados que excluam arquivos na pasta `/emr/instance-controller/lib/bootstrap-actions` em suas instâncias primárias. Você encontra o log `stdout` da ação de bootstrap neste local do Amazon S3:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
1. Inicie um novo cluster com a ação de bootstrap atualizada.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY
## Visão geral do
O erro `BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY` indica que a instância primária não tem espaço em disco suficiente ao instalar o software necessário.
## Resolução
Para resolver esse erro, confirme se a instância primária tem espaço em disco suficiente no volume raiz.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`primary-instance-id`**
O ID da instância primária com espaço em disco insuficiente.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
1. Analise as práticas recomendadas para o volume do dispositivo raiz EBS do seu cluster. Consulte [Personalização do volume raiz do dispositivo do Amazon EBS](emr-custom-ami-root-volume-size.md) no *Guia de gerenciamento do Amazon EMR*.
1. Inicie um novo cluster usando um tamanho maior do volume do dispositivo raiz do EBS.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER
## Visão geral do
O erro `BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER` indica que uma ou mais instâncias de operadores não têm espaço em disco suficiente ao instalar o software necessário.
## Resolução
Para resolver esse erro, confirme se suas instâncias de operadores têm espaço em disco suficiente no volume raiz.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`worker-instance-ids`**
A IDs das instâncias de trabalho com espaço em disco insuficiente.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
1. Analise as práticas recomendadas para o volume do dispositivo raiz EBS do seu cluster. Consulte [Personalização do volume raiz do dispositivo do Amazon EBS](emr-custom-ami-root-volume-size.md) no *Guia de gerenciamento do Amazon EMR*.
1. Inicie um novo cluster usando um tamanho maior do volume do dispositivo raiz do EBS.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY
## Visão geral do
O erro `BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY` indica que a instância primária não consegue estabelecer uma conexão com o metastore do Hive externo configurado.
## Resolução
Para resolver o erro, confirme se o metastore do Hive externo está configurado corretamente e se a instância primária tem permissão para se conectar a ele.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`primary-instance-id`**
O ID da instância primária que não consegue estabelecer uma conexão com o metastore do Hive externo configurado.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
1. Analise as práticas recomendadas para configurar um metastore externo para o Hive. Consulte [Configurar um metastore externo para o Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html).
1. Inicie um novo cluster com a configuração de cluster atualizada.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER
## Visão geral do
O erro `BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER` indica que uma ou mais instâncias de operadores não conseguem estabelecer uma conexão com o metastore do Hive externo configurado.
## Resolução
Para resolver o erro, confirme se o metastore do Hive externo está configurado corretamente e se as instâncias de operadores podem se conectar a ele.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`worker-instance-ids`**
A IDs das instâncias de trabalho incapazes de estabelecer uma conexão com o Hive Metastore externo configurado.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
1. Analise as práticas recomendadas para configurar um metastore externo para o Hive. Consulte [Configurar um metastore externo para o Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html).
1. Inicie um novo cluster com a configuração de cluster atualizada.
# Códigos de erro internos do Amazon EMR
As seções a seguir fornecem informações sobre solução de problemas para códigos de erro internos, incluindo códigos de capacidade insuficiente ou nenhuma capacidade.
**Topics**
+ [ERRO\$1INTERNO\$1 EC2 \$1CAPACIDADE\$1AZ INSUFICIENTE\$1AZ](INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY](INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY](INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY.md)
# ERRO\$1INTERNO\$1 EC2 \$1CAPACIDADE\$1AZ INSUFICIENTE\$1AZ
## Visão geral do
Um cluster é terminado com um erro `INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ` quando a zona de disponibilidade selecionada não tem capacidade suficiente para atender à solicitação de tipo de instância do Amazon EC2. A sub-rede que você selecionou para um cluster determina a zona de disponibilidade. Para obter mais informações sobre sub-redes para o Amazon EMR, consulte [Configuração de redes em uma VPC no Amazon EMR](emr-plan-vpc-subnet.md).
## Resolução
Para resolver esse erro, modifique as configurações de tipo de instância e crie um novo cluster com a solicitação atualizada.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`instance-type`**
O tipo de instância que está fora da capacidade.
**`availability-zone`**
A zona de disponibilidade para a qual sua sub-rede é resolvida.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Execute estas etapas para identificar e corrigir a causa raiz do erro de configuração do cluster:
+ Analise as práticas recomendadas para conexão de cluster. Consulte [Configuração dos tipos de instância de cluster e práticas recomendadas do Amazon EMR para instâncias spot](emr-plan-instances-guidelines.md) no *Guia de gerenciamento do Amazon EMR*.
+ Solucionar os problemas de inicialização e revisar a configuração. Consulte [Solucionar problemas de inicialização de instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) no *Guia do usuário do Amazon EC2*.
+ Inicie um novo cluster com a configuração de cluster atualizada.
# INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY
## Visão geral do
Um cluster é terminado com um erro `INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY` quando o Amazon EMR não consegue atender à solicitação de instância spot para o nó primário porque as instâncias não estão disponíveis até o preço spot máximo. Para obter mais informações, consulte [Instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) no *Guia do Usuário do Amazon EC2*.
## Resolução
Para resolver esse erro, especifique os tipos de instância do cluster que estejam dentro da meta de preço ou aumente o limite de preço para o mesmo tipo de instância.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`primary-instance-id`**
O ID da instância primária do cluster que falhou.
**`instance-type`**
O tipo de instância que está fora da capacidade.
**`availability-zone`**
A zona de disponibilidade em que a sub-rede reside.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Execute as etapas a seguir para solucionar problemas da estratégia de configuração de cluster e iniciar um novo cluster:
1. Analise as práticas recomendadas para instâncias spot do Amazon EC2 e analise a estratégia de configuração de cluster. Para obter mais informações, consulte [Práticas recomendadas para spot do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) no *Guia do usuário do Amazon EC2* e [Configuração dos tipos de instância de cluster e práticas recomendadas do Amazon EMR para instâncias spot](emr-plan-instances-guidelines.md).
1. Modifique as configurações de tipo de instância ou zona de disponibilidade e crie um novo cluster com a solicitação atualizada.
1. Se o problema persistir, use a capacidade sob demanda para a instância primária.
# INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY
## Visão geral do
Um cluster é terminado com um erro `INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY` quando não há capacidade suficiente para atender a uma solicitação de instância spot para o nó primário. Para obter mais informações, consulte [Instâncias spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) no *Guia do Usuário do Amazon EC2*.
## Resolução
Para resolver esse erro, especifique os tipos de instância do cluster que estejam dentro da meta de preço ou aumente o limite de preço para o mesmo tipo de instância.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`primary-instance-id`**
O ID da instância primária do cluster que falhou.
**`instance-type`**
O tipo de instância que está fora da capacidade.
**`availability-zone`**
A zona de disponibilidade para a qual sua sub-rede é resolvida.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Execute as etapas a seguir para solucionar problemas da estratégia de configuração de cluster e iniciar um novo cluster:
1. Analise as práticas recomendadas para instâncias spot do Amazon EC2 e analise a estratégia de configuração de cluster. Para obter mais informações, consulte [Práticas recomendadas para spot do EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) no *Guia do usuário do Amazon EC2* e [Configuração dos tipos de instância de cluster e práticas recomendadas do Amazon EMR para instâncias spot](emr-plan-instances-guidelines.md).
1. Modifique as configurações de tipo de instância e crie um novo cluster com a solicitação atualizada.
1. Se o problema persistir, use a capacidade sob demanda para a instância primária.
# Códigos de erro de falha de validação no Amazon EMR
As seções a seguir fornecem informações sobre solução de problemas para códigos de erro de falha de validação.
**Topics**
+ [VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME](VALIDATION_ERROR_INVALID_SSH_KEY_NAME.md)
+ [VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED](VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED.md)
# VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC
## Visão geral do
Quando seu cluster e as sub-redes que você faz referência para seu cluster pertencem a diferentes nuvens privadas virtuais (VPCs), o cluster é encerrado com um erro. `VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC` Você pode iniciar clusters usando o Amazon EMR com a configuração de frotas de instâncias em sub-redes em uma VPC. Para obter mais informações sobre frotas de instâncias, consulte [Planejamento e configuração de frotas de instâncias para o cluster do Amazon EMR](emr-instance-fleet.md) no *Guia de gerenciamento do Amazon EMR*.
## Resolução
Para resolver esse erro, use sub-redes que pertençam à mesma VPC do cluster.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`vpc`**
Para cada par sub-rede:VPC, o ID da VPC à qual a sub-rede pertence.
**`subnet`**
Para cada par sub-rede:VPC, o ID da sub-rede.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Realize as etapas a seguir para identificar e corrigir o erro:
1. Analise as sub-redes IDs listadas na `ErrorData` matriz e confirme se elas pertencem à VPC em que você deseja iniciar o cluster do EMR.
1. Modifique as configurações de sub-rede. Use um dos métodos a seguir para encontrar todas as sub-redes públicas e privadas em uma VPC.
+ Acesse o console da Amazon VPC. Escolha **Sub-redes** e liste todas as sub-redes que residem dentro do Região da AWS seu cluster. Para encontrar somente sub-redes públicas ou privadas, aplique o filtro de **atribuição automática de endereço público IPv4 **. Para encontrar e selecionar sub-redes na VPC que o cluster usa, use a opção **Filtrar por VPC**. Para obter mais informações sobre como criar sub-redes, consulte [Criar uma sub-rede](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) no *Guia do usuário da Amazon Virtual Private Cloud*.
+ Use o AWS CLI para encontrar todas as sub-redes públicas e privadas disponíveis na VPC que seu cluster usa. Para obter mais informações, consulte a API [describe-subnets](https://amazonaws.com/ec2/describe-subnets.html). Para criar novas sub-redes em uma VPC, consulte a API [create-subnet](https://amazonaws.com/ec2/create-subnet.html).
1. Inicie um novo cluster com sub-redes da mesma VPC do cluster.
# VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC
## Visão geral do
Quando seu cluster e os grupos de segurança que você atribui ao seu cluster pertencem a diferentes nuvens privadas virtuais (VPCs), o cluster é encerrado com um `VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC` erro. Para obter mais informações sobre grupos de segurança, consulte [Especificar grupos de segurança gerenciados pelo Amazon EMR e adicionais](emr-sg-specify.md) e [Controle do tráfego de rede com grupos de segurança para o cluster do Amazon EMR](emr-security-groups.md).
## Resolução
Para resolver esse erro, use grupos de segurança que pertençam à mesma VPC do cluster.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`vpc`**
Para cada par security-group:VPC, o ID da VPC à qual o grupo de segurança pertence.
**`security-group`**
Para cada par security-group:VPC, o ID do grupo de segurança.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Realize as etapas a seguir para identificar e corrigir o erro:
1. Analise IDs os grupos de segurança listados na `ErrorData` matriz e confirme se eles pertencem à VPC em que você deseja iniciar o cluster do EMR.
1. Acesse o console da Amazon VPC. Escolha **Grupos de segurança** para listar todos os grupos de segurança da selecionada. Encontre os grupos de segurança da mesma VPC que o cluster e modifique a configuração do grupo de segurança.
1. Inicie um novo cluster com grupos de segurança da mesma VPC do cluster.
# VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME
## Visão geral do
Um cluster é terminado com um erro `VALIDATION_ERROR_INVALID_SSH_KEY_NAME` quando você usa um par de chaves do Amazon EC2 que não é válido para SSH na instância primária. O nome do par de chaves pode estar incorreto ou o par de chaves pode não existir na solicitação Região da AWS. Para obter mais informações sobre pares de chave, consulte [Pares de chaves do Amazon EC2 e instâncias do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*.
## Resolução
Para resolver esse erro, crie um novo cluster com um nome de par de chaves SSH válido.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`ssh-key`**
O nome do par de chaves SSH fornecido ao criar o cluster.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Realize as etapas a seguir para identificar e corrigir o erro:
1. Verifique seu *keypair* arquivo.pem e confirme se ele corresponde ao nome da chave SSH que você vê no console do Amazon EMR.
1. Navegue até o console do Amazon EC2. Verifique se o nome da chave SSH que você usou está disponível no nome Região da AWS que seu cluster usa. Você pode encontrar seu Região da AWS próximo ID de conta na parte superior do Console de gerenciamento da AWS.
1. Inicie um novo cluster com um nome de chave SSH válido.
# VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED
## Visão geral do
Um cluster é terminado com um erro `VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED` quando as Região da AWS e as zonas de disponibilidade do cluster não oferecem suporte ao tipo de instância especificado para um ou mais grupos de instâncias. Talvez o Amazon EMR ofereça suporte a um tipo de instância em uma zona de disponibilidade dentro de uma região, mas não em outra. A sub-rede selecionada para um cluster determina a zona de disponibilidade na região. Para obter uma lista de tipos de instância e regiões com suporte do Amazon EMR, consulte [Tipos de instância compatíveis do Amazon EMR](emr-supported-instance-types.md).
## Resolução
Para resolver esse erro, especifique os tipos de instância para seu cluster compatíveis com o Amazon EMR na região e na zona de disponibilidade em que o cluster é solicitado.
Para solucionar o problema do cluster EMR com falha, consulte `ErrorDetail` as informações retornadas do e. `DescribeCluster` `ListClusters` APIs Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md). A matriz `ErrorData` em `ErrorDetail` retorna as seguintes informações para o código de erro:
**`instance-types`**
A lista de tipos de instância com suporte.
**`availability-zones`**
A lista de zonas de disponibilidade para a qual sua sub-rede é resolvida.
**`public-doc`**
O URL público da documentação do código de erro.
## Etapas a serem executadas
Realize as etapas a seguir para identificar e corrigir o erro:
1. Use o AWS CLI para recuperar os tipos de instância disponíveis em uma zona de disponibilidade. Para fazer isso, você pode usar o `[ec2 describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)` comando para filtrar os tipos de instância disponíveis por local (Região da AWS ou zona de disponibilidade). Por exemplo, o comando a seguir retorna os tipos de instância que são oferecidos na AZ especificada, `us-east-2a`.
```
aws ec2 describe-instance-type-offerings --location-type "availability-zone" --filters Name=location,Values=us-east-2a --region us-east-2 --query "InstanceTypeOfferings[*].[InstanceType]" --output text | sort
```
Para saber mais sobre como descobrir tipos de instância disponíveis, consulte [Localizar um tipo de instância do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
1. Após determinar os tipos de instância que estão disponíveis na mesma região e zona de disponibilidade do cluster, escolha uma das seguintes resoluções para continuar:
1. Crie um novo cluster e escolha uma sub-rede para o cluster que esteja em uma zona de disponibilidade onde o tipo de instância que você selecionou esteja disponível e tenha suporte do Amazon EMR.
1. Crie um novo cluster na mesma região e sub-rede do Amazon EC2 do cluster que falhou, mas com um tipo de instância compatível com o Amazon EMR naquele local.
Para obter uma lista de tipos de instância e regiões com suporte do Amazon EMR, consulte [Tipos de instância compatíveis do Amazon EMR](emr-supported-instance-types.md). Para comparar os recursos dos tipos de instância do EC2, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types).
# Erros de recursos durante as operações de cluster do Amazon EMR
Os seguintes erros são geralmente causados pela restrição de recursos no cluster. A orientação descreve cada erro e fornece ajuda na solução de problemas.
**Topics**
+ [O cluster do Amazon EMR é encerrado com NO\$1SLAVE\$1LEFT e nós centrais FAILED\$1BY\$1MASTER](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md)
+ [Erro de cluster do Amazon EMR: não é possível replicar o bloco, só foi possível replicar para zero nós.](enough-hdfs-space.md)
+ [Erro de cluster do Amazon EMR: COTA DO EC2 EXCEDIDA](emr-EC2.md)
+ [Erro de cluster do Amazon EMR: muitas falhas de busca](emr-troubleshoot-error-resource-1.md)
+ [Erro de cluster do Amazon EMR: o arquivo só pôde ser replicado para 0 nós em vez de 1](emr-troubleshoot-error-resource-2.md)
+ [Erro de cluster do Amazon EMR: nós listados como negados](emr-troubleshoot-error-resource-3.md)
+ [Erros de controle de utilização com um cluster do Amazon EMR](emr-throttling-error.md)
+ [Erro de cluster do Amazon EMR: tipo de instância sem suporte](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md)
+ [Erro de cluster do Amazon EMR: o EC2 está sem capacidade](emr-EC2_INSUFFICIENT_CAPACITY-error.md)
+ [Erro de cluster do Amazon EMR: erro do fator de replicação do HDFS](emr-hdfs-insufficient-replication.md)
+ [Erro de cluster do Amazon EMR: erro de espaço insuficiente no HDFS](emr-hdfs-insufficient-space.md)
# O cluster do Amazon EMR é encerrado com NO\$1SLAVE\$1LEFT e nós centrais FAILED\$1BY\$1MASTER
Geralmente, isso acontece porque a proteção contra encerramento está desabilitada, e todos os nós core excedem a capacidade de armazenamento em disco, conforme especificado por um limite de utilização máxima na classificação de configuração `yarn-site`, que corresponde ao arquivo `yarn-site.xml`. Esse valor é 90%, por padrão. Quando a utilização do disco de um nó principal excede o limite de utilização, o serviço de NodeManager integridade do YARN relata o nó como. `UNHEALTHY` Enquanto ele estiver nesse estado, o Amazon EMR coloca o nó na lista de negação e não aloca contêineres YARN a ele. Se o nó permanecer não íntegro por 45 minutos, o Amazon EMR marcará a instância associada do Amazon EC2 para término como `FAILED_BY_MASTER`. Quando todas as instâncias do Amazon EC2 associadas a nós centrais são marcadas para término, o cluster é terminado com o status `NO_SLAVE_LEFT` porque não há recursos para executar trabalhos.
Ultrapassar a utilização de disco em um nó core pode causar uma reação em cadeia. Se um único nó exceder o limite de utilização de disco por causa do HDFS, outros nós também poderão estar perto do limite. O primeiro nó excede o limite de utilização de disco, então o Amazon EMR o coloca na lista de negação. Isso aumenta a carga de utilização do disco para os nós restantes, pois eles começam a replicar dados do HDFS entre si que foram perdidos no nó que está na lista de negação. Cada nó subsequentemente entra no status `UNHEALTHY` da mesma maneira, e o cluster por fim é encerrado.
## Práticas recomendadas e orientações
### Configurar o hardware do cluster com armazenamento adequado
Ao criar um cluster, certifique-se de que haja nós core suficientes e que cada um tenha um armazenamento de instâncias adequado e volumes de armazenamento do EBS para HDFS. Para obter mais informações, consulte [Calcular a capacidade necessária do HDFS de um cluster](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs). Você também pode adicionar instâncias core aos grupos de instâncias existentes manualmente ou usando a escalabilidade automática. As novas instâncias têm a mesma configuração de armazenamento que outras instâncias no grupo de instâncias. Para obter mais informações, consulte [Use o ajuste de escala de cluster do Amazon EMR para se ajustar às mudanças nas workloads](emr-scale-on-demand.md).
### Habilitar a proteção contra encerramento
Habilitar a proteção contra encerramento. Dessa forma, se um nó central estiver na lista de negação, você poderá se conectar à instância associada do Amazon EC2 usando SSH para solucionar problemas e recuperar dados. Se você habilitar a proteção contra término, lembre-se de que o Amazon EMR não substitui a instância do Amazon EC2 por uma nova instância. Para obter mais informações, consulte [Uso da proteção contra encerramento para proteger clusters do Amazon EMR do desligamento acidental](UsingEMR_TerminationProtection.md).
### Crie um alarme para a CloudWatch métrica MRUnhealthy Nodes
Essa métrica informa o número de nós com o status `UNHEALTHY`. É equivalente à métrica do YARN `mapred.resourcemanager.NoOfUnhealthyNodes`. Você pode configurar uma notificação desse alarme para avisá-lo de nós não íntegros antes que o limite de 45 minutos seja atingido. Para obter mais informações, consulte [Monitorando métricas do Amazon EMR com CloudWatch](UsingEMR_ViewingMetrics.md).
### Ajustar as configurações com yarn-site
As configurações a seguir podem ser ajustadas de acordo com os requisitos do aplicativo. Por exemplo, talvez você queira aumentar o limite de utilização de disco onde um nó informa `UNHEALTHY` ao aumentar o valor de `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage`.
Você pode definir esses valores ao criar um cluster usando a classificação de configuração `yarn-site`. Para obter mais informações, consulte [Configuring applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) no *Guia de lançamento do Amazon EMR*. Você também pode se conectar às instâncias do Amazon EC2 associadas a nós centrais usando SSH e, em seguida, adicionar os valores `/etc/hadoop/conf.empty/yarn-site.xml` usando um editor de texto. Depois de fazer a alteração, você deve reiniciar hadoop-yarn-nodemanager conforme mostrado abaixo.
**Importante**
Quando você reinicia o NodeManager serviço, os contêineres ativos do YARN são eliminados, a menos que `yarn.nodemanager.recovery.enabled` esteja configurado para `true` usar a classificação de `yarn-site` configuração ao criar o cluster. Você também deve especificar o diretório no qual armazenar um estado de contêiner usando a propriedade `yarn.nodemanager.recovery.dir`.
```
sudo /sbin/stop hadoop-yarn-nodemanager
sudo /sbin/start hadoop-yarn-nodemanager
```
Para obter mais informações sobre as propriedades `yarn-site` atuais e valores padrão, consulte [Configurações padrão do YARN](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml) na documentação do Apache Hadoop.
| Propriedade | Valor padrão | Description |
| --- | --- | --- |
| yarn.nodemanager. disk-health-checker.intervalo-ms | 120000 | A frequência (em segundos) em que o verificador de integridade do disco é executado. |
| yarn.nodemanager. disk-health-checker. min-healthy-disks | 0.25 | A fração mínima do número de discos que devem estar íntegros NodeManager para lançar novos contêineres. Isso corresponde a yarn.nodemanager.local-dirs (por padrão, `/mnt/yarn` no Amazon EMR) e yarn.nodemanager.log-dirs (por padrão `/var/log/hadoop-yarn/containers`, que apresenta um link simbólico para `mnt/var/log/hadoop-yarn/containers` no Amazon EMR). |
| `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90.0 | A porcentagem máxima de utilização de espaço em disco permitido depois que um disco é marcado como inválido. Os valores variam de 0,0 a 100,0. Se o valor for maior ou igual a 100, NodeManager verificará se há um disco cheio. Isso se aplica a `yarn-nodemanager.local-dirs` e a `yarn.nodemanager.log-dirs`. |
| `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | O espaço mínimo que deve estar disponível em um disco para que ele seja usado. Isso se aplica a `yarn-nodemanager.local-dirs` e a `yarn.nodemanager.log-dirs`. |
# Erro de cluster do Amazon EMR: não é possível replicar o bloco, só foi possível replicar para zero nós.
O erro: “Não é possível replicar os blocos, só foi possível replicar para zero nós”. normalmente ocorre quando o cluster não tem armazenamento HDFS suficiente. Esse erro ocorre quando você gera no seu cluster uma quantidade de dados maior do que o HDFS pode armazenar. Você verá esse erro somente enquanto o cluster estiver em execução, porque quando o trabalho é terminado, ele libera o espaço que o HDFS estava usando.
A quantidade de espaço disponível no HDFS para um cluster depende do número e do tipo de instâncias do Amazon EC2 que são usadas como nós centrais. Nós de tarefa não são usados para armazenamento HDFS. Todo o espaço em disco em cada instância do Amazon EC2, incluindo os volumes de armazenamento do EBS anexados, está disponível para o HDFS. Para obter mais informações sobre a quantidade de armazenamento local para cada tipo de instância do EC2, consulte os [tipos e famílias de instâncias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) no *Guia do usuário do Amazon EC2*.
O outro fator que pode afetar a quantidade de espaço disponível no HDFS é o fator de replicação, que é o número de cópias de cada bloco de dados que são armazenadas no HDFS por redundância. O fator de replicação aumenta de acordo com o número de nós no cluster: são 3 cópias de cada bloco de dados para um cluster com 10 ou mais nós, 2 cópias de cada bloco para um cluster com 4 a 9 nós e 1 cópia (sem redundância) para clusters com 3 ou menos nós. O total de espaço disponível no HDFS é dividido pelo fator de replicação. Em alguns casos, como por exemplo, com o aumento do número de nós de 9 para 10, o aumento no fator de replicação pode realmente fazer com que a quantidade de espaço disponível no HDFS diminua.
Por exemplo, um cluster com 10 nós core do tipo m1.large teria 2833 GB de espaço disponível para o HDFS ((10 nós X 850 GB por nó)/fator de replicação de 3).
Se o seu cluster exceder a quantidade de espaço disponível no HDFS, você pode adicionar mais nós core ao cluster ou usar a compactação de dados para criar mais espaço no HDFS. Se o cluster pode ser interrompido e reiniciado, você pode considerar o uso dos nós centrais de um tipo de instância maior do Amazon EC2. Você também deve considerar um ajuste no fator de replicação. Observe, no entanto, que a redução do fator de replicação diminui a redundância dos dados do HDFS e, consequentemente, a capacidade do seu cluster para recuperar blocos perdidos ou corrompidos do HDFS.
# Erro de cluster do Amazon EMR: COTA DO EC2 EXCEDIDA
Se uma mensagem `EC2 QUOTA EXCEEDED` for exibida, pode haver várias causas. Dependendo das diferenças na configuração, pode demorar entre 5 a 20 minutos para que clusters anteriores sejam encerrados totalmente e liberem os recursos alocados. Se você está recebendo um erro `EC2 QUOTA EXCEEDED` ao tentar iniciar um cluster, pode ser que os recursos de um cluster recém-encerrado ainda não tenham sido liberados. Essa mensagem também pode ser causada pelo redimensionamento de um grupo ou frota de instâncias para um tamanho de destino maior do que a cota de instâncias atual da conta. Isso pode acontecer manualmente ou automaticamente por meio de escalabilidade automática.
Considere as opções a seguir para resolver o problema:
+ Siga as instruções descritas em [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) no *Referência geral da Amazon Web Services* para solicitar um aumento do limite de serviço. Para alguns APIs, organizar um CloudWatch evento pode ser uma opção melhor do que aumentar os limites. Consulte mais detalhes em [Quando configurar eventos do EMR em CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Se um ou mais clusters em execução não estiverem na capacidade, redimensione os grupos de instâncias ou reduza as capacidades de destino nas frotas de instâncias para os clusters em execução.
+ Crie clusters com um número menor de instâncias do EC2 ou reduza a capacidade de destino.
# Erro de cluster do Amazon EMR: muitas falhas de busca
A presença de mensagens de erro "**Too many fetch-failures (Excesso de falhas de busca)**" ou "**Error reading task output (Erro ao ler a saída da tarefa)**" nas etapas ou em logs de tentativas de tarefas indica que a tarefa em execução está dependendo da saída de uma outra tarefa. Isso geralmente ocorre quando uma tarefa é colocada na fila de execução e necessita da saída de uma ou mais tarefas de mapeamento, e essa saída ainda não está disponível.
Há vários motivos pelos quais a saída pode não estar disponível:
+ A tarefa de pré-requisito ainda está em processamento. Essa geralmente é uma tarefa de mapeamento.
+ Os dados podem estar indisponíveis devido à conectividade de rede ruim, se os dados estiverem localizados em uma instância diferente.
+ Se o HDFS estiver sendo usado para recuperar a saída, pode haver um problema com o HDFS.
A causa mais comum deste erro é que a tarefa anterior ainda está em processamento. Isso é mais provável se os erros estão ocorrendo quando as tarefas de redução estão sendo executadas pela primeira vez. Você pode verificar se é esse o caso examinando o log do syslog para a etapa do cluster que está gerando o erro. Se o syslog mostra que ambas as tarefas de mapeamento e redução estão em andamento, isso indica que a fase de redução foi iniciada e, ao mesmo tempo, há tarefas de mapeamento que ainda não foram concluídas.
Um item a ser pesquisado nos logs é a porcentagem de andamento do mapeamento que vai até 100% e, em seguida, cai para um valor mais baixo. Quando a porcentagem está em 100%, isso não significa que todas as tarefas de mapeamento foram concluídas. Isto significa simplesmente que o Hadoop está executando todas as tarefas de mapeamento. Se esse valor voltar a ficar abaixo de 100%, isso significa que uma tarefa de mapeamento falhou e, dependendo da configuração, o Hadoop pode tentar reprogramar a tarefa. Se a porcentagem do mapa permanecer em 100% nos registros, observe as CloudWatch métricas, especificamente`RunningMapTasks`, para verificar se a tarefa do mapa ainda está sendo processada. Você também pode encontrar essas informações usando a interface da web do Hadoop no nó principal.
Se você está vendo esse problema, pode tentar várias ações:
+ Inclua instruções na fase de redução para esperar mais antes de iniciar. Você pode fazer isso alterando a definição da configuração do Hadoop mapred.reduce.slowstart.completed.maps para um tempo maior. Para obter mais informações, consulte [Como criar ações de bootstrap para instalar softwares adicionais com um cluster do Amazon EMR](emr-plan-bootstrap.md).
+ Iguale a contagem de reducers com a capacidade total de reducers do cluster. Você pode fazer isso ajustando a definição de configuração do Hadoop mapred.reduce.tasks de acordo com o trabalho.
+ Use um código de classe de combiner para minimizar o número de saídas que precisam ser obtidas.
+ Verifique se não há problemas com o serviço do Amazon EC2 que estejam afetando a performance de rede do cluster. Você pode fazer isso usando o [Painel de status dos serviços](https://status.aws.amazon.com/).
+ Analise os recursos de CPU e memória das instâncias no seu cluster para assegurar-se de que o processamento dos dados não está degradando os recursos dos seus nós. Para obter mais informações, consulte [Configuração de hardware e redes do cluster do Amazon EMR](emr-plan-instances.md).
+ Verifique a versão da Imagem de máquina da Amazon (AMI) usada no cluster do Amazon EMR. Se a versão estiver entre a 2.3.0 e a 2.4.4, ambas incluídas, atualize para uma versão mais recente. As versões da AMI desse intervalo especificado usam uma versão do Jetty que pode falhar ao produzir uma saída da fase de mapeamento. O erro de busca ocorre quando os reducers não conseguem obter uma saída da fase de mapeamento.
O Jetty é um servidor de HTTP de código aberto usado para estabelecer a comunicação entre máquinas em um cluster do Hadoop.
# Erro de cluster do Amazon EMR: o arquivo só pôde ser replicado para 0 nós em vez de 1
Quando um arquivo é gravado no HDFS, ele é replicado para vários nós core. Quando você vê esse erro, significa que o NameNode daemon não tem nenhuma DataNode instância disponível para gravar dados no HDFS. Em outras palavras, a replicação de blocos não está sendo realizada. Esse erro pode ser causado por vários problemas:
+ O sistema de arquivos do HDFS pode estar com o espaço esgotado. Esta é a causa mais provável.
+ DataNode as instâncias podem não estar disponíveis quando o trabalho foi executado.
+ DataNode as instâncias podem ter sido bloqueadas de se comunicar com o nó principal.
+ As instâncias no grupo de instâncias core podem não estar disponíveis.
+ Podem estar faltando permissões. Por exemplo, o JobTracker daemon pode não ter permissões para criar informações do rastreador de tarefas.
+ A configuração do espaço reservado para uma DataNode instância pode ser insuficiente. Verifique se esse é o caso, examinando a definição da configuração de dfs.datanode.du.reserved.
Para verificar se esse problema é causado pela falta de espaço em disco do HDFS, veja a `HDFSUtilization` métrica em CloudWatch. Se o valor for muito alto, você pode adicionar mais nós core ao cluster. Se você tem um cluster que acha que pode ficar sem espaço em disco no HDFS, você pode configurar um alarme CloudWatch para alertá-lo quando o valor de `HDFSUtilization` subir acima de um determinado nível. Para obter mais informações, consulte [Redimensionar manualmente um cluster do Amazon EMR em execução](emr-manage-resize.md) e [Monitorando métricas do Amazon EMR com CloudWatch](UsingEMR_ViewingMetrics.md).
Se o HDFS ficar sem espaço não fosse o problema, verifique os registros, os DataNode NameNode registros e a conectividade de rede em busca de outros problemas que poderiam ter impedido o HDFS de replicar dados. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
# Erro de cluster do Amazon EMR: nós listados como negados
O NodeManager daemon é responsável por lançar e gerenciar contêineres nos nós principais e de tarefas. Os contêineres são alocados ao NodeManager daemon pelo ResourceManager daemon executado no nó principal. Ele ResourceManager monitora o NodeManager nó por meio de um batimento cardíaco.
Há algumas situações em que o ResourceManager daemon deny lista uma NodeManager, removendo-a do pool de nós disponíveis para processar tarefas:
+ Se o não NodeManager tiver enviado uma pulsação ao ResourceManager daemon nos últimos 10 minutos (600.000 milissegundos). Esse intervalo de tempo pode ser configurado usando a definição da configuração `yarn.nm.liveness-monitor.expiry-interval-ms`. Para obter mais informações sobre a alteração das definições de configuração do Yarn, consulte [Configuring applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) no *Guia de lançamento do Amazon EMR*.
+ NodeManager verifica a integridade dos discos determinada por `yarn.nodemanager.local-dirs` e. `yarn.nodemanager.log-dirs` As verificações incluem permissões e espaço livre em disco (< 90%). Se um disco falhar na verificação, ele para de NodeManager usar esse disco específico, mas ainda informa o status do nó como íntegro. Se vários discos falharem na verificação, o nó será reportado como não íntegro ResourceManager e os novos contêineres não serão atribuídos ao nó.
O mestre do aplicativo também pode negar a lista de um NodeManager nó se ele tiver mais de três tarefas com falha. Você pode aumentar esse valor usando o parâmetro de configuração `mapreduce.job.maxtaskfailures.per.tracker`. Outras definições de configuração que você pode alterar controlam o número de tentativas para uma tarefa antes de marcá-la como falha: `mapreduce.map.max.attempts` para tarefas de mapeamento e `mapreduce.reduce.maxattempts` para tarefas de redução. Para obter mais informações sobre a alteração das definições de configuração, consulte [Configuring applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) no *Guia de lançamento do Amazon EMR*.
# Erros de controle de utilização com um cluster do Amazon EMR
Os erros “Limitado *Amazon EC2* ao iniciar o cluster” e “Falha ao provisionar instâncias devido à limitação de” *Amazon EC2* ocorrem quando o Amazon EMR não consegue concluir uma solicitação porque outro serviço limitou a atividade. O Amazon EC2 é a origem mais comum de erros de controle de utilização, mas outros serviços podem ocasionar esses erros. Os [limites de serviço da AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) se aplicam por região para melhorar a performance, e um erro de controle de utilização indica que você excedeu o limite de serviço da conta naquela região.
## Possíveis causas
A origem mais comum de erros de controle de utilização do Amazon EC2 é um grande número de instâncias do cluster sendo iniciadas, de modo que o limite de serviço para instâncias do EC2 é excedido. As instâncias do cluster podem ser executadas pelos seguintes motivos:
+ Novos clusters são criados.
+ Os clusters são redimensionados manualmente. Para obter mais informações, consulte [Redimensionar manualmente um cluster do Amazon EMR em execução](emr-manage-resize.md).
+ Os grupos de instâncias em um cluster adicionam instâncias (expandem) como resultado de uma regra de escalabilidade automática. Para obter mais informações, consulte [Noções básicas sobre as regras de ajuste de escala automático](emr-automatic-scaling.md#emr-scaling-rules).
+ As frotas de instâncias em um cluster adicionam instâncias para atender a uma maior capacidade de destino. Para obter mais informações, consulte [Planejamento e configuração de frotas de instâncias para o cluster do Amazon EMR](emr-instance-fleet.md).
Também é possível que a frequência ou tipo de solicitação de API sendo feita ao Amazon EC2 cause erros de controle de utilização. Para obter mais informações sobre como o Amazon EC2 limita solicitações de API, consulte [Query API request rate](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) na *Amazon EC2 API Reference*.
## Soluções
Considere as seguintes soluções:
+ Siga as instruções descritas em [AWS service quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) no *Referência geral da Amazon Web Services* para solicitar um aumento do limite de serviço. Para alguns APIs, organizar um CloudWatch evento pode ser uma opção melhor do que aumentar os limites. Consulte mais detalhes em [Quando configurar eventos do EMR em CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Se você tiver clusters são executados no mesmo agendamento (por exemplo, no começo da hora) considere intercalar os horários de início.
+ Se tiver clusters que são dimensionados para picos de demanda, e você periodicamente tiver capacidade de instância, considere especificar a escalabilidade automática para adicionar e remover instâncias sob demanda. Dessa forma, as instâncias serão usadas de forma mais eficiente e, dependendo do perfil de demanda, menos instâncias poderão ser solicitadas em um determinado momento em uma conta. Para obter mais informações, consulte [Uso do ajuste de escala automático com uma política personalizada para grupos de instâncias no Amazon EMR](emr-automatic-scaling.md).
# Erro de cluster do Amazon EMR: tipo de instância sem suporte
Se você criar um cluster e ele falhar com a mensagem de erro “O tipo de instância solicitado não *InstanceType* é suportado na zona de disponibilidade solicitada”, significa que você criou o cluster e especificou um tipo de instância para um ou mais grupos de instâncias que não é suportado pelo Amazon EMR na região e na zona de disponibilidade em que o cluster foi criado. O Amazon EMR pode oferecer suporte a um tipo de instância em uma zona de disponibilidade de uma região e não em outra. A sub-rede selecionada para um cluster determina a Zona de disponibilidade na região.
## Solução
**Determine os tipos de instância disponíveis em uma zona de disponibilidade usando o AWS CLI**
+ Use o comando `ec2 run-instances` com a opção `--dry-run`. No exemplo abaixo, *m5.xlarge* substitua pelo tipo de instância que você deseja usar, pela AMI *ami-035be7bafff33b6b6* associada a esse tipo de instância e *subnet-12ab3c45* por uma sub-rede na zona de disponibilidade que você deseja consultar.
```
aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45
```
Para obter instruções sobre como encontrar um ID de AMI, consulte [Encontre uma AMI do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html). Para encontrar um ID de sub-rede, você pode usar o comando [describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html).
Para saber mais sobre como descobrir tipos de instância disponíveis, consulte [Localizar um tipo de instância do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
Depois de determinar os tipos de instâncias disponíveis, você pode fazer o seguinte:
+ Crie o cluster na mesma região e sub-rede do EC2 e selecione um tipo de instância diferente com recursos semelhantes que a escolha inicial. Para obter uma lista dos tipos de instâncias compatíveis, consulte [Tipos de instância compatíveis do Amazon EMR](emr-supported-instance-types.md). Para comparar recursos de tipos de instância do EC2, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
+ Selecione uma sub-rede para o cluster em uma zona de disponibilidade onde o tipo de instância esteja disponível e tenha suporte do Amazon EMR.
**Mitigue as falhas de lançamento do cluster da frota de instâncias devido a tipos de instância primária sem suporte no Amazon EMR**
Os nós primários são essenciais nos clusters do Amazon EMR. A inicialização de um cluster do EMR pode falhar com um erro `instance type not supported` em que o Amazon EMR tenta iniciar o cluster em uma zona de disponibilidade, caso o tipo de instância primária não tenha suporte. A seleção aprimorada da zona de disponibilidade para clusters de frotas de instâncias no Amazon EMR filtra automaticamente os tipos de AZs instâncias primárias que você especificou na configuração do cluster. Isso significa que o Amazon EMR não escolherá uma zona de disponibilidade em que os tipos de instância primária configurados não tenham suporte, o que evita falhas na inicialização do cluster devido a tipos de instância não compatíveis.
Para permitir essa melhoria, adicione a permissão necessária ao perfil ou política de serviço do cluster. A versão mais recente do `AmazonEMRServicePolicy_v2` inclui essa permissão, portanto, se você usar essa política, a melhoria já estará disponível. Ao usar um perfil ou política de serviço personalizados, adicione a permissão `ec2:DescribeInstanceTypeOfferings` ao iniciar o cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstanceTypeOfferings"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowEC2Describeinstancetypeofferings"
}
]
}
```
------
# Erro de cluster do Amazon EMR: o EC2 está sem capacidade
Um *EC2 está sem capacidade porque* um *InstanceType* erro ocorre quando você tenta criar um cluster ou adicionar instâncias a um cluster em uma zona de disponibilidade que não tem mais do tipo de instância EC2 especificado. A sub-rede que você selecionou para um cluster determina a zona de disponibilidade.
Para criar um cluster, siga um destes procedimentos:
+ Especificar outro tipo de instância com recursos semelhantes
+ Criar o cluster em outra região
+ Selecione uma sub-rede em uma zona de disponibilidade em que o tipo de instância desejado possa estar disponível.
Para adicionar instância a um cluster em execução, realize uma destas ações:
+ Modifique as configurações do grupo de instâncias ou as configurações da frota de instâncias para adicionar os tipos de instância disponíveis com recursos semelhantes. Para obter uma lista dos tipos de instâncias compatíveis, consulte [Tipos de instância compatíveis do Amazon EMR](emr-supported-instance-types.md). Para comparar recursos de tipos de instância do EC2, consulte [Tipos de instância do Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
+ Termine o cluster e o recrie em uma região e zona de disponibilidade em que o tipo de instância está disponível.
# Erro de cluster do Amazon EMR: erro do fator de replicação do HDFS
Quando você remove um nó central de um [grupo de instâncias](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html) centrais ou de uma [frota de instâncias](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html), o Amazon EMR pode se deparar com um erro de replicação do HDFS. Esse erro ocorre quando você remove os nós centrais e o número deles fica abaixo do [fator de replicação dfs.replication](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html) configurado para o Sistema de Arquivos Distribuído do Hadoop (HDFS). Dessa forma, o Amazon EMR não pode realizar a operação com segurança. Para determinar o valor padrão da configuração `dfs.replication`, [configuração do HDFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html).
## Possíveis causas
Confira as possíveis causas do erro do fator de replicação do HDFS:
+ Se você [redimensionar manualmente](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html) um grupo de instâncias centrais ou uma frota de instâncias abaixo do fator `dfs.replication` configurado.
+ Suas políticas de [escalabilidade gerenciada](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) ou [ajuste de escala automático](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html) podem permitir que o ajuste reduza o número de nós centrais abaixo do limite de `dfs.replication`.
+ Esse erro também pode ocorrer se o Amazon EMR tentar [substituir](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html) um nó central não íntegro quando um cluster tem o número mínimo de nós centrais definido por []().
## Soluções e práticas recomendadas
Consulte as seguintes informações para obter as soluções e práticas recomendadas:
+ Ao redimensionar manualmente um cluster do Amazon EMR, não reduza a escala verticalmente abaixo de `dfs.replication`, pois o Amazon EMR não pode concluir o redimensionamento com segurança.
+ Ao usar o ajuste de escala gerenciado ou automático, certifique-se de que a capacidade mínima do cluster não seja inferior ao fator `dfs.replication`.
+ O número de instâncias centrais deve ser pelo menos `dfs.replication` mais uma. Isso garante que o Amazon EMR possa substituir com êxito um nó central não íntegro se você habilitou a substituição de núcleo não íntegro.
**Importante**
A falha de um único nó central pode levar à perda de dados do HDFS se você definir `dfs.replication` como 1. Se o cluster tiver armazenamento HDFS, é recomendável configurá-lo com pelo menos quatro nós centrais para workloads de produção e evitar perda de dados; defina também um fator `dfs.replication` de pelo menos 2.
# Erro de cluster do Amazon EMR: erro de espaço insuficiente no HDFS
Um erro de espaço insuficiente do Sistema de Arquivos Distribuído do Hadoop (HDFS) pode ocorrer se você tentar remover um nó central, mas o Amazon EMR não pode concluir a operação com segurança devido à falta de espaço no HDFS. Antes que o Amazon EMR remova um nó central, todos os dados do HDFS no nó devem ser transferidos para outros nós centrais para garantir a redundância dos dados. No entanto, se não houver espaço suficiente nos outros nós centrais para replicação, o Amazon EMR não poderá desativar o nó.
## Possíveis causas
Confira esta lista das possíveis causas do erro de espaço insuficiente no HDFS:
+ Se você reduzir manualmente a escala de um grupo de instâncias centrais ou de uma frota de instâncias quando não houver espaço suficiente no HDFS nos nós restantes para replicação de dados antes de reduzir a escala verticalmente.
+ O ajuste de escala gerenciado ou automático reduzem verticalmente a escala de um grupo de instâncias centrais ou de uma frota de instâncias quando não há espaço suficiente no HDFS para a replicação de dados.
+ O Amazon EMR tenta substituir um nó central não íntegro, mas não consegue substituí-lo com segurança devido ao espaço insuficiente no HDFS.
## Soluções e práticas recomendadas
Consulte as seguintes informações para obter as soluções e práticas recomendadas:
+ Aumente verticalmente a escala do número de nós centrais no cluster do Amazon EMR. Se você usa ajuste de escala gerenciado ou automático, aumente a capacidade mínima dos nós centrais.
+ Use volumes maiores do EBS para os nós centrais ao criar o cluster do EMR.
+ Exclua dados do HDFS desnecessários no cluster do EMR. Recomendamos que você configure CloudWatch alarmes para monitorar a `HDFSUtilization` métrica em seu cluster para saber se seu cluster EMR está com pouco espaço.
# Erros de entrada e saída do cluster durante as operações do Amazon EMR
Os erros a seguir são comuns em operações de entrada e saída do cluster. Use as orientações apresentadas neste tópico para solucionar problemas e verificar a configuração.
**Topics**
+ [O caminho para o Amazon Simple Storage Service (Amazon S3) com pelo menos três barras?](#threeslashes)
+ [Você está tentando, recursivamente, desviar diretórios de entrada?](#recurseinput)
+ [Seu diretório de saída já existe?](#directoryexist)
+ [Você está tentando especificar um recurso usando um URL HTTP?](#httpurl)
+ [Você está referenciando um bucket do Amazon S3 usando um nome de formato inválido?](#validdnsname)
+ [Você está tendo problemas para carregar dados para carregar ou descarregar dados do Amazon S3?](#emr-troubleshoot-errors-io-1)
## O caminho para o Amazon Simple Storage Service (Amazon S3) com pelo menos três barras?
Quando especificar um bucket do Amazon S3, inclua uma barra de término no final do URL. Por exemplo, em vez de referenciar um bucket como "s3n://amzn-s3-demo-bucket1", use "s3n://amzn-s3-demo-bucket1/", senão o cluster apresentará falha no Hadoop na maioria dos casos.
## Você está tentando, recursivamente, desviar diretórios de entrada?
O Hadoop não pesquisa recursivamente diretórios de entrada para arquivos. Se você tiver uma estrutura de diretório como /corpus/01/01.txt, /corpus/01/02.txt, /corpus/02/01.txt, etc. e especificar /corpus/ como o parâmetro de entrada para seu cluster, o Hadoop não localizará nenhum arquivo de entrada porque o diretório /corpus/está vazio, e o Hadoop não verificará o conteúdo dos subdiretórios. Da mesma forma, o Hadoop não verifica recursivamente os subdiretórios de buckets do Amazon S3.
Os arquivos de entrada devem estar diretamente no diretório de entrada ou no bucket do Amazon S3 que você especificar, e não nos subdiretórios.
## Seu diretório de saída já existe?
Se você especificar um caminho de saída que já existe, seu cluster apresentará falha no Hadoop na maioria dos casos. Isso significa que, se você executar um cluster uma vez e, em seguida, executá-lo novamente com, exatamente, os mesmos parâmetros ele, provavelmente, funcionará na primeira vez e depois nunca mais. Após a primeira execução, o caminho de saída passa a existir e isso faz com que haja falha em todas as execuções sucessivas.
## Você está tentando especificar um recurso usando um URL HTTP?
O Hadoop não aceita locais de recursos especificados usando o prefixo http://. Não é possível fazer referência a um recurso usando um URL HTTP. Por exemplo, passar em http://mysite/myjar.jar como o parâmetro JAR faz com que haja falha no cluster.
## Você está referenciando um bucket do Amazon S3 usando um nome de formato inválido?
Se você tentar usar um nome de bucket, como "amzn-s3-demo-bucket1.1" com o Amazon EMR, haverá falha no cluster porque o Amazon EMR exige que os nomes de bucket sejam nomes de host RFC 2396 válidos. O nome não pode terminar com um número. Além disso, devido aos requisitos do Hadoop, os nomes de bucket do Amazon S3 usados com o Amazon EMR devem conter somente letras minúsculas, números, pontos (.) e hífens (-). Para obter informações sobre como formatar nomes de buckets do Amazon S3, consulte [Restrições e limitações do bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/index.html?BucketRestrictions.html) no *guia do usuário do Amazon Simple Storage Service*.
## Você está tendo problemas para carregar dados para carregar ou descarregar dados do Amazon S3?
O Amazon S3 é a fonte de entrada e saída mais conhecida do Amazon EMR. Um erro comum é tratar o Amazon S3 como um sistema de arquivos típico. Há diferenças entre o Amazon S3 e um sistema de arquivos que você precisa levar em conta ao executar seu cluster.
+ Se ocorrer um erro interno no Amazon S3, sua aplicação deverá lidar com isso normalmente e repetir a operação.
+ Se as chamadas para o Amazon S3 levam muito tempo para retornar, talvez seja necessário reduzir a frequência com que a aplicação chama o Amazon S3.
+ Listar todos os objetos em um bucket do Amazon S3 é uma chamada de alto custo. O aplicativo deve minimizar o número de vezes que faz isso.
Há várias maneiras de melhorar como seu cluster interage com o Amazon S3.
+ Inicie o cluster usando a versão mais recente do Amazon EMR.
+ Use o S3 DistCp para mover objetos para dentro e para fora do Amazon S3. O S3 DistCp implementa tratamento de erros, novas tentativas e recuos para atender aos requisitos do Amazon S3. Para obter mais informações, consulte [Cópia distribuída usando o S3 DistCp](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/UsingEMR_s3distcp.html).
+ Projete seu aplicativo com consistência eventual em mente. Use o HDFS para armazenamento de dados intermediários enquanto o cluster está em execução e o Amazon S3 somente para a entrada de dados iniciais e a saída dos resultados finais.
+ Se os seus clusters confirmarem 200 ou mais transações por segundo para o Amazon S3, [entre em contato com o suporte](https://aws.amazon.com/contact-us/) para preparar seu bucket para mais transações por segundo e considere usar estratégias de partição de chave, descritas em [Amazon S3 performance tips and tricks](https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/).
+ Defina a configuração io.file.buffer.size do Hadoop como 65536. Isso faz com que o Hadoop gaste menos tempo procurando entre objetos do Amazon S3.
+ Considere desabilitar o atributo de execução especulativa do Hadoop, se o cluster estiver enfrentando problemas de simultaneidade do Amazon S3. Isso também é útil quando você estiver solucionando problemas de um cluster lento. Você pode fazer isso definindo as propriedades `mapreduce.reduce.speculative` e `mapreduce.map.speculative` como `false`. Ao executar um cluster, você pode definir esses valores usando a classificação de configuração `mapred-env`. Para obter mais informações, consulte [Configurar aplicações](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) no *Guia de versão do Amazon EMR*.
+ Se você estiver executando um cluster do Hive, consulte [Você está tendo problemas para carregar ou descarregar dados do Amazon S3 no Hive?](emr-troubleshoot-error-hive.md#emr-troubleshoot-error-hive-3).
Para obter informações adicionais, consulte [Práticas recomendadas com relação a erros do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html) no *Guia do usuário do Amazon Simple Storage Service*.
# Erros de permissões durante as operações de cluster do Amazon EMR
Os seguintes erros são comuns quando se utiliza permissões ou credenciais.
**Topics**
+ [Você está inserindo as credenciais corretas para o SSH?](#correctcred)
+ [Se você está usando o IAM, possui o conjunto apropriado de políticas do Amazon EC2?](#check-iam-permissions)
## Você está inserindo as credenciais corretas para o SSH?
Se você não consegue usar o SSH para se conectar ao nó principal, é muito provável que haja um problema com suas credenciais de segurança.
Primeiro, verifique se o arquivo .pem contendo a sua chave SSH tem as permissões adequadas. Você pode usar o chmod para alterar as permissões de seu arquivo .pem, como mostrado no exemplo a seguir, onde você deve substituir mykey.pem pelo nome do seu próprio arquivo .pem.
```
1. chmod og-rwx mykey.pem
```
A segunda possibilidade é você não estar usando o par de chaves especificado quando o cluster foi criado. Isso é fácil de acontecer se você tiver criado vários pares de chaves. Verifique os detalhes do cluster no console do Amazon EMR (ou use a opção `--describe` na CLI) para obter o nome do par de chaves que foi especificado quando o cluster foi criado.
Após verificar se está usando o par de chaves correto e se as permissões estão definidas corretamente no arquivo .pem, você pode usar o comando a seguir para se conectar ao nó principal usando o SSH, onde você deve substituir mykey.pem pelo nome do arquivo .pem e `hadoop@ec2-01-001-001-1.compute-1.amazonaws.com` pelo nome DNS público do nó principal (disponível por meio da opção `--describe` na CLI ou do console do Amazon EMR).
**Importante**
Você deve usar o nome de login `hadoop` quando se conectar a um nó do cluster do Amazon EMR, caso contrário, poderá ocorrer um erro semelhante a `Server refused our key`.
```
1. ssh -i mykey.pem hadoop@ec2-01-001-001-1.compute-1.amazonaws.com
```
Para obter mais informações, consulte [Como se conectar ao nó primário do cluster do Amazon EMR usando SSH](emr-connect-master-node-ssh.md).
## Se você está usando o IAM, possui o conjunto apropriado de políticas do Amazon EC2?
Como o Amazon EMR usa instâncias do EC2 como nós, os usuários do Amazon EMR também precisam ter determinadas políticas definidas para o Amazon EC2 a fim de que o Amazon EMR possa gerenciar essas instâncias em nome do usuário. Se você não tiver as permissões necessárias, o Amazon EMR gerará o erro: **“account is not authorized to call EC2”.**
Para obter mais informações sobre as políticas do Amazon EC2 que sua conta do IAM precisa ter definidas para executar o Amazon EMR, consulte [Como o Amazon EMR funciona com o IAM](security_iam_service-with-iam.md).
# Erros de cluster do Hive
Geralmente, você pode encontrar a causa de um erro do Hive no arquivo `syslog`, que você vincula a partir do painel **Steps (Etapas)**. Se você não conseguir determinar o problema lá, verifique a mensagem de erro de tentativa de tarefa do Hadoop. Vincule-se a ela no painel **Task Attempts (Tentativas da tarefa)**.
Os erros a seguir são comuns em clusters do Hive.
**Topics**
+ [Você está usando a versão mais recente do Hive?](#emr-troubleshoot-error-hive-0)
+ [Você encontrou um erro de sintaxe no script do Hive?](#emr-troubleshoot-error-hive-1)
+ [Houve falha em um trabalho quando executado interativamente?](#emr-troubleshoot-error-hive-2)
+ [Você está tendo problemas para carregar ou descarregar dados do Amazon S3 no Hive?](#emr-troubleshoot-error-hive-3)
## Você está usando a versão mais recente do Hive?
A versão mais recente do Hive tem todos os patches e correções de erros atuais e pode resolver o problema.
## Você encontrou um erro de sintaxe no script do Hive?
Se houver falha em uma etapa, examine o arquivo `stdout` de logs para a etapa que executou o script do Hive. Se o erro não estiver lá, examine o arquivo `syslog` dos logs das tentativas de tarefa que tiveram falha. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
## Houve falha em um trabalho quando executado interativamente?
Se você estiver executando o Hive interativamente no nó principal e houver falha no cluster, veja as entradas do `syslog` no log de tentativas de tarefa para a tentativa de tarefas com falha. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
## Você está tendo problemas para carregar ou descarregar dados do Amazon S3 no Hive?
Se você estiver com problemas para acessar dados no Amazon S3, verifique primeiro as possíveis causas listadas em [Você está tendo problemas para carregar dados para carregar ou descarregar dados do Amazon S3?](emr-troubleshoot-errors-io.md#emr-troubleshoot-errors-io-1). Se nenhum desses problemas for a causa, considere as opções a seguir específicas para o Hive.
+ Verifique se você está usando a versão mais recente do Hive, que tem todos os patches e correções de erros atuais e pode resolver o problema. Para obter mais informações, consulte [Apache Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive.html).
+ Usar `INSERT OVERWRITE` exige a listagem do conteúdo do bucket ou pasta do Amazon S3. Isso é uma operação cara. Se possível, remova manualmente o caminho, em vez de fazer com que o Hive liste e exclua os objetos existentes.
+ Se você usar versões anteriores à 5.0 do Amazon EMR, poderá usar o seguinte comando no HiveQL para pré-armazenar em cache os resultados de uma operação de lista do Amazon S3 localmente no cluster:
```
set hive.optimize.s3.query=true;
```
+ Use partições estáticas sempre que possível.
+ Em algumas versões do Hive e do Amazon EMR, é possível que haja falha ao usar ALTER TABLES porque a tabela é armazenada em um local diferente do que o esperado pelo Hive. A solução é adicionar ou atualizar o seguinte no `/home/hadoop/conf/core-site.xml`:
```
fs.s3n.endpoint
s3.amazonaws.com
```
# Erros da VPC durante as operações de cluster do Amazon EMR
Os erros a seguir são comuns na configuração da VPC no Amazon EMR.
**Topics**
+ [Configuração de sub-rede inválida](#emr-troubleshoot-error-gateway)
+ [Conjunto de opções DHCP ausente](#emr-troubleshoot-error-dhcp)
+ [Erros de permissão](#emr-troubleshoot-error-denied)
+ [Erros que resultam em `START_FAILED`](#emr-troubleshoot-error-vpc-dns)
+ [Cluster `Terminated with errors` e NameNode falha ao iniciar](#emr-troubleshoot-namenode-dns)
## Configuração de sub-rede inválida
Na página **Cluster Details (Detalhes do cluster)**, no campo **Status**, será exibida uma mensagem de erro semelhante ao seguinte:
`The subnet configuration was invalid: Cannot find route to InternetGateway in main RouteTable rtb-id for vpc vpc-id.`
Para resolver esse problema, você deve criar um Gateway da Internet e anexá-lo à sua VPC. Para obter mais informações, consulte [Adicionar um gateway da Internet à VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html).
Como alternativa, verifique se você configurou a VPC com as opções **Enable DNS resolution (Habilitar resolução DNS)** e **Enable DNS hostname support (Habilitar suporte de nome de host DNS)** ativadas. Para obter mais informações, consulte [Como usar o DNS com sua VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html).
## Conjunto de opções DHCP ausente
Você verá uma falha de etapa no syslog (log do sistema) do cluster com uma mensagem de erro semelhante ao seguinte:
` ERROR org.apache.hadoop.security.UserGroupInformation (main): PriviledgedActionException as:hadoop (auth:SIMPLE) cause:java.io.IOException: org.apache.hadoop.yarn.exceptions.ApplicationNotFoundException: Application with id 'application_id' doesn't exist in RM. `
or
`ERROR org.apache.hadoop.streaming.StreamJob (main): Error Launching job : org.apache.hadoop.yarn.exceptions.ApplicationNotFoundException: Application with id 'application_id' doesn't exist in RM.`
Para resolver esse problema, você deve configurar uma VPC que inclui um conjunto de opções DHCP cujos parâmetros estejam definidos como os seguintes valores:
**nota**
Se você usar a região AWS GovCloud (Oeste dos EUA), defina nome de domínio como **us-gov-west-1.compute.internal** em vez do valor usado no exemplo a seguir.
+ **domain-name** = **ec2.internal**
Use **ec2.internal**, se a região for Leste dos EUA (Norte da Virgínia). Para outras regiões, use *region-name***.compute.internal**. Por exemplo, em us-west-2, use **domain-name**=**us-west-2.compute.internal**.
+ **domain-name-servers** = **AmazonProvidedDNS**
Para obter mais informações, consulte [Conjuntos de opções de DHCP](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
## Erros de permissão
Uma falha no log `stderr` para uma etapa indica que um recurso do Amazon S3 não tem as permissões apropriadas. Este é um erro 403 e a mensagem de erro é semelhante a algo como:
```
Exception in thread "main" com.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: REQUEST_ID
```
Se ActionOnFailure for definido como`TERMINATE_JOB_FLOW`, isso resultará no encerramento do cluster com o estado,`SHUTDOWN_COMPLETED_WITH_ERRORS`.
Algumas maneiras de solucionar esse problema incluem:
+ Se você estiver usando uma política de bucket do Amazon S3 dentro de uma VPC, certifique-se de dar acesso a todos os buckets, criando um endpoint da VPC e selecionando **Permitir todos** na opção Política ao criar o endpoint.
+ Certifique-se de que as políticas associadas a recursos do S3 incluam a VPC na qual você inicia o cluster.
+ Tente executar o seguinte comando a partir de seu cluster, para verificar se você pode acessar o bucket
```
hadoop fs -copyToLocal s3://path-to-bucket /tmp/
```
+ Você pode obter mais informações de depuração específicas, ao configurar o parâmetro `log4j.logger.org.apache.http.wire` como `DEBUG` no arquivo `/home/hadoop/conf/log4j.properties` no cluster. Você pode verificar o arquivo de log `stderr` depois de tentar acessar o bucket a partir do cluster. O arquivo de log fornecerá informações mais detalhadas:
```
Access denied for getting the prefix for bucket - us-west-2.elasticmapreduce with path samples/wordcount/input/
15/03/25 23:46:20 DEBUG http.wire: >> "GET /?prefix=samples%2Fwordcount%2Finput%2F&delimiter=%2F&max-keys=1 HTTP/1.1[\r][\n]"
15/03/25 23:46:20 DEBUG http.wire: >> "Host: us-west-2.elasticmapreduce.s3.amazonaws.com[\r][\n]"
```
## Erros que resultam em `START_FAILED`
Antes da AMI 3.7.0, para VPCs onde um nome de host é especificado, o Amazon EMR mapeia os nomes de host internos da sub-rede com endereços de domínio personalizados da seguinte forma:. `ip-X.X.X.X.customdomain.com.tld` Por exemplo, se o nome do host fosse `ip-10.0.0.10` e a VPC tivesse a opção nome de domínio definida como customdomain.com, o nome de host resultante mapeado pelo Amazon EMR seria `ip-10.0.1.0.customdomain.com`. Uma entrada é incluída em `/etc/hosts` para resolver o nome do host como 10.0.0.10. Esse comportamento é alterado com a AMI 3.7.0 e agora o Amazon EMR honra totalmente a configuração de DHCP da VPC. Anteriormente, os clientes também podiam usar uma ação de bootstrap para especificar um mapeamento de nome de host.
Se quiser preservar esse comportamento, você deve fornecer o DNS e encaminhar a configuração de resolução que você precisa para o domínio personalizado.
## Cluster `Terminated with errors` e NameNode falha ao iniciar
Ao iniciar um cluster do EMR em uma VPC que faz o uso de um nome de domínio DNS personalizado, pode haver falha no cluster com a seguinte mensagem de erro no console:
```
Terminated with errors On the master instance(instance-id), bootstrap action 1 returned a non-zero return code
```
A falha é resultado da NameNode impossibilidade de inicialização. Isso resultará no seguinte erro encontrado nos NameNode registros, cujo URI do Amazon S3 tem o formato:: `s3://amzn-s3-demo-bucket/logs/cluster-id/daemons/master instance-id/hadoop-hadoop-namenode-master node hostname.log.gz`
```
2015-07-23 20:17:06,266 WARN
org.apache.hadoop.hdfs.server.namenode.FSNamesystem (main): Encountered exception
loading fsimage java.io.IOException: NameNode is not formatted.
at
org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:212)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1020)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:739)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:537)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:596)
at org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:765)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:749)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1441)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1507)
```
Isso é causado por um possível problema em que uma instância do EC2 pode ter vários conjuntos de nomes de domínio totalmente qualificados ao iniciar clusters do EMR em uma VPC que faz uso de um servidor DNS fornecido pela AWS e um servidor DNS personalizado fornecido pelo usuário. Se o servidor DNS fornecido pelo usuário não fornecer nenhum PTR (registro do apontador) para qualquer um dos registros A usados para designar nós em um cluster do EMR, haverá falha de inicialização nos clusters quando configurado desta maneira. A solução é adicionar um registro PTR para cada registro A criado quando uma instância do EC2 é executada em qualquer uma das sub-redes na VPC.
# Erros em clusters de streaming no Amazon EMR
Em geral, você pode encontrar a causa de um erro de streaming em um arquivo `syslog`. Estabeleça um link para ela no painel **Steps (Etapas)**.
Os seguintes erros são comuns em clusters de streaming.
**Topics**
+ [Os dados estão sendo enviados ao mapeador no formato errado?](#emr-troubleshoot-error-streaming-1)
+ [Seu script está perdendo a validade?](#emr-troubleshoot-error-streaming-2)
+ [Você está transmitindo argumentos de streaming inválidos?](#invalidarg)
+ [Seu script foi encerrado com um erro?](#emr-troubleshoot-error-streaming-3)
## Os dados estão sendo enviados ao mapeador no formato errado?
Para verificar se esse é o caso, procure uma mensagem de erro no arquivo `syslog` de uma tentativa de tarefa com falha nos logs de tentativas de tarefas. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
## Seu script está perdendo a validade?
O tempo limite padrão para um script de mapeador ou reducer é de 600 segundos. Se o script demorar mais do que isso, a tentativa de tarefa falhará. Você pode verificar se esse é o caso consultando o arquivo `syslog` de uma tentativa de tarefa com falha nos logs de tentativas de tarefas. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
Você pode alterar o limite de tempo definindo um novo valor para a definição de configuração `mapred.task.timeout`. Essa configuração especifica o número de milissegundos após os quais o Amazon EMR encerrará uma tarefa que não lei entradas, gravou saídas ou atualizou sua string de status. Você pode atualizar esse valor transmitindo um argumento de streaming adicional `-jobconf mapred.task.timeout=800000`.
## Você está transmitindo argumentos de streaming inválidos?
O streaming do Hadoop oferece suporte apenas aos seguintes argumentos. Se você transmitir argumentos diferentes dos listados abaixo, o cluster falhará.
```
1. -blockAutoGenerateCacheFiles
2. -cacheArchive
3. -cacheFile
4. -cmdenv
5. -combiner
6. -debug
7. -input
8. -inputformat
9. -inputreader
10. -jobconf
11. -mapper
12. -numReduceTasks
13. -output
14. -outputformat
15. -partitioner
16. -reducer
17. -verbose
```
Além disso, o streaming do Hadoop só reconhece argumentos transmitidos usando a sintaxe Java; ou seja, precedidos por um único hífen. Se você transmitir argumentos precedidos de um hífen duplo, o cluster falhará.
## Seu script foi encerrado com um erro?
Se a saída do seu script de mapeador ou reducer for gerada com um erro, você poderá localizar esse erro no arquivo `stderr` dos logs de tentativas da tarefa com falha. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
# Amazon EMR: erros de cluster com JAR personalizado
Os seguintes erros são comuns em clusters com JAR personalizado.
**Topics**
+ [Seu JAR está lançando uma exceção antes de criar um trabalho?](#emr-troubleshoot-error-custom-jar-1)
+ [Seu JAR está lançando um erro dentro em uma tarefa map?](#emr-troubleshoot-error-custom-jar-2)
## Seu JAR está lançando uma exceção antes de criar um trabalho?
Se o programa principal do seu JAR personalizado lançar uma exceção ao criar o trabalho do Hadoop, o melhor lugar para procurar é no arquivo `syslog` dos logs de etapas. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
## Seu JAR está lançando um erro dentro em uma tarefa map?
Se o seu JAR personalizado e o mapeador lançarem uma exceção ao processarem dados de entrada, o melhor lugar para procurar é no arquivo `syslog` dos logs de tentativas de tarefas. Para obter mais informações, consulte [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
# Erros do Amazon EMR AWS GovCloud (Oeste dos EUA)
A região AWS GovCloud (Oeste dos EUA) difere de outras regiões em sua segurança, configuração e configurações padrão. Como resultado, use a lista de verificação a seguir para solucionar erros do Amazon EMR que são específicos da região AWS GovCloud (Oeste dos EUA) antes de usar recomendações mais gerais de solução de problemas.
+ Verifique se os perfis do IAM estão configuradas corretamente. Para obter mais informações, consulte [Configurar funções de serviço do IAM para permissões do Amazon EMR para AWS serviços e recursos](emr-iam-roles.md).
+ Certifique-se de que sua configuração de VPC tenha configurado corretamente os parâmetros de resolution/hostname suporte a DNS, Internet Gateway e DHCP Option Set. Para obter mais informações, consulte [Erros da VPC durante as operações de cluster do Amazon EMR](emr-troubleshoot-error-vpc.md).
Se essas etapas não resolverem o problema, continue com as etapas para solucionar os erros comuns do Amazon EMR. Para obter mais informações, consulte [Coleções de erros comuns do Amazon EMR](emr-troubleshoot-errors.md).
## Encontrar um cluster ausente
Se o cluster estiver ausente da lista do console ou da API `ListClusters`, verifique o seguinte:
+ Confirme se a idade do cluster, a partir do momento da conclusão, é inferior a dois meses. O Amazon EMR preserva informações de metadados de clusters concluídos gratuitamente, por dois meses. Não é possível excluir clusters concluídos do console. Em vez disso, o Amazon EMR limpa os clusters concluídos automaticamente após dois meses.
+ Confirme que você tem permissões de perfil para visualizar o cluster.
+ Confirme se você está visualizando o mesmo Região da AWS local em que o cluster reside.
# Solucionar problemas de um cluster do Amazon EMR que falhou com um código de erro
Esta seção orienta você durante o processo de solução de problemas de um cluster que apresentou falha. Isso significa que o cluster foi encerrado com um código de erro.
**nota**
Quando um cluster do EMR termina com um erro, o `DescribeCluster` e `ListClusters` APIs retorna um código de erro e uma mensagem de erro. Para alguns erros de cluster, a matriz de dados `ErrorDetail` também ajuda a solucionar a falha. Para obter mais informações, consulte [Códigos de erro com ErrorDetail informações no Amazon EMR](emr-troubleshoot-error-errordetail.md).
Se o cluster é executado, mas leva muito tempo para retornar resultados, consulte [Solucionar problemas com um cluster lento do Amazon EMR](emr-troubleshoot-slow.md).
**Topics**
+ [Etapa 1: coletar dados sobre o problema com o cluster do Amazon EMR](emr-troubleshoot-failed-1.md)
+ [Etapa 2: verificar o ambiente](emr-troubleshoot-failed-2.md)
+ [Etapa 3: conferir a última alteração de estado](emr-troubleshoot-failed-3.md)
+ [Etapa 4: examinar os arquivos de log do Amazon EMR](emr-troubleshoot-failed-4.md)
+ [Etapa 5: testar o cluster do Amazon EMR passo a passo](emr-troubleshoot-failed-5-test-steps.md)
# Etapa 1: coletar dados sobre o problema com o cluster do Amazon EMR
A primeira etapa para solucionar problemas de um cluster é coletar informações sobre o que deu errado e o status e a configuração atuais do cluster. Essas informações serão usadas nas etapas a seguir para confirmar ou descartar as possíveis causas do problema.
## Definir o problema
Começamos fazendo uma definição clara do problema. Algumas perguntas para se fazer:
+ O que eu esperava que acontecesse? O que aconteceu em vez disso?
+ Quando o problema ocorreu pela primeira vez? Com que frequência ele ocorreu desde então?
+ Alguma coisa mudou na forma como eu configuro ou executo o cluster?
## Detalhes do cluster
Os detalhes do cluster a seguir são úteis para ajudar a monitorar problemas. Para obter mais informações sobre como reunir essas informações, consulte [Exibição de status e detalhes do cluster do Amazon EMR](emr-manage-view-clusters.md).
+ Identificador do cluster. (Também chamado de identificador de fluxo de trabalho.)
+ Região da AWS e na Zona de Disponibilidade em que o cluster foi lançado.
+ Estado do cluster, inclusive detalhes da última alteração de estado.
+ Tipo e número de instâncias do EC2 especificados para os nós principal, central e de tarefa.
# Etapa 2: verificar o ambiente
O Amazon EMR opera como parte de um ecossistema de serviços da Web e software de código aberto. As coisas que afetam essas dependências podem afetar a performance do Amazon EMR.
**Topics**
+ [Verificar a existência de interrupções de serviço](#emr-troubleshoot-failed-2-outages)
+ [Verificar os limites de uso](#emr-troubleshoot-failed-2-limits)
+ [Verificar a versão](#emr-troubleshoot-failed-2-ami)
+ [Verificar a configuração da sub-rede da Amazon VPC](#emr-troubleshoot-failed-2-vpc)
## Verificar a existência de interrupções de serviço
O Amazon EMR usa diversos Amazon Web Services internamente. Ele executa servidores virtuais no Amazon EC2, armazena dados e scripts no Amazon S3 e reporta métricas para. CloudWatch Os eventos que interrompem esses serviços são raros, mas, quando ocorrem, podem causar problemas no Amazon EMR.
Antes de avançar, verifique o [Painel de status dos serviços](https://status.aws.amazon.com/). Verifique a região onde você iniciou o cluster para saber se há um eventos de interrupção em qualquer um desses serviços.
## Verificar os limites de uso
Se você estiver iniciando um cluster grande, tiver lançado vários clusters simultaneamente ou se for um usuário compartilhando um Conta da AWS com outros usuários, o cluster pode ter falhado porque você excedeu um limite de AWS serviço.
O Amazon EC2 limita o número de instâncias de servidores virtuais em execução em uma única AWS região a 20 instâncias sob demanda ou reservadas. Se você iniciar um cluster com mais de 20 nós ou executar um cluster que faça com que o número total de instâncias do EC2 ativas em você Conta da AWS exceda 20, o cluster não poderá executar todas as instâncias do EC2 necessárias e poderá falhar. Quando isso acontece, o Amazon EMR retorna um erro `EC2 QUOTA EXCEEDED`. Você pode solicitar o AWS aumento do número de instâncias do EC2 que você pode executar em sua conta enviando uma [solicitação para aumentar o aplicativo Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/) Instance Limit.
Outra coisa que pode fazer você exceder os limites de uso é o atraso entre quando um cluster é encerrado e quando ele libera todos os recursos. Dependendo da configuração, pode demorar de 5 a 20 minutos para um cluster ser encerrado totalmente e liberar os recursos alocados. Se você estiver recebendo um erro `EC2 QUOTA EXCEEDED` ao tentar iniciar um cluster, isso poderá acontecer porque os recursos de um cluster recém-encerrado talvez ainda não tenham sido liberados. Nesse caso, é possível [solicitar que sua cota do Amazon EC2 seja aumentada](https://aws.amazon.com/contact-us/ec2-request/) ou esperar 20 minutos e reiniciar o cluster.
O Amazon S3 limita a cem o número de buckets criados em uma conta. Se o cluster criar um bucket novo que exceda esse limite, haverá falha na criação do bucket e poderá fazer com que haja uma falha no cluster.
## Verificar a versão
Compare o rótulo da versão usada para iniciar o cluster com a versão do Amazon EMR mais recente. Cada versão do Amazon EMR inclui melhorias, como novas aplicações, recursos, patches e correções de bug. O problema que está afetando o cluster já pode ter sido corrigido na versão mais recente. Se possível, execute o cluster novamente usando a versão da mais recente.
## Verificar a configuração da sub-rede da Amazon VPC
Se o cluster foi iniciado em uma sub-rede da Amazon VPC, a sub-rede precisa ser configurada conforme descrito em [Configuração de redes em uma VPC no Amazon EMR](emr-plan-vpc-subnet.md). Além disso, verifique se a sub-rede na qual o cluster é iniciado tem endereços IP elásticos livres suficientes para atribuir um a cada nó do cluster.
# Etapa 3: conferir a última alteração de estado
A última alteração de estado fornece informações sobre o que ocorreu na última vez em que o estado do cluster foi alterado. Isso, geralmente, tem informações que podem determinar o que deu errado, conforme o estado de um cluster muda para `FAILED`. Por exemplo, se você iniciar um cluster de transmissão e especificar um local de saída que já exista no Amazon S3, haverá falha no cluster com uma última alteração de estado de “Streaming output directory already exists”.
Você pode localizar o último valor de alteração de estado a partir do console, visualizando o painel de detalhes do cluster; a partir da CLI, usando os argumentos `list-steps` ou `describe-cluster` ou a partir da API, usando as ações `DescribeCluster` e `ListSteps`. Para obter mais informações, consulte [Exibição de status e detalhes do cluster do Amazon EMR](emr-manage-view-clusters.md).
# Etapa 4: examinar os arquivos de log do Amazon EMR
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 [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
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.
# Etapa 5: testar o cluster do Amazon EMR passo a passo
Uma técnica útil quando você está tentando rastrear a origem de um erro é reiniciar o cluster e enviar as etapas a ele uma por uma. Isso permite que você verifique os resultados de cada etapa antes de processar a seguinte e dá a você a oportunidade de corrigir e executar novamente uma etapa que tenha apresentado falha. Isso também permite que você carregue seus dados de entrada somente uma vez.
**Para testar um cluster passo a passo**
1. Execute um novo cluster, com as proteções de encerramento e keep alive ativadas. A proteção keep alive mantém o cluster em execução após ter processado todas as suas etapas pendentes. A proteção de encerramento impede que um cluster seja encerrado no caso de um erro. Para obter mais informações, consulte [Configuração de um cluster do Amazon EMR para continuar ou encerrar após a execução da etapa](emr-plan-longrunning-transient.md) e [Uso da proteção contra encerramento para proteger clusters do Amazon EMR do desligamento acidental](UsingEMR_TerminationProtection.md).
1. Envie uma etapa para o cluster. Para obter mais informações, consulte [Envio de trabalhos para um cluster do Amazon EMR](emr-work-with-steps.md).
1. Quando a etapa for concluída, verifique se há erros de processamento nos arquivos de log da etapa. Para obter mais informações, consulte [Etapa 4: examinar os arquivos de log do Amazon EMR](emr-troubleshoot-failed-4.md). A maneira mais rápida de localizar esses arquivos de log é estabelecer uma conexão com o nó principal e exibir os arquivos de log. Os arquivos de log da etapa não serão exibidos até que a etapa seja executada por algum tempo, seja concluída ou apresente uma falha.
1. Se a etapa for concluída com êxito, execute a próxima etapa. Se houver erros, investigue o erro nos arquivos de log. Se houve um erro em seu código, faça a correção e execute novamente a etapa. Continue até que todas as etapas sejam executadas sem erros.
1. Quando você terminar a depuração do cluster e quiser encerrá-lo, deverá fazê-lo manualmente. Isso é necessário porque o cluster foi iniciado com a proteção de encerramento ativada. Para obter mais informações, consulte [Uso da proteção contra encerramento para proteger clusters do Amazon EMR do desligamento acidental](UsingEMR_TerminationProtection.md).
# Solucionar problemas com um cluster lento do Amazon EMR
Esta seção orienta você durante o processo de solução de problemas com um cluster que ainda está em execução, mas está demorando muito para retornar resultados. Para obter mais informações sobre o que fazer se o cluster tiver sido encerrado com um código de erro, consulte [Solucionar problemas de um cluster do Amazon EMR que falhou com um código de erro](emr-troubleshoot-failed.md)
O Amazon EMR permite que você especifique o número e o tipo de instâncias no cluster. Essas especificações são os principais meios de afetar a velocidade com a qual o processamento dos seus dados é concluída. Uma ação que você pode considerar é reexecutar o cluster, dessa vez especificando instâncias do EC2 com recursos maiores ou especificando um número maior de instâncias no cluster. Para obter mais informações, consulte [Configuração de hardware e redes do cluster do Amazon EMR](emr-plan-instances.md).
Os tópicos a seguir você orientam você durante o processo de identificar as causas alternativas de um cluster lento.
**Topics**
+ [Etapa 1: coletar dados sobre o problema com o cluster do Amazon EMR](emr-troubleshoot-slow-1.md)
+ [Etapa 2: verificar o ambiente de cluster do EMR](emr-troubleshoot-slow-2.md)
+ [Etapa 3: examinar os arquivos de log do cluster do Amazon EMR](emr-troubleshoot-slow-3.md)
+ [Etapa 4: verificar a integridade do cluster e das instâncias do Amazon EMR](emr-troubleshoot-slow-4.md)
+ [Etapa 5: verificar se há grupos suspensos](emr-troubleshoot-slow-5.md)
+ [Etapa 6: revisar as configurações do cluster do Amazon EMR](emr-troubleshoot-slow-6.md)
+ [Etapa 7: examinar dados de entrada do cluster do Amazon EMR](emr-troubleshoot-slow-7.md)
# Etapa 1: coletar dados sobre o problema com o cluster do Amazon EMR
A primeira etapa para solucionar problemas de um cluster é coletar informações sobre o que deu errado e o status e a configuração atuais do cluster. Essas informações serão usadas nas etapas a seguir para confirmar ou descartar as possíveis causas do problema.
## Definir o problema
Começamos fazendo uma definição clara do problema. Algumas perguntas para se fazer:
+ O que eu esperava que acontecesse? O que aconteceu em vez disso?
+ Quando o problema ocorreu pela primeira vez? Com que frequência ele ocorreu desde então?
+ Alguma coisa mudou na forma como eu configuro ou executo o cluster?
## Detalhes do cluster
Os detalhes do cluster a seguir são úteis para ajudar a monitorar problemas. Para obter mais informações sobre como reunir essas informações, consulte [Exibição de status e detalhes do cluster do Amazon EMR](emr-manage-view-clusters.md).
+ Identificador do cluster. (Também chamado de identificador de fluxo de trabalho.)
+ Região da AWS e na Zona de Disponibilidade em que o cluster foi lançado.
+ Estado do cluster, inclusive detalhes da última alteração de estado.
+ Tipo e número de instâncias do EC2 especificados para os nós principal, central e de tarefa.
# Etapa 2: verificar o ambiente de cluster do EMR
Verifique seu ambiente para ver se há interrupções no serviço ou se você excedeu um limite de AWS serviço.
**Topics**
+ [Verificar a existência de interrupções de serviço](#emr-troubleshoot-slow-2-outages)
+ [Verificar os limites de uso](#emr-troubleshoot-slow-2-limits)
+ [Verificar a configuração da sub-rede da Amazon VPC](#emr-troubleshoot-slow-2-vpc)
+ [Reiniciar o cluster](#emr-troubleshoot-slow-2-restart)
## Verificar a existência de interrupções de serviço
O Amazon EMR usa diversos Amazon Web Services internamente. Ele executa servidores virtuais no Amazon EC2, armazena dados e scripts no Amazon S3 e reporta métricas para. CloudWatch Os eventos que interrompem esses serviços são raros, mas, quando ocorrem, podem causar problemas no Amazon EMR.
Antes de avançar, verifique o [Painel de status dos serviços](https://status.aws.amazon.com/). Verifique a região onde você iniciou o cluster para saber se há um eventos de interrupção em qualquer um desses serviços.
## Verificar os limites de uso
Se você estiver iniciando um cluster grande, tiver lançado vários clusters simultaneamente ou se for um usuário compartilhando um Conta da AWS com outros usuários, o cluster pode ter falhado porque você excedeu um limite de AWS serviço.
O Amazon EC2 limita o número de instâncias de servidores virtuais em execução em uma única AWS região a 20 instâncias sob demanda ou reservadas. Se você iniciar um cluster com mais de 20 nós ou executar um cluster que faça com que o número total de instâncias do EC2 ativas em você Conta da AWS exceda 20, o cluster não poderá executar todas as instâncias do EC2 necessárias e poderá falhar. Quando isso acontece, o Amazon EMR retorna um erro `EC2 QUOTA EXCEEDED`. Você pode solicitar o AWS aumento do número de instâncias do EC2 que você pode executar em sua conta enviando uma [solicitação para aumentar o aplicativo Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/) Instance Limit.
Outra coisa que pode fazer você exceder os limites de uso é o atraso entre quando um cluster é encerrado e quando ele libera todos os recursos. Dependendo da configuração, pode demorar de 5 a 20 minutos para um cluster ser encerrado totalmente e liberar os recursos alocados. Se você estiver recebendo um erro `EC2 QUOTA EXCEEDED` ao tentar iniciar um cluster, isso poderá acontecer porque os recursos de um cluster recém-encerrado talvez ainda não tenham sido liberados. Nesse caso, é possível [solicitar que sua cota do Amazon EC2 seja aumentada](https://aws.amazon.com/contact-us/ec2-request/) ou esperar 20 minutos e reiniciar o cluster.
O Amazon S3 limita a cem o número de buckets criados em uma conta. Se o cluster criar um bucket novo que exceda esse limite, haverá falha na criação do bucket e poderá fazer com que haja uma falha no cluster.
## Verificar a configuração da sub-rede da Amazon VPC
Se o cluster foi iniciado em uma sub-rede da Amazon VPC, a sub-rede precisa ser configurada conforme descrito em [Configuração de redes em uma VPC no Amazon EMR](emr-plan-vpc-subnet.md). Além disso, verifique se a sub-rede na qual o cluster é iniciado tem endereços IP elásticos livres suficientes para atribuir um a cada nó do cluster.
## Reiniciar o cluster
A lentidão no processamento pode ser causada por uma condição transitória. Considere encerrar e reiniciar o cluster para ver se o desempenho melhora.
# Etapa 3: examinar os arquivos de log do cluster do Amazon EMR
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 [Exibição dos arquivos de log do Amazon EMR](emr-manage-view-web-log-files.md).
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 JobTracker registros para mapear uma tentativa de tarefa malsucedida para o 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.
# Etapa 4: verificar a integridade do cluster e das instâncias do Amazon EMR
Um cluster do Amazon EMR é formado por nós em execução em instâncias do Amazon EC2. Se essas instâncias tornarem-se limitadas por recursos (por exemplo, se ficarem sem memória ou CPU), passarem por problemas de conectividade de rede ou forem encerradas, a velocidade de processamento do cluster será prejudicada.
Existem até três tipos de nós em um cluster:
+ **nó principal**: gerencia o cluster. Se ele sofrer um problema de desempenho, todo o cluster será afetado.
+ **nós core**: processam tarefas map/reduce e mantêm o Sistema de Arquivos Distribuído do Hadoop (HDFS). Se um dos nós passar por um problema de desempenho, isso poderá retardar as operações do HDFS, bem como o processamento de map/reduce. Você pode adicionar outros nós core a um cluster para melhorar o desempenho, mas não pode remover nós core. Para obter mais informações, consulte [Redimensionar manualmente um cluster do Amazon EMR em execução](emr-manage-resize.md).
+ **nós de tarefa**: processam tarefas map/reduce. Estes são recursos puramente de computação e não armazenam dados. Você pode adicionar nós de tarefas a um cluster para acelerar o desempenho ou pode remover nós de tarefas que não são necessários. Para obter mais informações, consulte [Redimensionar manualmente um cluster do Amazon EMR em execução](emr-manage-resize.md).
Ao examinar a integridade de um cluster, você deve considerar o desempenho do cluster como um todo, bem como o desempenho de instâncias individuais. Existem várias ferramentas que pode ser usadas:
## Verifique a integridade do cluster com CloudWatch
Cada cluster do Amazon EMR reporta métricas para. CloudWatch Essas métricas fornecem informações de desempenho resumidas sobre o cluster, como a carga total, a utilização do HDFS, as tarefas em execução, as tarefas restantes, os blocos corrompidos e muito mais. A análise das CloudWatch métricas fornece uma visão geral do que está acontecendo com seu cluster e pode fornecer informações sobre o que está causando a lentidão no processamento. Além de usar CloudWatch para analisar um problema de desempenho existente, você pode definir alarmes que CloudWatch causem alertas caso ocorra um problema de desempenho futuro. Para obter mais informações, consulte [Monitorando métricas do Amazon EMR com CloudWatch](UsingEMR_ViewingMetrics.md).
## Verificar a integridade do status do trabalho e do HDFS
Use as **Interfaces do usuário do aplicativo** na página de detalhes do cluster para visualizar os detalhes do aplicativo YARN. Para determinados aplicativos, você pode analisar diretamente os logs de acesso em mais detalhes. Isso é útil principalmente para aplicativos Spark. Para obter mais informações, consulte [Como exibir o histórico da aplicação do Amazon EMR](emr-cluster-application-history.md).
O Hadoop fornece uma série de interfaces Web que você pode usar para visualizar informações. Para obter mais informações sobre como acessar essas interfaces Web, consulte [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md).
+ JobTracker — fornece informações sobre o progresso do trabalho que está sendo processado pelo cluster. Você pode usar essa interface para identificar quando um trabalho ficou preso.
+ HDFS NameNode — fornece informações sobre a porcentagem de utilização do HDFS e o espaço disponível em cada nó. Você pode usar essa interface para identificar quando o HDFS está se tornando limitado por recursos e requer capacidade adicional.
+ TaskTracker — fornece informações sobre as tarefas do trabalho que está sendo processado pelo cluster. Você pode usar essa interface para identificar quando uma tarefa ficou presa.
## Verificar a integridade da instância com o Amazon EC2
Outra maneira de procurar informações sobre o status das instâncias no cluster é usar o console do Amazon EC2. Como cada nó do cluster é executado em uma instância do EC2, você pode usar as ferramentas fornecidas pelo Amazon EC2 para verificar seu status. Para obter mais informações, consulte [Visualizar instâncias de cluster no Amazon EC2](UsingEMR_Tagging.md).
# Etapa 5: verificar se há grupos suspensos
Um grupo de instâncias fica suspenso quando encontra muitos erros ao tentar executar nós. Por exemplo, se novos nós falharem repetidamente durante a execução de ações de bootstrap, depois de algum tempo, o grupo de instâncias entrará no estado `SUSPENDED` em vez de tentar provisionar continuamente novos nós.
Um nó poderá falhar se:
+ O Hadoop ou o cluster estiver de alguma forma com problemas e não aceitar um novo nó no cluster
+ Uma ação de bootstrap falhar no novo nó
+ O nó não estava funcionando corretamente e não conseguir fazer check-in no Hadoop
Se um grupo de instâncias estiver no estado `SUSPENDED`, e o cluster estiver em um estado `WAITING`, você poderá adicionar uma etapa de cluster para redefinir o número desejado de nós core e de tarefa. Adicionar a etapa retoma o processamento do cluster e coloca o grupo de instâncias em um estado `RUNNING`.
Para obter mais informações sobre como redefinir um cluster em um estado suspenso, consulte [Estado suspenso](emr-manage-resize.md#emr-manage-resizeSuspended).
# Etapa 6: revisar as configurações do cluster do Amazon EMR
Definições de configuração especificam detalhes sobre como um cluster é executado, como quantas vezes uma tarefa deve ser repetida e quanta memória está disponível para classificação. Quando você executa um cluster usando o Amazon EMR, existem configurações específicas do Amazon EMR, além das definições de configuração padrão do Hadoop. As definições de configuração são armazenadas no nó principal do cluster. Você pode verificar as definições de configuração para garantir que o cluster tenha os recursos necessários para um funcionamento eficiente.
O Amazon EMR define definições de configuração do Hadoop padrão que ele utiliza para iniciar um cluster. Os valores se baseiam na AMI e no tipo de instância que você especifica para o cluster. Você pode modificar os valores padrão das definições de configuração usando uma ação de bootstrap ou especificando novos valores em parâmetros de execução de trabalho. Para obter mais informações, consulte [Como criar ações de bootstrap para instalar softwares adicionais com um cluster do Amazon EMR](emr-plan-bootstrap.md). Para determinar se uma ação de bootstrap alterou as definições de configuração, verifique os logs dessa ação.
O Amazon EMR registra em log as configurações do Hadoop usadas para executar cada trabalho. Os dados de registro são armazenados em um arquivo nomeado no `job_job-id_conf.xml` `/mnt/var/log/hadoop/history/` diretório do nó principal, onde *job-id* são substituídos pelo identificador do trabalho. Se você habilitou o arquivamento de logs, esses dados são copiados para o Amazon S3 na pasta, *date* onde está `logs/date/jobflow-id/jobs` a data em que o trabalho foi executado *jobflow-id* e é o identificador do cluster.
As seguintes definições de configuração de trabalhos do Hadoop são especialmente úteis para investigar problemas de desempenho. Para obter mais informações sobre as definições de configuração do Hadoop e como elas afetam o comportamento do Hadoop, acesse [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/).
**Atenção**
Definir `dfs.replication` como 1 em clusters com menos de quatro nós poderá causar perda de dados do HDFS se um único nó ficar inativo. É recomendável usar um cluster com pelo menos quatro nós centrais para workloads de produção.
O Amazon EMR não permitirá que os clusters escalem os nós principais abaixo de `dfs.replication`. Por exemplo, se `dfs.replication = 2`, o número mínimo de nós central será 2.
Ao usar o Ajuste de Escala Gerenciado, o Auto Scaling ou optar por redimensionar manualmente o cluster, é recomendável definir `dfs.replication` como 2 ou mais.
| Definição da configuração | Description |
| --- | --- |
| dfs.replication | O número de nós HDFS para os quais um único bloco (como o bloco de disco rígido) é copiado a fim de produzir um ambiente semelhante ao RAID. Determina o número de nós HDFS que contêm uma cópia do bloco. |
| io.sort.mb | Total de memória disponível para classificação. Esse valor deve ser 10x io.sort.factor. Essa configuração também pode ser usada para calcular o total de memória usado pelo nó de tarefas, contando io.sort.mb multiplicado por mapred.tasktracker.ap.tasks.maximum. |
| io.sort.spill.percent | Usado durante a classificação, no momento em que o disco começa a ser usado porque a memória de classificação alocada está ficando cheia. |
| mapred.child.java.opts | Suspenso. Em vez disso, use mapred.map.child.java.opts e mapred.reduce.child.java.opts. As opções Java são TaskTracker usadas ao iniciar uma JVM para que uma tarefa seja executada nela. Um parâmetro comum é “-Xmx” para configurar o tamanho máximo da memória. |
| mapred.map.child.java.opts | As opções Java são TaskTracker usadas ao iniciar uma JVM para que uma tarefa de mapeamento seja executada nela. Um parâmetro comum é “-Xmx” para configurar o tamanho máximo do heap de memória. |
| mapred.map.tasks.speculative.execution | Determina se tentativas de tarefas map da mesma tarefa podem ser executadas em paralelo. |
| mapred.reduce.tasks.speculative.execution | Determina se tentativas de tarefas reduce da mesma tarefa podem ser executadas em paralelo. |
| mapred.map.max.attempts | O número máximo de vezes que uma tarefa map pode ser tentada. Se tudo falhar, a tarefa map será marcada como falha. |
| mapred.reduce.child.java.opts | As opções Java são TaskTracker usadas ao iniciar uma JVM para que uma tarefa reduzida seja executada nela. Um parâmetro comum é “-Xmx” para configurar o tamanho máximo do heap de memória. |
| mapred.reduce.max.attempts | O número máximo de vezes que uma tarefa reduce pode ser tentada. Se tudo falhar, a tarefa map será marcada como falha. |
| mapred.reduce.slowstart.completed.maps | A quantidade de tarefas map que devem ser concluídas antes que tarefas reduce sejam tentadas. Uma espera insuficiente pode causar erros “Too many fetch-failure” em tentativas. |
| mapred.reuse.jvm.num.tasks | Uma tarefa é executada em uma única JVM. Especifica quantas tarefas podem reutilizar a mesma JVM. |
| mapred.tasktracker.map.tasks.maximum | A quantidade máxima de tarefas que podem ser executadas em paralelo por nó de tarefa durante o mapeamento. |
| mapred.tasktracker.reduce.tasks.maximum | A quantidade máxima de tarefas que podem ser executadas em paralelo por nó de tarefa durante a redução. |
Se as suas tarefas de cluster consumirem muita memória, você poderá melhorar o desempenho usando menos tarefas por nó core e reduzindo seu tamanho do heap do rastreador de trabalhos.
# Etapa 7: examinar dados de entrada do cluster do Amazon EMR
Observe seus dados de entrada. Eles estão distribuídos uniformemente entre seus valores de chave? Se os seus dados estiverem fortemente desviados para um ou alguns valores de chave, a carga de processamento pode estar mapeada para um pequeno número de nós, enquanto outros nós estão ociosos. Essa distribuição desequilibrada de trabalho pode resultar em tempos de processamento mais lentos.
Um exemplo de um conjunto de dados desequilibrado seria executar um cluster para colocar palavras em ordem alfabética, mas ter um conjunto de dados contendo apenas palavras que começam com a letra "a". Quando o trabalho fosse mapeado, o nó processando valores que começam com "a" seria sobrecarregado, enquanto os nós processando palavras que começam com outras letras ficariam ociosos.
# Solucione problemas comuns ao usar o Amazon EMR AWS com o Lake Formation
Esta seção orienta você no processo de solução de problemas comuns ao usar o Amazon EMR com o AWS Lake Formation.
## O acesso ao data lake não é permitido
É necessário optar explicitamente pela filtragem de dados nos clusters do Amazon EMR para poder analisar e processar dados no data lake. Quando o acesso aos dados falhar, você verá uma mensagem genérica `Access is not allowed` na saída das entradas do caderno.
Para aceitar e permitir a filtragem de dados no Amazon EMR, consulte as instruções em [Allow data filtering on Amazon EMR](https://docs.aws.amazon.com/lake-formation/latest/dg/getting-started-setup.html#emr-switch) no *Guia do desenvolvedor do AWS Lake Formation *.
## Expiração da sessão
O tempo limite da sessão para Cadernos do EMR e Zeppelin é controlado pelo perfil do IAM para a configuração `Maximum CLI/API session duration` do Lake Formation. O valor padrão para essa configuração é uma hora. Quando ocorrer um tempo limite de sessão, você verá a seguinte mensagem na saída das entradas do bloco de anotações ao tentar executar comandos do Spark SQL.
```
Error 401 HTTP ERROR: 401 Problem accessing /sessions/2/statements.
Reason: JWT token included in request failed validation.
Powered by Jetty:// 9.3.24.v20180605 org.springframework.web.client.HttpClientErrorException: 401 JWT token included in request failed validation…
```
Para validar sua sessão, atualize a página. Será solicitado que você faça a autenticação novamente usando seu IdP e seja redirecionado de volta para o bloco de anotações. Você pode continuar a executar consultas após a nova autenticação.
## Não há permissões para o usuário na tabela solicitada
Ao tentar acessar uma tabela à qual você não tem acesso, você verá a seguinte exceção na saída das entradas do bloco de anotações ao tentar executar comandos do Spark SQL.
```
org.apache.spark.sql.AnalysisException: org.apache.hadoop.hive.ql.metadata.HiveException: Unable to fetch table table.
Resource does not exist or requester is not authorized to access requested permissions.
(Service: AWSGlue; Status Code: 400; Error Code: AccessDeniedException; Request ID: …
```
Para acessar a tabela, você deve conceder acesso ao usuário atualizando as permissões associadas a essa tabela no Lake Formation.
## Consultar dados de várias contas compartilhados com o Lake Formation
Quando você usa o Amazon EMR para acessar dados de outra conta compartilhados com você, algumas bibliotecas do Spark tentarão chamar a operação de API `Glue:GetUserDefinedFunctions`. Como as versões 1 e 2 das permissões AWS RAM gerenciadas não oferecem suporte a essa ação, você recebe a seguinte mensagem de erro:
`"ERROR: User: arn:aws:sts::012345678901:assumed-role/my-spark-role/i-06ab8c2b59299508a is not authorized to perform: glue:GetUserDefinedFunctions on resource: arn:exampleCatalogResource because no resource-based policy allows the glue:GetUserDefinedFunctions action"`
Para resolver esse erro, o administrador do data lake que criou o compartilhamento de recursos deve atualizar as permissões AWS RAM gerenciadas anexadas ao compartilhamento de recursos. A versão 3 das permissões gerenciadas pelo AWS RAM permite que as entidades principais executem a ação `glue:GetUserDefinedFunctions`.
Se você criar um novo compartilhamento de recursos, o Lake Formation aplicará a versão mais recente da permissão AWS RAM gerenciada por padrão, e nenhuma ação será exigida por você. Para habilitar o acesso a dados entre contas para compartilhamentos de recursos existentes, você precisa atualizar as permissões AWS RAM gerenciadas para a versão 3.
Você pode ver as AWS RAM permissões atribuídas aos recursos compartilhados com você em AWS RAM. As permissões incluídas na versão 3 são estas:
```
Databases
AWSRAMPermissionGlueDatabaseReadWriteForCatalog
AWSRAMPermissionGlueDatabaseReadWrite
Tables
AWSRAMPermissionGlueTableReadWriteForCatalog
AWSRAMPermissionGlueTableReadWriteForDatabase
AllTables
AWSRAMPermissionGlueAllTablesReadWriteForCatalog
AWSRAMPermissionGlueAllTablesReadWriteForDatabase
```
**Para atualizar a versão de permissões AWS RAM gerenciadas dos compartilhamentos de recursos existentes**
Você (administrador do data lake) pode [atualizar as permissões AWS RAM gerenciadas para uma versão mais recente](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-update-permissions.html) seguindo as instruções no *Guia do AWS RAM usuário* ou revogar todas as permissões existentes para o tipo de recurso e concedê-las novamente. Se você revogar as permissões, AWS RAM excluirá o compartilhamento AWS RAM de recursos associado ao tipo de recurso. Quando você concede permissões novamente, AWS RAM cria novos compartilhamentos de recursos anexando a versão mais recente das permissões AWS RAM gerenciadas.
## Inserir, criar e alterar tabelas
Não há suporte para a inserção, a criação ou a alteração de tabelas em bancos de dados protegidos por políticas do Lake Formation. Ao executar essas operações, você verá a seguinte exceção na saída das entradas do bloco de anotações ao tentar executar comandos do Spark SQL:
```
java.io.IOException: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception:
Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: …
```
Para obter mais informações, consulte [Limitações da integração do Amazon EMR com. AWS Lake Formation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lf-scope.html#emr-lf-limitations)