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á. # Gerenciamento de clusters do Amazon EMR Após iniciar o cluster, você poderá conectar-se a ele e gerenciá-lo. O Amazon EMR fornece uma coleção de ferramentas que você pode usar para isso. Esta seção fornece orientações para se conectar ao cluster, dar trabalho a ele, monitorar o trabalho à medida que ele é feito e solucionar problemas. **Topics** + [ # Conectar-se a um cluster do Amazon EMR ](emr-connect-master-node.md) + [ # Envio de trabalhos para um cluster do Amazon EMR ](emr-work-with-steps.md) + [ # Exibição e monitoramento de um cluster do Amazon EMR enquanto executa trabalhos ](emr-manage-view.md) + [ # Use o ajuste de escala de cluster do Amazon EMR para se ajustar às mudanças nas workloads ](emr-scale-on-demand.md) + [ # Encerramento de um cluster do Amazon EMR em estado iniciando, executando ou aguardando ](UsingEMR_TerminateJobFlow.md) + [ # Como clonar um cluster do Amazon EMR usando o console ](clone-console.md) + [ # Automatize clusters recorrentes do Amazon EMR com AWS Data Pipeline ](emr-manage-recurring.md) # Conectar-se a um cluster do Amazon EMR Ao executar um cluster do Amazon EMR, muitas vezes, tudo o que você precisa fazer é executar uma aplicação para analisar seus dados e depois coletar a saída de um bucket do Amazon S3. Às vezes, você pode querer interagir com o nó primário enquanto o cluster está em execução. Por exemplo, talvez você queira se conectar ao nó primário para executar consultas interativas, verificar arquivos de log, depurar um problema com o cluster, monitorar a performance usando uma aplicação como o Ganglia, que é executada no nó primário e assim por diante. As seções a seguir descrevem técnicas que você pode usar para conectar-se ao nó primário. Em um cluster do EMR, o nó primário é uma instância do Amazon EC2 que coordena as instâncias do EC2 em execução como nós centrais e de tarefa. O nó primário expõe um nome DNS público que você pode usar para conectar-se a ele. Por padrão, o Amazon EMR cria regras de grupo de segurança para o nó primário e para os nós centrais e de tarefa, que determinam como você acessa esses nós. **nota** Você pode conectar-se ao nó primário somente enquanto o cluster está em execução. Quando o cluster for encerrado, a instância do EC2 atuando como o nó primário será terminada e não estará mais disponível. Para se conectar ao nó primário, você também deve se autenticar para o cluster. Você pode usar o Kerberos para autenticação ou especificar uma chave privada do par de chaves do Amazon EC2 ao iniciar o cluster. Para obter mais informações sobre como configurar o Kerberos e se conectar, consulte [Usar o Kerberos para autenticação com o Amazon EMR](emr-kerberos.md). Quando executar um cluster no console, a chave privada do par de chaves do Amazon EC2 será especificada na seção **Segurança e acesso** da página **Criar cluster**. Por padrão, o grupo de segurança ElasticMapReduce -master não permite acesso SSH de entrada. Talvez seja necessário adicionar uma regra de entrada que permita acesso SSH (porta TCP 22) a partir das origens às quais você deseja ter acesso. Para obter mais informações sobre como modificar regras de grupos de segurança, consulte [Adding rules to a security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) no *Guia do usuário do Amazon EC2*. **Importante** Não modifique as regras restantes no grupo de segurança ElasticMapReduce -master. Modificar essas regras pode interferir com o funcionamento do cluster. **Topics** + [ # Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada ](emr-connect-ssh-prereqs.md) + [ # Como se conectar ao nó primário do cluster do Amazon EMR usando SSH ](emr-connect-master-node-ssh.md) # Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada Antes de se conectar a um cluster do Amazon EMR, é necessário autorizar o tráfego SSH de entrada (porta 22) de clientes confiáveis, como o endereço IP do computador. Para isso, edite as regras do grupo de segurança gerenciado para os nós aos quais deseja se conectar. Por exemplo, as instruções a seguir mostram como adicionar uma regra de entrada para acesso SSH ao grupo de segurança ElasticMapReduce -master padrão. Para ter mais informações sobre usar grupos de segurança com o Amazon EMR, consulte [Controle do tráfego de rede com grupos de segurança para o cluster do Amazon EMR](emr-security-groups.md). ------ #### [ Console ] **Para conceder o acesso SSH a fontes confiáveis ​​ao grupo de segurança primário com o console** Para editar seus grupos de segurança, você deve ter permissão para gerenciar os grupos de segurança para a VPC na qual o cluster está localizado. Para obter mais informações, consulte [Alteração de permissões de um usuário](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html) e o [exemplo de política](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html) que permite o gerenciamento de grupos de segurança do EC2 no *Guia do usuário do IAM*. 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e, em seguida, escolha o cluster que você deseja atualizar. Isso abre a página de detalhes do cluster. A guia **Propriedades** da página será pré-selecionada. 1. Em **Redes** na guia **Propriedades**, selecione a seta ao lado de **Grupos de segurança do EC2 (firewall)** para expandir esta seção. Em **Nó primário**, selecione o link do grupo de segurança. Isso abre o console do EC2. 1. Escolha a guia **Regras de entrada** e escolha **Editar regras**. 1. Verifique se há uma regra de entrada que permita acesso público com as configurações a seguir. Se existir, escolha **Excluir** para removê-la. + **Tipo** SSH + **Porta** 22 + **Origem** Personalizado 0.0.0.0/0 **Atenção** Antes de dezembro de 2020, o grupo de segurança ElasticMapReduce -master tinha uma regra pré-configurada para permitir tráfego de entrada na Porta 22 de todas as fontes. Esta regra foi criada para simplificar as conexões SSH iniciais com o nó primário. Recomendamos fortemente remover esta regra de entrada e restringir o tráfego para origens confiáveis. 1. Role até o final da lista de regras e escolha **Adicionar regra**. 1. Em **Type (Tipo)**, selecione **SSH**. Essa seleção SSH insere automaticamente **TCP** para **Protocolo** e **22** para **Intervalo de portas**. 1. Para a origem, selecione **Meu IP** para adicionar automaticamente seu endereço IP como o endereço de origem. Você também pode adicionar um intervalo ​​**personalizado** de endereços IP de clientes confiáveis ou criar regras adicionais para outros clientes. Diversos ambientes de rede alocam endereços IP dinamicamente, portanto, pode ser necessário atualizar os endereços IP para clientes confiáveis ​​no futuro. 1. Escolha **Salvar**. 1. Opcionalmente, retorne à Etapa 3, escolha os **Nós centrais e de tarefa** e repita as Etapas 4 a 8. Isso concede aos nós centrais e de tarefa acesso ao cliente SSH. ------ # Como se conectar ao nó primário do cluster do Amazon EMR usando SSH O Secure Shell (SSH) é um protocolo de rede que você pode usar para criar uma conexão segura com um computador remoto. Depois de estabelecer uma conexão, o terminal no computador local se comporta como se estivesse em execução no computador remoto. Os comandos que você emitir localmente serão executados no computador remoto, e a saída do comando do computador remoto será exibida na janela do terminal. Ao usar SSH com AWS, você está se conectando a uma instância do EC2, que é um servidor virtual executado na nuvem. Ao trabalhar com o Amazon EMR, o uso mais comum do SSH é para conexão com a instância do EC2 que está atuando como o nó primário do cluster. O uso do SSH para conectar-se ao nó primário permite monitorar o cluster e interagir com ele. Você pode emitir comandos do Linux no nó primário, executar aplicações como o Hive e o Pig interativamente, pesquisar diretórios, ler arquivos de log e assim por diante. Também pode criar um túnel na sua conexão SSH para visualizar as interfaces Web hospedadas no nó primário. Para obter mais informações, consulte [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md). Para se conectar ao nó primário usando o SSH, você precisa do nome DNS público do nó primário. Além disso, o grupo de segurança associado ao nó primário deve ter uma regra de entrada que permite o tráfego SSH (porta TCP 22) de uma fonte que inclui o cliente onde a conexão SSH se origina. Talvez seja necessário adicionar uma regra para permitir uma conexão SSH do seu cliente. Para obter mais informações sobre como modificar regras de grupos de segurança, consulte [Controle do tráfego de rede com grupos de segurança para o cluster do Amazon EMR](emr-security-groups.md) e [Adding rules to a security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) no *Guia do usuário do Amazon EC2*. ## Recuperar o nome DNS público do nó primário Você pode recuperar o nome DNS público primário usando o console do Amazon EMR e a AWS CLI. ------ #### [ Console ] **Recuperar o nome DNS público do nó primário usando o novo console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e, em seguida, selecione o cluster em que deseja recuperar o nome DNS público. 1. Observe o valor do **DNS público do nó primário** na seção **Resumo** da página de detalhes do cluster. ------ #### [ CLI ] **Para recuperar o nome DNS público do nó primário com o AWS CLI** 1. Para recuperar o identificador do cluster, digite o seguinte comando. ``` 1. aws emr list-clusters ``` A saída lista seus clusters, incluindo o cluster IDs. Observe o ID do cluster ao qual você está se conectando. ``` "Status": { "Timeline": { "ReadyDateTime": 1408040782.374, "CreationDateTime": 1408040501.213 }, "State": "WAITING", "StateChangeReason": { "Message": "Waiting after step completed" } }, "NormalizedInstanceHours": 4, "Id": "j-2AL4XXXXXX5T9", "Name": "My cluster" ``` 1. Para listar as instâncias de cluster, incluindo o nome DNS público do cluster, digite um dos comandos a seguir. *j-2AL4XXXXXX5T9*Substitua pelo ID do cluster retornado pelo comando anterior. ``` 1. aws emr list-instances --cluster-id j-2AL4XXXXXX5T9 ``` Ou: ``` aws emr describe-cluster --cluster-id j-2AL4XXXXXX5T9 ``` A saída lista as instâncias de cluster, incluindo nomes DNS e endereços IP. Observe o valor para `PublicDnsName`. ``` "Status": { "Timeline": { "ReadyDateTime": 1408040779.263, "CreationDateTime": 1408040515.535 }, "State": "RUNNING", "StateChangeReason": {} }, "Ec2InstanceId": "i-e89b45e7", "PublicDnsName": "ec2-###-##-##-###.us-west-2.compute.amazonaws.com" "PrivateDnsName": "ip-###-##-##-###.us-west-2.compute.internal", "PublicIpAddress": "##.###.###.##", "Id": "ci-12XXXXXXXXFMH", "PrivateIpAddress": "###.##.#.###" ``` Para obter mais informações, consulte os [comandos do Amazon EMR na AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/emr). ------ ## Conectar-se ao nó primário usando SSH e uma chave privada do Amazon EC2 no Linux, Unix e Mac OS X Para criar uma conexão SSH autenticada com um arquivo de chave privada, você precisa especificar a chave privada do par de chaves do Amazon EC2 ao iniciar um cluster. Para obter mais informações sobre como acessar seu par de chaves, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*. Seu computador Linux muito provavelmente inclui um cliente SSH por padrão. Por exemplo, a OpenSSH está instalada na maioria dos sistemas operacionais Unix, Linux e MacOS X. É possível verificar se existe um cliente SSH digitando **ssh** na linha de comando. Se o computador não reconhecer o comando, instale um cliente SSH para se conectar ao nó primário. O projeto OpenSSH fornece uma implementação grátis do pacote completo de ferramentas SSH. Para obter mais informações, consulte o site do [OpenSSH](http://www.openssh.org/). As instruções a seguir demonstram como abrir uma conexão SSH com o nó primário do Amazon EMR no Linux, Unix e Mac OS X. **Para configurar as permissões do arquivo de chave privada do par de chaves** Antes de usar sua chave privada do par de chaves do Amazon EC2 para criar uma conexão SSH, você deve definir permissões no arquivo `.pem` para que apenas o proprietário da chave tenha permissão para acessar o arquivo. Isso é necessário para criar uma conexão SSH usando o terminal ou o. AWS CLI 1. Verifique se você permitiu tráfego SSH de entrada. Para instruções, consulte [Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada](emr-connect-ssh-prereqs.md). 1. Localize seu arquivo `.pem`. Estas instruções pressupõem que o arquivo se chame `mykeypair.pem` e esteja armazenado no diretório inicial do usuário atual. 1. Digite o seguinte comando para definir as permissões. *\$1/mykeypair.pem*Substitua pelo caminho completo e pelo nome do arquivo de chave privada do par de chaves. Por exemplo, `C:/Users//.ssh/mykeypair.pem`. ``` 1. chmod 400 ~/mykeypair.pem ``` Se você não definir permissões no arquivo `.pem`, receberá um erro indicando que o arquivo de chave está desprotegido e que a chave será rejeitada. Para conectar, você só precisa definir permissões no arquivo de chave privada do par de chaves ao usá-lo pela primeira vez. **Conectar-se ao nó primário usando o terminal** 1. Abra uma janela do terminal. No Mac OS X, escolha **Applications > Utilities > Terminal (Aplicativos > Utilitários > Terminal)**. Em outras distribuições do Linux, o terminal está normalmente localizado em **Applications > Accessories > Terminal (Aplicativos > Acessórios > Terminal)**. 1. Para estabelecer uma conexão com o nó primário, digite o comando a seguir. *ec2-\$1\$1\$1-\$1\$1-\$1\$1-\$1\$1\$1.compute-1.amazonaws.com*Substitua pelo nome DNS público primário do seu cluster e *\$1/mykeypair.pem* substitua pelo caminho completo e pelo nome do `.pem` arquivo. Por exemplo, `C:/Users//.ssh/mykeypair.pem`. ``` 1. ssh hadoop@ec2-###-##-##-###.compute-1.amazonaws.com -i ~/mykeypair.pem ``` **Importante** Você deve usar o nome de logon `hadoop` ao se conectar ao nó primário do Amazon EMR; caso contrário, poderá ver um erro semelhante a `Server refused our key`. 1. Um aviso afirma que não foi possível verificar a autenticidade do host ao qual você está se conectando. Digite `yes` para continuar. 1. Quando você encerrar de trabalhar no nó primário, digite o seguinte comando para encerrar a conexão SSH. ``` exit ``` Caso tenha dificuldades ao usar o SSH para se conectar ao nó primário, consulte [Solução de problemas para conectar-se à sua instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html). ## Conectar-se ao nó primário usando SSH no Windows Os usuários do Windows podem usar um cliente SSH, como o PuTTY para se conectarem ao nó primário. Antes de se conectar ao nó primário do Amazon EMR, você deve baixar e instalar o PuTTY e o Pu. TTYgen Você pode baixar essas ferramentas na [página de download do PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/). O PuTTY não oferece suporte nativamente ao formato de arquivo de chave privada com par de chaves (`.pem`) gerado pelo Amazon EC2. Você usa Pu TTYgen para converter seu arquivo de chave para o formato PuTTY necessário ()`.ppk`. É necessário converter a chave nesse formato (`.ppk`) antes de tentar se conectar ao nó primário usando o PuTTY. Para obter mais informações sobre como converter sua chave, consulte [Convertendo sua chave privada usando Pu TTYgen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) no Guia do usuário do *Amazon EC2*. **Conectar-se ao nó primário usando PuTTY** 1. Verifique se você permitiu tráfego SSH de entrada. Para instruções, consulte [Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada](emr-connect-ssh-prereqs.md). 1. Abra o `putty.exe`. Você também pode executar o PuTTY na lista de programas do Windows. 1. Se necessário, na lista **Category (Categoria)**, escolha **Session (Sessão)**. 1. Em **Nome do host (ou endereço IP)**, digite `hadoop@`*MasterPublicDNS*. Por exemplo: `hadoop@`*ec2-\$1\$1\$1-\$1\$1-\$1\$1-\$1\$1\$1.compute-1.amazonaws.com*. 1. Na lista **Category (Categoria)**, escolha **Connection > SSH (Conexão > SSH)**, **Auth**. 1. Para **Private key file for authentication (Arquivo de chave privada para autenticação)**, escolha **Browse (Procurar)** e selecione o arquivo `.ppk` que você gerou. 1. Escolha **Abrir** e depois **Sim** para descartar o alerta de segurança do PuTTY. **Importante** Quando fizer login no nó primário, digite `hadoop` se for solicitado a especificar um nome de usuário. 1. Quando terminar de trabalhar no nó primário, você poderá encerrar a conexão SSH fechando o PuTTY. **nota** Para evitar que a conexão SSH atinja o tempo limite, é possível escolher **Connection (Conexão)** na lista **Category (Categoria)** e selecionar a opção **Enable TCP\$1keepalives (Habilitar TCP\$1keepalives)**. Se você tiver uma sessão SSH ativa no PuTTY, poderá alterar suas configurações abrindo o contexto (botão direito do mouse) para a barra de título do PuTTY e escolhendo **Alterar configurações**. Caso tenha dificuldades ao usar o SSH para se conectar ao nó primário, consulte [Solução de problemas para conectar-se à sua instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html). ## Conecte-se ao nó primário usando o AWS CLI Você pode criar uma conexão SSH com o nó primário usando o AWS CLI no Windows e no Linux, Unix e Mac OS X. Independentemente da plataforma, você precisa do nome DNS público do nó primário e da chave privada do par de chaves do Amazon EC2. Se você estiver usando o AWS CLI no Linux, Unix ou Mac OS X, também deverá definir permissões no arquivo de chave privada (`.pem`ou`.ppk`), conforme mostrado em[Para configurar as permissões do arquivo de chave privada do par de chaves](#emr-keypair-file-permission-config). **Para se conectar ao nó primário usando o AWS CLI** 1. Verifique se você permitiu tráfego SSH de entrada. Para instruções, consulte [Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada](emr-connect-ssh-prereqs.md). 1. Para recuperar o identificador de cluster, digite: ``` 1. aws emr list-clusters ``` A saída lista seus clusters, incluindo o cluster IDs. Observe o ID do cluster ao qual você está se conectando. ``` "Status": { "Timeline": { "ReadyDateTime": 1408040782.374, "CreationDateTime": 1408040501.213 }, "State": "WAITING", "StateChangeReason": { "Message": "Waiting after step completed" } }, "NormalizedInstanceHours": 4, "Id": "j-2AL4XXXXXX5T9", "Name": "AWS CLI cluster" ``` 1. Digite o comando a seguir para abrir uma conexão SSH com o nó primário. No exemplo a seguir, *j-2AL4XXXXXX5T9* substitua pelo ID do cluster e *\$1/mykeypair.key* substitua pelo caminho completo e pelo nome do `.pem` arquivo (para Linux, Unix e Mac OS X) ou `.ppk` arquivo (para Windows). Por exemplo, `C:\Users\\.ssh\mykeypair.pem`. ``` aws emr ssh --cluster-id j-2AL4XXXXXX5T9 --key-pair-file ~/mykeypair.key ``` 1. Quando terminar de trabalhar no nó primário, feche a AWS CLI janela. Para obter mais informações, consulte os [comandos do Amazon EMR na AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/emr). Caso tenha dificuldades ao usar o SSH para se conectar ao nó primário, consulte [Solução de problemas para conectar-se à sua instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html). # Portas de serviços do Amazon EMR **nota** Veja a seguir interfaces e portas de serviço para componentes do Amazon EMR. Esta não é uma lista completa de portas de serviço. Não estão listados serviços não padrão, como portas SSL e outros tipos de protocolos. **Importante** Tome cuidado ao editar as regras de grupo de segurança para portas abertas. Adicione regras que só permitam tráfego de clientes confiáveis e autenticados para os protocolos e portas que sejam necessários para executar suas workloads. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-service-ports.html) # Visualizar interfaces Web hospedadas em clusters do Amazon EMR **Importante** É possível configurar um grupo de segurança personalizado para permitir acesso de entrada a essas interfaces da Web. Lembre-se de que qualquer porta na qual você permita o tráfego de entrada representa uma possível vulnerabilidade de segurança. Revise atentamente os grupos de segurança personalizados para minimizar vulnerabilidades. Para obter mais informações, consulte [Controle do tráfego de rede com grupos de segurança para o cluster do Amazon EMR](emr-security-groups.md). O Hadoop e outras aplicações que você instala no cluster do EMR publicam interfaces de usuário como sites hospedados no nó primário. Por motivos de segurança, ao usar grupos de segurança gerenciados pelo Amazon EMR, esses sites estão disponíveis somente no nó primário do servidor Web local. Por isso, é necessário se conectar ao nó primário para visualizar as interfaces Web. 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). O Hadoop também publica interfaces de usuário como sites hospedados nos nós core e escravos. Esses sites também só estão disponíveis em servidores Web locais nos nós. A tabela a seguir lista as interfaces da web que você pode visualizar nas instâncias do cluster. Essas interfaces Hadoop estão disponíveis em todos os clusters. Para as interfaces da instância mestre, *master-public-dns-name* substitua pelo **DNS público principal** listado na guia **Resumo** do cluster no console do Amazon EMR. Para interfaces principais e de instância de tarefas, *coretask-public-dns-name* substitua pelo **nome DNS público** listado para a instância. Para encontrar um **Nome público DNS**, no console do Amazon EMR, escolha seu cluster na lista, escolha a guia **Hardware**, escolha o **ID** do grupo de instâncias que contém a instância à qual você deseja se conectar e anote o **Nome público DNS** listado para a instância. | Nome da interface | URI | | --- | --- | | Servidor de histórico do Flink (EMR versão 5.33 e posteriores) | http: //:8082/ master-public-dns-name | | Ganglia | http://master-public-dns-name/ganglia/ | | Hadoop HDFS (versão NameNode EMR anterior à 6.x) | http: //:50070/ master-public-dns-name | | Hadoop HDFS (versão NameNode EMR anterior à 6.x) | https: //:50470/ master-public-dns-name | | Hadoop HDFS ( NameNode EMR versão 6.x) | http: //:9870/ master-public-dns-name | | Hadoop HDFS ( NameNode EMR versão 6.x) | https: //:9871/ master-public-dns-name | | Hadoop HDFS (versão DataNode EMR anterior à 6.x) | http: //:50075/ coretask-public-dns-name | | Hadoop HDFS (versão DataNode EMR anterior à 6.x) | https: //:50475/ coretask-public-dns-name | | Hadoop HDFS ( DataNodeEMR versão 6.x) | http: //:9864/ coretask-public-dns-name | | Hadoop HDFS ( DataNode EMR versão 6.x) | https: //:9865/ coretask-public-dns-name | | HBase | http: //:16010/ master-public-dns-name | | Hue | http: //:8888/ master-public-dns-name | | JupyterHub | https: //:9443/ master-public-dns-name | | Livy | http: //:8998/ master-public-dns-name | | Faísca HistoryServer | http: //:18080/ master-public-dns-name | | Tez | http: //:8080/tez-ui master-public-dns-name | | FIO NodeManager | http: //:8042/ coretask-public-dns-name | | FIO ResourceManager | http: //:8088/ master-public-dns-name | | Zeppelin | http: //:8890/ master-public-dns-name | Como existem várias interfaces específicas de aplicações disponíveis no nó primário, mas não disponíveis nos nós centrais e de tarefa, as instruções neste documento são específicas para o nó primário do Amazon EMR. O acesso as interfaces Web em todos os nós centrais e de tarefa pode ser feito da mesma maneira como você acessaria as interfaces Web no nó primário. Existem várias maneiras de acessar as interfaces Web no nó primário. O método mais fácil e rápido é usar o SSH para conectar-se ao nó primário e usar o navegador baseado em texto, o Lynx, para visualizar os sites no cliente SSH. No entanto, o Lynx é um navegador baseado em texto com uma interface de usuário limitada que não pode exibir gráficos. O exemplo a seguir mostra como abrir a ResourceManager interface do Hadoop usando o Lynx (o Lynx também URLs é fornecido quando você faz login no nó primário usando SSH). ``` lynx http://ip-###-##-##-###.us-west-2.compute.internal:8088/ ``` Existem duas opções restantes para acessar interfaces Web no nó primário que fornecem funcionalidade de navegador completa. Escolha uma das seguintes opções: + Opção 1 (recomendada para usuários mais técnicos): use um cliente SSH para conectar-se ao nó primário, configurar o túnel SSH com o encaminhamento de porta local e usar um navegador da Internet para abrir interfaces Web hospedadas no nó primário. Esse método permite que você configure o acesso à interface Web sem usar um proxy SOCKS. + Opção 2 (recomendada para novos usuários): use um cliente SSH para se conectar ao nó primário, configure o tunelamento SSH com encaminhamento dinâmico de portas e configure seu navegador da Internet para usar um complemento, como o Firefox ou SwitchyOmega o Chrome, FoxyProxy para gerenciar suas configurações de proxy SOCKS. Esse método permite filtrar automaticamente URLs com base em padrões de texto e limitar as configurações de proxy a domínios que correspondam ao formato do nome DNS do nó primário. Para obter mais informações sobre como configurar FoxyProxy para o Firefox e o Google Chrome, consulte[Opção 2, parte 2: configurar definições de proxy para exibir sites hospedados no nó primário do cluster do Amazon EMR](emr-connect-master-node-proxy.md). **nota** Se você modificar a porta em que a aplicação é executada por meio da configuração do cluster, o hiperlink para a porta não será atualizado no console do Amazon EMR. Isso ocorre porque o console não tem a funcionalidade de ler a configuração `server.port`. Com a versão 5.25.0 ou posterior do Amazon EMR, você pode acessar a interface do usuário do servidor de histórico do Spark a partir do console sem configurar um proxy da web por meio de uma conexão SSH. Para obter mais informações, consulte [One-click access to persistent Spark history server](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html). **Topics** + [ # Opção 1: configurar um túnel SSH ao nó primário do Amazon EMR usando o encaminhamento de portas locais ](emr-ssh-tunnel-local.md) + [ # Opção 2, parte 1: configurar um túnel SSH para o nó primário usando o encaminhamento de portas dinâmicas ](emr-ssh-tunnel.md) + [ # Opção 2, parte 2: configurar definições de proxy para exibir sites hospedados no nó primário do cluster do Amazon EMR ](emr-connect-master-node-proxy.md) # Opção 1: configurar um túnel SSH ao nó primário do Amazon EMR usando o encaminhamento de portas locais Para se conectar ao servidor Web local no nó primário, crie um túnel SSH entre seu computador e o nó primário. Isso também é conhecido como *encaminhamento de portas*. Se não quiser usar um proxy SOCKS, você poderá configurar um túnel SSH para o nó primário usando o encaminhamento de portas locais. Com o encaminhamento de portas locais, você pode especificar portas locais que são utilizadas para encaminhar o tráfego a portas remotas específicas no servidor Web local do nó primário. A configuração de um túnel SSH usando o encaminhamento de portas locais requer o nome DNS público do nó primário e seu arquivo de chave privada do par de chaves. Para obter informações sobre como localizar o nome DNS público principal, consulte [Recuperar o nome DNS público do nó primário](emr-connect-master-node-ssh.md#emr-connect-master-dns). Para obter mais informações sobre como acessar seu par de chaves, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*. Para obter mais informações sobre os sites que você pode querer visualizar no nó primário, consulte [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md). ## Configurar um túnel SSH ao nó primário usando o encaminhamento de portas locais com OpenSSH **Para configurar um túnel SSH usando o encaminhamento de portas locais no terminal** 1. Verifique se você permitiu tráfego SSH de entrada. Para instruções, consulte [Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada](emr-connect-ssh-prereqs.md). 1. Abra uma janela do terminal. No Mac OS X, escolha **Applications > Utilities > Terminal (Aplicativos > Utilitários > Terminal)**. Em outras distribuições do Linux, o terminal está normalmente localizado em **Applications > Accessories > Terminal (Aplicativos > Acessórios > Terminal)**. 1. Digite o comando a seguir para abrir um túnel SSH em sua máquina local. Este exemplo de comando acessa a interface ResourceManager da web encaminhando o tráfego na porta local 8157 (uma porta local não usada escolhida aleatoriamente) para a porta 8088 no servidor web local do nó principal.  No comando, *\$1/mykeypair.pem* substitua pelo local e pelo nome do `.pem` arquivo e *ec2-\$1\$1\$1-\$1\$1-\$1\$1-\$1\$1\$1.compute-1.amazonaws.com* substitua pelo nome DNS público principal do cluster. Para acessar uma interface da Web diferente, `8088` substitua pelo número de porta apropriado. Por exemplo, `8088` substitua `8890` pela interface do Zeppelin. ``` ssh -i ~/mykeypair.pem -N -L 8157:ec2-###-##-##-###.compute-1.amazonaws.com:8088 hadoop@ec2-###-##-##-###.compute-1.amazonaws.com ``` `-L` significa o uso do encaminhamento de portas locais, que permite especificar uma porta local usada para encaminhar dados à porta remota identificada no servidor Web local do nó principal. Após a emissão desse comando, o terminal permanece aberto e não retorna uma resposta.  1. Para abrir a interface ResourceManager da web em seu navegador, digite `http://localhost:8157/` na barra de endereço. 1. Quando terminar de trabalhar com as interfaces Web no nó primário, feche as janelas do terminal. # Opção 2, parte 1: configurar um túnel SSH para o nó primário usando o encaminhamento de portas dinâmicas Para se conectar ao servidor Web local no nó primário, crie um túnel SSH entre seu computador e o nó primário. Isso também é conhecido como *encaminhamento de portas*. Se você criar seu túnel SSH usando o encaminhamento de portas dinâmicas, todo o tráfego encaminhado para uma porta local não utilizada especificada será encaminhado ao servidor Web local no nó primário. Isso cria um proxy SOCKS. Em seguida, você pode configurar seu navegador da Internet para usar um complemento, como FoxyProxy ou SwitchyOmega para gerenciar suas configurações de proxy SOCKS. O uso de um complemento de gerenciamento de proxy permite filtrar automaticamente URLs com base em padrões de texto e limitar as configurações de proxy a domínios que correspondam ao formato do nome DNS público do nó primário. O complemento do navegador manipula automaticamente a ativação e desativação do proxy quando você alterna entre visualizar sites hospedados no nó primário e aqueles na Internet. Antes de começar, você precisa do nome DNS público do nó primário e do arquivo de chave privada do par de chaves. Para obter informações sobre como localizar o nome DNS público primário, consulte [Recuperar o nome DNS público do nó primário](emr-connect-master-node-ssh.md#emr-connect-master-dns). Para obter mais informações sobre como acessar seu par de chaves, consulte [Pares de chaves do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) no *Guia do usuário do Amazon EC2*. Para obter mais informações sobre os sites que você pode querer visualizar no nó primário, consulte [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md). ## Para configurar um túnel SSH usando o encaminhamento de portas dinâmicas do nó primário com o OpenSSH **Configurar um túnel SSH usando o encaminhamento de portas dinâmicas com OpenSSH** 1. Verifique se você permitiu tráfego SSH de entrada. Para instruções, consulte [Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada](emr-connect-ssh-prereqs.md). 1. Abra uma janela do terminal. No Mac OS X, escolha **Applications > Utilities > Terminal (Aplicativos > Utilitários > Terminal)**. Em outras distribuições do Linux, o terminal está normalmente localizado em **Applications > Accessories > Terminal (Aplicativos > Acessórios > Terminal)**. 1. Digite o seguinte comando para abrir um túnel SSH na sua máquina local. *\$1/mykeypair.pem*Substitua pelo local e pelo nome do `.pem` arquivo, *8157* substitua por um número de porta local não utilizado e *ec2-\$1\$1\$1-\$1\$1-\$1\$1-\$1\$1\$1.compute-1.amazonaws.com* substitua pelo nome DNS público primário do seu cluster. ``` 1. ssh -i ~/mykeypair.pem -N -D 8157 hadoop@ec2-###-##-##-###.compute-1.amazonaws.com ``` Após a execução desse comando, o terminal permanece aberto e não retorna uma resposta. **nota** `-D` significa o uso do encaminhamento de portas dinâmicas, que permite especificar uma porta local usada para encaminhar dados a todas as portas remotas identificadas no servidor Web local do nó primário. O encaminhamento de portas dinâmicas cria um proxy SOCKS local que escuta na porta especificada no comando. 1. Depois que o túnel estiver ativo, configure um proxy SOCKS para o seu navegador. Para obter mais informações, consulte [Opção 2, parte 2: configurar definições de proxy para exibir sites hospedados no nó primário do cluster do Amazon EMR](emr-connect-master-node-proxy.md). 1. Quando terminar de trabalhar com as interfaces Web no nó primário, feche a janela do terminal. ## Configure um túnel SSH usando o encaminhamento dinâmico de portas com o AWS CLI Você pode criar uma conexão SSH com o nó primário usando o AWS CLI no Windows e no Linux, Unix e Mac OS X. Se você estiver usando o AWS CLI no Linux, Unix ou Mac OS X, deverá definir as permissões no `.pem` arquivo conforme mostrado em. [Para configurar as permissões do arquivo de chave privada do par de chaves](emr-connect-master-node-ssh.md#emr-keypair-file-permission-config) Se você estiver usando o AWS CLI no Windows, o PuTTY deverá aparecer na variável de ambiente path ou você poderá receber um erro como OpenSSH ou PuTTY não disponível. **Para configurar um túnel SSH usando o encaminhamento dinâmico de portas com o AWS CLI** 1. Verifique se você permitiu tráfego SSH de entrada. Para instruções, consulte [Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada](emr-connect-ssh-prereqs.md). 1. Crie uma conexão SSH com o nó primário, conforme mostrado em [Conecte-se ao nó primário usando o AWS CLI](emr-connect-master-node-ssh.md#emr-connect-cli). 1. Para recuperar o identificador de cluster, digite: ``` 1. aws emr list-clusters ``` A saída lista seus clusters, incluindo o cluster IDs. Observe o ID do cluster ao qual você está se conectando. ``` "Status": { "Timeline": { "ReadyDateTime": 1408040782.374, "CreationDateTime": 1408040501.213 }, "State": "WAITING", "StateChangeReason": { "Message": "Waiting after step completed" } }, "NormalizedInstanceHours": 4, "Id": "j-2AL4XXXXXX5T9", "Name": "AWS CLI cluster" ``` 1. Digite o seguinte comando para abrir um túnel SSH para o nó primário usando o encaminhamento de portas dinâmicas. No exemplo a seguir, *j-2AL4XXXXXX5T9* substitua pelo ID do cluster e *\$1/mykeypair.key* substitua pelo local e nome do `.pem` arquivo (para Linux, Unix e Mac OS X) ou `.ppk` arquivo (para Windows). ``` aws emr socks --cluster-id j-2AL4XXXXXX5T9 --key-pair-file ~/mykeypair.key ``` **nota** O comando socks configura automaticamente o encaminhamento de portas dinâmicas na porta local 8157. Atualmente, essa configuração não pode ser modificada. 1. Depois que o túnel estiver ativo, configure um proxy SOCKS para o seu navegador. Para obter mais informações, consulte [Opção 2, parte 2: configurar definições de proxy para exibir sites hospedados no nó primário do cluster do Amazon EMR](emr-connect-master-node-proxy.md). 1. Quando terminar de trabalhar com as interfaces da Web no nó primário, feche a AWS CLI janela. Para obter mais informações sobre o uso dos comandos do Amazon EMR no AWS CLI, consulte. [https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr) ## Configurar um túnel SSH para o nó primário usando PuTTY Os usuários do Windows podem usar um cliente SSH, como o PuTTY, para criar um túnel SSH para o nó primário. Antes de se conectar ao nó primário do Amazon EMR, você deve baixar e instalar o PuTTY e o Pu. TTYgen Você pode baixar essas ferramentas na [página de download do PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/). O PuTTY não oferece suporte nativamente ao formato de arquivo de chave privada com par de chaves (`.pem`) gerado pelo Amazon EC2. Você usa Pu TTYgen para converter seu arquivo de chave para o formato PuTTY necessário ()`.ppk`. É necessário converter a chave nesse formato (`.ppk`) antes de tentar se conectar ao nó primário usando o PuTTY. Para obter mais informações sobre como converter sua chave, consulte [Convertendo sua chave privada usando Pu TTYgen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html) no Guia do usuário do *Amazon EC2*. **Configurar um túnel SSH usando o encaminhamento de portas dinâmicas usando PuTTY** 1. Verifique se você permitiu tráfego SSH de entrada. Para instruções, consulte [Antes de se conectar ao Amazon EMR: autorize o tráfego de entrada](emr-connect-ssh-prereqs.md). 1. Clique duas vezes em `putty.exe` para iniciar o PuTTY. Você também pode executar o PuTTY na lista de programas do Windows. **nota** Se você já tiver uma sessão SSH ativa com o nó primário, poderá adicionar um túnel clicando com o botão direito do mouse na barra de título do PuTTY e escolhendo **Alterar configurações**. 1. Se necessário, na lista **Category (Categoria)**, escolha **Session (Sessão)**. 1. No campo **Nome do host**, digite **hadoop@***MasterPublicDNS*. Por exemplo: **hadoop@***ec2-\$1\$1\$1-\$1\$1-\$1\$1-\$1\$1\$1.compute-1.amazonaws.com*. 1. Na lista **Category (Categoria)**, expanda **Connection > SSH (Conexão > SSH)** e escolha **Auth**. 1. Para **Private key file for authentication (Arquivo de chave privada para autenticação)**, escolha **Browse (Procurar)** e selecione o arquivo `.ppk` que você gerou. **nota** O PuTTY não oferece suporte nativamente ao formato de arquivo de chave privada com par de chaves (`.pem`) gerado pelo Amazon EC2. Você usa Pu TTYgen para converter seu arquivo de chave para o formato PuTTY necessário ()`.ppk`. É necessário converter a chave nesse formato (`.ppk`) antes de tentar se conectar ao nó primário usando o PuTTY. 1. Na lista **Category (Categoria)**, expanda **Connection > SSH (Conexão > SSH)** e escolha **Tunnels (Túneis)**. 1. No campo **Porta de origem**, digite `8157` (uma porta local não utilizada) e escolha **Adicionar**. 1. Deixe o campo **Destination (Destino)** em branco. 1. Selecione as opções **Dynamic (Dinâmico)** e **Auto**. 1. Escolha **Open (Abrir)**. 1. Escolha **Yes (Sim)** para descartar o alerta de segurança do PuTTY. **Importante** Ao fazer login no nó primário, digite `hadoop` se for solicitado um nome de usuário. 1. Depois que o túnel estiver ativo, configure um proxy SOCKS para o seu navegador. Para obter mais informações, consulte [Opção 2, parte 2: configurar definições de proxy para exibir sites hospedados no nó primário do cluster do Amazon EMR](emr-connect-master-node-proxy.md). 1. Quando terminar de trabalhar com as interfaces Web no nó primário, feche a janela do PuTTY. # Opção 2, parte 2: configurar definições de proxy para exibir sites hospedados no nó primário do cluster do Amazon EMR Se você usar um túnel SSH com o encaminhamento de portas dinâmicas, deverá usar um complemento de gerenciamento de proxy SOCKS para controlar as configurações de proxy no seu navegador. O uso de uma ferramenta de gerenciamento de proxy SOCKS permite filtrar automaticamente URLs com base em padrões de texto e limitar as configurações de proxy a domínios que correspondam ao formato do nome DNS público do nó primário. O complemento do navegador manipula automaticamente a ativação e desativação do proxy quando você alterna entre visualizar sites hospedados no nó primário e aqueles na Internet. Para gerenciar suas configurações de proxy, configure seu navegador para usar um complemento como FoxyProxy ou SwitchyOmega. Para obter mais informações sobre como criar um túnel SSH, consulte [Opção 2, parte 1: configurar um túnel SSH para o nó primário usando o encaminhamento de portas dinâmicas](emr-ssh-tunnel.md). Para obter mais informações sobre as interfaces Web disponíveis, consulte [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md). Inclua as seguintes configurações ao definir o complemento de proxy: + Use **localhost** como endereço do host. + Use o mesmo número de porta local que você selecionou para estabelecer o túnel SSH com o nó primário em [Opção 2, parte 1: configurar um túnel SSH para o nó primário usando o encaminhamento de portas dinâmicas](emr-ssh-tunnel.md). Por exemplo, porta*8157*. Essa porta também deve corresponder ao número de porta que você usa no PuTTY ou em qualquer outro emulador de terminal usado para conexão. + Especifique o protocolo **SOCKS v5**. Com o SOCKS v5, opcionalmente, você pode configurar a autorização do usuário. + **URL Patterns (Padrões de URL)** Os seguintes padrões de URL devem ser allow-listed e estão especificados com um tipo de padrão de curinga: + Os padrões **\$1ec2\$1.\$1compute\$1.amazonaws.com\$1** e **\$110\$1.amazonaws.com\$1** para corresponder ao nome DNS público dos clusters nas regiões dos EUA. + Os padrões **\$1ec2\$1.compute\$1** e **\$110\$1.compute\$1** correspondem ao nome DNS público dos clusters de todas as outras regiões. + UM **10. **\$1 padrão para fornecer acesso aos arquivos de JobTracker log no Hadoop. Altere esse filtro se ele entrar em conflito com seu plano de acesso de rede. + Os padrões **\$1.ec2.internal\$1** e **\$1.compute.internal\$1** correspondem aos nomes DNS privados (internos) dos clusters na região `us-east-1` e em todas as outras regiões, respectivamente. ## Exemplo: Configurar FoxyProxy para o Firefox O exemplo a seguir demonstra uma configuração FoxyProxy padrão (versão 7.5.1) para o Mozilla Firefox. FoxyProxy fornece um conjunto de ferramentas de gerenciamento de proxy. Com ele, você pode usar um servidor proxy para URLs que correspondam aos padrões referentes aos domínios usados pelas instâncias do Amazon EC2 no cluster do Amazon EMR. **Para instalar e configurar FoxyProxy usando o Mozilla Firefox** 1. No Firefox, acesse [https://addons.mozilla.org/](https://addons.mozilla.org/), pesquise por FoxyProxy Padrão e siga as instruções para adicionar FoxyProxy ao Firefox. 1. Usando um editor de texto, crie um arquivo JSON chamado `foxyproxy-settings.json` com base no exemplo de configuração a seguir. ``` { "k20d21508277536715": { "active": true, "address": "localhost", "port": 8157, "username": "", "password": "", "type": 3, "proxyDNS": true, "title": "emr-socks-proxy", "color": "#0055E5", "index": 9007199254740991, "whitePatterns": [ { "title": "*ec2*.*compute*.amazonaws.com*", "active": true, "pattern": "*ec2*.*compute*.amazonaws.com*", "importedPattern": "*ec2*.*compute*.amazonaws.com*", "type": 1, "protocols": 1 }, { "title": "*ec2*.compute*", "active": true, "pattern": "*ec2*.compute*", "importedPattern": "*ec2*.compute*", "type": 1, "protocols": 1 }, { "title": "10.*", "active": true, "pattern": "10.*", "importedPattern": "http://10.*", "type": 1, "protocols": 2 }, { "title": "*10*.amazonaws.com*", "active": true, "pattern": "*10*.amazonaws.com*", "importedPattern": "*10*.amazonaws.com*", "type": 1, "protocols": 1 }, { "title": "*10*.compute*", "active": true, "pattern": "*10*.compute*", "importedPattern": "*10*.compute*", "type": 1, "protocols": 1 }, { "title": "*.compute.internal*", "active": true, "pattern": "*.compute.internal*", "importedPattern": "*.compute.internal*", "type": 1, "protocols": 1 }, { "title": "*.ec2.internal* ", "active": true, "pattern": "*.ec2.internal*", "importedPattern": "*.ec2.internal*", "type": 1, "protocols": 1 } ], "blackPatterns": [] }, "logging": { "size": 100, "active": false }, "mode": "patterns", "browserVersion": "68.12.0", "foxyProxyVersion": "7.5.1", "foxyProxyEdition": "standard" } ``` 1. Abra a página **Gerenciamento de extensões** do Firefox (acesse **about:addons** e escolha **Extensões**). 1. Escolha **FoxyProxy Padrão** e, em seguida, escolha o botão de mais opções (o botão que parece uma elipse). 1. Selecione **Opções** no menu suspenso. 1. Escolha **Importar configurações** no menu esquerdo. 1. **Na página **Configurações de importação**, escolha **Importar configurações** em **Importar configurações do FoxyProxy 6.0\$1**, navegue até o local do `foxyproxy-settings.json` arquivo que você criou, selecione o arquivo e escolha Abrir.** 1. Escolha **OK** quando solicitado para substituir as configurações atuais e salvar a nova configuração. ## Exemplo: Configurar SwitchyOmega para o Chrome O exemplo a seguir demonstra como configurar a SwitchyOmega extensão para o Google Chrome. SwitchyOmega permite configurar, gerenciar e alternar entre vários proxies. **Para instalar e configurar SwitchyOmega usando o Google Chrome** 1. Vá para [https://chrome.google.com/webstore/categoria/extensões](https://chrome.google.com/webstore/category/extensions), pesquise por **Proxy SwitchyOmega** e adicione-o ao Chrome. 1. Escolha **Novo perfil** e insira `emr-socks-proxy` como nome do perfil. 1. Escolha **Perfil PAC** e **Criar**. Os arquivos de [configuração automática de proxy (PAC)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_(PAC)_file) ajudam a definir uma lista de permissões para solicitações do navegador que devem ser encaminhadas a um servidor proxy da Web. 1. No campo **Script PAC**, substitua o conteúdo pelo script a seguir, que define o que URLs deve ser encaminhado por meio do seu servidor proxy web. Se você especificou um número de porta diferente ao configurar seu túnel SSH, *8157* substitua pelo número da porta. ``` function FindProxyForURL(url, host) { if (shExpMatch(url, "*ec2*.*compute*.amazonaws.com*")) return 'SOCKS5 localhost:8157'; if (shExpMatch(url, "*ec2*.compute*")) return 'SOCKS5 localhost:8157'; if (shExpMatch(url, "http://10.*")) return 'SOCKS5 localhost:8157'; if (shExpMatch(url, "*10*.compute*")) return 'SOCKS5 localhost:8157'; if (shExpMatch(url, "*10*.amazonaws.com*")) return 'SOCKS5 localhost:8157'; if (shExpMatch(url, "*.compute.internal*")) return 'SOCKS5 localhost:8157'; if (shExpMatch(url, "*ec2.internal*")) return 'SOCKS5 localhost:8157'; return 'DIRECT'; } ``` 1. Em **Ações**, escolha **Aplicar alterações** para salvar as configurações de proxy. 1. Na barra de ferramentas do Chrome, escolha SwitchyOmega e selecione o `emr-socks-proxy` perfil. ## Acessar uma interface da Web no navegador Para abrir uma interface Web, insira o nome DNS público do seu nó primário ou central seguido pelo número da porta da interface escolhida na barra de endereço do navegador. O exemplo a seguir mostra a URL que você digitaria para se conectar ao Spark HistoryServer. ``` http://master-public-dns-name:18080/ ``` Para obter instruções sobre como recuperar o nome DNS público de um nó, consulte [Recuperar o nome DNS público do nó primário](emr-connect-master-node-ssh.md#emr-connect-master-dns). Para obter uma lista completa da interface da web URLs, consulte[Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md). # Envio de trabalhos para um cluster do Amazon EMR Esta seção descreve os métodos que você pode usar para enviar trabalhos a um cluster do Amazon EMR. Para enviar trabalhos, é possível adicionar etapas ou enviar trabalhos do Hadoop de forma interativa para o nó primário. Considere estas regras de comportamento de etapas ao enviar etapas para um cluster: + Um ID de etapa pode conter até 256 caracteres. + Pode haver até 256 etapas PENDING e RUNNING em um cluster. + Mesmo com 256 etapas ativas em execução no cluster, é possível enviar trabalhos de forma interativa ao nó primário. Você pode enviar um número ilimitado de etapas durante a vida útil de um cluster de execução prolongada, mas apenas 256 etapas podem estar no estado RUNNING ou PENDING em um determinado momento. + Com as versões 4.8.0 e posteriores do Amazon EMR, exceto a versão 5.0.0, você pode cancelar etapas pendentes. Para obter mais informações, consulte [Cancelamento de etapas ao enviar trabalho para um cluster do Amazon EMR](emr-cancel-steps.md). + Com o Amazon EMR 5.28.0 e versões posteriores, você pode cancelar as etapas pendentes e em execução. Você também pode optar por executar várias etapas em paralelo para melhorar a utilização de cluster e economizar custos. Para obter mais informações, consulte [Considerações sobre a execução de várias etapas em paralelo ao enviar trabalhos para o Amazon EMR](emr-concurrent-steps.md). **nota** Para obter o melhor desempenho, recomendamos que você armazene ações de bootstrap, scripts e outros arquivos personalizados que você deseja usar com o Amazon EMR em um bucket do Amazon S3 que esteja no Região da AWS mesmo que seu cluster. **Topics** + [ # Adicionar etapas a um cluster com o Console de Gerenciamento do Amazon EMR ](emr-add-steps-console.md) + [ # Adicionar etapas a um cluster do Amazon EMR com o AWS CLI ](add-step-cli.md) + [ # Considerações sobre a execução de várias etapas em paralelo ao enviar trabalhos para o Amazon EMR ](emr-concurrent-steps.md) + [ # Exibição das etapas após enviar trabalhos para um cluster do Amazon EMR ](emr-view-steps.md) + [ # Cancelamento de etapas ao enviar trabalho para um cluster do Amazon EMR ](emr-cancel-steps.md) # Adicionar etapas a um cluster com o Console de Gerenciamento do Amazon EMR Realize os procedimentos a seguir para adicionar etapas a um cluster usando o Console de gerenciamento da AWS. Para obter informações detalhadas sobre como enviar etapas para aplicações específicas de big data, consulte as seguintes seções do *[Guia de lançamento do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html)*: + [Enviar uma etapa de JAR personalizado](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-launch-custom-jar-cli.html) + [Enviar uma etapa de transmissão do Hadoop ](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/CLI_CreateStreaming.html) + [Enviar uma etapa do Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-submit-step.html) + [Enviar uma etapa do Pig](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-pig-launch.html#ConsoleCreatingaPigJob) + [Executar um comando ou script como etapa](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-launch-custom-jar-cli.html) + [Transmitir valores em etapas para executar scripts do Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-differences.html#emr-hive-additional-features) ## Adicionar etapas durante a criação do cluster A partir do Console de gerenciamento da AWS, você pode adicionar etapas ao criar um cluster. ------ #### [ Console ] **Para adicionar etapas ao criar um cluster usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters** e depois **Criar cluster**. 1. Em **Etapas**, escolha **Adicionar etapa**. Insira os valores apropriados nos campos da caixa de diálogo **Adicionar etapa**. Para obter informações sobre como formatar argumentos de etapa, consulte [Adicionar argumentos de etapas](#emr-add-steps-console-arguments). As opções diferem dependendo do tipo de etapa. Para adicionar a etapa e sair da caixa de diálogo, selecione **Adicionar etapa**. 1. Escolha qualquer outra opção que se aplique ao cluster. 1. Para iniciar o cluster, escolha **Criar cluster**. ------ ## Adicionar etapas a um cluster em execução Com o Console de gerenciamento da AWS, você pode adicionar etapas a um cluster com a opção de encerramento automático desativada. ------ #### [ Console ] **Para adicionar etapas a um cluster em execução usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e selecione o cluster que você deseja atualizar. 1. Na guia **Etapas** da página de detalhes do cluster, selecione a guia **Adicionar etapa**. Para clonar uma etapa já existente, escolha o menu suspenso **Ações** e selecione **Clonar etapa**. 1. Insira os valores apropriados nos campos da caixa de diálogo **Adicionar etapa**. As opções diferem dependendo do tipo de etapa. Para adicionar a etapa e sair da caixa de diálogo, escolha **Adicionar etapa**. ------ ## Modificar o nível de simultaneidade da etapa em um cluster em execução Com o Console de gerenciamento da AWS, você pode modificar o nível de simultaneidade de etapas em um cluster em execução. **nota** Só é possível executar múltiplas etapas em paralelo com o Amazon EMR versão 5.28.0 e posteriores. ------ #### [ Console ] **Para modificar a simultaneidade da etapa em um cluster em execução usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e selecione o cluster que você deseja atualizar. O cluster deve estar em execução para alterar o respectivo atributo de simultaneidade. 1. Na guia **Etapas** da página de detalhes do cluster, encontre a seção **Atributos**. Selecione **Editar** para alterar a simultaneidade. Insira um valor entre 1 e 256. ------ ## Adicionar argumentos de etapas Ao usar o Console de gerenciamento da AWS para adicionar uma etapa ao seu cluster, você pode especificar argumentos para essa etapa no campo **Argumentos**. É necessário separar argumentos com espaço em branco e cercar com aspas argumentos de sequência de caracteres formados por caracteres *e* espaços em branco. **Example : Argumentos corretos** Os argumentos de exemplo a seguir estão formatados corretamente para o Console de gerenciamento da AWS, com aspas ao redor do argumento final da string. ``` bash -c "aws s3 cp s3://amzn-s3-demo-bucket/my-script.sh ." ``` Também é possível colocar cada argumento em uma linha separada para facilitar a leitura, como mostra o exemplo a seguir. ``` bash -c "aws s3 cp s3://amzn-s3-demo-bucket/my-script.sh ." ``` **Example : Argumentos incorretos** Os argumentos de exemplo a seguir estão formatados incorretamente para o Console de gerenciamento da AWS. Observa-se que o argumento final da string ,`aws s3 cp s3://amzn-s3-demo-bucket/my-script.sh .`, contém espaços em branco e não está entre aspas. ``` bash -c aws s3 cp s3://amzn-s3-demo-bucket/my-script.sh . ``` # Adicionar etapas a um cluster do Amazon EMR com o AWS CLI Os procedimentos a seguir demonstram como adicionar etapas a um cluster recém-criado e a um cluster em execução com a AWS CLI. Ambos os exemplos usam o subcomando `--steps` para adicionar etapas ao cluster. **Para adicionar etapas durante a criação do cluster** + Digite o seguinte comando para criar um cluster e adicionar uma etapa do Apache Pig. Substitua *`myKey`* pelo nome do par de chaves do Amazon EC2. ``` 1. aws emr create-cluster --name "Test cluster" \ 2. --applications Name=Spark \ 3. --use-default-roles \ 4. --ec2-attributes KeyName=myKey \ 5. --instance-groups InstanceGroupType=PRIMARY,InstanceCount=1,InstanceType=m5.xlarge InstanceGroupType=CORE,InstanceCount=2,InstanceType=m5.xlarge \ 6. --steps '[{"Args":["spark-submit","--deploy-mode","cluster","--class","org.apache.spark.examples.SparkPi","/usr/lib/spark/examples/jars/spark-examples.jar","5"],"Type":"CUSTOM_JAR","ActionOnFailure":"CONTINUE","Jar":"command-runner.jar","Properties":"","Name":"Spark application"}]' ``` **nota** A lista de argumentos muda dependendo do tipo de etapa. Por padrão, o nível de simultaneidade da etapa é `1`. É possível definir o nível de simultaneidade da etapa usando o parâmetro `StepConcurrencyLevel` ao criar um cluster. A saída é um identificador de cluster semelhante ao seguinte: ``` 1. { 2. "ClusterId": "j-2AXXXXXXGAPLF" 3. } ``` **Para adicionar uma etapa a um cluster em execução** + Digite o seguinte comando para adicionar uma etapa a um cluster em execução. Substitua `j-2AXXXXXXGAPLF` por seu próprio ID do cluster. ``` aws emr add-steps --cluster-id j-2AXXXXXXGAPLF \ --steps '[{"Args":["spark-submit","--deploy-mode","cluster","--class","org.apache.spark.examples.SparkPi","/usr/lib/spark/examples/jars/spark-examples.jar","5"],"Type":"CUSTOM_JAR","ActionOnFailure":"CONTINUE","Jar":"command-runner.jar","Properties":"","Name":"Spark application"}]' ``` A saída é um identificador de etapa semelhante ao seguinte: ``` 1. { 2. "StepIds": [ 3. "s-Y9XXXXXXAPMD" 4. ] 5. } ``` **Para modificar o StepConcurrencyLevel em um cluster em execução** 1. Em um cluster em execução, é possível modificar `StepConcurrencyLevel` com a API `ModifyCluster`. Por exemplo, digite o seguinte comando para aumentar o `StepConcurrencyLevel` para `10`. Substitua `j-2AXXXXXXGAPLF` pelo nome do ID do cluster. ``` aws emr modify-cluster --cluster-id j-2AXXXXXXGAPLF --step-concurrency-level 10 ``` 1. A saída é semelhante à seguinte. ``` { "StepConcurrencyLevel": 10 } ``` Para obter mais informações sobre o uso dos comandos do Amazon EMR no AWS CLI, consulte a Referência de [AWS CLI comandos](https://docs.aws.amazon.com/cli/latest/reference/emr). # Considerações sobre a execução de várias etapas em paralelo ao enviar trabalhos para o Amazon EMR Executar várias etapas paralelamente ao enviar trabalhos para o Amazon EMR exige decisões preliminares sobre planejamento de recursos e expectativas em relação ao comportamento do cluster. Isso é abordado em detalhes aqui. + As etapas executadas em paralelo podem ser concluídas em qualquer ordem, mas as etapas pendentes na fila passam para o estado de execução na ordem em que são enviadas. + Ao selecionar um nível de simultaneidade da etapa para o cluster, você deve considerar se o tipo de instância de nó primário atende ou não aos requisitos de memória das workloads do usuário. O processo executor da etapa principal é executado no nó primário de cada etapa. Executar várias etapas em paralelo requer mais memória e utilização da CPU do nó primário do que executar uma etapa de cada vez. + Para alcançar a programação complexa e o gerenciamento de recursos de etapas simultâneas, você pode usar recursos de programação do YARN, como `FairScheduler` ou `CapacityScheduler`. Por exemplo, você pode usar o `FairScheduler` com um conjunto `queueMaxAppsDefault` para impedir que mais de um determinado número de trabalhos seja executado por vez. + O nível de simultaneidade da etapa está sujeito às configurações dos gerenciadores de recursos. Por exemplo, se o YARN estiver configurado com apenas um paralelismo de `5`, você só poderá ter cinco aplicativos do YARN sendo executados em paralelo, ainda que o `StepConcurrencyLevel` esteja definido como `10`. Para obter mais informações sobre a configuração de gerenciadores de recursos, consulte [Configure applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) no *Guia de lançamento do Amazon EMR*. + Não é possível adicionar uma etapa com `ActionOnFailure` que não seja CONTINUE enquanto o nível de simultaneidade de etapas do cluster for maior que 1. + Se o nível de simultaneidade de etapas do cluster for maior que 1, o atributo `ActionOnFailure` da etapa não será ativado. + Se o nível de simultaneidade de etapas do cluster for `1`, mas houver várias etapas em execução, `TERMINATE_CLUSTER ActionOnFailure` poderá ser ativada, mas não `CANCEL_AND_WAIT ActionOnFailure` será. Esse caso extremo ocorre quando o nível de simultaneidade da etapa do cluster é maior que 1, mas diminui durante a execução de várias etapas. + Você pode usar a escalabilidade automática no EMR para aumentar e diminuir a escala com base nos recursos do YARN de modo a evitar contenção de recursos. Para obter mais informações, consulte [Using automatic scaling with a custom policy for instance groups](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html) no *Guia de gerenciamento do Amazon EMR*. + Quando você diminui o nível de simultaneidade da etapa, o EMR permite que as etapas em execução sejam concluídas antes de reduzir o número de etapas. Se os recursos estiverem esgotados porque o cluster está executando muitas etapas simultâneas, recomendamos cancelar as etapas em execução manualmente para liberar recursos. # Exibição das etapas após enviar trabalhos para um cluster do Amazon EMR Você pode exibir até 10.000 etapas que o Amazon EMR concluiu nos últimos sete dias. Você também pode exibir 1.000 etapas que o Amazon EMR concluiu a qualquer momento. Esse total inclui tanto etapas do sistema quanto etapas enviadas pelo usuário. Se você enviar novas etapas quando o cluster atingir o limite de registro de 1.000 etapas, o Amazon EMR excluirá as etapas inativas enviadas pelo usuário cujos status seja CONCLUÍDO, CANCELADO ou FALHA por mais de sete dias. Se você enviar etapas além do limite de registro de 10.000 etapas, o Amazon EMR excluirá os registros de etapas inativas enviadas pelo usuário, independentemente da duração da inatividade. O Amazon EMR não remove esses registros dos arquivos de log. O Amazon EMR os remove do AWS console e eles não são retornados quando você usa a API AWS CLI ou para recuperar informações do cluster. Registros de etapas do sistema nunca são removidos. As informações de etapas que você pode visualizar dependem do mecanismo usado para recuperar informações do cluster. A tabela a seguir indica as informações de etapa retornadas por cada uma das opções disponíveis. | Opção | DescribeJobFlow ou --describe --jobflow | ListSteps ou lista-etapas | | --- | --- | --- | | SDK | 256 etapas | Até 10 mil etapas | | CLI do Amazon EMR | 256 etapas | NA | | AWS CLI | NA | Até 10 mil etapas | | solicitações de | 256 etapas | Até 10 mil etapas | # Cancelamento de etapas ao enviar trabalho para um cluster do Amazon EMR Você pode cancelar etapas pendentes e em execução do Console de gerenciamento da AWS AWS CLI, do ou do Amazon EMR ao enviar trabalhos para o seu cluster. API. ------ #### [ Console ] **Para cancelar etapas usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e, em seguida, selecione o cluster que você deseja atualizar. 1. Na guia **Etapas** da página de detalhes do cluster, marque a caixa de seleção ao lado da etapa que você deseja cancelar. Escolha o menu suspenso **Ações** e selecione **Cancelar etapas**. 1. Na caixa de diálogo **Cancelar a etapa**, escolha entre cancelar a etapa e esperar a saída ou cancelar a etapa e forçar a saída. Depois, selecione **Confirm** (Confirmar). 1. O status das etapas na tabela **Etapas** é alterado para `CANCELLED`. ------ #### [ CLI ] **Para cancelar usando o AWS CLI** + Use o comando `aws emr cancel-steps`, especificando o cluster e as etapas a serem canceladas. O exemplo a seguir demonstra um comando da AWS CLI para cancelar duas etapas. ``` aws emr cancel-steps --cluster-id j-2QUAXXXXXXXXX \ --step-ids s-3M8DXXXXXXXXX s-3M8DXXXXXXXXX \ --step-cancellation-option SEND_INTERRUPT ``` Com o Amazon EMR versão 5.28.0, você pode escolher uma das duas opções de cancelamento a seguir para o parâmetro `StepCancellationOption` ao cancelar etapas. + `SEND_INTERRUPT`: essa é a opção padrão. Quando uma solicitação de cancelamento de etapa é recebida, o EMR envia um sinal `SIGTERM` para a etapa. Adicione um processador de sinal `SIGTERM` à lógica de etapas para capturar esse sinal e terminar os processos da etapa descendente ou aguarde eles serem concluídos. + `TERMINATE_PROCESS`: quando essa opção é selecionada, o EMR envia um sinal `SIGKILL` para a etapa e para todos os seus processos descendentes, o que os termina imediatamente. ------ **Considerações sobre o cancelamento de etapas** + Cancelar uma etapa em execução ou pendente removerá a etapa da contagem de etapas ativas. + Cancelar uma etapa em execução não permite que uma etapa pendente comece a ser executada, supondo que não haja alteração em `stepConcurrencyLevel`. + O cancelamento de uma etapa em execução não aciona a etapa `ActionOnFailure`. + Para o EMR 5.32.0 e versões posteriores, `SEND_INTERRUPT StepCancellationOption` envia um sinal `SIGTERM` para o processo filho da etapa. Observe esse sinal e faça uma limpeza e desligue-o normalmente. `TERMINATE_PROCESS StepCancellationOption` envia um sinal `SIGKILL` para o processo filho da etapa e para todos os seus processos descendentes; mas os processos assíncronos não são afetados. # Exibição e monitoramento de um cluster do Amazon EMR enquanto executa trabalhos O Amazon EMR fornece várias ferramentas que você pode usar para coletar informações sobre o cluster. Você pode acessar informações sobre o cluster a partir do console, da CLI ou de forma programática. As interfaces Web padrão do Hadoop e os arquivos de log estão disponíveis no nó primário. Você também pode usar serviços de monitoramento, como o CloudWatch Ganglia, para monitorar o desempenho do seu cluster. O histórico do aplicativo também está disponível no console usando o aplicativo UIs “persistente” do Spark History Server a partir do Amazon EMR 5.25.0. Com o Amazon EMR 6.x, o servidor persistente de linha de tempo do YARN e as interfaces do usuário Tez também estão disponíveis. Esses serviços são hospedados fora do cluster, portanto, você pode acessar o histórico de aplicativos por 30 dias após o encerramento do cluster, sem a necessidade de uma conexão SSH ou proxy da Web. Consulte [Visualizar o histórico da aplicação](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html). **Topics** + [ # Exibição de status e detalhes do cluster do Amazon EMR ](emr-manage-view-clusters.md) + [ # Etapa aprimorada de depuração com o Amazon EMR ](emr-enhanced-step-debugging.md) + [ # Como exibir o histórico da aplicação do Amazon EMR ](emr-cluster-application-history.md) + [ # Exibição dos arquivos de log do Amazon EMR ](emr-manage-view-web-log-files.md) + [ # Visualizar instâncias de cluster no Amazon EC2 ](UsingEMR_Tagging.md) + [ # CloudWatch eventos e métricas do Amazon EMR ](emr-manage-cluster-cloudwatch.md) + [ # Exibição das métricas para aplicações de cluster usando o Ganglia com Amazon EMR ](ViewingGangliaMetrics.md) + [ # Registrando AWS chamadas da API EMR usando AWS CloudTrail ](logging-using-cloudtrail.md) + [ # Práticas recomendadas de observabilidade do EMR ](emr-metrics-observability.md) # Exibição de status e detalhes do cluster do Amazon EMR Depois de criar um cluster, você pode monitorar seu status e obter informações detalhadas sobre sua execução e erros que podem ter ocorrido, mesmo depois de ele ter sido terminado. O Amazon EMR salva metadados sobre clusters terminados para sua referência por dois meses, e os metadados são excluídos após esse período. Você não pode excluir clusters do histórico de clusters, mas, usando o Console de gerenciamento da AWS, você pode usar o **Filter (Filtro)** e, usando a AWS CLI, você pode usar opções com o comando `list-clusters` para focalizar nos clusters que interessam a você. Você pode acessar o histórico do aplicativo armazenado no cluster por uma semana a partir de sua gravação, independentemente de se o cluster está em execução ou encerrado. Além disso, as interfaces do usuário de aplicativos persistentes armazenam o histórico de aplicativos fora do cluster por 30 dias após o encerramento de um cluster. Consulte [Visualizar o histórico da aplicação](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html). Para obter mais informações sobre estados de cluster, como Waiting e Running, consulte [Noções básicas sobre o ciclo de vida do cluster](emr-overview.md#emr-overview-cluster-lifecycle). ## Visualize os detalhes do cluster usando o Console de gerenciamento da AWS A lista **Clusters** no [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) lista todos os clusters em sua conta e AWS região, incluindo clusters encerrados. A lista mostra o seguinte para cada cluster: o **Nome** e o **ID**, o **Status** e os **Detalhes do status**, a **Hora da criação**, o **Tempo decorrido** em que o cluster esteve em execução e as **Horas da instância normalizadas** que foram acumuladas para todas as instâncias do EC2 no cluster. Essa lista é o ponto de partida para monitorar o status dos clusters. Ela foi criada para que você possa analisar detalhadamente cada cluster para análise e solução de problemas. ------ #### [ Console ] **Para exibir as informações do cluster usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e selecione o cluster que você deseja visualizar. 1. Use o painel **Resumo** para visualizar as informações básicas sobre a configuração do cluster, como o status do cluster, as aplicações de código aberto que o Amazon EMR instalou no cluster e a versão do Amazon EMR usada para criar o cluster. Use cada guia abaixo do Resumo para visualizar informações, conforme descrito na tabela a seguir. ------ ## Visualize os detalhes do cluster usando o AWS CLI Os exemplos a seguir demonstram como recuperar detalhes de cluster usando a AWS CLI. Para obter mais informações sobre os comandos disponíveis, consulte [AWS CLI Command Reference for Amazon EMR](https://docs.aws.amazon.com/cli/latest/reference/emr). Você pode usar o comando [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/emr/describe-cluster.html) para visualizar detalhes em nível de cluster, incluindo status, configuração de hardware e software, configurações da VPC, ações de bootstrap, grupos de instâncias, etc. Para obter mais informações sobre estados de cluster, consulte [Noções básicas sobre o ciclo de vida do cluster](emr-overview.md#emr-overview-cluster-lifecycle). O exemplo a seguir demonstra o uso do comando `describe-cluster`, seguido por exemplos do comando [list-clusters](https://docs.aws.amazon.com/cli/latest/reference/emr/describe-cluster.html). **Example Visualizar o status do cluster** Para usar o comando `describe-cluster`, você precisa do ID do cluster. Este exemplo demonstra como usar para obter uma lista de clusters criados em um determinado intervalo de datas e, em seguida, usar um dos clusters IDs retornados para listar mais informações sobre o status de um cluster individual. O comando a seguir descreve o cluster*j-1K48XXXXXXHCB*, que você substitui pelo ID do cluster. ``` aws emr describe-cluster --cluster-id j-1K48XXXXXXHCB ``` A saída do comando é semelhante à seguinte. ``` { "Cluster": { "Status": { "Timeline": { "ReadyDateTime": 1438281058.061, "CreationDateTime": 1438280702.498 }, "State": "WAITING", "StateChangeReason": { "Message": "Waiting for steps to run" } }, "Ec2InstanceAttributes": { "EmrManagedMasterSecurityGroup": "sg-cXXXXX0", "IamInstanceProfile": "EMR_EC2_DefaultRole", "Ec2KeyName": "myKey", "Ec2AvailabilityZone": "us-east-1c", "EmrManagedSlaveSecurityGroup": "sg-example" }, "Name": "Development Cluster", "ServiceRole": "EMR_DefaultRole", "Tags": [], "TerminationProtected": false, "ReleaseLabel": "emr-4.0.0", "NormalizedInstanceHours": 16, "InstanceGroups": [ { "RequestedInstanceCount": 1, "Status": { "Timeline": { "ReadyDateTime": 1438281058.101, "CreationDateTime": 1438280702.499 }, "State": "RUNNING", "StateChangeReason": { "Message": "" } }, "Name": "CORE", "InstanceGroupType": "CORE", "Id": "ig-2EEXAMPLEXXP", "Configurations": [], "InstanceType": "m5.xlarge", "Market": "ON_DEMAND", "RunningInstanceCount": 1 }, { "RequestedInstanceCount": 1, "Status": { "Timeline": { "ReadyDateTime": 1438281023.879, "CreationDateTime": 1438280702.499 }, "State": "RUNNING", "StateChangeReason": { "Message": "" } }, "Name": "MASTER", "InstanceGroupType": "MASTER", "Id": "ig-2A1234567XP", "Configurations": [], "InstanceType": "m5.xlarge", "Market": "ON_DEMAND", "RunningInstanceCount": 1 } ], "Applications": [ { "Version": "1.0.0", "Name": "Hive" }, { "Version": "2.6.0", "Name": "Hadoop" }, { "Version": "0.14.0", "Name": "Pig" }, { "Version": "1.4.1", "Name": "Spark" } ], "BootstrapActions": [], "MasterPublicDnsName": "ec2-X-X-X-X.compute-1.amazonaws.com", "AutoTerminate": false, "Id": "j-jobFlowID", "Configurations": [ { "Properties": { "hadoop.security.groups.cache.secs": "250" }, "Classification": "core-site" }, { "Properties": { "mapreduce.tasktracker.reduce.tasks.maximum": "5", "mapred.tasktracker.map.tasks.maximum": "2", "mapreduce.map.sort.spill.percent": "90" }, "Classification": "mapred-site" }, { "Properties": { "hive.join.emit.interval": "1000", "hive.merge.mapfiles": "true" }, "Classification": "hive-site" } ] } } ``` **Example Listar clusters por data de criação** Para recuperar clusters criados em um intervalo de dados específicos, use o comando `list-clusters` com os parâmetros `--created-after` e `--created-before`. O comando a seguir lista todos os clusters criados entre 9 e 12 de outubro de 2019. ``` aws emr list-clusters --created-after 2019-10-09T00:12:00 --created-before 2019-10-12T00:12:00 ``` **Example Listar clusters por estado** Para listar clusters por estado, use o comando `list-clusters` com o parâmetro `--cluster-states`. Os estados de cluster válidos incluem: STARTING, BOOTSTRAPPING, RUNNING, WAITING, TERMINATING, TERMINATED e TERMINATED\$1WITH\$1ERRORS. ``` aws emr list-clusters --cluster-states TERMINATED ``` Você também pode usar os seguintes parâmetros de atalho para listar todos os clusters nos estados especificados: + `--active` – filtra clusters nos estados STARTING, BOOTSTRAPPING, RUNNING, WAITING ou TERMINATING. + `--terminated` filtra clusters no estado TERMINATED. + O parâmetro `--failed` filtra clusters no estado TERMINATED\$1WITH\$1ERRORS. As seguintes comandos retornam o mesmo resultado. ``` aws emr list-clusters --cluster-states TERMINATED ``` ``` aws emr list-clusters --terminated ``` Para obter mais informações sobre estados de cluster, consulte [Noções básicas sobre o ciclo de vida do cluster](emr-overview.md#emr-overview-cluster-lifecycle). # Etapa aprimorada de depuração com o Amazon EMR Se houver falha em uma etapa do Amazon EMR e você enviou seu trabalho usando a operação de etapa de API com uma AMI de versão 5.x ou posterior, o Amazon EMR poderá identificar e retornar a causa raiz da falha na etapa em alguns casos, juntamente com o nome do arquivo de log relevante e uma parte do rastreamento da pilha de aplicações pela API. Por exemplo, as seguintes falhas podem ser identificadas: + Um erro do Hadoop comum, como o diretório de saída já existe, o diretório de entrada não existe ou um aplicativo ficou sem memória. + Erros de Java, como um aplicativo que foi compilado com uma versão incompatível do Java ou executado com uma classe principal não encontrada. + Um problema ao acessar objetos armazenados no Amazon S3. Essas informações estão disponíveis usando as operações [DescribeStep](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_DescribeStep.html)e [ListSteps](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_ListSteps.html)da API. O [FailureDetails](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_FailureDetails.html)campo do [StepSummary](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_StepSummary.html)retornado por essas operações. Para acessar as FailureDetails informações, use a AWS CLI, o console ou AWS o SDK. ------ #### [ Console ] O novo console do Amazon EMR não oferece depuração por etapas. No entanto, é possível visualizar os detalhes do encerramento do cluster realizando as etapas a seguir. **Para exibir os detalhes da falha usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e, em seguida, selecione o cluster que você deseja visualizar. 1. Observe o valor do **Status** na seção **Resumo** da página de detalhes do cluster. Se o status for **Terminado com erros**, passe o mouse sobre o texto para visualizar os detalhes da falha do cluster. ------ #### [ CLI ] **Para ver os detalhes da falha com o AWS CLI** + Para obter detalhes da falha de uma etapa com o AWS CLI, use o `describe-step` comando. ``` aws emr describe-step --cluster-id j-1K48XXXXXHCB --step-id s-3QM0XXXXXM1W ``` A saída será semelhante à seguinte: ``` { "Step": { "Status": { "FailureDetails": { "LogFile": "s3://amzn-s3-demo-bucket/logs/j-1K48XXXXXHCB/steps/s-3QM0XXXXXM1W/stderr.gz", "Message": "org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory s3://amzn-s3-demo-bucket/logs/beta already exists", "Reason": "Output directory already exists." }, "Timeline": { "EndDateTime": 1469034209.143, "CreationDateTime": 1469033847.105, "StartDateTime": 1469034202.881 }, "State": "FAILED", "StateChangeReason": {} }, "Config": { "Args": [ "wordcount", "s3://amzn-s3-demo-bucket/input/input.txt", "s3://amzn-s3-demo-bucket/logs/beta" ], "Jar": "s3://amzn-s3-demo-bucket/jars/hadoop-mapreduce-examples-2.7.2-amzn-1.jar", "Properties": {} }, "Id": "s-3QM0XXXXXM1W", "ActionOnFailure": "CONTINUE", "Name": "ExampleJob" } } ``` ------ # Como exibir o histórico da aplicação do Amazon EMR É possível visualizar os detalhes da aplicação de serviço do Spark History Server e do cronograma do YARN na página de detalhes do cluster no console. O uso do histórico de aplicação do Amazon EMR facilita a solução de problemas e a análise de trabalhos ativos e do histórico de trabalhos. **nota** Para aumentar a segurança das aplicações fora do console que podem ser usadas com o Amazon EMR, os domínios de hospedagem das aplicações são registrados na Public Suffix List (PSL). Exemplos desses domínios de hospedagem incluem os seguintes: `emrstudio-prod.us-east-1.amazonaws.com`, `emrnotebooks-prod.us-east-1.amazonaws.com`, `emrappui-prod.us-east-1.amazonaws.com`. Para maior segurança, se precisar definir cookies confidenciais no nome de domínio padrão, recomendamos que você use cookies com um prefixo `__Host-`. Isso ajuda a defender seu domínio contra tentativas de falsificação de solicitação entre sites (CSRF). Para obter mais informações, consulte a página [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) em *Mozilla Developer Network*. A seção **Interfaces de usuário da aplicação** da guia **Aplicações** fornece várias opções de visualização, conforme o status do cluster e das aplicações instaladas no cluster. + [Acesso fora do cluster a interfaces de usuário de aplicações persistentes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html): a partir do Amazon EMR versão 5.25.0, os links de interface de usuário de aplicações persistentes estão disponíveis para a interface de usuário do Spark e o Spark History Service. Com o Amazon EMR 5.30.1 e versões posteriores, a IU do Tez e o servidor de linha do tempo do YARN também possuem interfaces do usuário de aplicações persistentes. O servidor de linha do tempo do YARN e a interface do usuário do Tez são aplicativos de código aberto que fornecem métricas para clusters ativos e encerrados. A interface do usuário do Spark fornece detalhes sobre as tarefas e os estágios do programador, tamanhos de RDD e uso de memória, informações sobre o ambiente e informações sobre os executores em execução. UIs Os aplicativos persistentes são executados fora do cluster, portanto, as informações e os registros do cluster ficam disponíveis por 30 dias após o término do aplicativo. Diferentemente das interfaces de usuário de aplicativos em cluster, os aplicativos persistentes UIs não exigem que você configure um proxy web por meio de uma conexão SSH. + [Interfaces de usuário de aplicações no cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-web-interfaces.html): há uma variedade de interfaces de usuário de histórico de aplicações que podem ser executadas em um cluster. As interfaces do usuário no cluster são hospedadas no nó principal e exigem que você configure uma conexão SSH com o servidor Web. As interfaces do usuário de aplicativos no cluster mantêm o histórico de aplicativos por uma semana após o encerramento do aplicativo. Para obter mais informações e instruções sobre como configurar um túnel SSH, consulte [Visualizar interfaces Web hospedadas em clusters do Amazon EMR](emr-web-interfaces.md). Com exceção do servidor de histórico do Spark, do servidor de linha de tempo do YARN e das aplicações Hive, o histórico de aplicações no cluster só pode ser visualizado enquanto o cluster estiver em execução. # Exibir interfaces do usuário de aplicações persistentes no Amazon EMR O Amazon EMR versão 5.25.0, você pode se conectar aos detalhes da aplicação servidor de histórico do Spark persistente hospedado fora do cluster usando a página **Resumo** do cluster ou a guia **Interfaces de usuário da aplicação** no console. A IU do Tez e as interfaces de aplicações persistentes do servidor de linha de tempo do YARN estão disponíveis a partir do Amazon EMR versão 5.30.1. O acesso com um clique, por meio de um link, ao histórico de aplicativos persistente fornece os seguintes benefícios: + Você pode analisar e solucionar problemas de trabalhos ativos e histórico de trabalhos sem configurar um proxy da Web por meio de uma conexão SSH. + Você pode acessar o histórico de aplicativos e os arquivos de log relevantes para clusters ativos e encerrados. Os logs ficam disponíveis por 30 dias após o aplicativo ser encerrado. Navegue até os detalhes do seu cluster no console e selecione a guia **Aplicações**. Selecione a interface do usuário da aplicação que você deseja após a inicialização do cluster. A interface do usuário da aplicação abre em uma nova guia do navegador. Para obter mais informações, consulte [Monitoring and instrumentation](https://spark.apache.org/docs/latest/monitoring.html). Você pode exibir logs de contêiner do YARN por meio dos links no servidor de histórico do Spark, no servidor de linha de tempo do YARN e na interface do usuário do Tez. **nota** Para acessar os logs de contêiner do YARN pelo servidor de histórico do Spark, servidor de linha de tempo do YARN e interface do usuário do Tez, é necessário habilitar o registro em log no Amazon S3 para o cluster. Se você não habilitar o registro em log, os links para os logs de contêiner do YARN não funcionarão. ## Coleta de logs Para habilitar o acesso com um clique às interfaces do usuário de aplicações persistentes, o Amazon EMR coleta dois tipos de logs: + Os **logs de eventos do aplicativo** são coletados em um bucket do sistema EMR. Os logs de eventos são criptografados em repouso usando a criptografia no lado do servidor com as chaves gerenciadas pelo Amazon S3 (SSE-S3). Se você usa uma sub-rede privada para seu cluster, certifique-se de incluir o bucket correto do sistema ARNs na lista de recursos da política do Amazon S3 para a sub-rede privada. Para obter mais informações, consulte [Minimum Amazon S3 policy for private subnet](https://docs.aws.amazon.com/emr/latest/ManagementGuide/private-subnet-iampolicy.html). + Os **logs de contêiner do YARN** são coletados em um bucket do Amazon S3 de sua propriedade. Você deve habilitar o registro em log para que seu cluster acesse logs de contêiner do YARN. Para obter mais informações, consulte [Configurar registro em log e depuração do cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-debugging.html). Se você precisar desabilitar esse recurso por motivos de privacidade, será possível interromper o daemon usando um script de bootstrap ao criar um cluster, como demonstra o exemplo a seguir. ``` aws emr create-cluster --name "Stop Application UI Support" --release-label emr-7.12.0 \ --applications Name=Hadoop Name=Spark --ec2-attributes KeyName= \ --instance-groups InstanceGroupType=MASTER,InstanceCount=1,InstanceType=m3.xlarge InstanceGroupType=CORE,InstanceCount=1,InstanceType=m3.xlarge InstanceGroupType=TASK,InstanceCount=1,InstanceType=m3.xlarge \ --use-default-roles --bootstrap-actions Path=s3://region.elasticmapreduce/bootstrap-actions/run-if,Args=["instance.isMaster=true","echo Stop Application UI | sudo tee /etc/apppusher/run-apppusher; sudo systemctl stop apppusher || exit 0"] ``` Após executar esse script de bootstrap, o Amazon EMR não coletará nenhum log de eventos do servidor de histórico do Spark ou servidor de linha de tempo do YARN no bucket do sistema EMR. Nenhuma informação do histórico do aplicativo estará disponível na guia **Interfaces do usuário do aplicativo** e você perderá acesso a todas as interfaces do usuário do aplicativo do console. ## Arquivos grandes de log de eventos do Spark Em alguns casos, trabalhos de execução prolongada do Spark, como transmissão do Spark, e trabalhos grandes, como consultas SQL do Spark, podem gerar grandes logs de eventos. Com grandes registros de eventos, você pode rapidamente usar espaço em disco nas instâncias de computação e encontrar `OutOfMemory` erros ao carregar o Persistent UIs. Para evitar esses problemas, recomenda-se ativar o atributo de rolagem e compactação do log de eventos do Spark. Esse atributo está disponível no Amazon EMR versões emr-6.1.0 e posteriores. Para obter mais detalhes sobre rolagem e compactação, consulte [Applying compaction on rolling event log files](https://spark.apache.org/docs/latest/monitoring.html#applying-compaction-on-rolling-event-log-files) na documentação do Spark. Para ativar o atributo de rolagem e compactação do log de eventos do Spark, ative as configurações do Spark a seguir. + `spark.eventLog.rolling.enabled`: ativa a rolagem do log de eventos com base no tamanho. Essa configuração é desativada por padrão. + `spark.eventLog.rolling.maxFileSize`: quando a rolagem é ativada, especifica o tamanho máximo do arquivo de log de eventos antes da rolagem. O padrão é 128 MB. + `spark.history.fs.eventLog.rolling.maxFilesToRetain`: especifica o número máximo de arquivos de log de eventos não compactados a serem retidos. Por padrão, todos os arquivos de log de eventos são mantidos. Defina com um número menor para compactar logs de eventos mais antigos. O valor mais baixo é 1. A compactação tenta excluir eventos com arquivos de log de eventos desatualizados, como os apresentados a seguir. Se ele descartar eventos, eles não serão mais exibidos na interface do Spark History Server. + Eventos para trabalhos concluídos e eventos relacionados de preparação ou de tarefa. + Eventos para executores terminados. + Eventos para consultas SQL concluídas e eventos relacionados de trabalho, preparação e tarefas. **Para iniciar um cluster com rolagem e compactação habilitadas** 1. Crie um arquivo `spark-configuration.json` com a configuração a seguir. ``` [ { "Classification": "spark-defaults", "Properties": { "spark.eventLog.rolling.enabled": true, "spark.history.fs.eventLog.rolling.maxFilesToRetain": 1 } } ] ``` 1. Crie o cluster com a configuração de compactação contínua do Spark da forma exibida a seguir. ``` aws emr create-cluster \ --release-label emr-6.6.0 \ --instance-type m4.large \ --instance-count 2 \ --use-default-roles \ --configurations file://spark-configuration.json ``` ## Permissões para visualizar interfaces do usuário de aplicações persistentes O exemplo a seguir mostra as permissões de perfil necessárias para acessar interfaces de usuário de aplicações persistentes. Para clusters com perfil de runtime habilitado, isso permitirá que os usuários acessem apenas aplicações enviadas pela mesma identidade de usuário e perfil de runtime. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "elasticmapreduce:CreatePersistentAppUI", "elasticmapreduce:DescribePersistentAppUI" ], "Resource": [ "arn:aws:elasticmapreduce:*:123456789012:cluster/clusterId" ], "Sid": "AllowELASTICMAPREDUCECreatepersistentappui" }, { "Effect": "Allow", "Action": [ "elasticmapreduce:GetPersistentAppUIPresignedURL" ], "Resource": [ "arn:aws:elasticmapreduce:*:123456789012:cluster/clusterId", "arn:aws:elasticmapreduce:*:123456789012:persistent-app-ui/*" ], "Condition": { "StringEqualsIfExists": { "elasticmapreduce:ExecutionRoleArn": [ "arn:aws:iam::123456789012:role/executionRoleArn" ] } }, "Sid": "AllowELASTICMAPREDUCEGetpersistentappuipresignedurl" } ] } ``` ------ A amostra a seguir mostra as permissões de perfil necessárias para remover as restrições de visualização de aplicativos nas interfaces de usuário de aplicativos persistentes para clusters habilitados para perfil de runtime. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "elasticmapreduce:CreatePersistentAppUI", "elasticmapreduce:DescribePersistentAppUI", "elasticmapreduce:AccessAllEventLogs" ], "Resource": [ "arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-XXXXXXXXXXXXX" ], "Sid": "AllowELASTICMAPREDUCECreatepersistentappui" }, { "Effect": "Allow", "Action": [ "elasticmapreduce:GetPersistentAppUIPresignedURL" ], "Resource": [ "arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-XXXXXXXXXXXXX", "arn:aws:elasticmapreduce:us-east-1:123456789012:persistent-app-ui/*" ], "Condition": { "StringEqualsIfExists": { "elasticmapreduce:ExecutionRoleArn": [ "arn:aws:iam::123456789012:role/YourExecutionRoleName" ] } }, "Sid": "AllowELASTICMAPREDUCEGetpersistentappuipresignedurl" } ] } ``` ------ ## Considerações e limitações No momento, o acesso com um clique às interfaces do usuário de aplicações persistentes tem as limitações a seguir. + Haverá um atraso de pelo menos dois minutos quando os detalhes da aplicação forem exibidos na interface do Spark History Server. + Esse recurso só funciona quando o diretório de log de eventos do aplicativo está no HDFS. Por padrão, o Amazon EMR armazena logs de eventos em um diretório do HDFS. Se você alterar o diretório padrão para um sistema de arquivos diferente, como, por exemplo o Amazon S3, esse atributo não funcionará. + Esse recurso não está disponível no momento para clusters do EMR com vários nós principais ou para clusters do EMR integrados ao AWS Lake Formation. + Para habilitar o acesso com um clique às interfaces do usuário de aplicações persistentes, é preciso ter permissão para as ações `CreatePersistentAppUI`, `DescribePersistentAppUI` e `GetPersistentAppUIPresignedURL` do Amazon EMR. Se você negar permissão para uma entidade principal do IAM a essas ações, levará aproximadamente cinco minutos para que a alteração na permissão seja propagada. + Se um cluster for um cluster habilitado para perfil de runtime, ao acessar o Spark History Server a partir da interface do usuário da aplicação persistente, o usuário só poderá acessar um trabalho do Spark se ele tiver sido enviado por um perfil de runtime. + Se um cluster for um cluster habilitado para perfil de runtime, cada usuário poderá acessar apenas uma aplicação enviada pela mesma identidade de usuário e perfil de runtime. + A ação `AccessAllEventLogs` para o Amazon EMR é necessária para visualizar todas as aplicações em interfaces de usuário de aplicações persistentes para clusters habilitados para perfil de runtime. + Se você reconfigurar os aplicativos em um cluster em execução, o histórico do aplicativo não estará disponível na interface do usuário do aplicativo. + Para cada um Conta da AWS, o limite padrão para o aplicativo ativo UIs é 200. + A seguir Regiões da AWS, você pode acessar o aplicativo a UIs partir do console com o Amazon EMR 6.14.0 e superior: + Ásia-Pacífico (Jacarta) (ap-southeast-3) + Europa (Espanha) (eu-south-2) + Ásia-Pacífico (Melbourne) (ap-southeast-4) + Israel (Tel Aviv) (il-central-1) + Oriente Médio (EAU) (me-central-1) + A seguir Regiões da AWS, você pode acessar o aplicativo a UIs partir do console com o Amazon EMR 5.25.0 e superior: + Leste dos EUA (Norte da Virgínia) (us-east-1) + Oeste dos EUA (Oregon) (us-west-2) + Ásia-Pacífico (Mumbai) (ap-south-1) + Ásia-Pacífico (Seul) (ap-northeast-2) + Ásia-Pacífico (Singapura) (ap-southeast-1) + Ásia-Pacífico (Sydney) (ap-southeast-2) + Ásia Pacific (Tóquio) (ap-northeast-1) + Canadá (Central) (ca-central-1) + América do Sul (São Paulo) (sa-east-1) + Europa (Frankfurt) (eu-central-1) + Europa (Irlanda) (eu-west-1) + Europa (Londres) (eu-west-2) + Europa (Paris) (eu-west-3) + UE (Estocolmo) (eu-north-1) + China (Pequim) (cn-north-1) + China (Ningxia) (cn-northwest-1) # Exibição de um histórico de aplicações de alto nível no Amazon EMR **nota** Recomenda-se usar a interface da aplicação persistente para melhorar a experiência do usuário e reter o histórico da aplicação por até 30 dias. O histórico de aplicativos de alto nível descrito nesta página não está disponível no novo console do Amazon EMR [https://console.aws.amazon.com(](https://console.aws.amazon.com/emr)/emr). Para obter mais informações, consulte [Exibir interfaces do usuário de aplicações persistentes no Amazon EMR](app-history-spark-UI.md). Com as versões do Amazon EMR 5.8.0 a 5.36.0 e 6.x a 6.8.0, é possível visualizar um histórico de aplicações de alto nível na guia **Interfaces de usuário da aplicação** do console antigo do Amazon EMR. A **Interface de usuário da aplicação** do Amazon EMR mantém o resumo do histórico da aplicação por sete dias após a aplicação ser concluída. ## Considerações e limitações Considere as limitações a seguir ao usar a guia **Interfaces de usuário da aplicação** no console antigo do Amazon EMR. + Só é possível acessar o atributo de histórico de aplicações de alto nível usando as versões 5.8.0 a 5.36.0 e 6.x a 6.8.0 do Amazon EMR. A partir de 23 de janeiro de 2023, o Amazon EMR descontinuará o histórico de aplicações de alto nível em todas as versões. Se você usa o Amazon EMR 5.25.0 ou versões posteriores, recomenda-se usar a interface de usuário da aplicação persistente. + O atributo de histórico de aplicações de alto nível não é compatível com aplicações Spark Streaming. + No momento, o acesso com um clique às interfaces de usuário de aplicações persistentes não está disponível para clusters do Amazon EMR com múltiplos nós principais ou para clusters do Amazon EMR integrados ao AWS Lake Formation. ## Exemplo: visualizar um histórico de aplicações de alto nível A sequência a seguir demonstra uma busca detalhada de uma aplicação YARN ou Spark nos detalhes do trabalho usando a guia **Interfaces do usuário da aplicação** na página de detalhes do cluster do console antigo. Para visualizar detalhes do cluster, selecione o **Nome** de um cluster na lista **Clusters**. Para visualizar informações sobre os logs de contêiner do YARN, é necessário habilitar o registro em log do cluster. Para obter mais informações, consulte [Configurar registro em log e depuração do cluster](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-debugging.html). Para o histórico da aplicação Spark, as informações fornecidas na tabela de resumo são apenas um subconjunto das informações disponíveis pela IU do servidor de histórico do Spark. Na guia **Interfaces de usuário da aplicação**, em **Histórico da aplicação de alto nível**, você pode expandir uma linha para exibir o resumo do diagnóstico de uma aplicação Spark ou selecionar um link de **ID da aplicação** para visualizar detalhes sobre outra aplicação. ![\[Application user interfaces tab showing persistent and on-cluster UIs, with YARN application history.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/app-history-app.png) Quando você seleciona um link de **ID da aplicação**, a interface do usuário passa a exibir os detalhes da **aplicação YARN** daquela aplicação. Na guia **Trabalhos** dos detalhes da **aplicação YARN**, é possível escolher o link **Descrição** de um trabalho para exibir os detalhes desse trabalho. ![\[YARN application details showing job history with completed Spark tasks and their statuses.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/app-history-job-1.png) Na página de detalhes do trabalho, você pode expandir as informações sobre a preparação do trabalho individual e selecionar o link **Descrição** para ver os detalhes da preparação. ![\[EMR cluster interface showing persistent and on-cluster application UIs, with job details and stages.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/app-history-job-2.png) Na página de detalhes da preparação, você pode visualizar as principais métricas para tarefas e executores do preparação. Também é possível visualizar os logs de tarefa e do executor usando os links **Visualizar logs**. ![\[Application history page showing task metrics, executor details, and log access links for a Spark job.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/app-history-job-3.png) # Exibição dos arquivos de log do Amazon EMR Tanto o Amazon EMR como o Hadoop produzem arquivos de log que informam o status no cluster. Por padrão, esses são gravados no nó primário, no diretório `/mnt/var/log/`. Dependendo de como você configurou seu cluster quando o executou, esses logs também podem ser arquivados no Amazon S3 e podem ser visualizados na ferramenta de depuração gráfica. Há muitos tipos de logs gravados no nó primário. O Amazon EMR grava logs de etapa, ação de bootstrap e estado de instâncias. O Apache Hadoop grava logs para informar o processamento de trabalhos, tarefas e tentativas de tarefas. O Hadoop também registra logs de seus daemons. [Para obter mais informações sobre os registros escritos pelo Hadoop, acesse http://hadoop.apache. org/docs/stable/hadoop-project-dist/hadoop-common/ClusterSetup.html](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/ClusterSetup.html). ## Visualizar arquivos de log no nó primário A tabela a seguir lista alguns dos arquivos de log que você encontrará no nó primário. | Local | Description | | --- | --- | | /emr/instance-controller/log/bootstrap-ações | Logs gravados durante o processamento das ações de bootstrap. | | /mnt/var/log/hadoop-state pusher | Logs gravados pelo processo de agente de envio de estado do Hadoop. | | /emr/instance-controller/log | Logs do controlador de instâncias. | | /emr/instance-state | Logs de estado de instância. Contém informações sobre a CPU, o estado da memória e os threads de coletor de lixo do nó. | | /emr/service-nanny | Logs gravados pelo processo nanny de serviço. | | /mnt/var/log/*application* | Logs específicos de um aplicativo, como o Hadoop, o Spark ou o Hive. | | /mnt/var/log/hadoop/steps/*N* | Logs de etapa que contêm informações sobre o processamento da etapa. O valor de *N* indica o StepID atribuído pelo Amazon EMR. Por exemplo, um cluster tem duas etapas: `s-1234ABCDEFGH` e `s-5678IJKLMNOP`. A primeiro etapa está localizado em `/mnt/var/log/hadoop/steps/s-1234ABCDEFGH/` e segundo etapa, em `/mnt/var/log/hadoop/steps/s-5678IJKLMNOP/`. Os logs de etapas escritos pelo Amazon EMR estão apresentados a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-manage-view-web-log-files.html) | **Para visualizar arquivos de log no nó primário usando a AWS CLI.** 1. Use o SSH para conectar-se ao nó primário, conforme descrito em [Como se conectar ao nó primário do cluster do Amazon EMR usando SSH](emr-connect-master-node-ssh.md). 1. Navegue até o diretório que contém as informações do arquivo de log que você deseja visualizar. A tabela anterior fornece uma lista dos tipos de arquivos de log que estão disponíveis e onde você os encontrará. O exemplo a seguir mostra o comando para navegar até o log de etapas com um ID `s-1234ABCDEFGH`. ``` cd /mnt/var/log/hadoop/steps/s-1234ABCDEFGH/ ``` 1. Use um visualizador de arquivos de sua preferência para visualizar o arquivo de log. O exemplo a seguir usa o comando `less` do Linux para visualizar o arquivo de log `controller`. ``` less controller ``` ## Visualizar arquivos de log arquivados no Amazon S3 Por padrão, os clusters do Amazon EMR iniciados com o uso do console arquivam automaticamente os arquivos de log no Amazon S3. Você pode especificar seu próprio caminho de log ou pode permitir que o console gere automaticamente um caminho de log para você. Para clusters iniciados com o uso da CLI ou da API, você deve configurar o arquivamento de log do Amazon S3 manualmente. Quando o Amazon EMR é configurado para arquivar arquivos de log no Amazon S3, ele armazena os arquivos no local do S3 que você especificou, na pasta*cluster-id*//, *cluster-id* onde está o ID do cluster. A tabela a seguir lista alguns dos arquivos de log que você encontrará no Amazon S3. | Local | Description | | --- | --- | | /*cluster-id*/nó/ | Logs de nós, incluindo logs de ações de bootstrap, estado da instância e aplicativo para o nó. Os logs para cada nó são armazenados em uma pasta rotulada com o identificador da instância do EC2 desse nó. | | /*cluster-id*/nó/*instance-id*/*application* | Os logs criados por cada aplicativo ou daemon associado a um aplicativo. Por exemplo, o log do servidor Hive está localizado em `cluster-id/node/instance-id/hive/hive-server.log`. | | /*cluster-id**step-id*/etapas// | Logs de etapa que contêm informações sobre o processamento da etapa. O valor de *step-id* indica o ID da etapa atribuído pelo Amazon EMR. Por exemplo, um cluster tem duas etapas: `s-1234ABCDEFGH` e `s-5678IJKLMNOP`. A primeiro etapa está localizado em `/mnt/var/log/hadoop/steps/s-1234ABCDEFGH/` e segundo etapa, em `/mnt/var/log/hadoop/steps/s-5678IJKLMNOP/`. Os logs de etapas escritos pelo Amazon EMR estão apresentados a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-manage-view-web-log-files.html) | | /*cluster-id*/contêineres | Logs de contêiner de aplicativo. Os logs para cada aplicativo YARN são armazenados nesses locais. | | /*cluster-id*/hadoop-mapreduce/ | Os registros que contêm informações sobre detalhes de configuração e histórico de MapReduce trabalhos. | **Visualizar os arquivos de log arquivados no Amazon S3 usando o console do Amazon S3** 1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon S3 em. [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) 1. Abra o bucket do S3 especificado quando você configurou o cluster para arquivar arquivos de log no Amazon S3. 1. Navegue até o arquivo de log que contém as informações a serem exibidas. A tabela anterior fornece uma lista dos tipos de arquivos de log que estão disponíveis e onde você os encontrará. 1. Baixe o objeto do arquivo de log para visualizá-lo. Para obter instruções, consulte [Fazer download de um objeto](https://docs.aws.amazon.com/AmazonS3/latest/userguide/download-objects.html). # Visualizar instâncias de cluster no Amazon EC2 Para ajudá-lo a gerenciar seus recursos, o Amazon EC2 permite atribuir metadados a recursos no formato de tags. Cada tag do Amazon EC2 consiste em uma chave e um valor. Tags permitem categorizar seus recursos do Amazon EC2 de diferentes maneiras: por exemplo, por finalidade, proprietário ou ambiente. Você pode pesquisar e filtrar recursos com base nessas tags. As tags que você atribui aos recursos por meio de sua AWS conta estão disponíveis somente para você. Outras contas que compartilham o recurso não podem visualizar suas etiquetas. O Amazon EMR marca automaticamente cada instância do EC2 que ele executa com pares de chave-valor. As chaves identificam o cluster e o grupo de instâncias ao qual a instância pertence. Isso facilita a filtragem de instâncias do EC2 para exibir, por exemplo, somente aquelas que pertencem a um determinado cluster ou para exibir todas as instâncias atualmente em execução no grupo de instâncias para a tarefa. Isso é especialmente útil quando você executa vários clusters simultaneamente ou gerencia um grande número de instâncias do EC2. Estes são os pares de chave-valor predefinidos que o Amazon EMR atribui: | Chave | Valor | Definição de valor | | --- | --- | --- | | aws:elasticmapreduce:job-flow-id | `job-flow-identifier` | O ID do cluster para o qual a instância está provisionada. Ele é exibido no formato `j-XXXXXXXXXXXXX` e pode conter até 256 caracteres. | | aws:elasticmapreduce:instance-group-role | `group-role` | O tipo de grupo de instâncias, inserido como um destes valores: `master`, `core` ou `task`. | Você pode visualizar e filtrar com base nas etiquetas adicionadas pelo Amazon EMR. Para obter mais informações, consulte [Using tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html) no *Guia do usuário do Amazon EC2*. Como as etiquetas definidas pelo Amazon EMR são etiquetas do sistema e não podem ser editadas ou excluídas, as seções sobre como exibir e filtrar etiquetas são as mais relevantes. **nota** O Amazon EMR adiciona etiquetas à instância do EC2 quando seu status é atualizado para **Running**. Se a latência ocorrer entre o momento em que a instância do EC2 for provisionada e o momento em que seu status for definido como **Running**, as etiquetas definidas pelo Amazon EMR serão exibidas quando a instância for iniciada. Se você não vir as tags, aguarde alguns minutos e atualize a exibição. # CloudWatch eventos e métricas do Amazon EMR Use eventos e métricas para rastrear a atividade e a integridade de um cluster do Amazon EMR. Eventos são úteis para monitorar uma ocorrência específica em um cluster. Por exemplo, quando um cluster muda do estado iniciando para em execução. Métricas são úteis para monitorar um valor específico, como, por exemplo, a porcentagem de espaço em disco disponível que o HDFS está usando em um cluster. Para obter mais informações sobre CloudWatch eventos, consulte o [Guia do usuário do Amazon CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/). Para obter mais informações sobre CloudWatch métricas, consulte [Uso de CloudWatch métricas da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) e [Criação de CloudWatch alarmes da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) no *Guia do CloudWatch usuário da Amazon*. **Topics** + [ # Monitorando métricas do Amazon EMR com CloudWatch ](UsingEMR_ViewingMetrics.md) + [ # Monitorando eventos do Amazon EMR com CloudWatch ](emr-manage-cloudwatch-events.md) + [ # Respondendo a CloudWatch eventos do Amazon EMR ](emr-events-response.md) # Monitorando métricas do Amazon EMR com CloudWatch As métricas são atualizadas a cada cinco minutos e coletadas e enviadas automaticamente CloudWatch para cada cluster do Amazon EMR. Esse intervalo não é configurável. Não há cobrança pelas métricas do Amazon EMR relatadas em. CloudWatch Essas métricas de ponto de dados de cinco minutos são arquivadas por 63 dias, e os dados são descartados após esse período. ## Como usar métricas do Amazon EMR? A tabela a seguir mostra os usos comuns das métricas informadas pelo Amazon EMR. Essas são sugestões para você começar, e não uma lista abrangente. Para obter uma lista completa das métricas relatadas pelo Amazon EMR, consulte [Métricas relatadas pelo Amazon EMR em CloudWatch](#UsingEMR_ViewingMetrics_MetricsReported). **** | Como eu faço para... | Métricas relevantes | | --- | --- | | Controlar o progresso do meu cluster | Examine as métricas RunningMapTasks, RemainingMapTasks, RunningReduceTasks e RemainingReduceTasks. | | Detectar clusters ociosos | A métrica IsIdle controla se um cluster está ativo, mas não executando tarefas no momento. Você pode definir um alarme a ser disparado quando o cluster permanecer ocioso por um determinado tempo, como trinta minutos. | | Detectar quando um nó fica sem armazenamento | A métrica MRUnhealthyNodes rastreia quando um ou mais nós centrais ou de tarefa ficam sem armazenamento em disco local e fazem a transição para o estado UNHEALTHY do YARN. Por exemplo, os nós centrais ou de tarefa estão com pouco espaço em disco e não poderão executar tarefas. | | Detectar quando um cluster fica sem armazenamento | A métrica HDFSUtilization monitora a capacidade HDFS combinada do cluster e pode exigir o redimensionamento do cluster para adicionar mais nós centrais. Por exemplo, a utilização do HDFS é alta, o que pode afetar os trabalhos e a integridade do cluster. | | Detectar quando um cluster está em execução com capacidade reduzida | A métrica MRLostNodes rastreia quando um ou mais nós centrais ou de tarefa não conseguem se comunicar com o nó principal. Por exemplo, o nó principal não consegue acessar o nó central ou de tarefa. | Para obter mais informações, consulte [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) e [AWSSupport-AnalyzeEMRLogs](https://docs.aws.amazon.com//systems-manager-automation-runbooks/latest/userguide/automation-awssupport-analyzeemrlogs.html). ## CloudWatch Métricas de acesso para o Amazon EMR Você pode visualizar as métricas às quais o Amazon EMR reporta CloudWatch usando o console do Amazon EMR ou o console. CloudWatch Você também pode recuperar métricas usando o `[mon-get-stats](https://docs.aws.amazon.com/AmazonCloudWatch/latest/cli/cli-mon-get-stats.html)` comando CloudWatch CLI ou CloudWatch `[GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)` a API. Para obter mais informações sobre a visualização ou recuperação de métricas para CloudWatch uso do Amazon EMR, consulte o Guia do usuário da [ CloudWatch Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/). ------ #### [ Console ] **Para exibir as métricas usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e, em seguida, escolha o cluster cujas métricas você deseja visualizar. Isso abrirá a página de detalhes do cluster. 1. Selecione a guia **Monitoramento** da página de detalhes do cluster. Escolha qualquer uma das opções **Status do cluster**, **Status do nó** ou **Entradas e saídas** para carregar os relatórios sobre o progresso e a integridade do cluster. 1. Após escolher uma métrica para visualizar, você poderá aumentar cada grafo. Para filtrar o período de tempo do grafo, selecione uma opção pré-preenchida ou escolha **Personalizado**. ------ ## Métricas relatadas pelo Amazon EMR em CloudWatch As tabelas a seguir listam as métricas que o Amazon EMR reporta no console e para as quais envia. CloudWatch ### Métricas do Amazon EMR O Amazon EMR envia dados de várias métricas para. CloudWatch Todos os clusters do Amazon EMR enviam métricas automaticamente em intervalos de cinco minutos. As métricas são arquivadas por duas semanas. Depois desse período, os dados serão descartados. O namespace `AWS/ElasticMapReduce` inclui as métricas a seguir. **nota** O Amazon EMR extrai métricas de um cluster. Se um cluster torna-se inacessível, nenhuma métrica é relatada até que o cluster fique disponível novamente. As métricas a seguir estão disponíveis para clusters que executam o Hadoop versões 2.x. | Métrica | Description | | --- | --- | | Status do cluster | | IsIdle | Indica que um cluster não está mais executando nenhum trabalho, mas ainda está ativo e acumulando cobranças. É definido como 1 se nenhuma tarefa ou nenhum trabalho estiver em execução, caso contrário, é definido como 0. Esse valor é verificado em intervalos de 5 minutos, sendo que um valor de 1 indica somente que o cluster estava ocioso no momento da verificação, e não que ele ficou ocioso durante todo o período de 5 minutos. Para evitar falsos positivos, você deve gerar um alerta quando esse valor for 1 em mais de uma verificação consecutiva de 5 minutos. Por exemplo, você pode gerar um alerta para esse valor se ele for 1 por 30 minutos ou mais. Caso de uso: monitorar a performance do cluster Unidade: *booliano* | | ContainerAllocated | O número de contêineres de recursos alocados peloResourceManager. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ContainerReserved | O número de contêineres reservados. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ContainerPending | O número de contêineres na fila que ainda não foram alocados. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ContainerPendingRatio | A proporção de contêineres pendentes em relação aos contêineres alocados (ContainerPendingRatio = ContainerPending / ContainerAllocated). Se ContainerAllocated = 0, então ContainerPendingRatio =ContainerPending. O valor de ContainerPendingRatio representa um número, não uma porcentagem. Esse valor é útil para escalonar recursos de cluster com base no comportamento de alocação do contêiner. Unidades: *Contagem* | | AppsCompleted | O número de aplicativos enviados para o YARN que foram concluídos. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | AppsFailed | O número de aplicativos enviados para o YARN que apresentaram falha ao concluir. Caso de uso: monitorar o progresso do cluster, monitorar a integridade do cluster Unidades: *Contagem* | | AppsKilled | O número de aplicativos enviados para o YARN que foram interrompidos. Caso de uso: monitorar o progresso do cluster, monitorar a integridade do cluster Unidades: *Contagem* | | AppsPending | O número de aplicativos enviados para o YARN em estado pendente. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | AppsRunning | O número de aplicativos enviados para o YARN que estão em execução. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | AppsSubmitted | O número de aplicativos enviados para o YARN. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | Status do nó | | CoreNodesRunning | O número de nós core em funcionamento. Os pontos de dados para essa métrica são relatados somente quando existe um grupo de instâncias correspondente. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | CoreNodesPending | O número de nós core aguardando atribuição. Todos os nós core solicitados podem não estar disponíveis imediatamente; essa métrica reporta as solicitações pendentes. Os pontos de dados para essa métrica são relatados somente quando existe um grupo de instâncias correspondente. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | LiveDataNodes | A porcentagem de nós de dados que estão recebendo trabalho do Hadoop. Caso de uso: monitorar a integridade do cluster Unidade: *percentual* | | MRTotalNodos | O número de nós atualmente disponíveis para MapReduce trabalhos. Equivalente ao `mapred.resourcemanager.TotalNodes` da métrica YARN. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* Nota: MRTotal Os nós contabilizam somente os nós atualmente ativos no sistema. O YARN remove automaticamente os nós encerrados dessa contagem e para de rastreá-los, portanto, eles não são considerados na métrica MRTotal Nodes. | | MRActiveNodos | O número de nós que estão executando MapReduce tarefas ou trabalhos no momento. Equivalente ao `mapred.resourcemanager.NoOfActiveNodes` da métrica YARN. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | MRLostNodos | O número de nós alocados MapReduce que foram marcados no estado LOST. Equivalente ao `mapred.resourcemanager.NoOfLostNodes` da métrica YARN. Caso de uso: monitorar a integridade do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | MRUnhealthyNodos | O número de nós disponíveis para MapReduce trabalhos marcados em um estado UNHEALTHY. Equivalente ao `mapred.resourcemanager.NoOfUnhealthyNodes` da métrica YARN. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | MRDecommissionedNodos | O número de nós alocados para MapReduce aplicativos que foram marcados no estado DESCOMISSIONADO. Equivalente ao `mapred.resourcemanager.NoOfDecommissionedNodes` da métrica YARN. Caso de uso: monitorar a integridade do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | MRRebootedNodos | O número de nós disponíveis MapReduce que foram reinicializados e marcados no estado REINICIALIZADO. Equivalente ao `mapred.resourcemanager.NoOfRebootedNodes` da métrica YARN. Caso de uso: monitorar a integridade do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | MultiMasterInstanceGroupNodesRunning | O número de nós principais em execução. Caso de uso: monitorar falhas do nó principal e substituição Unidades: *Contagem* | | MultiMasterInstanceGroupNodesRunningPercentage | A porcentagem de nós principais em execução sobre a contagem solicitada de instâncias de nós principais. Caso de uso: monitorar falhas do nó principal e substituição Unidade: *percentual* | | MultiMasterInstanceGroupNodesRequested | O número de nós principais solicitados. Caso de uso: monitorar falhas do nó principal e substituição Unidades: *Contagem* | | IO | | S3 BytesWritten | O número de bytes gravados no Amazon S3. Essa métrica agrega somente MapReduce trabalhos e não se aplica a outras cargas de trabalho no Amazon EMR. Caso de uso: analisar a performance do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | S3 BytesRead | O número de bytes lidos no Amazon S3. Essa métrica agrega somente MapReduce trabalhos e não se aplica a outras cargas de trabalho no Amazon EMR. Caso de uso: analisar a performance do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | HDFSUtilization | O percentual de armazenamento do HDFS em uso no momento. Caso de uso: analisar a performance do cluster Unidade: *percentual* | | HDFSBytesLeia | O número de bytes lidos do HDFS. Essa métrica agrega somente MapReduce trabalhos e não se aplica a outras cargas de trabalho no Amazon EMR. Caso de uso: analisar a performance do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | HDFSBytesEscrito | O número de bytes gravados no HDFS. Essa métrica agrega somente MapReduce trabalhos e não se aplica a outras cargas de trabalho no Amazon EMR. Caso de uso: analisar a performance do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | MissingBlocks | O número de blocos em que o HDFS não tem réplicas. Esses podem ser blocos danificados. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | CorruptBlocks | O número de blocos que o HDFS reporta como corrompidos. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | TotalLoad | O número total de transferências simultâneas de dados. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | MemoryTotalMB | A quantidade total de memória no cluster. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | MemoryReservedMB | A quantidade de memória reservada. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | MemoryAvailableMB | A quantidade de memória disponível para ser alocada. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | YARNMemoryAvailablePercentage | A porcentagem de memória restante disponível para o YARN (YARNMemoryAvailablePercentage = MemoryAvailable MB/MemoryTotalMB). Esse valor é útil para escalonar recursos de cluster com base no uso da memória YARN. Unidade: *percentual* | | MemoryAllocatedMB | A quantidade de memória alocada para o cluster. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | PendingDeletionBlocks | O número de blocos marcados para exclusão. Caso de uso: monitorar o progresso do cluster, monitorar a integridade do cluster Unidades: *Contagem* | | UnderReplicatedBlocks | O número de blocos que precisam ser replicados uma ou mais vezes. Caso de uso: monitorar o progresso do cluster, monitorar a integridade do cluster Unidades: *Contagem* | | DfsPendingReplicationBlocks | O status da replicação de bloco: blocos sendo replicados, idade das solicitações de replicação e solicitações de replicação sem sucesso. Caso de uso: monitorar o progresso do cluster, monitorar a integridade do cluster Unidades: *Contagem* | | CapacityRemainingGB | A quantidade de capacidade de disco do HDFS restante. Caso de uso: monitorar o progresso do cluster, monitorar a integridade do cluster Unidades: *Contagem* | Veja a seguir as métricas do Hadoop 1: | Métrica | Description | | --- | --- | | Status do cluster | | IsIdle | Indica que um cluster não está mais executando nenhum trabalho, mas ainda está ativo e acumulando cobranças. É definido como 1 se nenhuma tarefa ou nenhum trabalho estiver em execução, caso contrário, é definido como 0. Esse valor é verificado em intervalos de 5 minutos, sendo que um valor de 1 indica somente que o cluster estava ocioso no momento da verificação, e não que ele ficou ocioso durante todo o período de 5 minutos. Para evitar falsos positivos, você deve gerar um alerta quando esse valor for 1 em mais de uma verificação consecutiva de 5 minutos. Por exemplo, você pode gerar um alerta para esse valor se ele for 1 por 30 minutos ou mais. Caso de uso: monitorar a performance do cluster Unidade: *booliano* | | JobsRunning | O número de trabalhos no cluster que estão em execução no momento. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | JobsFailed | O número de trabalhos no cluster que apresentaram falha. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | Map/Reduce | | MapTasksRunning | O número de tarefas de mapeamento em execução para cada trabalho. Se você tiver um programador instalado e vários trabalhos em execução, vários gráficos são gerados. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | MapTasksRemaining | O número de tarefas de mapeamento restantes para cada trabalho. Se você tiver um programador instalado e vários trabalhos em execução, vários gráficos são gerados. Uma tarefa de mapeamento restante não está em nenhum dos seguintes estados: Running, Killed ou Completed. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | MapSlotsOpen | A capacidade não utilizada da tarefa de mapeamento. É calculado como o número máximo de tarefas de mapeamento para um determinado cluster, menos o número total de tarefas de mapeamento em execução no momento nesse cluster. Caso de uso: analisar a performance do cluster Unidades: *Contagem* | | RemainingMapTasksPerSlot | A razão entre o total de tarefas de mapeamento restantes e o total de slots de mapeamento disponíveis no cluster. Caso de uso: analisar a performance do cluster Unidade: *razão* | | ReduceTasksRunning | O número de tarefas de redução em execução para cada trabalho. Se você tiver um programador instalado e vários trabalhos em execução, vários gráficos são gerados. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ReduceTasksRemaining | O número de tarefas de redução restantes para cada trabalho. Se você tiver um programador instalado e vários trabalhos em execução, vários gráficos são gerados. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ReduceSlotsOpen | Capacidade não utilizada das tarefas de redução. É calculado como a capacidade máxima da tarefa de redução para um determinado cluster, menos o número total de tarefas de redução em execução no momento nesse cluster. Caso de uso: analisar a performance do cluster Unidades: *Contagem* | | Status do nó | | CoreNodesRunning | O número de nós core em funcionamento. Os pontos de dados para essa métrica são relatados somente quando existe um grupo de instâncias correspondente. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | CoreNodesPending | O número de nós core aguardando atribuição. Todos os nós core solicitados podem não estar disponíveis imediatamente; essa métrica reporta as solicitações pendentes. Os pontos de dados para essa métrica são relatados somente quando existe um grupo de instâncias correspondente. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | LiveDataNodes | A porcentagem de nós de dados que estão recebendo trabalho do Hadoop. Caso de uso: monitorar a integridade do cluster Unidade: *percentual* | | TaskNodesRunning | O número de nós da tarefa trabalhando. Os pontos de dados para essa métrica são relatados somente quando existe um grupo de instâncias correspondente. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | TaskNodesPending | O número de nós de tarefa aguardando atribuição. Todos os nós de tarefa solicitados podem não estar disponíveis imediatamente; essa métrica reporta as solicitações pendentes. Os pontos de dados para essa métrica são relatados somente quando existe um grupo de instâncias correspondente. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | LiveTaskTrackers | O percentual dos rastreadores de tarefas que estão funcionando. Caso de uso: monitorar a integridade do cluster Unidade: *percentual* | | IO | | S3 BytesWritten | O número de bytes gravados no Amazon S3. Essa métrica agrega somente MapReduce trabalhos e não se aplica a outras cargas de trabalho no Amazon EMR. Caso de uso: analisar a performance do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | S3 BytesRead | O número de bytes lidos no Amazon S3. Essa métrica agrega somente MapReduce trabalhos e não se aplica a outras cargas de trabalho no Amazon EMR. Caso de uso: analisar a performance do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | HDFSUtilization | O percentual de armazenamento do HDFS em uso no momento. Caso de uso: analisar a performance do cluster Unidade: *percentual* | | HDFSBytesLeia | O número de bytes lidos do HDFS. Caso de uso: analisar a performance do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | HDFSBytesEscrito | O número de bytes gravados no HDFS. Caso de uso: analisar a performance do cluster, monitorar o progresso do cluster Unidades: *Contagem* | | MissingBlocks | O número de blocos em que o HDFS não tem réplicas. Esses podem ser blocos danificados. Caso de uso: monitorar a integridade do cluster Unidades: *Contagem* | | TotalLoad | O número total atual de leitores e escritores relatados por todos DataNodes em um cluster. Caso de uso: diagnostique até que ponto o alto I/O pode estar contribuindo para o baixo desempenho da execução do trabalho. Os nós de trabalho que executam o DataNode daemon também devem realizar tarefas de mapeamento e redução. TotalLoad Valores persistentemente altos ao longo do tempo podem indicar que altos I/O podem ser um fator que contribui para um desempenho ruim. Os picos ocasionais nesse valor são típicos e geralmente não são indícios de problema. Unidades: *Contagem* | #### Métricas de capacidade de cluster As métricas a seguir indicam as capacidades atuais ou de destino de um cluster. Essas métricas só estão disponíveis quando o ajuste de escala gerenciado ou o término automático estão habilitados. Para clusters compostos por frotas de instâncias, as métricas de capacidade de cluster são medidas em `Units`. Para clusters compostos por grupos de instâncias, as métricas de capacidade de cluster são medidas em `Nodes` ou `VCPU` com base no tipo de unidade usado na política de escalabilidade gerenciada. Para obter mais informações, consulte [Using EMR-managed scaling](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) no *Guia de gerenciamento do Amazon EMR*. | Métrica | Description | | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | O número total alvo de units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | O número total atual de units/nodes/vCPUs disponíveis em um cluster em execução. Quando um redimensionamento de cluster for solicitado, essa métrica será atualizada depois que as novas instâncias forem adicionadas ou removidas do cluster. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | O número alvo de CORE units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | O número atual de CORE em units/nodes/vCPUs execução em um cluster. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | O número alvo de TASK units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | O número atual de TAREFAS em units/nodes/vCPUs execução em um cluster. Unidades: *Contagem* | O Amazon EMR emite as métricas a seguir em uma granularidade de um minuto quando você habilita o término automático usando uma política de término automático. Algumas métricas estão disponíveis somente para o Amazon EMR 6.4.0 e versões posteriores. Para saber mais sobre término automático, consulte [Uso de uma política de encerramento automático para limpeza de cluster do Amazon EMR](emr-auto-termination-policy.md). **** | Métrica | Description | | --- | --- | | TotalNotebookKernels | O total de kernels de cadernos em execução e ociosos no cluster. Essa métrica está disponível somente para o Amazon EMR 6.4.0 e versões posteriores. | | AutoTerminationIsClusterIdle | Indica se o cluster está em uso.O valor **0** indica que o cluster está sendo usado ativamente por um destes componentes:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) O valor **1** indica que o cluster está ocioso. O Amazon EMR verifica a ociosidade contínua do cluster (`AutoTerminationIsClusterIdle` = 1). Quando o tempo ocioso de um cluster é igual ao valor `IdleTimeout` na política de término automático, o Amazon EMR termina o cluster. | ### Dimensões para métricas do Amazon EMR Os dados do Amazon EMR podem ser filtrados usando qualquer uma das dimensões da tabela a seguir. | Dimensão | Description | | --- | --- | | JobFlowId | Igual ao ID do cluster, que é o identificador exclusivo de um cluster no formato j-XXXXXXXXXXXXX. Encontre esse valor clicando no cluster do console do Amazon EMR. | # Monitorando eventos do Amazon EMR com CloudWatch O Amazon EMR controla eventos e mantém as informações sobre eles por até sete dias no console do Amazon EMR. O Amazon EMR registra eventos quando há uma alteração no estado de clusters, grupos de instâncias, frotas de instâncias, políticas de ajuste de escala automático ou etapas. Os eventos capturam a data e a hora em que o evento ocorreu, detalhes sobre os elementos afetados e outros pontos de dados essenciais. A tabela apresentada a seguir lista os eventos do Amazon EMR em conjunto com o estado ou a alteração de estado que o evento indica, a gravidade do evento, o tipo de evento, o código do evento e as mensagens do evento. O Amazon EMR representa eventos como objetos JSON e os envia automaticamente para um fluxo de eventos. O objeto JSON é importante quando você configura regras para processamento de CloudWatch eventos usando Eventos porque as regras buscam corresponder aos padrões no objeto JSON. Para obter mais informações, consulte [Eventos e padrões de eventos](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CloudWatchEventsandEventPatterns.html) e eventos do [Amazon EMR no Guia](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#emr_event_type) *do usuário do Amazon CloudWatch Events*. **nota** O EMR emite periodicamente eventos com o código de evento **Provisionamento do EC2 - Capacidade insuficiente da instância**. Esses eventos ocorrem quando seu cluster do Amazon EMR encontra um erro de capacidade insuficiente do Amazon EMR para sua frota de instâncias ou grupo de instâncias durante a criação do cluster ou operação de redimensionamento. Um evento pode não incluir todos os tipos de instância que AZs você forneceu, porque o EMR inclui apenas os tipos de instância e AZs tentou provisionar capacidade desde a última emissão do evento de capacidade insuficiente. Para obter informações sobre como responder a esses eventos, consulte [Responder a eventos de capacidade insuficiente de instância do cluster do Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-events-response-insuff-capacity.html). ## Eventos de início de cluster | Estado ou alteração de estado | Gravidade | Tipo de evento | Código do evento | Mensagem | | --- | --- | --- | --- | --- | | CREATING | WARN | Provisionamento da frota de instâncias do EMR | Provisionamento do EC2: capacidade de instância insuficiente | Não foi possível criar o cluster ClusterId (ClusterName) do Amazon EMR para a frota de instâncias InstanceFleetID. O Amazon EC2 tem capacidade spot insuficiente para o tipo de instância [Instancetype1, Instancetype2] e capacidade sob demanda insuficiente para o tipo de instância [Instancetype3, Instancetype4] na zona de disponibilidade [AvailabilityZone1, AvaliabilityZone2]. Confira aqui a [documentação](emr-EC2_INSUFFICIENT_CAPACITY-error.md) para obter mais informações sobre como responder a esse evento. | | CREATING | WARN | Provisionamento do grupo de instâncias do EMR | Provisionamento do EC2: capacidade de instância insuficiente | Não foi possível criar o cluster ClusterId (ClusterName) do Amazon EMR para o grupo de instâncias InstanceGroupID. O Amazon EC2 tem capacidade spot insuficiente para o tipo de instância [Instancetype1, Instancetype2] e capacidade sob demanda insuficiente para o tipo de instância [Instancetype3, Instancetype4] na zona de disponibilidade [AvailabilityZone1, AvaliabilityZone2]. Confira aqui a [documentação](emr-EC2_INSUFFICIENT_CAPACITY-error.md) para obter mais informações sobre como responder a esse evento. | | CREATING | WARN | Provisionamento da frota de instâncias do EMR | Provisionamento do EC2: endereços livres insuficientes na sub-rede | Não podemos criar o cluster ClusterId (ClusterName) do Amazon EMR solicitado para a frota de instâncias InstanceFleetID porque a sub-rede [Subnet1, Subnet2] especificada não contém endereços IP privados livres suficientes para atender à solicitação. Use a operação DescribeSubnets para consultar quantos endereços IP estão disponíveis (não usados) na sub-rede. Para obter informações sobre como responder a esse evento, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html) | | CREATING | WARN | Provisionamento do grupo de instâncias do EMR | Provisionamento do EC2: endereços livres insuficientes na sub-rede | Não podemos criar o cluster ClusterId (ClusterName) do Amazon EMR solicitado para o grupo de instâncias InstanceGroupID porque a sub-rede [Subnet1, Subnet2] especificada não contém endereços IP privados livres suficientes para atender à solicitação. Use a operação DescribeSubnets para consultar quantos endereços IP estão disponíveis (não usados) na sub-rede. Para obter informações sobre como responder a esse evento, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html) | | CREATING | WARN | Provisionamento da frota de instâncias do EMR | Provisionamento do EC2: limite de vCPU excedido | O fornecimento InstanceFleetID no cluster do Amazon EMR ClusterId (ClusterName) está atrasado porque você atingiu o limite do número de v CPUs (unidades de processamento virtual) atribuídas às instâncias em execução no seu. account (accountId) Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html) | | CREATING | WARN | Provisionamento do grupo de instâncias do EMR | Provisionamento do EC2: limite de vCPU excedido | O fornecimento do grupo de instâncias InstanceGroupID no cluster do Amazon EMR ClusterId está atrasado porque você atingiu o limite do número de v CPUs (unidades de processamento virtual) atribuídas às instâncias em execução na sua conta. (accountId) Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html) | | CREATING | WARN | Provisionamento da frota de instâncias do EMR | Provisionamento do EC2: limite de contagem de instâncias spot excedido | O fornecimento da frota de instâncias InstanceFleetID no cluster ClusterID (ClusterName) do Amazon EMR está atrasado porque você atingiu o limite do número de Instâncias spot que podem ser executadas no account (accountId). Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | CREATING | WARN | Provisionamento do grupo de instâncias do EMR | Provisionamento do EC2: limite de contagem de instâncias spot excedido | O fornecimento do grupo de instâncias InstanceGroupID no cluster ClusterID (ClusterName) do Amazon EMR está atrasado porque você atingiu o limite do número de instâncias spot que podem ser executadas no account (accountId). Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | CREATING | WARN | Provisionamento da frota de instâncias do EMR | Provisionamento do EC2: limite de instâncias excedido | O fornecimento da frota de instâncias InstanceFleetID no cluster ClusterId (ClusterName) do Amazon EMR está atrasado porque você atingiu o limite do número de instâncias que podem ser executadas simultaneamente no account (accountID). Para obter mais informações sobre os limites de serviço do Amazon EC2, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | CREATING | WARN | Provisionamento do grupo de instâncias do EMR | Provisionamento do EC2: limite de instâncias excedido | O fornecimento do grupo de instâncias InstanceGroupID no cluster ClusterId (ClusterName) do Amazon EMR está atrasado porque você atingiu o limite do número de instâncias que podem ser executadas simultaneamente no account (accountID). Para obter mais informações sobre os limites de serviço do Amazon EC2, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | CREATING | WARN | Provisionamento do grupo de instâncias do EMR | *none* | O cluster `ClusterId (ClusterName)` do Amazon EMR foi criado às `Time` e está pronto para uso. - ou - O cluster `ClusterId (ClusterName)` do Amazon EMR concluiu a execução de todas as etapas pendentes às `Time`. Um cluster no estado `WAITING` pode ainda estar processando trabalhos. | | STARTING | INFO | Alteração de estado de clusters do EMR | *none* | O cluster `ClusterId (ClusterName)` do Amazon EMR foi solicitado às `Time` e está sendo criado. | | STARTING | INFO | Alteração de estado de clusters do EMR | *none* | Aplica-se apenas a clusters com a configuração de frotas de instâncias e várias zonas de disponibilidade selecionadas no Amazon EC2. O cluster `ClusterId (ClusterName)` do Amazon EMR está sendo criado na zona (`AvailabilityZoneID`), que foi escolhida entre as opções de zona de disponibilidade. | | STARTING | INFO | Alteração de estado de clusters do EMR | *none* | O cluster `ClusterId (ClusterName)` do Amazon EMR começou a executar etapas às `Time`. | | WAITING | INFO | Alteração de estado de clusters do EMR | *none* | O cluster `ClusterId (ClusterName)` do Amazon EMR foi criado às `Time` e está pronto para uso. - ou - O cluster `ClusterId (ClusterName)` do Amazon EMR concluiu a execução de todas as etapas pendentes às `Time`. Um cluster no estado `WAITING` pode ainda estar processando trabalhos. | **nota** Os eventos com código de evento `EC2 provisioning - Insufficient Instance Capacity` são emitidos periodicamente quando o cluster do EMR encontra um erro de capacidade insuficiente do Amazon EC2 para a frota de instâncias ou grupo de instâncias durante a criação ou operação de redimensionamento do cluster. Para obter informações sobre como responder a esses eventos, consulte [Responder eventos de capacidade de instância insuficiente do cluster do Amazon EMR](emr-events-response-insuff-capacity.md). ## Eventos de término de clusters | Estado ou alteração de estado | Gravidade | Tipo de evento | Código do evento | Mensagem | | --- | --- | --- | --- | --- | | TERMINATED | A gravidade depende do motivo da mudança de estado, conforme mostrado a seguir: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html) | Alteração de estado de clusters do EMR | *none* | O cluster `ClusterId (ClusterName)` do Amazon EMR foi terminado às `Time` pelo motivo `StateChangeReason:Code`. | | TERMINATED\$1WITH\$1ERRORS | CRITICAL | Alteração de estado de clusters do EMR | *none* | O cluster `ClusterId (ClusterName)` do Amazon EMR foi terminado com erros às `Time` pelo motivo `StateChangeReason:Code`. | | TERMINATED\$1WITH\$1ERRORS | CRITICAL | Alteração de estado de clusters do EMR | *none* | O cluster `ClusterId (ClusterName)` do Amazon EMR foi terminado com erros às `Time` pelo motivo `StateChangeReason:Code`. | ## Eventos de alteração de estado da frota de instâncias **nota** A configuração de frotas de instância só está disponível em versões do Amazon EMR 4.8.0 e posteriores, exceto versões 5.0.0 e 5.0.3. **** | Estado ou alteração de estado | Gravidade | Tipo de evento | Código do evento | Mensagem | | --- | --- | --- | --- | --- | | De `PROVISIONING` até `WAITING` | INFO | | none | O provisionamento da frota de instâncias `InstanceFleetID`no cluster do Amazon EMR foi concluído `ClusterId (ClusterName)`. O provisionamento começou às `Time` e levou `Num` minutos. Agora, a frota de instâncias tem capacidade sob demanda de `Num` e capacidade spot de `Num`. A capacidade sob demanda de destino era `Num`, e a capacidade spot de destino era `Num`. | | De `WAITING` até `RESIZING` | INFO | | none | Um redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi iniciado às `Time`. A frota de instâncias está sendo redimensionada de uma capacidade sob demanda de `Num` para um destino de `Num` e de uma capacidade spot de `Num` para um destino de `Num`. | | De `RESIZING` até `WAITING` | INFO | | none | A operação de redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi concluída. O redimensionamento começou às `Time` e durou `Num` minutos. Agora, a frota de instâncias tem capacidade sob demanda de `Num` e capacidade spot de `Num`. A capacidade sob demanda de destino era `Num`, e a capacidade spot de destino era `Num`. | | De `RESIZING` até `WAITING` | INFO | | none | A operação de redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR atingiu o tempo limite e foi interrompida. O redimensionamento começou às `Time` e foi interrompido após `Num` minutos. Agora, a frota de instâncias tem capacidade sob demanda de `Num` e capacidade spot de `Num`. A capacidade sob demanda de destino era `Num`, e a capacidade spot de destino era `Num`. | | SUSPENDED | ERROR | | none | A frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi presa às `Time` pelo seguinte motivo: `ReasonDesc`. | | RESIZING | WARNING | | none | A operação de redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR está paralisada pelo seguinte motivo: `ReasonDesc`. | | `WAITING` ou `Running` | INFO | | none | Não foi possível concluir a operação de redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR enquanto o Amazon EMR adicionava capacidade spot à zona de disponibilidade `AvailabilityZone`. Cancelamos sua solicitação para provisionar uma capacidade spot maior. Para ver as ações recomendadas, verifique [Flexibilidade da zona de disponibilidade em um cluster do Amazon EMR](emr-flexibility.md) e tente novamente. | | `WAITING` ou `Running` | INFO | | none | Uma operação de redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi iniciada por `Entity` às `Time`. | ## Eventos de reconfiguração de frota de instâncias **** | Estado ou alteração de estado | Gravidade | Mensagem | | --- | --- | --- | | Solicitação de reconfiguração da frota de instâncias | INFO | Um usuário solicitou a reconfiguração da frota de instâncias `InstanceFleetID` no cluster do Amazon EMR `ClusterId` (`ClusterName`). | | Início da reconfiguração da frota de instâncias | INFO | O Amazon EMR iniciou uma reconfiguração da frota de instâncias `InstanceFleetID` no cluster do Amazon EMR `ClusterId` (`ClusterName`) às `Time`. | | Reconfiguração da frota de instâncias concluída | INFO | O Amazon EMR concluiu a reconfiguração da frota de instâncias `InstanceFleetID` no cluster do Amazon EMR. `ClusterId` (`ClusterName`). | | Falha na reconfiguração da frota de instâncias | WARNING | O Amazon EMR falhou ao reconfigurar a frota de instâncias `InstanceFleetID` no cluster do Amazon EMR `ClusterId` (`ClusterName`) às `Time`. A reconfiguração falhou porque `Reason`. | | Início da reversão da reconfiguração da frota de instâncias | INFO | O Amazon EMR está revertendo a frota de instâncias `InstanceFleetID` no cluster do Amazon EMR `ClusterId` (`ClusterName`) para a configuração anterior bem-sucedida. | | Reversão da reconfiguração da frota de instâncias concluída | INFO | O Amazon EMR finalizou a reversão da frota de instâncias `InstanceFleetID` no cluster do Amazon EMR `ClusterId` (`ClusterName`) para a configuração anterior bem-sucedida. | | Falha na reversão da reconfiguração da frota de instâncias | CRITICAL | O Amazon EMR não conseguiu reverter a frota de instâncias `InstanceFleetID` no cluster do Amazon EMR `ClusterId` (`ClusterName`) para a configuração anterior com êxito em `Time`. A reversão da reconfiguração falhou devido a `Reason`. | | Reversão bloqueada da reconfiguração da frota de instâncias | INFO | O Amazon EMR bloqueou temporariamente a frota de instâncias `InstanceFleetID` no cluster do Amazon EMR `ClusterId` (`ClusterName`) às `Time` porque a frota de instâncias está no estado `State`. | ## Eventos de redimensionamento da frota de instâncias **** | Tipo de evento | Gravidade | Código do evento | Mensagem | | --- | --- | --- | --- | | Redimensionamento da frota de instâncias do EMR | ERROR | Tempo limite de provisionamento spot | Não foi possível concluir a operação de redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR durante a aquisição da capacidade spot na AZ `AvailabilityZone`. Já cancelamos a solicitação e paramos de tentar provisionar qualquer capacidade spot adicional, e a frota de instâncias provisionou a capacidade spot de `num`. A capacidade spot de destino era `num`. Para obter mais informações e ações recomendadas, consulte a página de documentação [aqui](emr-flexibility.md) e tente novamente. | | Redimensionamento da frota de instâncias do EMR | ERROR | Tempo limite de provisionamento sob demanda | Não foi possível concluir a operação de redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR durante a aquisição da capacidade sob demanda na AZ `AvailabilityZone`. Já cancelamos a solicitação e paramos de tentar provisionar qualquer capacidade sob demanda adicional, e a frota de instâncias provisionou a capacidade sob demanda de `num`. A capacidade sob demanda de destino era `num`. Para obter mais informações e ações recomendadas, consulte a página de documentação [aqui](emr-flexibility.md) e tente novamente. | | Redimensionamento da frota de instâncias do EMR | WARNING | Provisionamento do EC2: capacidade de instância insuficiente | Não foi possível concluir a operação de redimensionamento da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do EMR, pois o Amazon EC2 tem capacidade spot insuficiente para tipos de instância `[Instancetype1, Instancetype2]` e capacidade sob demanda insuficiente para tipos de instância `[Instancetype3, Instancetype4]` na zona de disponibilidade `[AvailabilityZone1]`. Até agora, a frota de instâncias provisionou a capacidade sob demanda de `num`, e a capacidade sob demanda de destino era `num`. A capacidade spot provisionada é `num`, e a capacidade spot de destino era `num`. Confira aqui a [documentação](emr-EC2_INSUFFICIENT_CAPACITY-error.md) para obter mais informações sobre como responder a esse evento. | | Redimensionamento da frota de instâncias do EMR | WARNING | Tempo limite de provisionamento spot: redimensionamento contínuo | Ainda estamos provisionando a capacidade spot para a operação de redimensionamento da frota de instâncias que foi iniciada às `time` para o ID da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR para `[Instancetype1, Instancetype2]` ou na AZ `AvailabilityZone`. Para a operação de redimensionamento anterior iniciada às `time`, o período de tempo limite expirou, então o Amazon EMR parou de provisionar a capacidade spot após adicionar `num` das `num` instâncias solicitadas à frota de instâncias. Para obter mais informações e ações recomendadas, confira a página de documentação [aqui](emr-flexibility.md). | | Redimensionamento da frota de instâncias do EMR | WARNING | Tempo limite de provisionamento sob demanda: redimensionamento contínuo | Ainda estamos provisionando a capacidade sob demanda para a operação de redimensionamento da frota de instâncias que foi iniciada às `time` para o ID da frota de instâncias `InstanceFleetID` no cluster `ClusterId (ClusterName)` do Amazon EMR para `[Instancetype1, Instancetype2]` ou na AZ `AvailabilityZone`. Para a operação de redimensionamento anterior iniciada às `time`, o período de tempo limite expirou, então o Amazon EMR parou de provisionar a capacidade sob demanda após adicionar `num` das `num` instâncias solicitadas à frota de instâncias. Para obter mais informações e ações recomendadas, confira a página de documentação [aqui](emr-flexibility.md). | | Redimensionamento da frota de instâncias do EMR | WARNING | Provisionamento do EC2: endereço livre insuficiente na sub-rede | Não podemos concluir a operação de redimensionamento da frota de instâncias InstanceFleetID no cluster ClusterId (ClusterName) do Amazon EMR porque a sub-rede especificada [Subnet1, Subnet2] não contém endereços IP privados livres suficientes para atender à solicitação. Use a operação DescribeSubnets para exibir quantos endereços IP estão disponíveis (não usados) na sub-rede. Para obter informações sobre como responder a esse evento, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | Redimensionamento da frota de instâncias do EMR | WARNING | Provisionamento do EC2: limite de vCPU excedido | O redimensionamento da frota de instâncias InstanceFleetID no ClusterName cluster do Amazon EMR está atrasado porque você atingiu o limite do número de CPUs v (unidades de processamento virtual) atribuídas às instâncias em execução na sua. account (accountId) Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | Redimensionamento da frota de instâncias do EMR | WARNING | Provisionamento do EC2: limite de contagem de instâncias spot excedido | O fornecimento da frota de instâncias InstanceFleetID no cluster ClusterID (ClusterName) do Amazon EMR está atrasado porque você atingiu o limite do número de Instâncias spot que podem ser executadas no account (accountId). Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | Redimensionamento da frota de instâncias do EMR | WARNING | Provisionamento do EC2: limite de instâncias excedido | O fornecimento da frota de instâncias InstanceFleetID no cluster ClusterID (ClusterName) do Amazon EMR está atrasado porque você atingiu o limite do número de instâncias sob demanda que podem ser executadas no account (accountId). Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | **nota** Os eventos de tempo limite de provisionamento são emitidos quando o Amazon EMR interrompe o provisionamento de capacidade spot ou sob demanda da frota após o tempo limite expirar. Para obter informações sobre como responder a esses eventos, consulte [Responder a eventos de tempo limite de redimensionamento da frota de instâncias de cluster do Amazon EMR](emr-events-response-timeout-events.md). ## Eventos de instâncias de grupos **** | Tipo de evento | Gravidade | Código do evento | Mensagem | | --- | --- | --- | --- | | De `RESIZING` até `Running` | INFO | none | A operação de redimensionamento do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi concluída. Agora, ele tem uma contagem de instâncias de `Num`. O redimensionamento começou às `Time` e levou `Num` minutos para ser concluído. | | De `RUNNING` até `RESIZING` | INFO | none | Um redimensionamento do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi iniciado às `Time`. Ele está sendo redimensionado de uma contagem de instâncias de `Num` a `Num`. | | SUSPENDED | ERROR | none | O grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi preso às `Time` pelo seguinte motivo: `ReasonDesc`. | | RESIZING | WARNING | none | A operação de redimensionamento do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR está paralisada pelo seguinte motivo: `ReasonDesc`. | | Redimensionamento do grupo de instâncias do EMR | WARNING | Provisionamento do EC2: capacidade de instância insuficiente | Não foi possível concluir a operação de redimensionamento iniciada às `time` para o grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do EMR, pois o Amazon EC2 não tem capacidade `Spot/On Demand` suficiente para o tipo de instância `[Instancetype]` na zona de disponibilidade `[AvailabilityZone1]`. Até agora, o grupo de instâncias tem uma contagem de instâncias em execução de `num`, e a contagem de instâncias solicitadas era `num`. Confira aqui a [documentação](emr-EC2_INSUFFICIENT_CAPACITY-error.md) para obter mais informações sobre como responder a esse evento. | | Redimensionamento do grupo de instâncias do EMR | WARNING | Provisionamento do EC2: endereço livre insuficiente na sub-rede | Não podemos concluir a operação de redimensionamento do grupo de instâncias InstanceGroupID no cluster ClusterId (ClusterName) do Amazon EMR porque a sub-rede especificada [Subnet1, Subnet2] não contém endereços IP privados livres suficientes para atender à solicitação. Use a operação DescribeSubnets para exibir quantos endereços IP estão disponíveis (não usados) na sub-rede. Para obter informações sobre como responder a esse evento, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | Redimensionamento do grupo de instâncias do EMR | WARNING | Provisionamento do EC2: limite de vCPU excedido | O redimensionamento do grupo de instâncias InstanceGroupID no ClusterName cluster do Amazon EMR está atrasado porque você atingiu o limite do número de CPUs v (unidades de processamento virtual) atribuídas às instâncias em execução no seu. account (accountId) Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | Redimensionamento do grupo de instâncias do EMR | WARNING | Provisionamento do EC2: limite de contagem de instâncias spot excedido | O fornecimento do grupo de instâncias InstanceGroupID no cluster ClusterID (ClusterName) do Amazon EMR está atrasado porque você atingiu o limite do número de instâncias spot que podem ser executadas no account (accountId). Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | Redimensionamento do grupo de instâncias do EMR | WARNING | Provisionamento do EC2: limite de instâncias excedido | O fornecimento do grupo de instâncias InstanceGroupID no cluster ClusterID (ClusterName) do Amazon EMR está atrasado porque você atingiu o limite do número de instâncias sob demanda que podem ser executadas no account (accountId). Para obter mais informações, consulte [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html). | | De `RUNNING` até `RESIZING` | INFO | none | Um redimensionamento do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi iniciado por `Entity` às `Time`. | **nota** Com as versões 5.21.0 e posteriores do Amazon EMR, você pode substituir as configurações de cluster e especificar classificações de configuração adicionais para cada grupo de instâncias em um cluster em execução. Você faz isso usando o console do Amazon EMR, o AWS Command Line Interface (AWS CLI) ou o AWS SDK. Para obter mais informações, consulte [Supplying a Configuration for an Instance Group in a Running Cluster](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html). A tabela a seguir lista eventos do Amazon EMR para a operação de reconfiguração, juntamente com o estado ou a alteração de estado que cada um indica, a gravidade do evento e as mensagens do evento. **** | Estado ou alteração de estado | Gravidade | Mensagem | | --- | --- | --- | | RUNNING | INFO | Uma reconfiguração do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi iniciada pelo usuário às `Time`. A versão da configuração solicitada é `Num`. | | De `RECONFIGURING` até `Running` | INFO | A operação de reconfiguração do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi concluída. A reconfiguração começou às `Time` e levou `Num` minutos para ser concluída. A versão de configuração atual é `Num`. | | De `RUNNING` até `RECONFIGURING` in | INFO | Uma reconfiguração para o grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi iniciada às `Time`. Ela é a configuração do número da versão `Num` ao número da versão `Num`. | | RESIZING | INFO | A operação de reconfiguração para a versão de configuração `Num` do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR é temporariamente bloqueada às `Time` porque o grupo de instâncias está em `State`. | | RECONFIGURING | INFO | A operação de redimensionamento para a contagem de instâncias Num do grupo de instâncias InstanceGroupID no cluster ClusterId (ClusterName) do Amazon EMR é temporariamente bloqueada às Time porque o grupo de instâncias está em State. | | RECONFIGURING | WARNING | A operação de reconfiguração do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR falhou às `Time` e levou `Num` minutos para falhar. A versão de configuração com falha é `Num`. | | RECONFIGURING | INFO | As configurações estão sendo revertidas com êxito para o número da versão anterior `Num` do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR às `Time`. A nova versão de configuração é `Num`. | | De `RECONFIGURING` até `Running` | INFO | As configurações foram revertidas com êxito para a versão anterior `Num` do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR às `Time`. A nova versão de configuração é `Num`. | | De `RECONFIGURING` até `SUSPENDED` | CRITICAL | Falha ao reverter para a versão com êxito anterior `Num` do grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR às `Time`. | ## Eventos de política do Auto Scaling **** | Estado ou alteração de estado | Gravidade | Mensagem | | --- | --- | --- | | PENDING | INFO | Uma política do Auto Scaling foi adicionada para o grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR às `Time`. A política tem um anexo pendente. - ou - A política do Auto Scaling para o grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi atualizada às `Time`. A política tem um anexo pendente. | | ATTACHED | INFO | A política do Auto Scaling para o grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi anexada às `Time`. | | `DETACHED` | INFO | A política do Auto Scaling para o grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR foi desvinculada às `Time`. | | FAILED | ERROR | Não foi possível anexar a política do Auto Scaling para o grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR, que falhou às `Time`. - ou - Não foi possível desvincular a política do Auto Scaling para o grupo de instâncias `InstanceGroupID` no cluster `ClusterId (ClusterName)` do Amazon EMR, que falhou às `Time`. | ## Eventos de etapa **** | Estado ou alteração de estado | Gravidade | Mensagem | | --- | --- | --- | | PENDING | INFO | A etapa `StepID (StepName)` foi adicionada ao cluster `ClusterId (ClusterName)` do Amazon EMR às `Time` e está com execução pendente. | | CANCEL\$1PENDING | WARN | A etapa `StepID (StepName)` no cluster `ClusterId (ClusterName)` do Amazon EMR foi cancelada às `Time` e está com cancelamento pendente. | | RUNNING | INFO | A etapa `StepID (StepName)` no cluster `ClusterId (ClusterName)` do Amazon EMR começou a ser executada às `Time`. | | COMPLETED | INFO | A etapa `StepID (StepName)` no cluster `ClusterId (ClusterName)` do Amazon EMR concluiu a execução em `Time`. A etapa começou a ser executada às `Time` e levou `Num` minutos para ser concluída. | | CANCELLED | WARN | A solicitação de cancelamento teve êxito na etapa do cluster `StepID (StepName)` no cluster `ClusterId (ClusterName)` do Amazon EMR às `Time`, e a etapa já foi cancelada. | | FAILED | ERROR | A etapa `StepID (StepName)` no cluster `ClusterId (ClusterName)` do Amazon EMR falhou às `Time`. | ## Eventos de substituição de nós não íntegros | Tipo de evento | Gravidade | Código do evento | Mensagem | | --- | --- | --- | --- | | Substituição de nós não íntegros do Amazon EMR | INFO | Detectado nó central não íntegro | O Amazon EMR identificou que a instância principal `[instanceID (InstanceName)]` em `InstanceGroup/Fleet` no cluster `clusterID (ClusterName)` do Amazon EMR está `UNHEALTHY`. O Amazon EMR tentará recuperar ou substituir a instância `UNHEALTHY` normalmente. | | Substituição de nós não íntegros do Amazon EMR | INFO | Nó central não íntegro: substituição desabilitada | O Amazon EMR identificou que a instância principal `[instanceID (InstanceName)]` em `InstanceGroup/Fleet` no cluster `(clusterID) (ClusterName)` do Amazon EMR está `UNHEALTHY`. Ative a substituição de nós centrais não íntegros no cluster para permitir que o Amazon EMR troque as instâncias `UNHEALTHY` sem problemas, caso elas não possam ser recuperadas. | | Substituição de nós não íntegros do Amazon EMR | WARN | O nó central não íntegro não foi substituído | O Amazon EMR não pode substituir a instância principal `UNHEALTHY` `[instanceID (InstanceName)]` em `InstanceGroup/Fleet` no cluster `clusterID (ClusterName)` do Amazon EMR devido ao *motivo*. O motivo pelo qual o Amazon EMR não pode substituir o nó central varia de acordo com o cenário. Por exemplo, uma razão pela qual o Amazon EMR não pode excluir um nó é porque um cluster não teria nenhum nó central restante. | | Substituição de nós não íntegros do Amazon EMR | INFO | O nó central não íntegro foi recuperado | O Amazon EMR recuperou as instâncias centrais `UNHEALTHY` `[instanceID (InstanceName)]` em `InstanceGroup/Fleet` no cluster `clusterID (ClusterName)` do Amazon EMR | Para obter mais informações sobre a substituição de nós não íntegros, consulte [Replacing unhealthy nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html). ## Visualizar eventos usando o console do Amazon EMR Para cada cluster, você pode visualizar uma lista simples de eventos no painel de detalhes, que lista os eventos em ordem decrescente de ocorrência. Você também pode visualizar todos os eventos para todos os clusters de uma região em ordem decrescente de ocorrência. Se não quiser que um usuário veja todos os eventos de cluster para uma região, adicione uma instrução que negue permissão (`"Effect": "Deny"`) para a ação `elasticmapreduce:ViewEventsFromAllClustersInConsole` a uma política anexada a esse usuário. **Para exibir eventos de todos os clusters em uma região usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Eventos**. **Para exibir os eventos de um determinado cluster usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters** e, em seguida, escolha um cluster. 1. Para visualizar todos os seus eventos, selecione a guia **Eventos** na página de detalhes do cluster. # Respondendo a CloudWatch eventos do Amazon EMR [Esta seção descreve várias maneiras de responder a eventos acionáveis que o Amazon EMR emite CloudWatch como mensagens de eventos.](emr-manage-cloudwatch-events.md) As formas de responder aos eventos incluem criar regras, definir alarmes, dentre outras. As seções a seguir incluem links para procedimentos e respostas recomendadas para eventos comuns. **Topics** + [ # Criação de regras para eventos do Amazon EMR com CloudWatch ](emr-events-cloudwatch-console.md) + [ # Configurando alarmes em CloudWatch métricas do Amazon EMR ](UsingEMR_ViewingMetrics_Alarm.md) + [ # Responder eventos de capacidade de instância insuficiente do cluster do Amazon EMR ](emr-events-response-insuff-capacity.md) + [ # Responder a eventos de tempo limite de redimensionamento da frota de instâncias de cluster do Amazon EMR ](emr-events-response-timeout-events.md) # Criação de regras para eventos do Amazon EMR com CloudWatch O Amazon EMR envia automaticamente eventos para um CloudWatch stream de eventos. Você pode criar regras que correspondem eventos de acordo com um padrão especificado e rotear esses eventos para destinos a fim de realizar ações, como enviar uma notificação por e-mail. Os padrões são correspondidos ao objeto JSON do evento. Para obter mais informações sobre os detalhes dos eventos do Amazon EMR, consulte Eventos do Amazon [EMR no](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#emr_event_type) Guia do usuário do *Amazon CloudWatch * Events. Para obter informações sobre como configurar regras de CloudWatch eventos, consulte [Criação de uma CloudWatch regra que é acionada em um](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html) evento. # Configurando alarmes em CloudWatch métricas do Amazon EMR O Amazon EMR envia métricas para a Amazon. CloudWatch Em resposta, você pode usar CloudWatch para definir alarmes em suas métricas do Amazon EMR. Por exemplo, você pode configurar um alarme CloudWatch para enviar um e-mail sempre que a utilização do HDFS ultrapassar 80%. Para obter instruções detalhadas, consulte [Criar ou editar um CloudWatch alarme](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) no *Guia do CloudWatch usuário da Amazon*. # Responder eventos de capacidade de instância insuficiente do cluster do Amazon EMR ## Visão geral do Os clusters do Amazon EMR retornam o código de evento `EC2 provisioning - Insufficient Instance Capacity` quando a zona de disponibilidade selecionada não tem capacidade suficiente para solucionar a solicitação de inicialização ou redimensionamento do cluster. O evento é emitido periodicamente com grupos de instâncias e frotas de instâncias se o Amazon EMR encontrar repetidamente exceções de capacidade insuficientes e não puder solucionar solicitação de provisionamento para iniciar ou redimensionar o cluster. Esta página descreve como você pode responder melhor a esse tipo de evento quando ele ocorre no cluster do EMR. ## Solução recomendada a um evento de capacidade insuficiente Recomendamos responder a um evento de capacidade insuficiente de uma das seguintes maneiras: + Aguarde a recuperação da capacidade. Como a capacidade muda com frequência, uma exceção de capacidade insuficiente pode se recuperar sozinha. Os clusters começarão ou terminarão de ser redimensionados assim que a capacidade do Amazon EC2 estiver disponível. + Como alternativa, você pode encerrar o cluster, modificar as configurações de tipo de instância e criar um novo cluster com a solicitação de configuração de cluster atualizada. Para obter mais informações, consulte [Flexibilidade da zona de disponibilidade em um cluster do Amazon EMR](emr-flexibility.md). Também é possível configurar regras ou respostas automatizadas para um evento de capacidade insuficiente, conforme descrito na próxima seção. ## Recuperação automatizada de um evento de capacidade insuficiente É possível criar automação em resposta aos eventos do Amazon EMR, como aqueles com código de evento `EC2 provisioning - Insufficient Instance Capacity`. Por exemplo, a AWS Lambda função a seguir encerra um cluster do EMR com um grupo de instâncias que usa instâncias sob demanda e, em seguida, cria um novo cluster do EMR com um grupo de instâncias que contém tipos de instância diferentes da solicitação original. Estas condições acionam a ocorrência do processo automatizado: + O evento de capacidade insuficiente foi emitido para nós primários ou centrais durante mais de 20 minutos. + O cluster não está no estado **READY** ou **WAITING**. Para obter mais informações sobre estados de cluster do EMR, consulte [Noções básicas sobre o ciclo de vida do cluster](emr-overview.md#emr-overview-cluster-lifecycle). **nota** Ao criar um processo automatizado para uma exceção de capacidade insuficiente, considere que o evento de capacidade insuficiente é recuperável. A capacidade muda com frequência, e os clusters retomarão o redimensionamento ou iniciarão a operação assim que a capacidade do Amazon EC2 estiver disponível. **Example função para responder ao evento de capacidade insuficiente** ``` // Lambda code with Python 3.10 and handler is lambda_function.lambda_handler // Note: related IAM role requires permission to use Amazon EMR import json import boto3 import datetime from datetime import timezone INSUFFICIENT_CAPACITY_EXCEPTION_DETAIL_TYPE = "EMR Instance Group Provisioning" INSUFFICIENT_CAPACITY_EXCEPTION_EVENT_CODE = ( "EC2 provisioning - Insufficient Instance Capacity" ) ALLOWED_INSTANCE_TYPES_TO_USE = [ "m5.xlarge", "c5.xlarge", "m5.4xlarge", "m5.2xlarge", "t3.xlarge", ] CLUSTER_START_ACCEPTABLE_STATES = ["WAITING", "RUNNING"] CLUSTER_START_SLA = 20 CLIENT = boto3.client("emr", region_name="us-east-1") # checks if the incoming event is 'EMR Instance Fleet Provisioning' with eventCode 'EC2 provisioning - Insufficient Instance Capacity' def is_insufficient_capacity_event(event): if not event["detail"]: return False else: return ( event["detail-type"] == INSUFFICIENT_CAPACITY_EXCEPTION_DETAIL_TYPE and event["detail"]["eventCode"] == INSUFFICIENT_CAPACITY_EXCEPTION_EVENT_CODE ) # checks if the cluster is eligible for termination def is_cluster_eligible_for_termination(event, describeClusterResponse): # instanceGroupType could be CORE, MASTER OR TASK instanceGroupType = event["detail"]["instanceGroupType"] clusterCreationTime = describeClusterResponse["Cluster"]["Status"]["Timeline"][ "CreationDateTime" ] clusterState = describeClusterResponse["Cluster"]["Status"]["State"] now = datetime.datetime.now() now = now.replace(tzinfo=timezone.utc) isClusterStartSlaBreached = clusterCreationTime < now - datetime.timedelta( minutes=CLUSTER_START_SLA ) # Check if instance group receiving Insufficient capacity exception is CORE or PRIMARY (MASTER), # and it's been more than 20 minutes since cluster was created but the cluster state and the cluster state is not updated to RUNNING or WAITING if ( (instanceGroupType == "CORE" or instanceGroupType == "MASTER") and isClusterStartSlaBreached and clusterState not in CLUSTER_START_ACCEPTABLE_STATES ): return True else: return False # Choose item from the list except the exempt value def choice_excluding(exempt): for i in ALLOWED_INSTANCE_TYPES_TO_USE: if i != exempt: return i # Create a new cluster by choosing different InstanceType. def create_cluster(event): # instanceGroupType cloud be CORE, MASTER OR TASK instanceGroupType = event["detail"]["instanceGroupType"] # Following two lines assumes that the customer that created the cluster already knows which instance types they use in original request instanceTypesFromOriginalRequestMaster = "m5.xlarge" instanceTypesFromOriginalRequestCore = "m5.xlarge" # Select new instance types to include in the new createCluster request instanceTypeForMaster = ( instanceTypesFromOriginalRequestMaster if instanceGroupType != "MASTER" else choice_excluding(instanceTypesFromOriginalRequestMaster) ) instanceTypeForCore = ( instanceTypesFromOriginalRequestCore if instanceGroupType != "CORE" else choice_excluding(instanceTypesFromOriginalRequestCore) ) print("Starting to create cluster...") instances = { "InstanceGroups": [ { "InstanceRole": "MASTER", "InstanceCount": 1, "InstanceType": instanceTypeForMaster, "Market": "ON_DEMAND", "Name": "Master", }, { "InstanceRole": "CORE", "InstanceCount": 1, "InstanceType": instanceTypeForCore, "Market": "ON_DEMAND", "Name": "Core", }, ] } response = CLIENT.run_job_flow( Name="Test Cluster", Instances=instances, VisibleToAllUsers=True, JobFlowRole="EMR_EC2_DefaultRole", ServiceRole="EMR_DefaultRole", ReleaseLabel="emr-6.10.0", ) return response["JobFlowId"] # Terminated the cluster using clusterId received in an event def terminate_cluster(event): print("Trying to terminate cluster, clusterId: " + event["detail"]["clusterId"]) response = CLIENT.terminate_job_flows(JobFlowIds=[event["detail"]["clusterId"]]) print(f"Terminate cluster response: {response}") def describe_cluster(event): response = CLIENT.describe_cluster(ClusterId=event["detail"]["clusterId"]) return response def lambda_handler(event, context): if is_insufficient_capacity_event(event): print( "Received insufficient capacity event for instanceGroup, clusterId: " + event["detail"]["clusterId"] ) describeClusterResponse = describe_cluster(event) shouldTerminateCluster = is_cluster_eligible_for_termination( event, describeClusterResponse ) if shouldTerminateCluster: terminate_cluster(event) clusterId = create_cluster(event) print("Created a new cluster, clusterId: " + clusterId) else: print( "Cluster is not eligible for termination, clusterId: " + event["detail"]["clusterId"] ) else: print("Received event is not insufficient capacity event, skipping") ``` # Responder a eventos de tempo limite de redimensionamento da frota de instâncias de cluster do Amazon EMR ## Visão geral do Os clusters do Amazon EMR emitem [eventos](emr-manage-cloudwatch-events.md#emr-cloudwatch-instance-fleet-resize-events) enquanto executam a operação de redimensionamento para clusters de frotas de instâncias. Os eventos de tempo limite de provisionamento são emitidos quando o Amazon EMR interrompe o provisionamento de capacidade spot ou sob demanda da frota após o tempo limite expirar. O usuário pode configurar a duração do tempo limite como parte das [especificações de redimensionamento](https://docs.aws.amazon.com/emr/latest/APIReference/API_InstanceFleetResizingSpecifications.html) das frotas de instâncias. Em cenários de redimensionamento consecutivo para a mesma frota de instâncias, o Amazon EMR emite os eventos `Spot provisioning timeout - continuing resize` ou `On-Demand provisioning timeout - continuing resize` quando o tempo limite da operação de redimensionamento atual expira. Em seguida, começa a provisionar capacidade para a próxima operação de redimensionamento da frota. ## Responder a eventos de tempo limite de redimensionamento da frota de instâncias Recomendamos responder a um evento de tempo limite de aprovisionamento de uma das seguintes maneiras: + Revisite as [especificações de redimensionamento](https://docs.aws.amazon.com/emr/latest/APIReference/API_InstanceFleetResizingSpecifications.html) e repita a operação de redimensionamento. Como a capacidade muda com frequência, os clusters serão redimensionados com êxito assim que a capacidade do Amazon EC2 estiver disponível. Recomendamos que os clientes configurem valores mais baixos para a duração do tempo limite dos trabalhos que exigem mais rigorSLAs. + Como alternativa, você pode: + Iniciar um novo cluster com tipos de instância diversificados com base nas [práticas recomendadas para instâncias e na flexibilidade da zona de disponibilidade](emr-flexibility.md#emr-flexibility-types) ou + Iniciar um cluster com capacidade sob demanda + Para o evento de tempo limite de provisionamento e redimensionamento contínuo, você também pode aguardar o processamento das operações de redimensionamento. O Amazon EMR continuará processando sequencialmente as operações de redimensionamento acionadas para a frota, atendendo às especificações de redimensionamento configuradas. Também é possível configurar regras ou respostas automatizadas para este evento, conforme descrito na próxima seção. ## Recuperação automatizada de um evento de tempo limite de provisionamento É possível criar automação em resposta aos eventos do Amazon EMR com código de evento `Spot Provisioning timeout`. Por exemplo, a função do AWS Lambda a seguir desativa um cluster do EMR com uma frota de instâncias que usa instâncias spot para nós de tarefa e cria um novo cluster do EMR com uma frota de instâncias que contém tipos de instância mais diversificados do que a solicitação original. Neste exemplo, o evento `Spot Provisioning timeout` emitido para os nós de tarefa acionará a execução da função do Lambda. **Example Exemplo de função para responder ao evento `Spot Provisioning timeout`** ``` // Lambda code with Python 3.10 and handler is lambda_function.lambda_handler // Note: related IAM role requires permission to use Amazon EMR import json import boto3 import datetime from datetime import timezone SPOT_PROVISIONING_TIMEOUT_EXCEPTION_DETAIL_TYPE = "EMR Instance Fleet Resize" SPOT_PROVISIONING_TIMEOUT_EXCEPTION_EVENT_CODE = ( "Spot Provisioning timeout" ) CLIENT = boto3.client("emr", region_name="us-east-1") # checks if the incoming event is 'EMR Instance Fleet Resize' with eventCode 'Spot provisioning timeout' def is_spot_provisioning_timeout_event(event): if not event["detail"]: return False else: return ( event["detail-type"] == SPOT_PROVISIONING_TIMEOUT_EXCEPTION_DETAIL_TYPE and event["detail"]["eventCode"] == SPOT_PROVISIONING_TIMEOUT_EXCEPTION_EVENT_CODE ) # checks if the cluster is eligible for termination def is_cluster_eligible_for_termination(event, describeClusterResponse): # instanceFleetType could be CORE, MASTER OR TASK instanceFleetType = event["detail"]["instanceFleetType"] # Check if instance fleet receiving Spot provisioning timeout event is TASK if (instanceFleetType == "TASK"): return True else: return False # create a new cluster by choosing different InstanceType. def create_cluster(event): # instanceFleetType cloud be CORE, MASTER OR TASK instanceFleetType = event["detail"]["instanceFleetType"] # the following two lines assumes that the customer that created the cluster already knows which instance types they use in original request instanceTypesFromOriginalRequestMaster = "m5.xlarge" instanceTypesFromOriginalRequestCore = "m5.xlarge" # select new instance types to include in the new createCluster request instanceTypesForTask = [ "m5.xlarge", "m5.2xlarge", "m5.4xlarge", "m5.8xlarge", "m5.12xlarge" ] print("Starting to create cluster...") instances = { "InstanceFleets": [ { "InstanceFleetType":"MASTER", "TargetOnDemandCapacity":1, "TargetSpotCapacity":0, "InstanceTypeConfigs":[ { 'InstanceType': instanceTypesFromOriginalRequestMaster, "WeightedCapacity":1, } ] }, { "InstanceFleetType":"CORE", "TargetOnDemandCapacity":1, "TargetSpotCapacity":0, "InstanceTypeConfigs":[ { 'InstanceType': instanceTypesFromOriginalRequestCore, "WeightedCapacity":1, } ] }, { "InstanceFleetType":"TASK", "TargetOnDemandCapacity":0, "TargetSpotCapacity":100, "LaunchSpecifications":{}, "InstanceTypeConfigs":[ { 'InstanceType': instanceTypesForTask[0], "WeightedCapacity":1, }, { 'InstanceType': instanceTypesForTask[1], "WeightedCapacity":2, }, { 'InstanceType': instanceTypesForTask[2], "WeightedCapacity":4, }, { 'InstanceType': instanceTypesForTask[3], "WeightedCapacity":8, }, { 'InstanceType': instanceTypesForTask[4], "WeightedCapacity":12, } ], "ResizeSpecifications": { "SpotResizeSpecification": { "TimeoutDurationMinutes": 30 } } } ] } response = CLIENT.run_job_flow( Name="Test Cluster", Instances=instances, VisibleToAllUsers=True, JobFlowRole="EMR_EC2_DefaultRole", ServiceRole="EMR_DefaultRole", ReleaseLabel="emr-6.10.0", ) return response["JobFlowId"] # terminated the cluster using clusterId received in an event def terminate_cluster(event): print("Trying to terminate cluster, clusterId: " + event["detail"]["clusterId"]) response = CLIENT.terminate_job_flows(JobFlowIds=[event["detail"]["clusterId"]]) print(f"Terminate cluster response: {response}") def describe_cluster(event): response = CLIENT.describe_cluster(ClusterId=event["detail"]["clusterId"]) return response def lambda_handler(event, context): if is_spot_provisioning_timeout_event(event): print( "Received spot provisioning timeout event for instanceFleet, clusterId: " + event["detail"]["clusterId"] ) describeClusterResponse = describe_cluster(event) shouldTerminateCluster = is_cluster_eligible_for_termination( event, describeClusterResponse ) if shouldTerminateCluster: terminate_cluster(event) clusterId = create_cluster(event) print("Created a new cluster, clusterId: " + clusterId) else: print( "Cluster is not eligible for termination, clusterId: " + event["detail"]["clusterId"] ) else: print("Received event is not spot provisioning timeout event, skipping") ``` # Exibição das métricas para aplicações de cluster usando o Ganglia com Amazon EMR O Ganglia está disponível nas versões 4.2 e 6.15 do Amazon EMR. O Ganglia é um projeto de código aberto que é um sistema distribuído e escalável projetado para monitorar clusters e grades e, ao mesmo tempo, minimizar o impacto no desempenho. Quando você habilita o Ganglia no seu cluster, pode gerar relatórios e visualizar o desempenho do cluster como um todo, bem como inspecionar o desempenho de instâncias de nós individuais. O Ganglia também é configurado para analisar e visualizar as métricas do Hadoop e do Spark. Para obter mais informações, consulte [Ganglia](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-ganglia.html) no *Guia de lançamento do Amazon EMR*. # Registrando AWS chamadas da API EMR usando AWS CloudTrail AWS O EMR é integrado com [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), um serviço que fornece um registro das ações realizadas por um usuário, função ou um. AWS service (Serviço da AWS) CloudTrail captura todas as chamadas de API para AWS EMR como eventos. As chamadas capturadas incluem chamadas do console do AWS EMR e chamadas de código para as operações da API do AWS EMR. Usando as informações coletadas por CloudTrail, você pode determinar a solicitação que foi feita ao AWS EMR, o endereço IP do qual a solicitação foi feita, quando foi feita e detalhes adicionais. Cada entrada de log ou evento contém informações sobre quem gerou a solicitação. As informações de identidade ajudam a determinar o seguinte: + Se a solicitação foi feita com credenciais de usuário raiz ou credenciais de usuário. + Se a solicitação foi feita em nome de um usuário do Centro de Identidade do IAM. + Se a solicitação foi feita com credenciais de segurança temporárias de um perfil ou de um usuário federado. + Se a solicitação foi feita por outro AWS service (Serviço da AWS). CloudTrail está ativo Conta da AWS quando você cria a conta e você tem acesso automático ao **histórico de CloudTrail eventos**. O **histórico de CloudTrail eventos** fornece um registro visível, pesquisável, baixável e imutável dos últimos 90 dias de eventos de gerenciamento registrados em um. Região da AWS Para obter mais informações, consulte [Trabalhando com o histórico de CloudTrail eventos](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) no *Guia AWS CloudTrail do usuário*. Não há CloudTrail cobrança pela visualização do **histórico de eventos**. Para um registro contínuo dos eventos dos Conta da AWS últimos 90 dias, crie uma trilha ou um armazenamento de dados de eventos do [CloudTrailLake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html). **CloudTrail trilhas** Uma *trilha* permite CloudTrail entregar arquivos de log para um bucket do Amazon S3. Todas as trilhas criadas usando o Console de gerenciamento da AWS são multirregionais. Só é possível criar uma trilha de região única ou de várias regiões usando a AWS CLI. É recomendável criar uma trilha multirregional porque você captura todas as atividades Regiões da AWS em sua conta. Ao criar uma trilha de região única, é possível visualizar somente os eventos registrados na Região da AWS da trilha. Para obter mais informações sobre trilhas, consulte [Criar uma trilha para a Conta da AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) e [Criar uma trilha para uma organização](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) no *Guia do usuário do AWS CloudTrail *. Você pode entregar uma cópia dos seus eventos de gerenciamento contínuos para o bucket do Amazon S3 sem nenhum custo CloudTrail criando uma trilha. No entanto, há cobranças de armazenamento do Amazon S3. Para obter mais informações sobre CloudTrail preços, consulte [AWS CloudTrail Preços](https://aws.amazon.com/cloudtrail/pricing/). Para receber informações sobre a definição de preços do Amazon S3, consulte [Definição de preços do Amazon S3](https://aws.amazon.com/s3/pricing/). **CloudTrail Armazenamentos de dados de eventos em Lake** *CloudTrail O Lake* permite que você execute consultas baseadas em SQL em seus eventos. CloudTrail O Lake converte eventos existentes no formato JSON baseado em linhas para o formato [Apache](https://orc.apache.org/) ORC. O ORC é um formato colunar de armazenamento otimizado para recuperação rápida de dados. Os eventos são agregados em *armazenamentos de dados de eventos*, que são coleções imutáveis de eventos baseados nos critérios selecionados com a aplicação de [seletores de eventos avançados](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors). Os seletores que aplicados a um armazenamento de dados de eventos controlam quais eventos persistem e estão disponíveis para consulta. Para obter mais informações sobre o CloudTrail Lake, consulte [Trabalhando com o AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) no *Guia AWS CloudTrail do Usuário*. CloudTrail Os armazenamentos e consultas de dados de eventos em Lake incorrem em custos. Ao criar um armazenamento de dados de eventos, você escolhe a [opção de preço](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option) que deseja usar para ele. A opção de preço determina o custo para a ingestão e para o armazenamento de eventos, e o período de retenção padrão e máximo para o armazenamento de dados de eventos. Para obter mais informações sobre CloudTrail preços, consulte [AWS CloudTrail Preços](https://aws.amazon.com/cloudtrail/pricing/). ## AWS Eventos de dados do EMR em CloudTrail Os [Eventos de dados](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) fornecem informações sobre as operações de recursos realizadas em um recurso (por exemplo, leitura ou gravação em um objeto do Amazon S3). Também são conhecidas como operações de plano de dados. Os eventos de dados costumam ser atividades de alto volume. Por padrão, CloudTrail não registra eventos de dados. O **histórico de CloudTrail eventos** não registra eventos de dados. Há cobranças adicionais para eventos de dados. Para obter mais informações sobre CloudTrail preços, consulte [AWS CloudTrail Preços](https://aws.amazon.com/cloudtrail/pricing/). Você pode registrar eventos de dados para os tipos de recursos do AWS EMR usando o CloudTrail console ou as operações AWS CLI CloudTrail da API. Para saber mais sobre como registrar eventos de dados em log, consulte [Registrar eventos de dados com o Console de gerenciamento da AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) e [Registrar eventos de dados com a AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) no *Guia do usuário do AWS CloudTrail *. A tabela a seguir lista os tipos de recursos do AWS EMR para os quais você pode registrar eventos de dados. A coluna **Tipo de evento de dados (console)** mostra o valor a ser escolhido na lista **Tipo de evento de dados** no CloudTrail console. A coluna de **valor resources.type** mostra o `resources.type` valor, que você especificaria ao configurar seletores de eventos avançados usando o ou. AWS CLI CloudTrail APIs A CloudTrail coluna **Dados APIs registrados** em mostra as chamadas de API registradas CloudTrail para o tipo de recurso. Para obter mais informações sobre essas operações de API, consulte [Amazon EMR WAL (EMRWAL) CLI reference](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emrwalcli-ref.html). O Amazon EMR registra algumas operações da API de dados em operações HBase do sistema que você nunca chama diretamente. CloudTrail Essas operações não estão na referência da CLI do EMRWAL. | Tipo de evento de dados (console) | valor resources.type | Dados APIs registrados em CloudTrail | | --- | --- | --- | | Workspace de log de gravação antecipada do Amazon EMR | AWS::EMRWAL::Workspace | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/logging-using-cloudtrail.html) | É possível configurar seletores de eventos avançados para filtrar os campos `eventName`, `readOnly` e `resources.ARN` para registrar em log somente os eventos que são importantes para você. Para saber mais sobre esses campos, consulte [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) na *Referência de API do AWS CloudTrail *. ## AWS Eventos de gerenciamento de EMR em CloudTrail [Os eventos de gerenciamento](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) fornecem informações sobre as operações de gerenciamento que são realizadas nos recursos do seu Conta da AWS. Também são conhecidas como operações de ambiente de gerenciamento. Por padrão, CloudTrail registra eventos de gerenciamento. AWS O EMR registra todas as operações do plano de controle AWS do EMR como eventos de gerenciamento. [Para obter uma lista das operações do plano de controle do AWS EMR nas quais o AWS EMR se registra, CloudTrail consulte a Referência da API do AWS EMR.](https://docs.aws.amazon.com/emr/latest/APIReference/Welcome.html) ## AWS Exemplos de eventos do EMR Um evento representa uma única solicitação de qualquer fonte e inclui informações sobre a operação de API solicitada, a data e a hora da operação, os parâmetros da solicitação e assim por diante. CloudTrail os arquivos de log não são um rastreamento de pilha ordenado das chamadas públicas de API, portanto, os eventos não aparecem em nenhuma ordem específica. O exemplo a seguir mostra uma entrada de CloudTrail registro que demonstra a **RunJobFlow**ação. ``` { "Records": [ { "eventVersion":"1.01", "userIdentity":{ "type":"IAMUser", "principalId":"EX_PRINCIPAL_ID", "arn":"arn:aws:iam::123456789012:user/temporary-user-xx-7M", "accountId":"123456789012", "userName":"temporary-user-xx-7M" }, "eventTime":"2018-03-31T17:59:21Z", "eventSource":"elasticmapreduce.amazonaws.com", "eventName":"RunJobFlow", "awsRegion":"us-west-2", "sourceIPAddress":"192.0.2.1", "userAgent":"aws-sdk-java/unknown-version Linux/xx Java_HotSpot(TM)_64-Bit_Server_VM/xx", "requestParameters":{ "tags":[ { "value":"prod", "key":"domain" }, { "value":"us-west-2", "key":"realm" }, { "value":"VERIFICATION", "key":"executionType" } ], "instances":{ "slaveInstanceType":"m5.xlarge", "ec2KeyName":"emr-integtest", "instanceCount":1, "masterInstanceType":"m5.xlarge", "keepJobFlowAliveWhenNoSteps":true, "terminationProtected":false }, "visibleToAllUsers":false, "name":"MyCluster", "ReleaseLabel":"emr-5.16.0" }, "responseElements":{ "jobFlowId":"j-2WDJCGEG4E6AJ" }, "requestID":"2f482daf-b8fe-11e3-89e7-75a3d0e071c5", "eventID":"b348a38d-f744-4097-8b2a-e68c9b424698" }, ...additional entries ] } ``` Para obter informações sobre o conteúdo do CloudTrail registro, consulte [o conteúdo do CloudTrail registro](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) no *Guia AWS CloudTrail do usuário*. # Práticas recomendadas de observabilidade do EMR O EMR Observability engloba uma abordagem abrangente de monitoramento e gerenciamento para clusters do EMR. AWS A base está na Amazon CloudWatch como principal serviço de monitoramento, complementado pelo EMR Studio e por ferramentas de terceiros, como Prometheus e Grafana, para maior visibilidade. Neste documento, exploramos aspectos específicos da observabilidade do cluster: 1. *[Observabilidade do Spark](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Applications/Spark/observability.md)* (GitHub) — Com relação à interface de usuário do Spark, você tem três opções no Amazon EMR. 1. Solução de *[problemas do Spark](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Applications/Spark/troubleshooting.md)* (GitHub) — Resoluções para erros. 1. Monitoramento de *[cluster do EMR (GitHub) — Monitorando](https://aws.github.io/aws-emr-best-practices/docs/bestpractices/Observability/best_practices/)* o desempenho do cluster. 1. *[Solução de problemas do EMR](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Troubleshooting/Troubleshooting%20EMR.md)* (GitHub) — identifique, diagnostique e resolva problemas comuns do cluster EMR. 1. *[Otimização de custos](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Cost%20Optimizations/best_practices.md)* (GitHub) — Esta seção descreve as melhores práticas para executar cargas de trabalho econômicas. ## Ferramenta de otimização de performance para aplicações Apache Spark 1. AWS A ferramenta [EMR Advisor](https://github.com/aws-samples/aws-emr-advisor) analisa os registros de eventos do Spark para fornecer recomendações personalizadas para otimizar as configurações do cluster EMR, aprimorar o desempenho e reduzir custos. Ao aproveitar dados históricos, ela sugere tamanhos de executores e configurações de infraestrutura ideais, possibilitando a utilização mais eficiente dos recursos e a melhor performance geral do cluster. 1. A ferramenta [Amazon CodeGuru Profiler](https://github.com/amzn/amazon-codeguru-profiler-for-spark) ajuda os desenvolvedores a identificar gargalos de desempenho e ineficiências em seus aplicativos Spark coletando e analisando dados de tempo de execução. A ferramenta se integra perfeitamente aos aplicativos Spark existentes, exigindo configuração mínima, e fornece informações detalhadas por meio do AWS console sobre o uso da CPU, padrões de memória e pontos críticos de desempenho. # Use o ajuste de escala de cluster do Amazon EMR para se ajustar às mudanças nas workloads Você pode ajustar o número de instâncias do Amazon EC2 disponíveis para um cluster do Amazon EMR automaticamente ou manualmente, em resposta a workloads com demandas variáveis. Há duas opções para usar a escalabilidade automática. É possível habilitar o Ajuste de Escala Gerenciado do Amazon EMR ou criar uma política personalizada de ajuste de escala automático. A tabela a seguir descreve as diferenças entre as duas opções. | | Ajuste de Escala Gerenciado do Amazon EMR | Escalabilidade automática personalizada | | --- | --- | --- | | Políticas e regras de escalabilidade | Nenhuma política necessária. O Amazon EMR gerencia a ação de ajuste de escala automático avaliando continuamente as métricas de cluster e tomando decisões otimizadas de ajuste de escala. | É necessário definir e gerenciar as políticas e as regras de ajuste de escala automático, como as condições específicas que acionam ações de ajuste de escala, períodos de avaliação, períodos de esfriamento etc. | | Versões do Amazon EMR compatíveis | Amazon EMR versão 5.30.0 e posteriores (exceto Amazon EMR versão 6.0.0) | Amazon EMR 4.0.0 e versões posteriores | | Composição de cluster compatível | Grupos de instâncias ou frotas de instâncias | Somente grupos de instâncias | | Configuração de limites de escalabilidade | Os limites de escalabilidade são configurados para todo o cluster. | Os limites de escalabilidade só podem ser configurados para cada grupo de instâncias. | | Frequência da avaliação de métricas | A cada 5 a 10 segundos A avaliação mais frequente de métricas permite que o Amazon EMR tome decisões mais precisas relacionadas à ao ajuste de escala. | É possível definir os períodos de avaliação apenas em incrementos de cinco minutos. | | Aplicações compatíveis | Somente aplicativos do YARN são compatíveis, como Spark, Hadoop, Hive e Flink. A escalabilidade gerenciada do Amazon EMR não oferece suporte a aplicativos que não sejam baseados no YARN, como o Presto ou. HBase | Você pode escolher quais aplicativos são compatíveis ao definir as regras de escalabilidade automática. | ## Considerações + Um cluster do Amazon EMR sempre consiste em um ou três nós primários. Depois de configurar o cluster inicialmente, você só pode escalar os nós centrais e de tarefas. Você não pode escalar o número de nós primários para o cluster. + Para grupos de instâncias, as operações de reconfiguração e redimensionamento ocorrem consecutivamente e não simultaneamente. Se você iniciar uma reconfiguração enquanto um grupo de instâncias estiver sendo redimensionado, a reconfiguração será iniciada quando o grupo de instâncias concluir o redimensionamento em andamento. Por outro lado, se você iniciar uma operação de redimensionamento enquanto um grupo de instâncias está ocupado com a reconfiguração, o redimensionamento começará quando a reconfiguração estiver concluída. # Usar o ajuste de escala gerenciado no Amazon EMR **Importante** É altamente recomendável que você use a versão mais recente do Amazon EMR (Amazon EMR 7.12.0) para escalabilidade gerenciada. Em versões anteriores, você pode enfrentar falhas de aplicações intermitentes ou atrasos no ajuste de escala. O Amazon EMR resolveu esse problema nas versões 5.x: 5.30.2, 5.31.1, 5.32.1, 5.33.1 e posteriores, e nas versões 6.x: 6.1.1, 6.2.1, 6.3.1 e posteriores. Para ter mais informações sobre Regiões e disponibilidade de versões, consulte [Disponibilidade gerenciada de ajuste de escala](#emr-managed-scaling-availability). ## Visão geral do Com o Amazon EMR 5.30.0 e versões posteriores (exceto para o Amazon EMR 6.0.0), você pode habilitar o Ajuste de Escala Gerenciado do Amazon EMR. Com o ajuste de escala gerenciado, é possível aumentar ou diminuir automaticamente o número de instâncias ou unidades no cluster com base na workload. O Amazon EMR avalia continuamente as métricas do cluster para tomar decisões de ajuste de escala que otimizam os clusters em termos de custo e velocidade. O ajuste de escala gerenciado está disponível para clusters compostos por grupos de instâncias ou frotas de instâncias. ## Disponibilidade gerenciada de ajuste de escala + A seguir Regiões da AWS, a escalabilidade gerenciada do Amazon EMR está disponível com o Amazon EMR 6.14.0 e superior: + Ásia-Pacífico (Taipei) (ap-east-2) + Ásia-Pacífico (Melbourne) (ap-southeast-4) + Ásia-Pacífico (Malásia) (ap-southeast-5) + Ásia-Pacífico (Nova Zelândia) (ap-southeast-6) + Ásia-Pacífico (Tailândia) (ap-southeast-7) + Oeste do Canadá (Calgary) ca-west-1 + Europa (Espanha) (eu-south-2) + México (Centro) (mx-central-1) + A seguir Regiões da AWS, a escalabilidade gerenciada do Amazon EMR está disponível com o Amazon EMR 5.30.0 e 6.1.0 ou superior: + Leste dos EUA (Norte da Virgínia) (us-east-1) + Leste dos EUA (Ohio) (us-east-2) + Oeste dos EUA (Oregon) (us-west-2) + Oeste dos EUA (Norte da Califórnia) (us-west-1) + África (Cidade do Cabo) (af-south-1) + Ásia-Pacífico (Hong Kong) (ap-east-1) + Ásia-Pacífico (Mumbai) (ap-south-1) + Ásia-Pacífico (Hyderabad) (ap-south-2) + Ásia-Pacífico (Seul) (ap-northeast-2) + Ásia-Pacífico (Singapura) (ap-southeast-1) + Ásia-Pacífico (Sydney) (ap-southeast-2) + Ásia-Pacífico (Jacarta) (ap-southeast-3) + Ásia Pacific (Tóquio) (ap-northeast-1) + Ásia-Pacífico (Osaka) (ap-northeast-3) + Canadá (Central) (ca-central-1) + América do Sul (São Paulo) (sa-east-1) + Europa (Frankfurt) (eu-central-1) + Europa (Zurique) (eu-central-2) + Europa (Irlanda) (eu-west-1) + Europa (Londres) (eu-west-2) + UE (Milão) (eu-south-1) + Europa (Paris) (eu-west-3) + UE (Estocolmo) (eu-north-1) + Israel (Tel Aviv) (il-central-1) + Oriente Médio (EAU) (me-central-1) + China (Pequim) (cn-north-1) + China (Ningxia) (cn-northwest-1) + AWS GovCloud (Leste dos EUA) (us-gov-east-1) + AWS GovCloud (Oeste dos EUA) (us-gov-west-1) + O Ajuste de Escala Gerenciado do Amazon EMR só funciona com aplicações YARN, como Spark, Hadoop, Hive e Flink. Ele não oferece suporte a aplicativos que não sejam baseados no YARN, como o Presto e. HBase ## Parâmetros do ajuste de escala gerenciado É necessário configurar os parâmetros a seguir para ajuste de escala gerenciado. O limite só se aplica aos nós core e de tarefa. Não é possível escalar o nó primário após a configuração inicial. + **Mínimo** (`MinimumCapacityUnits`): o limite inferior da capacidade permitida do EC2 em um cluster. É medido por meio de núcleos ou instâncias da unidade central de processamento virtual (vCPU) para grupos de instâncias. É medido por meio de unidades para frotas de instâncias. + **Máximo** (`MaximumCapacityUnits`): o limite superior da capacidade permitida do EC2 em um cluster. É medido por meio de núcleos ou instâncias da unidade central de processamento virtual (vCPU) para grupos de instâncias. É medido por meio de unidades para frotas de instâncias. + **Limite sob demanda** (`MaximumOnDemandCapacityUnits`) (opcional): o limite superior da capacidade permitida do EC2 para o tipo de mercado sob demanda em um cluster. Se este parâmetro não for especificado, o valor `MaximumCapacityUnits` será usado como padrão. + Esse parâmetro é usado para dividir a alocação de capacidade entre instâncias sob demanda e spot. Por exemplo, se você definir o parâmetro mínimo como duas instâncias, o parâmetro máximo como cem instâncias e o limite sob demanda como dez instâncias, o Ajuste de Escala Gerenciado do Amazon EMR escalará até dez instâncias sob demanda e alocará a capacidade restante para instâncias spot. Para obter mais informações, consulte [Cenários de alocação de nós](managed-scaling-allocation-strategy.md#node-allocation-scenarios). + **Máximo de nós centrais** (`MaximumCoreCapacityUnits`) (opcional): o limite superior da capacidade permitida do EC2 para o tipo de nó central em um cluster. Se este parâmetro não for especificado, o valor `MaximumCapacityUnits` será usado como padrão. + Esse parâmetro é usado para dividir a alocação de capacidade entre nós de centrais e de tarefa. Por exemplo, se você definir o parâmetro mínimo como duas instâncias, o máximo como cem instâncias e o nó central máximo como 17 instâncias, o Ajuste de Escala Gerenciado do Amazon EMR escalará até 17 nós principais e alocará as 83 instâncias restantes aos nós de tarefa. Para obter mais informações, consulte [Cenários de alocação de nós](managed-scaling-allocation-strategy.md#node-allocation-scenarios). Para obter mais informações sobre parâmetros de ajuste de escala gerenciado, consulte [https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html). ## Considerações sobre Ajuste de Escala Gerenciado do Amazon EMR + A escalabilidade gerenciada é suportada em versões limitadas Regiões da AWS e do Amazon EMR. Para obter mais informações, consulte [Disponibilidade gerenciada de ajuste de escala](#emr-managed-scaling-availability). + Você deve configurar os parâmetros necessários para o Ajuste de Escala Gerenciado do Amazon EMR. Para obter mais informações, consulte [Parâmetros do ajuste de escala gerenciado](#emr-managed-scaling-parameters). + Para usar o ajuste de escala gerenciado, o processo coletor de métricas deve ser capaz de se conectar ao endpoint público da API para o ajuste de escala gerenciado no API Gateway. Se você usar um nome DNS privado com Amazon Virtual Private Cloud, o escalonamento gerenciado não funcionará corretamente. Para garantir que o ajuste de escala gerenciado funcione, é recomendável executar uma das seguintes ações: + Remova o endpoint da VPC de interface do API Gateway da Amazon VPC. + Siga as instruções em [Por que recebo um erro HTTP 403 Proibido ao me conectar ao meu API Gateway a APIs partir de uma VPC](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-vpc-connections/)? para desativar a configuração do nome DNS privado. + Em vez disso, inicie o cluster em sua sub-rede privada. Para obter mais informações, consulte o tópico em [Sub-redes privadas](emr-clusters-in-a-vpc.md#emr-vpc-private-subnet). + Se os trabalhos do YARN ficarem intermitentemente lentos durante a redução da escala verticalmente e os logs do YARN Resource Manager mostrarem que a maioria dos nós foram listados como negados durante o período, você poderá ajustar o limite do tempo limite de desativação. Reduza `spark.blacklist.decommissioning.timeout` de uma hora para um minuto para disponibilizar o nó para que outros contêineres pendentes continuem o processamento de tarefa. Defina também `YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs` como um valor maior para garantir que o Amazon EMR não force o término do nó enquanto a “Tarefa do Spark” mais longa ainda estiver em execução no nó. O padrão atual é 60 minutos, o que significa que o YARN força o término do contêiner após 60 minutos, quando o nó entra no estado de desativação. O exemplo a seguir da linha de log do YARN Resource Manager mostra os nós adicionados ao estado de desativação: ``` 2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: [] ``` Veja mais [detalhes sobre como o Amazon EMR se integra à lista de negação do YARN durante o desativação de nós](https://aws.amazon.com/blogs/big-data/spark-enhancements-for-elasticity-and-resiliency-on-amazon-emr/), [casos em que nós no Amazon EMR podem ser listados como negados](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-troubleshoot-error-resource-3.html) e [como configurar o comportamento de desativação de nós do Spark](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-decommissioning). + Para workloads do Spark, desabilitar o Spark Dynamic Resource Allocator (DRA) alterando a propriedade Spark **spark.dynamicAllocation.enabled** para `FALSE` pode causar problemas de ajuste de escala gerenciado, em que os clusters podem aumentar a escala verticalmente mais do que o necessário para suas workloads (até a computação máxima). Ao usar o ajuste de escala gerenciado para essas workloads, recomendamos que você mantenha o Spark DRA habilitado, que é o estado padrão dessa propriedade. + A utilização excessiva dos volumes do EBS pode causar problemas de ajuste de escala gerenciado. É recomendável manter o volume do EBS abaixo de 90% de utilização. Para obter mais informações, consulte [Opções e comportamento de armazenamento de instâncias no Amazon EMR](emr-plan-storage.md). + CloudWatch As métricas da Amazon são essenciais para a operação da escalabilidade gerenciada do Amazon EMR. Recomendamos que você monitore de perto CloudWatch as métricas da Amazon para garantir que os dados não estejam ausentes. Para obter mais informações sobre como você pode configurar CloudWatch alarmes para detectar métricas ausentes, consulte [Usando CloudWatch alarmes da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). + As operações de ajuste de escala gerenciado nos clusters das versões 5.30.0 e 5.30.1 sem o Presto instalado podem causar falhas na aplicação ou fazer com que um grupo de instâncias ou uma frota de instâncias uniforme permaneça no estado `ARRESTED`, sobretudo quando uma operação de redução da escala verticalmente logo é seguida por uma operação de aumento da escala verticalmente. Como solução alternativa, escolha o Presto como uma aplicação a ser instalada ao criar um cluster com as versões 5.30.0 e 5.30.1 do Amazon EMR, mesmo que o trabalho não exija o Presto. + Ao definir o nó central máximo e o limite sob demanda para o Ajuste de Escala Gerenciado do Amazon EMR, leve em consideração as diferenças entre grupos de instâncias e frotas de instâncias. Cada grupo de instâncias consiste no mesmo tipo de instância e na mesma opção de compra para instâncias: sob demanda ou spot. Para cada frota de instâncias, você pode especificar até cinco tipos de instâncias, que podem ser configurados como instâncias sob demanda e spot. Para obter mais informações, consulte [Create a cluster with instance fleets or uniform instance groups](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-group-configuration.html), [Instance fleet options](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html#emr-instance-fleet-options) e [Cenários de alocação de nós](managed-scaling-allocation-strategy.md#node-allocation-scenarios). + Com o Amazon EMR 5.30.0 e versões posteriores, ao remover a regra de saída **Permitir tudo** padrão para 0.0.0.0/ para o grupo de segurança principal, você deverá adicionar uma regra que permita a conectividade TCP de saída ao grupo de segurança para acesso ao serviço na porta 9443. O grupo de segurança para acesso ao serviço também deve permitir tráfego TCP de entrada na porta 9443 do grupo de segurança principal. Para obter mais informações sobre como configurar grupos de segurança, consulte [Amazon EMR-managed security group for the primary instance (private subnets)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-master-private). + Você pode usar AWS CloudFormation para configurar a escalabilidade gerenciada do Amazon EMR. Consulte mais informações em [AWS::EMR::Cluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticmapreduce-cluster.html) no *Guia de Usuário AWS CloudFormation *. + Caso esteja usando nós spot, considere usar rótulos de nós para evitar que o Amazon EMR remova processos de aplicações quando o Amazon EMR remover nós spot. Para obter mais informações sobre rótulos de nós, consulte [Task nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html#emr-plan-task). + Por padrão, a rotulagem de nós não é compatível com as versões 6.15 ou inferiores do Amazon EMR. Para obter mais informações, consulte [Understand node types: primary, core, and task nodes.](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html) + Caso esteja usando as versões 6.15 ou inferiores do Amazon EMR, só poderá atribuir rótulos de nós por tipo de nó, como nós centrais e de tarefa. No entanto, se estiver usando o Amazon EMR versão 7.0 ou superior, poderá configurar rótulos de nós por tipo de nó e tipo de mercado, como sob demanda e spot. + Se a demanda do processo da aplicação aumentar e a demanda do executor diminuir ao restringir o processo da aplicação aos nós centrais, você poderá adicionar novamente os nós centrais e remover os nós de tarefa na mesma operação de redimensionamento. Para obter mais informações, consulte [Understanding node allocation strategy and scenarios](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html). + O Amazon EMR não rotula os nós de tarefas, então você não pode definir as propriedades do YARN para restringir os processos da aplicação somente para nós de tarefas. No entanto, caso queira usar tipos de mercado como rótulos de nós, poderá usar os rótulos `ON_DEMAND` ou `SPOT` para o posicionamento do processo da aplicação. Não recomendamos usar nós spot nos processos primários da aplicação. + Ao usar rótulos de nós, o total de unidades em execução no cluster pode exceder temporariamente a computação máxima definida na sua política de ajuste de escala gerenciado, enquanto o Amazon EMR desativa algumas de suas instâncias. O total de unidades solicitadas sempre permanecerá igual ou abaixo da computação máxima da política. + O ajuste de escala gerenciado é compatível apenas com os rótulos dos nós `ON_DEMAND` e `SPOT` ou `CORE` e `TASK`. Não há suporte para rótulos de nós personalizados. + O Amazon EMR cria rótulos de nós ao criar o cluster e provisionar recursos. O Amazon EMR não oferece suporte à adição de rótulos de nós ao reconfigurar o cluster. Você também não pode modificar os rótulos dos nós ao configurar o ajuste de escala gerenciado após executar o cluster. + O ajuste de escala gerenciado dimensiona os nós centrais e de tarefas de forma independente, com base no processo da aplicação e na demanda do executor. Para evitar problemas de perda de dados do HDFS durante a redução vertical da escala central, siga a prática padrão para os nós centrais. Para saber mais sobre as práticas recomendadas para nós centrais e replicação do HDFS, consulte [Considerations and best practices](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-considerations.html). + Você não pode colocar o processo da aplicação e os executores somente no nó `core` ou `ON_DEMAND`. Caso queira adicionar o processo da aplicação e os executores em um dos nós, não use a configuração `yarn.node-labels.am.default-node-label-expression`. Por exemplo, para colocar o processo da aplicação e os executores em nós `ON_DEMAND`, defina a computação máxima como a máxima no nó `ON_DEMAND`. Remova também a configuração `yarn.node-labels.am.default-node-label-expression`. Para adicionar o processo da aplicação e os executores nos nós `core`, remova a configuração `yarn.node-labels.am.default-node-label-expression`. + Ao usar o ajuste de escala gerenciado com rótulos de nós, defina a propriedade `yarn.scheduler.capacity.maximum-am-resource-percent: 1` se planeja executar várias aplicações em paralelo. Isso garante que os processos da aplicação utilizem totalmente os nós `CORE` ou `ON_DEMAND` disponíveis. + Caso use ajuste de escala gerenciado com rótulos de nós, defina a propriedade `yarn.resourcemanager.decommissioning.timeout` para um valor maior do que a aplicação de execução mais longa no cluster. Isso reduz a chance de o ajuste de escala gerenciado do Amazon EMR precisar reprogramar suas aplicações para desativar nós `CORE` ou `ON_DEMAND`. + Para reduzir o risco de falhas na aplicação devido à perda de dados de shuffle, o Amazon EMR coleta métricas do cluster para determinar os nós que têm dados aleatórios transitórios existentes do estágio atual e do anterior. Em casos raros, as métricas podem continuar relatando dados obsoletos de aplicações que já foram concluídas ou encerradas. Isso pode afetar a redução oportuna da escala vertical das instâncias no seu cluster. Para clusters com grandes quantidades de dados de shuffle, considere usar as versões 6.13 e posteriores do EMR. ## Histórico de recursos Esta tabela lista as atualizações na funcionalidade de ajuste de escala gerenciado do Amazon EMR. | Data de lançamento | Recurso | Versões do Amazon EMR | | --- | --- | --- | | 20 de novembro de 2024 | O ajuste de escala gerenciado está disponível nas regiões il-central-1 Israel (Tel Aviv), me-central-1 Oriente Médio (Emirados Árabes Unidos) e ap-northeast-3 Ásia-Pacífico (Osaka). | 5.30.0, 6.1.0 e superiores | | 15 de novembro de 2024 | O ajuste de escala gerenciado está disponível na região eu-central-2 Europa (Zurique). | 5.30.0, 6.1.0 e superiores | | 20 de agosto de 2024 | Os rótulos de nós já estão disponíveis no ajuste de escala gerenciado, para que você possa rotular instâncias com base no tipo de mercado ou de nó para melhorar o ajuste de escala automático. | Versão 7.2.0 e posterior | | 31 de março de 2024 | O ajuste de escala gerenciado está disponível na região ap-south-2 Ásia-Pacífico (Hyderabad). | 6.14.0 e posterior | | 13 de fevereiro de 2024 | O ajuste de escala gerenciado está disponível na região eu-south-2 Europa (Espanha). | 6.14.0 e posterior | | 10 de outubro de 2023 | Ajuste de Escala Gerenciado disponível na região ap-southeast-3 Ásia-Pacífico (Jacarta). | 6.14.0 e posterior | | 28 de julho de 2023 | O ajuste de escala gerenciado foi aprimorado para alternar para um grupo de instâncias de tarefa diferente ao aumentar a escala verticalmente quando o Amazon EMR sofre um atraso ao aumentar a escala verticalmente com o grupo de instâncias atual. | 5.34.0 e posteriores, 6.4.0 e posteriores | | 16 de junho de 2023 | O ajuste de escala gerenciado foi aprimorado para reconhecer os nós que executam a aplicação principal, de forma que esses nós não sejam reduzidos. Para obter mais informações, consulte [Noções básicas da estratégia e dos cenários de alocação de nós do Amazon EMR](managed-scaling-allocation-strategy.md). | 5.34.0 e posteriores, 6.4.0 e posteriores | | 21 de março de 2022 | Foi adicionado o reconhecimento de dados de shuffle do Spark usado ao reduzir a escala verticalmente de clusters. Para clusters do Amazon EMR com o Apache Spark e o atributo de ajuste de escala gerenciado habilitado, o Amazon EMR monitora continuamente os executores do Spark e os locais intermediários de dados de shuffle. Com essas informações, o Amazon EMR reduz a escala verticalmente apenas das instâncias subutilizadas que não contêm dados de shuffle usados ativamente. Isso evita o recálculo de dados de shuffle perdidos, ajudando a reduzir custos e melhorar a performance do trabalho. Para obter mais informações, consulte o [Spark Programming Guide](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). | 5.34.0 e posteriores, 6.4.0 e posteriores | # Configuração do ajuste de escala gerenciado para o Amazon EMR As seções a seguir explicam como iniciar um cluster do EMR que usa escalabilidade gerenciada com o Console de gerenciamento da AWS AWS SDK para Java, o ou o. AWS Command Line Interface **Topics** + [ ## Use o Console de gerenciamento da AWS para configurar o escalonamento gerenciado ](#managed-scaling-console) + [ ## Use o AWS CLI para configurar o escalonamento gerenciado ](#managed-scaling-cli) + [ ## Use AWS SDK para Java para configurar o escalonamento gerenciado ](#managed-scaling-sdk) ## Use o Console de gerenciamento da AWS para configurar o escalonamento gerenciado Você pode usar o console do Amazon EMR para configurar o ajuste de escala gerenciado ao criar um cluster ou para alterar uma política de ajuste de escala gerenciado para um cluster em execução. ------ #### [ Console ] **Para configurar o ajuste de escala gerenciado ao criar um cluster usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters** e depois **Criar cluster**. 1. Escolha uma versão **emr-5.30.0** ou posterior do Amazon EMR, exceto a versão **emr-6.0.0**. 1. Em **Opção de ajuste de escala e provisionamento de clusters**, escolha **Usar ajuste de escala gerenciado pelo EMR**. Especifique o número **mínimo** e **máximo** de instâncias, o **máximo de instâncias do nó central** e o **máximo de instâncias sob demanda**. 1. Escolha qualquer outra opção que se aplique ao cluster. 1. Para iniciar o cluster, escolha **Criar cluster**. **Para configurar o ajuste de escala gerenciado em um cluster existente usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e selecione o cluster que você deseja atualizar. 1. Na guia **Instâncias** da página de detalhes do cluster, encontre a seção **Configurações do grupo de instâncias**. Na seção **Editar ajuste de escala do cluster**, especifique novos valores para os números **Mínimo** e **Máximo** de instâncias e o limite **Sob demanda**. ------ ## Use o AWS CLI para configurar o escalonamento gerenciado Você pode usar AWS CLI comandos do Amazon EMR para configurar a escalabilidade gerenciada ao criar um cluster. Você pode usar uma sintaxe abreviada, especificando a configuração do JSON nas linhas dos comandos relevantes, ou pode fazer referência a um arquivo que contém a configuração do JSON. Também é possível aplicar uma política de escalabilidade gerenciada a um cluster existente e remover uma política de escalabilidade gerenciada que foi aplicada anteriormente. Além disso, você pode recuperar os detalhes da configuração de uma política de escalabilidade de um cluster em execução. **Habilitar a escalabilidade gerenciada durante a execução do cluster** É possível habilitar a escalabilidade gerenciada durante a execução do cluster, conforme demonstra o exemplo a seguir. ``` aws emr create-cluster \ --service-role EMR_DefaultRole \ --release-label emr-7.12.0 \ --name EMR_Managed_Scaling_Enabled_Cluster \ --applications Name=Spark Name=Hbase \ --ec2-attributes KeyName=keyName,InstanceProfile=EMR_EC2_DefaultRole \ --instance-groups InstanceType=m4.xlarge,InstanceGroupType=MASTER,InstanceCount=1 InstanceType=m4.xlarge,InstanceGroupType=CORE,InstanceCount=2 \ --region us-east-1 \ --managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=2,MaximumCapacityUnits=4,UnitType=Instances}' ``` Você também pode especificar uma configuração de política gerenciada usando a managed-scaling-policy opção -- ao usar`create-cluster`. **Aplicar uma política de escalabilidade gerenciada a um cluster existente** É possível aplicar uma política de escalabilidade gerenciada a um cluster existente, conforme demonstra o exemplo a seguir. ``` aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=1, MaximumCapacityUnits=10, MaximumOnDemandCapacityUnits=10, UnitType=Instances}' ``` Também é possível aplicar uma política de escalabilidade gerenciada a um cluster existente usando o comando `aws emr put-managed-scaling-policy`. O exemplo a seguir usa uma referência a um arquivo JSON `managedscaleconfig.json`, que especifica a configuração da política de escalabilidade gerenciada. ``` aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy file://./managedscaleconfig.json ``` O exemplo a seguir mostra o conteúdo do arquivo `managedscaleconfig.json`, que define a política de escalabilidade gerenciada. ``` { "ComputeLimits": { "UnitType": "Instances", "MinimumCapacityUnits": 1, "MaximumCapacityUnits": 10, "MaximumOnDemandCapacityUnits": 10 } } ``` **Recuperar uma configuração de política de escalabilidade gerenciada** O comando `GetManagedScalingPolicy` recupera a configuração da política. Por exemplo, o comando a seguir recupera a configuração de um cluster com o ID `j-123456`. ``` aws emr get-managed-scaling-policy --cluster-id j-123456 ``` Este comando gera o seguinte exemplo de saída. ``` 1. { 2. "ManagedScalingPolicy": { 3. "ComputeLimits": { 4. "MinimumCapacityUnits": 1, 5. "MaximumOnDemandCapacityUnits": 10, 6. "MaximumCapacityUnits": 10, 7. "UnitType": "Instances" 8. } 9. } 10. } ``` Para obter mais informações sobre o uso dos comandos do Amazon EMR no AWS CLI, consulte. [https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr) **Remover a política de escalabilidade gerenciada** O comando `RemoveManagedScalingPolicy` remove a configuração da política. Por exemplo, o comando a seguir remove a configuração de um cluster com o ID `j-123456`. ``` aws emr remove-managed-scaling-policy --cluster-id j-123456 ``` ## Use AWS SDK para Java para configurar o escalonamento gerenciado O trecho do programa a seguir mostra como configurar a escalabilidade gerenciada usando o AWS SDK para Java: ``` package com.amazonaws.emr.sample; import java.util.ArrayList; import java.util.List; import com.amazonaws.AmazonClientException; import com.amazonaws.auth.AWSCredentials; import com.amazonaws.auth.AWSStaticCredentialsProvider; import com.amazonaws.auth.profile.ProfileCredentialsProvider; import com.amazonaws.regions.Regions; import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduce; import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduceClientBuilder; import com.amazonaws.services.elasticmapreduce.model.Application; import com.amazonaws.services.elasticmapreduce.model.ComputeLimits; import com.amazonaws.services.elasticmapreduce.model.ComputeLimitsUnitType; import com.amazonaws.services.elasticmapreduce.model.InstanceGroupConfig; import com.amazonaws.services.elasticmapreduce.model.JobFlowInstancesConfig; import com.amazonaws.services.elasticmapreduce.model.ManagedScalingPolicy; import com.amazonaws.services.elasticmapreduce.model.RunJobFlowRequest; import com.amazonaws.services.elasticmapreduce.model.RunJobFlowResult; public class CreateClusterWithManagedScalingWithIG { public static void main(String[] args) { AWSCredentials credentialsFromProfile = getCreadentials("AWS-Profile-Name-Here"); /** * Create an Amazon EMR client with the credentials and region specified in order to create the cluster */ AmazonElasticMapReduce emr = AmazonElasticMapReduceClientBuilder.standard() .withCredentials(new AWSStaticCredentialsProvider(credentialsFromProfile)) .withRegion(Regions.US_EAST_1) .build(); /** * Create Instance Groups - Primary, Core, Task */ InstanceGroupConfig instanceGroupConfigMaster = new InstanceGroupConfig() .withInstanceCount(1) .withInstanceRole("MASTER") .withInstanceType("m4.large") .withMarket("ON_DEMAND"); InstanceGroupConfig instanceGroupConfigCore = new InstanceGroupConfig() .withInstanceCount(4) .withInstanceRole("CORE") .withInstanceType("m4.large") .withMarket("ON_DEMAND"); InstanceGroupConfig instanceGroupConfigTask = new InstanceGroupConfig() .withInstanceCount(5) .withInstanceRole("TASK") .withInstanceType("m4.large") .withMarket("ON_DEMAND"); List igConfigs = new ArrayList<>(); igConfigs.add(instanceGroupConfigMaster); igConfigs.add(instanceGroupConfigCore); igConfigs.add(instanceGroupConfigTask); /** * specify applications to be installed and configured when Amazon EMR creates the cluster */ Application hive = new Application().withName("Hive"); Application spark = new Application().withName("Spark"); Application ganglia = new Application().withName("Ganglia"); Application zeppelin = new Application().withName("Zeppelin"); /** * Managed Scaling Configuration - * Using UnitType=Instances for clusters composed of instance groups * * Other options are: * UnitType = VCPU ( for clusters composed of instance groups) * UnitType = InstanceFleetUnits ( for clusters composed of instance fleets) **/ ComputeLimits computeLimits = new ComputeLimits() .withMinimumCapacityUnits(1) .withMaximumCapacityUnits(20) .withUnitType(ComputeLimitsUnitType.Instances); ManagedScalingPolicy managedScalingPolicy = new ManagedScalingPolicy(); managedScalingPolicy.setComputeLimits(computeLimits); // create the cluster with a managed scaling policy RunJobFlowRequest request = new RunJobFlowRequest() .withName("EMR_Managed_Scaling_TestCluster") .withReleaseLabel("emr-7.12.0") // Specifies the version label for the Amazon EMR release; we recommend the latest release .withApplications(hive,spark,ganglia,zeppelin) .withLogUri("s3://path/to/my/emr/logs") // A URI in S3 for log files is required when debugging is enabled. .withServiceRole("EMR_DefaultRole") // If you use a custom IAM service role, replace the default role with the custom role. .withJobFlowRole("EMR_EC2_DefaultRole") // If you use a custom Amazon EMR role for EC2 instance profile, replace the default role with the custom Amazon EMR role. .withInstances(new JobFlowInstancesConfig().withInstanceGroups(igConfigs) .withEc2SubnetId("subnet-123456789012345") .withEc2KeyName("my-ec2-key-name") .withKeepJobFlowAliveWhenNoSteps(true)) .withManagedScalingPolicy(managedScalingPolicy); RunJobFlowResult result = emr.runJobFlow(request); System.out.println("The cluster ID is " + result.toString()); } public static AWSCredentials getCredentials(String profileName) { // specifies any named profile in .aws/credentials as the credentials provider try { return new ProfileCredentialsProvider("AWS-Profile-Name-Here") .getCredentials(); } catch (Exception e) { throw new AmazonClientException( "Cannot load credentials from .aws/credentials file. " + "Make sure that the credentials file exists and that the profile name is defined within it.", e); } } public CreateClusterWithManagedScalingWithIG() { } } ``` # Ajuste de escala avançado para o Amazon EMR Começando com o Amazon EMR no EC2 versão 7.0, é possível utilizar o Ajuste de escala avançado para controlar o uso de recursos do cluster. O Advanced Scaling introduz uma escala de utilização-desempenho para ajustar a utilização dos recursos e o nível de desempenho de acordo com as necessidades da sua empresa. O valor que você define determina se seu cluster é mais voltado para a conservação de recursos ou para a escalabilidade para lidar com cargas de trabalho sensíveis service-level-agreement (SLA), onde a conclusão rápida é essencial. Quando o valor do ajuste de escala é ajustado, o ajuste de escala gerenciado interpreta sua intenção e escala de maneira inteligente para otimizar os recursos. Para obter mais informações sobre o Ajuste de escala gerenciado, consulte [Configurar o Ajuste de escala gerenciado para o Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-configure.html). ## Configurações avançadas de dimensionamento O valor que você definiu para o Ajuste de escala avançado otimiza o cluster de acordo com seus requisitos. Os valores variam de **1** a **100**. Os valores possíveis são **1**, **25**, **50**, **75** e **100**. Se você definir o índice para valores diferentes, isso resultará em um erro de validação. Valores de ajuste de escala são mapeados para estratégias de utilização de recursos. A lista a seguir define várias delas: + **Utilização otimizada [1]**: essa configuração evita o provisionamento excessivo de recursos. Use um valor baixo quando quiser manter os custos baixos e priorizar a utilização eficiente dos recursos. Isso faz com que o cluster aumente a escala verticalmente de maneira menos agressiva. Isso funciona bem para o caso de uso em que costumam ocorrer picos de workload e você não quer que os recursos aumentem muito rapidamente. + **Equilibrada [50]**: equilibra a utilização de recursos e a performance dos trabalhos. Essa configuração é adequada para workloads estáveis em que a maioria dos estágios tem um runtime estável. Também é adequado para workloads com uma combinação de estágios de curta e longa duração. Recomendamos começar com essa configuração se você não tem certeza de qual escolher. + **Otimizad para performance [100]**: essa estratégia prioriza a performance. O cluster se expande de maneira agressiva para garantir que os trabalhos sejam concluídos rapidamente e atendam às metas de performance. O desempenho otimizado é adequado para cargas de trabalho sensíveis service-level-agreement (SLA), nas quais o tempo de execução rápido é essencial. **nota** Os valores intermediários disponíveis fornecem um meio termo entre essas estratégias para ajustar o comportamento de Ajuste de escala avançado do cluster. ## Benefícios do escalonamento avançado Como há variabilidade no ambiente e nos requisitos, como alterações nos volumes de dados, ajustes nas metas de custos e implementações de SLAs, o ajuste de escala do cluster pode ajudar você a ajustar a configuração do cluster para atingir os seus objetivos. Os benefícios importantes incluem: + **Controle granular aprimorado**: a introdução da configuração de performance de utilização permite ajustar facilmente o comportamento de ajuste de escala do cluster de acordo com os seus requisitos. Você pode aumentar a escala verticalmente para atender à demanda por recursos de computação ou reduzir a escala verticalmente para economizar recursos com base em seus padrões de uso. + **Otimização de custos aprimorada**: você pode escolher um valor de utilização baixo, conforme os requisitos, para atender com mais facilidade aos seus objetivos de custo. ## Conceitos básicos sobre otimização **Instalação e configuração** Use estas etapas para definir o índice de performance e otimizar sua estratégia de ajuste de escala. 1. O comando a seguir atualiza um cluster existente com a estratégia de ajuste de escala `[1]` otimizada para utilização: ``` aws emr put-managed-scaling-policy --cluster-id 'cluster-id' \ --managed-scaling-policy '{ "ComputeLimits": { "UnitType": "Instances", "MinimumCapacityUnits": 1, "MaximumCapacityUnits": 2, "MaximumOnDemandCapacityUnits": 2, "MaximumCoreCapacityUnits": 2 }, "ScalingStrategy": "ADVANCED", "UtilizationPerformanceIndex": "1" }' \ --region "region-name" ``` Os atributos `ScalingStrategy` e `UtilizationPerformanceIndex` são novos e relevantes para a otimização de ajuste de escala. Você pode selecionar diferentes estratégias de ajuste de escala definindo valores correspondentes (1, 25, 50, 75 e 100) para o atributo `UtilizationPerformanceIndex` na política de ajuste de escala gerenciada. 1. Para reverter para a estratégia padrão de ajuste de escala gerenciado, execute o comando `put-managed-scaling-policy` sem incluir os atributos `ScalingStrategy` e `UtilizationPerformanceIndex`. (Isso é opcional.) Este exemplo mostra como fazer isso: ``` aws emr put-managed-scaling-policy \ --cluster-id 'cluster-id' \ --managed-scaling-policy '{"ComputeLimits":{"UnitType":"Instances","MinimumCapacityUnits":1,"MaximumCapacityUnits":2,"MaximumOnDemandCapacityUnits":2,"MaximumCoreCapacityUnits":2}}' \ --region "region-name" ``` **Usar métricas de monitoramento para rastrear a utilização do cluster** A partir da versão 7.3.0 do EMR, o Amazon EMR publica quatro novas métricas relacionadas à memória e à CPU virtual. Você pode usá-las para medir a utilização do cluster em todas as estratégias de ajuste de escala. Essas métricas estão disponíveis para qualquer caso de uso, mas você pode usar os detalhes fornecidos aqui para monitorar o Ajuste de escala avançado. As métricas úteis disponíveis incluem: + **YarnContainersUsedMemoryGBSeconds**— Quantidade de memória consumida por aplicativos gerenciados pelo YARN. + **YarnContainersTotalMemoryGBSeconds**— Capacidade total de memória alocada ao YARN dentro do cluster. + **YarnNodesUsedVCPUSeconds**— Total de segundos de VCPU para cada aplicativo gerenciado pelo YARN. + **YarnNodesTotalVCPUSeconds**— Total agregado de segundos de VCPU para memória consumida, incluindo a janela de tempo em que o fio não está pronto. Você pode analisar métricas de recursos usando o Amazon CloudWatch Logs Insights. Os recursos incluem uma linguagem de consulta específica que ajuda a extrair métricas específicas para uso e ajuste de escala de recursos. A consulta a seguir, que você pode executar no Amazon CloudWatch console, usa matemática métrica para calcular a utilização média da memória (e1) dividindo a soma contínua da memória consumida (e2) pela soma da memória total (e3): ``` { "metrics": [ [ { "expression": "e2/e3", "label": "Average Mem Utilization", "id": "e1", "yAxis": "right" } ], [ { "expression": "RUNNING_SUM(m1)", "label": "RunningTotal-YarnContainersUsedMemoryGBSeconds", "id": "e2", "visible": false } ], [ { "expression": "RUNNING_SUM(m2)", "label": "RunningTotal-YarnContainersTotalMemoryGBSeconds", "id": "e3", "visible": false } ], [ "AWS_EMR_ManagedResize", "YarnContainersUsedMemoryGBSeconds", "ACCOUNT_ID", "793684541905", "COMPONENT", "ManagerService", "JOB_FLOW_ID", "cluster-id", { "id": "m1", "label": "YarnContainersUsedMemoryGBSeconds" } ], [ ".", "YarnContainersTotalMemoryGBSeconds", ".", ".", ".", ".", ".", ".", { "id": "m2", "label": "YarnContainersTotalMemoryGBSeconds" } ] ], "view": "timeSeries", "stacked": false, "region": "region", "period": 60, "stat": "Sum", "title": "Memory Utilization" } ``` Para consultar registros, você pode selecionar CloudWatch no AWS console. Para obter mais informações sobre como escrever consultas para CloudWatch, consulte [Análise de dados de log com o CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) no Guia do usuário do Amazon CloudWatch Logs. A imagem a seguir mostra essas métricas para um cluster de exemplo: ![\[Gráfico mostrando estatísticas de utilização.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/scaling_graph_EMR.png) ## Considerações e limitações + A eficácia das estratégias de ajuste de escala pode variar dependendo das características exclusivas da workload e da configuração do cluster. Recomendamos que você experimente a configuração de ajuste de escala para determinar um valor de índice ideal para o seu caso de uso. + O Ajuste de escala automático do Amazon EMR é particularmente adequado para workloads em lotes. Para workloads de SQL/data warehouse e streaming, recomendamos usar a estratégia padrão de ajuste de escala gerenciado para obter performance ideal. + O Amazon EMR Advanced Scaling não é suportado quando as configurações de rótulos de nós estão habilitadas no cluster. Se as configurações Advanced Scaling e Node Label estiverem habilitadas juntas em um cluster, o comportamento de escalabilidade seria como se a configuração padrão de escalabilidade gerenciada estivesse ativada. + A estratégia de ajuste de escala otimizada para performance permite a execução mais rápida do trabalho, mantendo recursos de alta computação por um período mais longo do que a estratégia padrão de ajuste de escala gerenciado. Esse modo prioriza o aumento rápido da escala vertical para atender a demandas de recursos, resultando na conclusão mais rápida do trabalho. Isso pode resultar em custos mais altos em comparação com a estratégia padrão. + Nos casos em que o cluster já está otimizado e totalmente utilizado, habilitar o Ajuste de escala avançado pode não oferecer benefícios adicionais. Em algumas situações, habilitar o Ajuste de escala avançado pode aumentar os custos, pois as workloads podem durar mais. Nesses casos, recomendamos usar a estratégia padrão de ajuste de escala gerenciado para garantir a alocação ideal de recursos e a eficiência dos custos. + **No contexto do Ajuste de escala gerenciado, a ênfase muda para a utilização de recursos ao longo do tempo de execução, à medida que a configuração é ajustada de otimizada para performance [**100**] para otimizada para utilização [1**]. Porém, é importante observar que os resultados podem variar com base na natureza da workload e na topologia do cluster. Para garantir resultados ideais para seu caso de uso, é altamente recomendável testar as estratégias de ajuste de escala com suas workloads para determinar a configuração mais adequada. + O **PerformanceUtilizationIndex**aceita somente os seguintes valores: + **1** + **25** + **50** + **75** + **100** Quaisquer outros valores enviados resultam em um erro de validação. # Noções básicas da estratégia e dos cenários de alocação de nós do Amazon EMR Esta seção fornece uma visão geral da estratégia de alocação de nós e dos cenários comuns de ajuste de escala que você pode usar com o Ajuste de Escala Gerenciado do Amazon EMR. ## Estratégia de alocação de nós O Ajuste de Escala Gerenciado do Amazon EMR aloca nós centrais e de tarefa com base nas seguintes estratégias de aumento e redução da escala verticalmente: **Estratégia de aumento da escala verticalmente** + Para as versões 7.2 e superiores do Amazon EMR, o ajuste de escala gerenciado primeiro adiciona nós com base nos rótulos dos nós e na propriedade do YARN de restrição do processo de aplicação. + Para as versões 7.2 e superiores do Amazon EMR, caso tenha habilitado rótulos de nós e restringido processos de aplicações a nós `CORE`, o Ajuste de Escala Gerenciado do Amazon EMR aumenta a escala verticalmente de nós centrais e os nós de tarefas se a demanda do processo da aplicação e a demanda do executor aumentarem. Da mesma forma, caso tenha habilitado os rótulos de nós e restringido os processos da aplicação aos nós `ON_DEMAND`, o ajuste de escala gerenciado ampliará verticalmente os nós sob demanda se a demanda do processo da aplicação aumentar e escalará os nós spot se a demanda do executor crescer. + Se os rótulos de nós não estiverem habilitados, o posicionamento do processo da aplicação não estará restrito a nenhum nó ou tipo de mercado. + Ao usar rótulos de nós, o ajuste de escala gerenciado pode aumentar e reduzir a escala verticalmente de diferentes grupos de instâncias e frotas de instâncias na mesma operação de redimensionamento. Por exemplo, em um cenário em que `instance_group1` tem um nó `ON_DEMAND` e `instance_group2` tem um nó `SPOT`, os rótulos dos nós estão habilitados e os processos da aplicação são restritos aos nós com o rótulo `ON_DEMAND`. O ajuste de escala gerenciado reduzirá a escala verticalmente de `instance_group1` e aumentará a escala verticalmente de `instance_group2` se a demanda do processo da aplicação diminuir e a demanda do executor aumentar. + Quando o Amazon EMR sofre um atraso ao aumentar a escala verticalmente com o grupo de instâncias atual, os clusters que usam o ajuste de escala gerenciado alternam automaticamente para outro grupo de instâncias de tarefa. + Se o parâmetro `MaximumCoreCapacityUnits` estiver definido, o Amazon EMR escalará os nós centrais até que as unidades centrais atinjam o limite máximo permitido. Toda a capacidade restante é adicionada aos nós de tarefa. + Se o parâmetro `MaximumOnDemandCapacityUnits` estiver definido, o Amazon EMR escalará o cluster usando as instâncias sob demanda até que as unidades sob demanda atinjam o limite máximo permitido. Toda a capacidade restante é adicionada usando instâncias spot. + Se os parâmetros `MaximumCoreCapacityUnits` e `MaximumOnDemandCapacityUnits` estiverem definidos, o Amazon EMR considerará os dois limites durante o ajuste de escala. Por exemplo, se `MaximumCoreCapacityUnits` for menor que `MaximumOnDemandCapacityUnits`, o Amazon EMR primeiro escala os nós centrais até atingir o limite de capacidade do núcleo. Para a capacidade restante, o Amazon EMR primeiro usa instâncias sob demanda para escalar nós de tarefa até atingir o limite sob demanda e usa instâncias spot para nós de tarefa. **Estratégia de redução da escala verticalmente** + Semelhante à estratégia de aumento vertical da escala, o Amazon EMR remove nós com base nos rótulos dos nós. Para obter mais informações sobre os rótulos de nós, consulte [Understand node types: primary, core, and task nodes](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html). + Se você não habilitou os rótulos de nós, o ajuste de escala gerenciado remove os nós de tarefa e depois os nós centrais até alcançar a capacidade desejada de redução da escala verticalmente. O ajuste de escala gerenciado nunca reduz verticalmente a escala do cluster abaixo das restrições mínimas especificadas na política de ajuste de escala gerenciado. + O Amazon EMR 5.34.0 e versões posteriores e o Amazon EMR 6.4.0 e versões posteriores oferecem suporte ao reconhecimento de dados de shuffle do Spark, o que impede que a escala vertical de uma instância seja reduzida enquanto o ajuste de escala gerenciado reconhece dados de shuffle existentes. Para obter mais informações sobre operações de shuffle, consulte o [Guia de programação do Spark](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations). O Ajuste de escala gerenciado se esforça ao máximo para evitar reduzir a escala verticalmente de nós com dados de shuffle do estágio atual e anterior de qualquer aplicação Spark ativa por até um máximo de 30 minutos. Isso ajuda a minimizar a perda acidental de dados de shuffle, evitando a necessidade de repetir trabalhos e recalcular dados intermediários. No entanto, a prevenção da perda de dados de shuffle não é garantida. Para melhorar a proteção do Spark shuffle, recomendamos o reconhecimento aleatório em clusters com a etiqueta de versão 7.4 ou superior. Adicione os seguintes sinalizadores à configuração do cluster para ativar a proteção aprimorada do Spark shuffle. + Se o `yarn.nodemanager.shuffledata-monitor.interval-ms` sinalizador (padrão 30000 ms) ou o `spark.dynamicAllocation.executorIdleTimeout` (padrão 60 segundos) tiver sido alterado dos valores padrão, certifique-se de que a condição `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` permaneça `true` atualizando o sinalizador necessário. ``` [ { "Classification": "yarn-site", "Properties": { "yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true" } }, { "Classification": "spark-defaults", "Properties": { "spark.dynamicAllocation.enabled": "true", "spark.shuffle.service.removeShuffle": "true" } } ] ``` + O ajuste de escala gerenciado primeiro remove os nós de tarefa e depois os nós centrais até alcançar a capacidade desejada de redução da escala verticalmente. O cluster jamais escala abaixo das restrições mínimas especificadas na política de ajuste de escala gerenciado. + Para clusters que são lançados com o Amazon EMR 5.x versões 5.34.0 e superiores e 6.x versões 6.4.0 e superiores, o Amazon EMR Managed Scaling não reduz a escala dos nós que existem `ApplicationMaster` para o Apache Spark, se houver estágios ativos nos aplicativos em execução neles. Isso minimiza falhas e novas tentativas de trabalho, o que ajuda a melhorar a performance do trabalho e reduzir custos. Para confirmar quais nós do cluster estão executando `ApplicationMaster`, acesse o Spark History Server e filtre o driver na guia **Executores** do ID da aplicação Spark. + Embora o ajuste de escala inteligente com o Ajuste de escala gerenciado do EMR minimize a perda de dados de shuffle para o Spark, pode haver casos em que dados de shuffle transitórios podem não ser protegidos durante tal redução. Para fornecer maior resiliência dos dados de shuffle durante a redução da escala vertical, recomendamos habilitar a opção de **Desativação gradual para dados de shuffle** no YARN. Quando a opção **Desativação gradual para dados de shuffle** estiver habilitada no YARN, os nós selecionados para redução de escala vertical que tenham dados de shuffle entrarão no estado de **desativação** e continuarão a fornecer arquivos de shuffle. O YARN ResourceManager espera até que os nós relatem a presença de arquivos aleatórios antes de remover os nós do cluster. + A versão 6.11.0 e superior do Amazon EMR oferece suporte ao descomissionamento elegante baseado em Yarn para dados do **Hive** shuffle para os manipuladores Tez e Shuffle. MapReduce + Habilite a Desativação gradual para dados de shuffle definindo `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data` como `true`. + O Amazon EMR versão 7.4.0 e superior oferece suporte à desativação gradual com base no Yarn para dados de shuffle do Spark quando o serviço de shuffle externo está habilitado (habilitado por padrão no EMR no EC2). + O comportamento padrão do serviço de reprodução aleatória externa do Spark, ao executar o Spark no Yarn, é que o Yarn remova os arquivos aleatórios do aplicativo no NodeManager momento do encerramento do aplicativo. Isso pode ter um impacto na velocidade de descomissionamento dos nós e na utilização da computação. Para aplicações de longa execução, considere configurar `spark.shuffle.service.removeShuffle` como `true` para remover arquivos de shuffle que não estão mais em uso para permitir a desativação mais rápida de nós sem dados de shuffle ativos. + Para minimizar a perda de dados do Spark shuffle no Amazon EMR versão 7.4.0 e superior, considere definir as seguintes sinalizações. + Se o `yarn.nodemanager.shuffledata-monitor.interval-ms` sinalizador (padrão 30000 ms) ou o `spark.dynamicAllocation.executorIdleTimeout` (padrão 60 segundos) tiver sido alterado dos valores padrão, certifique-se de que a condição `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` permaneça `true` atualizando o sinalizador necessário. ``` [ { "Classification": "yarn-site", "Properties": { "yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true" } }, { "Classification": "spark-defaults", "Properties": { "spark.dynamicAllocation.enabled": "true", "spark.shuffle.service.removeShuffle": "true" } } ] ``` Se o cluster não tiver nenhuma carga, o Amazon EMR cancelará a adição de novas instâncias de uma avaliação anterior e executará operações de redução da escala verticalmente. Se o cluster tiver uma carga pesada, o Amazon EMR cancelará a remoção de instâncias e executará operações de aumento da escala verticalmente. ## Considerações sobre alocação de nós É recomendável usar a opção de compra sob demanda para os nós centrais para evitar a perda de dados do HDFS em caso de recuperação spot. Você pode usar a opção de compra spot para nós de tarefa para reduzir custos e obter uma execução mais rápida do trabalho quando mais instâncias spot são adicionadas aos nós de tarefa. ## Cenários de alocação de nós É possível criar vários cenários de ajuste de escala com base em suas necessidades configurando os parâmetros máximo, mínimo, limite sob demanda e nó central máximo em combinações diferentes. **Cenário 1: escalar somente os nós centrais** Para escalar somente os nós centrais, os parâmetros do ajuste de escala gerenciado devem atender aos seguintes requisitos: + O limite sob demanda é igual ao limite máximo. + O nó central máximo é igual ao limite máximo. Quando o limite sob demanda e os parâmetros máximos do nó central não estão especificados, ambos os parâmetros assumem o limite máximo como padrão. Esse cenário não é aplicável se você usa ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `CORE`, porque o ajuste de escala gerenciado dimensiona os nós de tarefas para acomodar a demanda do executor. Os exemplos a seguir demonstram o cenário de ajuste de escala somente para os nós centrais. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 2: escalar somente nós de tarefa** Para escalar somente os nós de tarefa, os parâmetros do ajuste de escala gerenciado devem atender ao seguinte requisito: + O nó central máximo deve ser igual ao limite mínimo. Os exemplos a seguir demonstram o cenário de ajuste de escala somente para os nós de tarefa. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 3: somente instâncias sob demanda no cluster** Para ter somente instâncias sob demanda, o cluster e os parâmetros de ajuste de escala gerenciado devem atender aos seguintes requisitos: + O limite sob demanda é igual ao limite máximo. Quando o limite sob demanda não é especificado, o valor do parâmetro assume o limite máximo como padrão. O valor padrão indica que o Amazon EMR escalará somente instâncias sob demanda. Se o nó central máximo for menor que o limite máximo, o parâmetro do nó central máximo poderá ser usado para dividir a alocação de capacidade entre os nós centrais e os nós de tarefa. Para habilitar esse cenário em um cluster composto por grupos de instâncias, todos os grupos de nós do cluster devem usar o tipo de mercado sob demanda durante a configuração inicial. Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `ON_DEMAND`, porque o ajuste de escala gerenciado dimensiona os nós `Spot` para acomodar a demanda do executor. Os exemplos a seguir demonstram o cenário de ter instâncias sob demanda em todo o cluster. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 4: somente instâncias spot no cluster** Para ter somente instâncias spot, os parâmetros de ajuste de escala gerenciado devem atender aos seguintes requisitos: + O limite sob demanda está definido como 0. Se o nó central máximo for menor que o limite máximo, o parâmetro do nó central máximo poderá ser usado para dividir a alocação de capacidade entre os nós centrais e os nós de tarefa. Para habilitar esse cenário em um cluster composto por grupos de instâncias, o grupo de instâncias central deve usar a opção de compra spot durante a configuração inicial. Se não houver nenhuma instância spot no grupo de instâncias de tarefa, o Ajuste de Escala Gerenciado do Amazon EMR criará um grupo de tarefas usando instâncias spot quando necessário. Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `ON_DEMAND`, porque o ajuste de escala gerenciado dimensiona os nós `ON_DEMAND` para acomodar a demanda do processo da aplicação. Os exemplos a seguir demonstram o cenário de ter instâncias spot em todo o cluster. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 5: escalar instâncias sob demanda nos nós centrais e instâncias spot nos nós de tarefa** Para escalar instâncias sob demanda em nós centrais e instâncias spot em nós de tarefa, os parâmetros de ajuste de escala gerenciado devem atender aos seguintes requisitos: + O limite sob demanda deve ser igual ao nó central máximo. + Tanto o limite sob demanda como o nó central máximo devem ser menores que o limite máximo. Para habilitar esse cenário em um cluster composto por grupos de instâncias, o grupo de nós centrais deve usar a opção de compra sob demanda. Esse cenário não é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `ON_DEMAND` ou `CORE`. Os exemplos a seguir demonstram o cenário de ajuste de escala de instâncias sob demanda nos nós centrais e instâncias spot nos nós de tarefa. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 6: escale as instâncias `CORE` para a demanda do processo da aplicação e as instâncias `TASK` para a demanda do executor.** Esse cenário só é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `CORE`. Para escalar os nós `CORE` com base na demanda do processo da aplicação e os nós `TASK` com base na demanda do executor, você deve definir as seguintes configurações na inicialização do cluster: + `yarn.node-labels.enabled:true` + `yarn.node-labels.am.default-node-label-expression: 'CORE'` Se você não especificar o limite de `ON_DEMAND` e os parâmetros máximos do nó `CORE`, ambos os parâmetros serão padronizados para o limite máximo. Se o nó `ON_DEMAND` máximo for menor que o limite máximo, o ajuste de escala gerenciado usará o parâmetro do nó `ON_DEMAND` máximo para dividir a alocação de capacidade entre os nós `ON_DEMAND` e `SPOT`. Se você definir o parâmetro máximo do nó `CORE` como menor ou igual ao parâmetro de capacidade mínima, os nós `CORE` permanecerão estáticos na capacidade máxima do núcleo. Os exemplos a seguir demonstram o cenário de ajuste de escala de instâncias CENTRAIS com base na demanda do processo da aplicação e de instâncias DE TAREFA com base na demanda do executor. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) **Cenário 7: escale as instâncias `ON_DEMAND` para a demanda do processo da aplicação e as instâncias `SPOT` para a demanda do executor.** Esse cenário só é aplicável se você usa o ajuste de escala gerenciado com rótulos de nós e restringe os processos da aplicação para serem executados somente em nós `ON_DEMAND`. Para escalar os nós `ON_DEMAND` com base na demanda do processo da aplicação e os nós `SPOT` com base na demanda do executor, você deve definir as seguintes configurações na inicialização do cluster: + `yarn.node-labels.enabled:true` + `yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'` Se você não especificar o limite de `ON_DEMAND` e os parâmetros máximos do nó `CORE`, ambos os parâmetros serão padronizados para o limite máximo. Se o nó `CORE` máximo for menor que o limite máximo, o ajuste de escala gerenciado usará o parâmetro do nó `CORE` máximo para dividir a alocação de capacidade entre os nós `CORE` e `TASK`. Se você definir o parâmetro máximo do nó `CORE` como menor ou igual ao parâmetro de capacidade mínima, os nós `CORE` permanecerão estáticos na capacidade máxima do núcleo. Os exemplos a seguir demonstram o cenário de ajuste de escala de instâncias sob demanda com base na demanda do processo da aplicação e de instâncias spot com base na demanda do executor. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html) # Noções básicas sobre métricas de ajuste de escala gerenciado no Amazon EMR O Amazon EMR publica métricas de alta resolução com dados em uma granularidade de um minuto quando o ajuste de escala gerenciado está habilitado em um cluster. Você pode visualizar eventos em cada iniciação e conclusão de redimensionamento controlados pela escalabilidade gerenciada com o console do Amazon EMR ou o console da Amazon. CloudWatch CloudWatch as métricas são essenciais para a operação da escalabilidade gerenciada do Amazon EMR. Recomendamos que você monitore de perto CloudWatch as métricas para garantir que os dados não estejam ausentes. Para obter mais informações sobre como você pode configurar CloudWatch alarmes para detectar métricas ausentes, consulte [Usando CloudWatch alarmes da Amazon](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Para obter mais informações sobre o uso de CloudWatch eventos com o Amazon EMR, consulte [Monitorar CloudWatch](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html) eventos. As métricas a seguir indicam as capacidades atuais ou de destino de um cluster. Essas métricas só estão disponíveis quando a escalabilidade gerenciada está habilitada. Para clusters compostos por frotas de instâncias, as métricas de capacidade de cluster são medidas em `Units`. Para clusters compostos por grupos de instâncias, as métricas de capacidade de cluster são medidas em `Nodes` ou `vCPU` com base no tipo de unidade usado na política de escalabilidade gerenciada. | Métrica | Description | | --- | --- | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número total alvo de units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número total atual de units/nodes/vCPUs disponíveis em um cluster em execução. Quando um redimensionamento de cluster for solicitado, essa métrica será atualizada depois que as novas instâncias forem adicionadas ou removidas do cluster. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número alvo de CORE units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número atual de CORE em units/nodes/vCPUs execução em um cluster. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número alvo de TASK units/nodes/vCPUs em um cluster, conforme determinado pelo escalonamento gerenciado. Unidades: *Contagem* | | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/managed-scaling-metrics.html) | O número atual de TAREFAS em units/nodes/vCPUs execução em um cluster. Unidades: *Contagem* | As métricas a seguir indicam o status de uso do cluster e dos aplicativos. Essas métricas estão disponíveis para todos os recursos do Amazon EMR mas são publicadas em uma resolução mais alta com dados em uma granularidade de um minuto quando o ajuste de gerenciado é habilitado para um cluster. É possível correlacionar as métricas a seguir com as métricas de capacidade do cluster na tabela anterior para entender as decisões de escalabilidade gerenciada. | Métrica | Description | | --- | --- | | `AppsCompleted` | O número de aplicativos enviados para o YARN que foram concluídos. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `AppsPending` | O número de aplicativos enviados para o YARN em estado pendente. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `AppsRunning` | O número de aplicativos enviados para o YARN que estão em execução. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ContainerAllocated | O número de contêineres de recursos alocados peloResourceManager. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `ContainerPending` | O número de contêineres na fila que ainda não foram alocados. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | ContainerPendingRatio | A proporção de contêineres pendentes em relação aos contêineres alocados (ContainerPendingRatio = ContainerPending / ContainerAllocated). Se ContainerAllocated = 0, então ContainerPendingRatio =ContainerPending. O valor de ContainerPendingRatio representa um número, não uma porcentagem. Esse valor é útil para escalonar recursos de cluster com base no comportamento de alocação do contêiner. Unidades: *Contagem* | | `HDFSUtilization` | O percentual de armazenamento do HDFS em uso no momento. Caso de uso: analisar a performance do cluster Unidade: *percentual* | | `IsIdle` | Indica que um cluster não está mais executando nenhum trabalho, mas ainda está ativo e acumulando cobranças. É definido como 1 se nenhuma tarefa ou nenhum trabalho estiver em execução, caso contrário, é definido como 0. Esse valor é verificado em intervalos de 5 minutos, sendo que um valor de 1 indica somente que o cluster estava ocioso no momento da verificação, e não que ele ficou ocioso durante todo o período de 5 minutos. Para evitar falsos positivos, é necessário gerar um alarme quando esse valor for 1 em mais de uma verificação consecutiva de cinco minutos. Por exemplo, você pode gerar um alerta para esse valor se ele for 1 por 30 minutos ou mais. Caso de uso: monitorar a performance do cluster Unidade: *booliano* | | `MemoryAvailableMB` | A quantidade de memória disponível para ser alocada. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `MRActiveNodes` | O número de nós que estão executando MapReduce tarefas ou trabalhos no momento. Equivalente ao `mapred.resourcemanager.NoOfActiveNodes` da métrica YARN. Caso de uso: monitorar o progresso do cluster Unidades: *Contagem* | | `YARNMemoryAvailablePercentage` | A porcentagem de memória restante disponível para o YARN (YARNMemoryAvailablePercentage = MemoryAvailable MB/MemoryTotalMB). Esse valor é útil para escalonar recursos de cluster com base no uso da memória YARN. Unidade: *percentual* | As métricas a seguir fornecem informações sobre os recursos usados pelos contêineres e nós YARN. Essas métricas do gerenciador de recursos do YARN oferecem informações sobre os recursos usados pelos contêineres e nós em execução no cluster. A comparação dessas métricas com as métricas de capacidade de cluster da tabela anterior fornece uma imagem mais clara do impacto do ajuste de escala gerenciado: | Métrica | Versões associadas | Description | | --- | --- | --- | | `YarnContainersUsedMemoryGBSeconds` | Disponível para a versão 7.3.0 e posteriores | A memória consumida do contêiner \$1 segundos durante o período de publicação. **Unidades:** GB \$1 segundos | | `YarnContainersTotalMemoryGBSeconds` | Disponível para a versão 7.3.0 e posteriores | O total do contêiner yarn \$1 segundos para o período de publicação. **Unidades:** GB \$1 segundos | | `YarnContainersUsedVCPUSeconds` | Disponível para a versão 7.5.0 e posteriores | A VCPU consumida do contêiner \$1 segundos durante o período de publicação. **Unidades:** VCPU \$1 segundos | | `YarnContainersTotalVCPUSeconds` | Disponível para a versão 7.5.0 e posteriores | O total da VCPU contêiner \$1 segundos para o período de publicação. **Unidades:** VCPU \$1 segundos | | `YarnNodesUsedMemoryGBSeconds` | Disponível para a versão 7.5.0 e posteriores | A memória consumida do nó \$1 segundos durante o período de publicação. **Unidades:** GB \$1 segundos | | `YarnNodesTotalMemoryGBSeconds` | Disponível para a versão 7.5.0 e posteriores | A memória total do nó \$1 segundos durante o período de publicação. **Unidades:** GB \$1 segundos | | `YarnNodesUsedVCPUSeconds` | Disponível para a versão 7.3.0 e posteriores | A VCPU consumida do nó \$1 segundos durante o período de publicação. **Unidades:** VCPU \$1 segundos | | `YarnNodesTotalVCPUSeconds` | Disponível para a versão 7.3.0 e posteriores | A VCPU total do nó \$1 segundos durante o período de publicação. **Unidades:** VCPU \$1 segundos | ## Criar grafos de métricas de ajuste de escala gerenciado É possível criar grafos de métricas para visualizar os padrões de workload do cluster e as decisões de ajuste de escala correspondentes tomadas pelo Ajuste de Escala Gerenciado do Amazon EMR, conforme demonstrado nas etapas a seguir. **Para representar graficamente as métricas de escalabilidade gerenciadas no console CloudWatch** 1. Abra o [console do CloudWatch](https://console.aws.amazon.com/cloudwatch/). 1. No painel de navegação, escolha o **Amazon EMR**. Você pode pesquisar com base no identificador do cluster para monitoramento. 1. Role para baixo até a métrica para exibição em gráfico. Abra uma métrica para exibir o gráfico. 1. Para criar um gráfico de uma ou mais métricas, marque a caixa de seleção ao lado de cada métrica. O exemplo a seguir ilustra a ação de Ajuste de Escala Gerenciado do Amazon EMR de um cluster. O gráfico mostra três períodos de redução automática, que economizam custos quando há uma workload menos ativa. ![\[Criar gráficos de métricas de escalabilidade gerenciada\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/Managed_Scaling_Decision.png) Todas as métricas de capacidade e uso do cluster são publicadas em intervalos de um minuto. As informações estatísticas adicionais também estão associadas a cada dado de um minuto, o que permite representar várias funções como `Percentiles`, `Min`, `Max`, `Sum`, `Average` e `SampleCount`. Por exemplo, o gráfico a seguir representa graficamente a mesma métrica `YARNMemoryAvailablePercentage` em percentis diferentes, P10, P50, P90 e P99, juntamente com `Sum`, `Average`, `Min` e `SampleCount`. ![\[Criar gráficos de métricas de escalabilidade gerenciada com diferentes percentis\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/Managed_Scaling_Metrics.png) # Uso do ajuste de escala automático com uma política personalizada para grupos de instâncias no Amazon EMR *A escalabilidade automática com uma política personalizada nas versões 4.0 e superiores do Amazon EMR permite que você escale e escale programaticamente os nós principais e os nós de tarefas com base em CloudWatch uma métrica e em outros parâmetros que você especifica em uma política de escalabilidade.* A escalabilidade automática com uma política personalizada está disponível com a configuração de grupos de instâncias e não está disponível ao usar frotas de instâncias. Para obter mais informações sobre os grupos de instâncias e frotas de instâncias, consulte [Criação de um cluster do Amazon EMR com frotas de instâncias ou grupos de instâncias uniformes](emr-instance-group-configuration.md). **nota** Para usar o ajuste de escala automático com um atributo de política personalizada no Amazon EMR, é necessário definir `true` para o parâmetro `VisibleToAllUsers` ao criar um cluster. Para obter mais informações, consulte [SetVisibleToAllUsers](https://docs.aws.amazon.com/emr/latest/APIReference/API_SetVisibleToAllUsers.html). A política de escalabilidade é parte da configuração de um grupo de instâncias. Você pode especificar uma política durante a configuração inicial de um grupo de instâncias ou pode modificar um grupo de instâncias de um cluster existente, mesmo que esse grupo de instâncias esteja ativo. Cada grupo de instâncias em um cluster, com exceção do grupo de instâncias primário, pode ter sua própria política de ajuste de escala, que consiste em regras de aumento ou redução da escala na horizontal. As regras de expansão e redução podem ser configuradas de forma independente, com parâmetros diferentes para cada regra. Você pode configurar políticas de escalabilidade com a Console de gerenciamento da AWS AWS CLI, a ou a API do Amazon EMR. Ao usar a API AWS CLI ou o Amazon EMR, você especifica a política de escalabilidade no formato JSON. Além disso, com a API do Amazon EMR AWS CLI ou com a API do Amazon EMR, você pode especificar métricas personalizadas CloudWatch . As métricas personalizadas não estão disponíveis para seleção ao usar o  Console de gerenciamento da AWS. Quando você cria inicialmente uma política de ajuste de escala usando o console, uma política padrão adequada para muitas aplicações é pré-configurada para ajudar você a começar. Você pode excluir ou modificar as regras padrão. Embora o escalonamento automático permita ajustar a on-the-fly capacidade do cluster do EMR, você ainda deve considerar os requisitos básicos de carga de trabalho e planejar suas configurações de nós e grupos de instâncias. Para obter mais informações, consulte [Cluster configuration guidelines](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html). **nota** Para a maioria das workloads, a configuração de ambas as regras de expansão e redução é desejável para otimizar a utilização de recursos. Definir uma regra sem a outra significa que você precisaria manualmente redimensionar o número de instâncias após uma ação de escalabilidade. Em outras palavras, isso definiria uma política "unidirecional" automática de expansão ou redução com uma reinicialização manual. ## Criar o perfil do IAM para ajuste de escala automático O ajuste de escala automático no Amazon EMR requer um perfil do IAM com permissões para adicionar e terminar instâncias quando as ações de ajuste de escala são iniciadas. Uma função padrão `EMR_AutoScaling_DefaultRole`, configurada com as políticas de função e de confiança adequadas, está disponível para esse objetivo. Quando você cria um cluster com uma política de escalabilidade pela primeira vez com o Console de gerenciamento da AWS, o Amazon EMR cria a função padrão e anexa a política gerenciada padrão para permissões,. `AmazonElasticMapReduceforAutoScalingRole` Ao criar um cluster com uma política de escalabilidade automática com o AWS CLI, você deve primeiro garantir que a função padrão do IAM exista ou que você tenha uma função personalizada do IAM com uma política anexada que forneça as permissões apropriadas. Para criar a função padrão, você pode executar o comando `create-default-roles` antes de criar um cluster. Em seguida, você pode especificar a opção `--auto-scaling-role EMR_AutoScaling_DefaultRole` ao criar um cluster. Como alternativa, você pode criar uma função personalizada de escalabilidade automática e, em seguida, especificá-la ao criar um cluster, por exemplo, `--auto-scaling-role MyEMRAutoScalingRole`. Se você criar um perfil personalizado de ajuste de escala automático para o Amazon EMR, recomendamos basear as políticas de permissão para o perfil personalizado com base na política gerenciada. 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). ## Noções básicas sobre as regras de ajuste de escala automático Quando uma regra de aumento da escala da horizontal aciona uma ação de ajuste de escala para um grupo de instâncias, as instâncias do Amazon EC2 são adicionadas ao grupo de instâncias, de acordo com as suas regras. Novos nós podem ser usados por aplicações como o Apache Spark, o Apache Hive e o Presto assim que a instância do Amazon EC2 entra no estado `InService`. Você também pode configurar uma regra de redução que encerra as instâncias e remove os nós. Para obter mais informações sobre o ciclo de vida das instâncias do Amazon EC2 que podem escalar automaticamente, consulte [Auto Scaling lifecycle](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. Você pode configurar como um cluster terminará as instâncias do Amazon EC2. Você pode optar por terminar no limite instância-hora do Amazon EC2 para o faturamento ou após a conclusão da tarefa. Esta configuração se aplica tanto ao Auto Scaling quanto ao redimensionamento manual de operações. Para saber mais sobre essa configuração, consulte [Opções de redução vertical da escala para os clusters do Amazon EMR](emr-scaledown-behavior.md). Os parâmetros a seguir se referem às regras das políticas e determinam o comportamento do Auto Scaling. **nota** Os parâmetros listados aqui são baseados nos do Console de gerenciamento da AWS Amazon EMR. Quando você usa a API AWS CLI ou o Amazon EMR, opções adicionais de configuração avançada estão disponíveis. Para obter mais informações sobre opções avançadas, consulte a [SimpleScalingPolicyConfiguration](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_PutAutoScalingPolicy.html)Referência da *API do Amazon EMR.* + Números máximo e mínimo de instâncias. A restrição **Máximo de instâncias** especifica o número máximo de instâncias do Amazon EC2 que podem estar no grupo de instâncias e se aplica a todas as regras de aumento da escala na horizontal. Da mesma forma, a restrição **Mínimo de instâncias** especifica o número mínimo de instâncias do Amazon EC2 e se aplica a todas as regras de redução da escala na horizontal. + O **Rule name (Nome da regra)**, que deve ser único dentro da política. + O **scaling adjustment (ajuste de escalabilidade)**, que determina o número de instâncias do EC2 a serem adicionadas (para regras de expansão) ou encerradas (para regras de redução) durante a ação de escalabilidade acionada pela regra. + A **CloudWatch métrica**, que é observada em busca de uma condição de alarme. + Um **operador de comparação**, usado para comparar a CloudWatch métrica com o valor **limite** e determinar uma condição de gatilho. + Um **período de avaliação**, em incrementos de cinco minutos, durante o qual a CloudWatch métrica deve estar em uma condição de gatilho antes que a atividade de escalabilidade seja acionada. + Um **Cooldown period (Desaquecimento)**, que determina a quantidade de tempo que deve se passar entre uma ação de escalabilidade iniciada por uma regra e o início da próxima ação de escalabilidade, independentemente da regra que o aciona. Quando um grupo de instâncias conclui uma atividade de escalabilidade e atinge seu estado de pós-escala, o período de espera oferece uma oportunidade para que as CloudWatch métricas que podem acionar as atividades de escalabilidade subsequentes se estabilizem. Para obter mais informações, consulte [Auto Scaling cooldowns](https://docs.aws.amazon.com/autoscaling/ec2/userguide/Cooldown.html) no *Guia do usuário do Amazon EC2 Auto Scaling*. ![\[Console de gerenciamento da AWS parâmetros de regras de escalabilidade automática para o Amazon EMR.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/auto-scaling-rule-params.png) ## Considerações e limitações + CloudWatch As métricas da Amazon são essenciais para a operação da escalabilidade automática do Amazon EMR. Recomendamos que você monitore de perto CloudWatch as métricas da Amazon para garantir que os dados não estejam ausentes. Para obter mais informações sobre como você pode configurar CloudWatch os alarmes da Amazon para detectar métricas ausentes, consulte [Usando CloudWatch alarmes da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). + A utilização excessiva dos volumes do EBS pode causar problemas de ajuste de escala gerenciado. É recomendável monitorar atentamente o uso do volume do EBS para garantir que o volume do EBS esteja abaixo de 90% de utilização. Consulte [Instance storage](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-storage.html) para obter informações sobre como especificar volumes do EBS adicionais. + A escalabilidade automática com uma política personalizada nas versões 5.18 a 5.28 do Amazon EMR pode apresentar falhas de escalabilidade causadas pela falta intermitente de dados nas métricas da Amazon. CloudWatch É recomendável usar as versões mais recentes do Amazon EMR para melhorar o ajuste de escala automático. Você também pode entrar em contato com o [AWS Support](https://aws.amazon.com/premiumsupport/) para obter um patch, caso precise usar uma versão do Amazon EMR entre 5.18 e 5.28. ## Usando o Console de gerenciamento da AWS para configurar o escalonamento automático Ao criar um cluster, você configura uma política de ajuste de escala para os grupos de instâncias usando as opções de configuração avançadas do cluster. Você também pode criar ou modificar uma política de escalabilidade para um grupo de instâncias em serviço modificando os grupos de instâncias nas configurações de **Hardware** de um cluster existente. 1. Navegue até o novo console do Amazon EMR e selecione **Alternar para o console antigo** na navegação lateral. Para obter mais informações sobre o que esperar ao alternar para o console antigo, consulte [Usar o console antigo](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in). 1. Se você estiver criando um cluster, no console do Amazon EMR, selecione **Criar cluster**, em seguida selecione **Ir para opções avançadas**, escolha as opções em **Etapa1: software e etapas** e acesse **Etapa 2: configuração de hardware**. ** - ou - ** Se você estiver modificando um grupo de instâncias em um cluster em execução, selecione o seu cluster na lista de clusters e, em seguida, expanda a seção **Hardware**. 1. Na seção **Opção de ajuste de escala e provisionamento de clusters**, selecione **Habilitar ajuste de escala de clusters**. Selecione **Criar uma política personalizada de escalabilidade automática**. Na tabela de **Políticas personalizadas de escalabilidade automática**, clique no ícone de lápis que aparece na linha do grupo de instâncias que você deseja configurar. A tela Regras do Auto Scaling é exibida. 1. Digite o número de **Maximum instances (Máximo de instâncias)** que você deseja que o grupo de instâncias tenha quando houver uma expansão e digite o número de **Minimum instances (Mínimo de instâncias)** que deseja que o grupo de instâncias tenha quando houver uma redução. 1. Clique no lápis para editar os parâmetros das regras, clique em **X** para remover uma regra da política e clique em **Add rule (Adicionar regra)** para acrescentar regras adicionais. 1. Escolha os parâmetros para as regras como descrevemos anteriormente neste tópico. *Para obter descrições das CloudWatch métricas disponíveis para o Amazon EMR, consulte as [métricas e dimensões do Amazon EMR no](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/emr-metricscollected.html) Guia do usuário da Amazon. CloudWatch * ## Usando o AWS CLI para configurar o escalonamento automático Você pode usar AWS CLI comandos para o Amazon EMR para configurar a escalabilidade automática ao criar um cluster e ao criar um grupo de instâncias. Você pode usar uma sintaxe abreviada, especificando a configuração do JSON nas linhas dos comandos relevantes, ou pode fazer referência a um arquivo que contém a configuração do JSON. Você também pode aplicar uma política de Auto Scaling para um grupo de instâncias existente e remover uma política de Auto Scaling que foi aplicada anteriormente. Além disso, você pode recuperar os detalhes da configuração de uma política de escalabilidade de um cluster em execução. **Importante** Ao criar um cluster que tem uma política de ajuste de escala automático, é necessário usar o comando `--auto-scaling-role MyAutoScalingRole` para especificar o perfil do IAM para o ajuste de escala automático. A função padrão é `EMR_AutoScaling_DefaultRole` e pode ser criada com o comando `create-default-roles`. Esta função só pode ser adicionada quando o cluster é criado e não em um cluster existente. Para obter uma descrição detalhada dos parâmetros disponíveis ao configurar uma política de escalabilidade automática, consulte a Referência da API do [PutAutoScalingPolicy](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_PutAutoScalingPolicy.html)Amazon *EMR.* ### Criar um cluster com uma política do Auto Scaling aplicada a um grupo de instâncias Você pode especificar uma configuração de escalabilidade automática dentro da opção `--instance-groups` do comando `aws emr create-cluster`. O exemplo a seguir ilustra um comando create-cluster em que uma política de Auto Scaling para o grupo de instâncias core é fornecida na linha. O comando cria uma configuração de escalabilidade equivalente à política de escalabilidade horizontal padrão que aparece quando você cria uma política de escalabilidade automática com o for Amazon Console de gerenciamento da AWS EMR. Para não estender a explicação, não mostramos uma política de redução. Não é recomendável criar uma regra de expansão sem uma regra de redução. ``` aws emr create-cluster --release-label emr-5.2.0 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --auto-scaling-role EMR_AutoScaling_DefaultRole --instance-groups Name=MyMasterIG,InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 'Name=MyCoreIG,InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=2,AutoScalingPolicy={Constraints={MinCapacity=2,MaxCapacity=10},Rules=[{Name=Default-scale-out,Description=Replicates the default scale-out rule in the console.,Action={SimpleScalingPolicyConfiguration={AdjustmentType=CHANGE_IN_CAPACITY,ScalingAdjustment=1,CoolDown=300}},Trigger={CloudWatchAlarmDefinition={ComparisonOperator=LESS_THAN,EvaluationPeriods=1,MetricName=YARNMemoryAvailablePercentage,Namespace=AWS/ElasticMapReduce,Period=300,Statistic=AVERAGE,Threshold=15,Unit=PERCENT,Dimensions=[{Key=JobFlowId,Value="${emr.clusterId}"}]}}}]}' ``` O comando a seguir ilustra como usar a linha de comando para fornecer a definição da política do Auto Scaling como parte de um arquivo de configuração de grupo de instâncias chamado `instancegroupconfig.json`. ``` aws emr create-cluster --release-label emr-5.2.0 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --instance-groups file://your/path/to/instancegroupconfig.json --auto-scaling-role EMR_AutoScaling_DefaultRole ``` O conteúdo do arquivo de configuração é o seguinte: ``` [ { "InstanceCount": 1, "Name": "MyMasterIG", "InstanceGroupType": "MASTER", "InstanceType": "m5.xlarge" }, { "InstanceCount": 2, "Name": "MyCoreIG", "InstanceGroupType": "CORE", "InstanceType": "m5.xlarge", "AutoScalingPolicy": { "Constraints": { "MinCapacity": 2, "MaxCapacity": 10 }, "Rules": [ { "Name": "Default-scale-out", "Description": "Replicates the default scale-out rule in the console for YARN memory.", "Action":{ "SimpleScalingPolicyConfiguration":{ "AdjustmentType": "CHANGE_IN_CAPACITY", "ScalingAdjustment": 1, "CoolDown": 300 } }, "Trigger":{ "CloudWatchAlarmDefinition":{ "ComparisonOperator": "LESS_THAN", "EvaluationPeriods": 1, "MetricName": "YARNMemoryAvailablePercentage", "Namespace": "AWS/ElasticMapReduce", "Period": 300, "Threshold": 15, "Statistic": "AVERAGE", "Unit": "PERCENT", "Dimensions":[ { "Key" : "JobFlowId", "Value" : "${emr.clusterId}" } ] } } } ] } } ] ``` ### Adicionar um grupo de instâncias com uma política do Auto Scaling a um cluster Você pode especificar uma configuração de política de ajuste de escala usando a opção `--instance-groups` com o comando `add-instance-groups` da mesma maneira com que usa o `create-cluster`. O exemplo a seguir usa uma referência a um arquivo JSON `instancegroupconfig.json`, com a configuração do grupo de instâncias. ``` aws emr add-instance-groups --cluster-id j-1EKZ3TYEVF1S2 --instance-groups file://your/path/to/instancegroupconfig.json ``` ### Aplicar uma política de ajuste de escala automático a um grupo de instâncias atual ou modificar uma política aplicada Use o comando `aws emr put-auto-scaling-policy` para aplicar uma política de Auto Scaling a um grupo de instâncias existente. O grupo de instâncias deve fazer parte de um cluster que usa o perfil do IAM de ajuste de escala automático. O exemplo a seguir usa uma referência a um arquivo JSON `autoscaleconfig.json`, que especifica a configuração da política de Auto Scaling. ``` aws emr put-auto-scaling-policy --cluster-id j-1EKZ3TYEVF1S2 --instance-group-id ig-3PLUZBA6WLS07 --auto-scaling-policy file://your/path/to/autoscaleconfig.json ``` O conteúdo do arquivo `autoscaleconfig.json`, que define a mesma regra de expansão apresentada no exemplo anterior, é mostrado a seguir. ``` { "Constraints": { "MaxCapacity": 10, "MinCapacity": 2 }, "Rules": [{ "Action": { "SimpleScalingPolicyConfiguration": { "AdjustmentType": "CHANGE_IN_CAPACITY", "CoolDown": 300, "ScalingAdjustment": 1 } }, "Description": "Replicates the default scale-out rule in the console for YARN memory", "Name": "Default-scale-out", "Trigger": { "CloudWatchAlarmDefinition": { "ComparisonOperator": "LESS_THAN", "Dimensions": [{ "Key": "JobFlowId", "Value": "${emr.clusterID}" }], "EvaluationPeriods": 1, "MetricName": "YARNMemoryAvailablePercentage", "Namespace": "AWS/ElasticMapReduce", "Period": 300, "Statistic": "AVERAGE", "Threshold": 15, "Unit": "PERCENT" } } }] } ``` ### Remover uma política de ajuste de escala automático de um grupo de instâncias ``` aws emr remove-auto-scaling-policy --cluster-id j-1EKZ3TYEVF1S2 --instance-group-id ig-3PLUZBA6WLS07 ``` ### Recuperar configuração de uma política de ajuste de escala automático O `describe-cluster` comando recupera a configuração da política no InstanceGroup bloco. Por exemplo, o comando a seguir recupera a configuração de um cluster com o ID `j-1CWOHP4PI30VJ`. ``` aws emr describe-cluster --cluster-id j-1CWOHP4PI30VJ ``` Este comando gera o seguinte exemplo de saída. ``` { "Cluster": { "Configurations": [], "Id": "j-1CWOHP4PI30VJ", "NormalizedInstanceHours": 48, "Name": "Auto Scaling Cluster", "ReleaseLabel": "emr-5.2.0", "ServiceRole": "EMR_DefaultRole", "AutoTerminate": false, "TerminationProtected": true, "MasterPublicDnsName": "ec2-54-167-31-38.compute-1.amazonaws.com", "LogUri": "s3n://aws-logs-232939870606-us-east-1/elasticmapreduce/", "Ec2InstanceAttributes": { "Ec2KeyName": "performance", "AdditionalMasterSecurityGroups": [], "AdditionalSlaveSecurityGroups": [], "EmrManagedSlaveSecurityGroup": "sg-09fc9362", "Ec2AvailabilityZone": "us-east-1d", "EmrManagedMasterSecurityGroup": "sg-0bfc9360", "IamInstanceProfile": "EMR_EC2_DefaultRole" }, "Applications": [ { "Name": "Hadoop", "Version": "2.7.3" } ], "InstanceGroups": [ { "AutoScalingPolicy": { "Status": { "State": "ATTACHED", "StateChangeReason": { "Message": "" } }, "Constraints": { "MaxCapacity": 10, "MinCapacity": 2 }, "Rules": [ { "Name": "Default-scale-out", "Trigger": { "CloudWatchAlarmDefinition": { "MetricName": "YARNMemoryAvailablePercentage", "Unit": "PERCENT", "Namespace": "AWS/ElasticMapReduce", "Threshold": 15, "Dimensions": [ { "Key": "JobFlowId", "Value": "j-1CWOHP4PI30VJ" } ], "EvaluationPeriods": 1, "Period": 300, "ComparisonOperator": "LESS_THAN", "Statistic": "AVERAGE" } }, "Description": "", "Action": { "SimpleScalingPolicyConfiguration": { "CoolDown": 300, "AdjustmentType": "CHANGE_IN_CAPACITY", "ScalingAdjustment": 1 } } }, { "Name": "Default-scale-in", "Trigger": { "CloudWatchAlarmDefinition": { "MetricName": "YARNMemoryAvailablePercentage", "Unit": "PERCENT", "Namespace": "AWS/ElasticMapReduce", "Threshold": 75, "Dimensions": [ { "Key": "JobFlowId", "Value": "j-1CWOHP4PI30VJ" } ], "EvaluationPeriods": 1, "Period": 300, "ComparisonOperator": "GREATER_THAN", "Statistic": "AVERAGE" } }, "Description": "", "Action": { "SimpleScalingPolicyConfiguration": { "CoolDown": 300, "AdjustmentType": "CHANGE_IN_CAPACITY", "ScalingAdjustment": -1 } } } ] }, "Configurations": [], "InstanceType": "m5.xlarge", "Market": "ON_DEMAND", "Name": "Core - 2", "ShrinkPolicy": {}, "Status": { "Timeline": { "CreationDateTime": 1479413437.342, "ReadyDateTime": 1479413864.615 }, "State": "RUNNING", "StateChangeReason": { "Message": "" } }, "RunningInstanceCount": 2, "Id": "ig-3M16XBE8C3PH1", "InstanceGroupType": "CORE", "RequestedInstanceCount": 2, "EbsBlockDevices": [] }, { "Configurations": [], "Id": "ig-OP62I28NSE8M", "InstanceGroupType": "MASTER", "InstanceType": "m5.xlarge", "Market": "ON_DEMAND", "Name": "Master - 1", "ShrinkPolicy": {}, "EbsBlockDevices": [], "RequestedInstanceCount": 1, "Status": { "Timeline": { "CreationDateTime": 1479413437.342, "ReadyDateTime": 1479413752.088 }, "State": "RUNNING", "StateChangeReason": { "Message": "" } }, "RunningInstanceCount": 1 } ], "AutoScalingRole": "EMR_AutoScaling_DefaultRole", "Tags": [], "BootstrapActions": [], "Status": { "Timeline": { "CreationDateTime": 1479413437.339, "ReadyDateTime": 1479413863.666 }, "State": "WAITING", "StateChangeReason": { "Message": "Cluster ready after last step completed." } } } } ``` # Redimensionar manualmente um cluster do Amazon EMR em execução Você pode adicionar e remover instâncias de grupos de instâncias principais e de tarefas e frotas de instâncias em um cluster em execução com a Console de gerenciamento da AWS, AWS CLI, ou a API do Amazon EMR. Se um cluster usa grupos de instâncias, você altera explicitamente a contagem de instâncias. Se o cluster usa frotas de instâncias, você pode alterar as unidades de destino para instâncias sob demanda e instâncias spot. A frota de instâncias, em seguida, adiciona e remove instâncias para corresponder ao novo destino. Para obter mais informações, consulte [Opções de frotas de instâncias](emr-instance-fleet.md#emr-instance-fleet-options). As aplicações podem usar essas instâncias do Amazon EC2 recém-disponibilizadas para hospedar os nós assim que as instâncias se tornarem disponíveis. Quando as instâncias são removidas, o Amazon EMR desativa as tarefas de uma forma que não interrompe os trabalhos e proteções contra a perda de dados. Para obter mais informações, consulte [Terminar na conclusão de tarefas](emr-scaledown-behavior.md#emr-scaledown-terminate-task). ## Redimensionar um cluster usando o console Você pode usar o console do Amazon EMR para redimensionar um cluster em execução. ------ #### [ Console ] **Alterar a contagem de instâncias para um cluster existente usando o novo console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2** no painel de navegação esquerdo, escolha **Clusters** e selecione o cluster que você deseja atualizar. O cluster deve estar em execução, e não é possível redimensionar um cluster provisionado ou terminado. 1. Na guia **Instâncias** da página de detalhes do cluster, visualize o painel **Grupos de instâncias**. 1. Para redimensionar um grupo de instâncias já existente, selecione o botão de opção ao lado do grupo de instâncias central ou de tarefa que você deseja redimensionar e escolha **Redimensionar grupo de instâncias**. Especifique o novo número de instâncias do grupo de instâncias e selecione **Redimensionar**. **nota** Se você optar por reduzir o tamanho de um grupo de instâncias que estão em execução, o Amazon EMR selecionará de forma inteligente as instâncias a serem removidas do grupo para perda mínima de dados. Para um controle mais granular da ação de redimensionamento, você pode selecionar o **ID** do grupo de instâncias, escolher as instâncias que deseja remover e usar a opção **Terminar**. Para obter mais informações sobre o comportamento inteligente de redução da escala verticalmente, consulte [Opções de redução vertical da escala para os clusters do Amazon EMR](emr-scaledown-behavior.md). 1. Para cancelar a ação de redimensionamento, selecione o botão de opção para um grupo de instâncias com o status **Resizing** e escolha **Interromper redimensionamento** na lista de ações. 1. Para adicionar um ou mais grupos de instâncias de tarefa ao cluster em resposta ao aumento da workload, escolha **Adicionar grupo de instâncias de tarefa** na lista de ações. Escolha o tipo de instância do Amazon EC2, insira o número de instâncias para o grupo de tarefa e selecione **Adicionar grupo de instâncias de tarefa** para retornar ao painel **Grupos de instâncias** do cluster. ------ Quando você altera o número de nós, o **Status** do grupo de instâncias é atualizado. Quando a alteração solicitada estiver concluída, o **Status** muda para **Running (Em execução)**. ## Redimensionar um cluster com o AWS CLI Você pode usar o AWS CLI para redimensionar um cluster em execução. Você pode aumentar ou diminuir o número de nós de tarefa, e pode aumentar o número de nós core de um cluster em execução. Também é possível encerrar uma instância no grupo de instâncias principal com a AWS CLI ou a API. Isso deve ser feito com cuidado. Desativar uma instância no grupo de instâncias centrais expõe você ao risco de perda de dados, e a instância não é substituída automaticamente. Além de redimensionar os grupos centrais e de tarefa, você também pode adicionar um ou mais grupos de instâncias de tarefa a um cluster em execução usando a AWS CLI. **Para redimensionar um cluster alterando a contagem de instâncias com o AWS CLI** Você pode adicionar instâncias ao grupo principal ou ao grupo de tarefas e remover instâncias do grupo de tarefas com o AWS CLI `modify-instance-groups` subcomando com o `InstanceCount` parâmetro. Para adicionar instâncias aos grupos core ou de tarefas, aumente o `InstanceCount`. Para reduzir o número de instâncias no grupo de tarefas, diminua o `InstanceCount`. Alterar o número de instâncias do grupo de tarefas para 0 remove todas as instâncias, mas não o grupo de instâncias. + Para aumentar o número de instâncias no grupo de instâncias de tarefas de 3 para 4, digite o comando a seguir e *ig-31JXXXXXXBTO* substitua pelo ID do grupo de instâncias. ``` aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-31JXXXXXXBTO,InstanceCount=4 ``` Para recuperar o `InstanceGroupId`, use o subcomando `describe-cluster`. A saída é um objeto JSON chamado `Cluster` que contém o ID de cada grupo de instâncias. Para usar esse comando, você precisa do ID do cluster (que pode ser recuperado usando o comando `aws emr list-clusters` ou pelo console). Para recuperar o ID do grupo de instâncias, digite o comando a seguir e *j-2AXXXXXXGAPLF* substitua-o pelo ID do cluster. ``` aws emr describe-cluster --cluster-id j-2AXXXXXXGAPLF ``` Com o AWS CLI, você também pode encerrar uma instância no grupo de instâncias principal com o `--modify-instance-groups` subcomando. **Atenção** A especificação de `EC2InstanceIdsToTerminate` deve ser feita com cuidado. As instâncias são encerradas imediatamente, independentemente do status dos aplicativos em execução nelas, e as instâncias não são substituídas automaticamente. Isso é verdadeiro, independentemente da configuração de **Scale down behavior (Comportamento da escalabilidade vertical)** do cluster. O encerramento de uma instância dessa forma tem o risco de perda de dados e de comportamento imprevisível do cluster. Para encerrar uma instância específica, você precisa do ID do grupo de instâncias (retornado pelo `aws emr describe-cluster --cluster-id` subcomando) e do ID da instância (retornado pelo `aws emr list-instances --cluster-id` subcomando), digite o comando a seguir, *ig-6RXXXXXX07SA* substitua pelo ID do grupo de instâncias e *i-f9XXXXf2* substitua pelo ID da instância. ``` 1. aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-6RXXXXXX07SA,EC2InstanceIdsToTerminate=i-f9XXXXf2 ``` Para obter mais informações sobre o uso dos comandos do Amazon EMR no AWS CLI, consulte. [https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr) **Para redimensionar um cluster adicionando grupos de instâncias de tarefas com o AWS CLI** Com o AWS CLI, você pode adicionar de 1 a 48 grupos de instâncias de tarefas a um cluster com o `--add-instance-groups` subcomando. Os grupos de instâncias de tarefa só podem ser adicionados a um cluster contendo um grupo de instâncias primárias e um grupo de instâncias centrais. Ao usar o AWS CLI, você pode adicionar até cinco grupos de instâncias de tarefas sempre que usar o `--add-instance-groups` subcomando. 1. Para adicionar um único grupo de instâncias de tarefas a um cluster, digite o comando a seguir e *j-JXBXXXXXX37R* substitua pelo ID do cluster. ``` 1. aws emr add-instance-groups --cluster-id j-JXBXXXXXX37R --instance-groups InstanceCount=6,InstanceGroupType=task,InstanceType=m5.xlarge ``` 1. Para adicionar vários grupos de instâncias de tarefas a um cluster, digite o comando a seguir e *j-JXBXXXXXX37R* substitua pelo ID do cluster. Você pode adicionar até cinco grupos de instâncias de tarefas em um único comando. ``` aws emr add-instance-groups --cluster-id j-JXBXXXXXX37R --instance-groups InstanceCount=6,InstanceGroupType=task,InstanceType=m5.xlarge InstanceCount=10,InstanceGroupType=task,InstanceType=m5.xlarge ``` Para obter mais informações sobre o uso dos comandos do Amazon EMR no AWS CLI, consulte. [https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr) ## Interromper um redimensionamento Usando o Amazon EMR versão 4.1.0 ou posteriores, você pode iniciar um redimensionamento no meio de uma operação de redimensionamento existente. Além disso, você pode interromper uma solicitação de redimensionamento enviada anteriormente ou enviar uma nova solicitação para substituir uma solicitação anterior, antes mesmo que ela seja concluída. Você também pode interromper um redimensionamento pelo console ou com a chamada de API `ModifyInstanceGroups`, usando a contagem atual como a contagem de destino do cluster. A imagem a seguir mostra um grupo de instâncias de tarefas que está sendo redimensionado mas pode ser interrompido pela opção de **Stop (Interromper)**. ![\[Task instance group showing resizing status with options to resize or stop.\]](http://docs.aws.amazon.com/pt_br/emr/latest/ManagementGuide/images/resize-stop.png) **Para interromper um redimensionamento com o AWS CLI** Você pode usar o AWS CLI para interromper o redimensionamento com o `modify-instance-groups` subcomando. Suponha que você tem seis instâncias em um grupo de instâncias e deseja aumentar este número para 10. E mais tarde você decide cancelar essa solicitação: + A solicitação inicial: ``` aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-myInstanceGroupId,InstanceCount=10 ``` A segunda solicitação para interromper a primeira solicitação: ``` aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-myInstanceGroupId,InstanceCount=6 ``` **nota** Como esse processo é assíncrono, é possível que você veja o número de instâncias ser alterado em relação às solicitações anteriores da API antes que as solicitações subsequentes sejam acatadas. Em caso de redução, se você tiver um trabalho em execução nos nós, é possível que o grupo de instâncias não seja reduzido até que os nós tenham concluído seu trabalho. ## Estado suspenso Um grupo de instâncias entra em estado suspenso se encontrar muitos erros durante a tentativa de iniciar os novos nós do cluster. Por exemplo, se os novos nós falham ao executar ações de bootstrap, o grupo de instâncias entra no estado *SUSPENDED*, em vez de continuar a fornecer novos nós. Depois de resolver o problema básico, redefina o número desejado de nós no grupo de instâncias do cluster e, em seguida, o grupo de instâncias reiniciará a alocação de nós. A modificação de um grupo de instâncias instrui o Amazon EMR a tentar fornecer nós novamente. Os nós em execução não são reiniciados ou encerrados. No AWS CLI, o `list-instances` subcomando retorna todas as instâncias e seus estados, assim como o `describe-cluster` subcomando. Se o Amazon EMR detecta uma falha com um grupo de instâncias, ele altera o estado do grupo para `SUSPENDED`. **Para redefinir um cluster em um estado SUSPENSO com o AWS CLI** Digite o subcomando `describe-cluster` com o parâmetro `--cluster-id` para visualizar o estado das instâncias no cluster. + Para ver informações sobre todas as instâncias e grupos de instâncias em um cluster, digite o comando a seguir e *j-3KVXXXXXXY7UG* substitua pelo ID do cluster. ``` 1. aws emr describe-cluster --cluster-id j-3KVXXXXXXY7UG ``` A saída exibe informações sobre os grupos de instâncias e o estado das instâncias: ``` 1. { 2. "Cluster": { 3. "Status": { 4. "Timeline": { 5. "ReadyDateTime": 1413187781.245, 6. "CreationDateTime": 1413187405.356 7. }, 8. "State": "WAITING", 9. "StateChangeReason": { 10. "Message": "Waiting after step completed" 11. } 12. }, 13. "Ec2InstanceAttributes": { 14. "Ec2AvailabilityZone": "us-west-2b" 15. }, 16. "Name": "Development Cluster", 17. "Tags": [], 18. "TerminationProtected": false, 19. "RunningAmiVersion": "3.2.1", 20. "NormalizedInstanceHours": 16, 21. "InstanceGroups": [ 22. { 23. "RequestedInstanceCount": 1, 24. "Status": { 25. "Timeline": { 26. "ReadyDateTime": 1413187775.749, 27. "CreationDateTime": 1413187405.357 28. }, 29. "State": "RUNNING", 30. "StateChangeReason": { 31. "Message": "" 32. } 33. }, 34. "Name": "MASTER", 35. "InstanceGroupType": "MASTER", 36. "InstanceType": "m5.xlarge", 37. "Id": "ig-3ETXXXXXXFYV8", 38. "Market": "ON_DEMAND", 39. "RunningInstanceCount": 1 40. }, 41. { 42. "RequestedInstanceCount": 1, 43. "Status": { 44. "Timeline": { 45. "ReadyDateTime": 1413187781.301, 46. "CreationDateTime": 1413187405.357 47. }, 48. "State": "RUNNING", 49. "StateChangeReason": { 50. "Message": "" 51. } 52. }, 53. "Name": "CORE", 54. "InstanceGroupType": "CORE", 55. "InstanceType": "m5.xlarge", 56. "Id": "ig-3SUXXXXXXQ9ZM", 57. "Market": "ON_DEMAND", 58. "RunningInstanceCount": 1 59. } 60. ... 61. } ``` Para exibir as informações sobre um grupo de instâncias específico, digite o subcomando `list-instances` com os parâmetros `--cluster-id` e `--instance-group-types`. Você pode visualizar as informações para grupos primários, centrais ou de tarefa. ``` 1. aws emr list-instances --cluster-id j-3KVXXXXXXY7UG --instance-group-types "CORE" ``` Use o subcomando `modify-instance-groups` com o parâmetro `--instance-groups` para redefinir um cluster no estado `SUSPENDED`. O ID do grupo de instâncias é obtido pelo subcomando `describe-cluster`. ``` 1. aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-3SUXXXXXXQ9ZM,InstanceCount=3 ``` ## Considerações ao reduzir o tamanho do cluster Se você optar por reduzir o tamanho de um cluster em execução, leve em consideração o seguinte comportamento e as práticas recomendadas do Amazon EMR: + Para reduzir o impacto nas tarefas que estão em andamento, o Amazon EMR seleciona de forma inteligente as instâncias a serem removidas. Para obter mais informações sobre o comportamento de redução da escala verticalmente do cluster, consulte [Terminar na conclusão de tarefas](emr-scaledown-behavior.md#emr-scaledown-terminate-task) no Guia de gerenciamento do Amazon EMR. + Quando você reduz a escala verticalmente de um cluster, o Amazon EMR copia os dados das instâncias que ele remove para as instâncias que permanecem. Verifique se há capacidade de armazenamento suficiente para esses dados nas instâncias que permanecem no grupo. + O Amazon EMR tenta desativar o HDFS em instâncias do grupo. Antes de reduzir o tamanho de um cluster, é recomendável minimizar a E/S de gravação do HDFS. + Para obter o controle mais granular ao reduzir o tamanho de um cluster, é possível visualizar o cluster no console e navegar até a guia **Instâncias**. Selecione o **ID** do grupo de instâncias que você deseja redimensionar. Em seguida, use a opção **Terminar** para as instâncias específicas que você deseja remover. # Configuração de tempos limite de provisionamento para controlar a capacidade no Amazon EMR Ao usar frotas de instâncias, é possível configurar os *tempos limite de provisionamento*. Um tempo limite de provisionamento instrui o Amazon EMR a interromper o provisionamento da capacidade da instância se o cluster exceder um limite de tempo especificado durante a inicialização do cluster ou as operações de ajuste de escala do cluster. Os tópicos a seguir abordam como configurar um tempo limite de provisionamento para a inicialização do cluster e para operações de aumento da escala verticalmente do cluster. **Topics** + [ # Configurar tempos limite de provisionamento para inicialização de clusters no Amazon EMR ](emr-provisioning-timeout-launch.md) + [ # Personalizar um período de tempo limite de provisionamento para redimensionamento do cluster no Amazon EMR ](emr-provisioning-timeout-resize.md) # Configurar tempos limite de provisionamento para inicialização de clusters no Amazon EMR Você pode definir um período de tempo limite para provisionar instâncias spot para cada frota do cluster. Se o Amazon EMR não puder provisionar a capacidade spot, você escolhe entre terminar o cluster ou provisionar a capacidade sob demanda. Se o período de tempo limite acabar durante o processo de redimensionamento do cluster, o Amazon EMR cancelará solicitações spot não provisionadas. As instâncias spot que não foram provisionadas não são transferidas para a capacidade sob demanda. Execute as etapas a seguir para personalizar um período de tempo limite de provisionamento para inicialização do cluster usando o console do Amazon EMR. ------ #### [ Console ] **Para configurar o tempo limite de provisionamento ao criar um cluster usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters** e depois **Criar cluster**. 1. Na página **Criar cluster**, navegue até **Configuração do cluster** e selecione **Frotas de instâncias**. 1. Em **Opção de ajuste de escala e provisionamento de clusters**, especifique o tamanho do spot para suas frotas centrais e de tarefa. 1. Em **Configuração de tempo limite spot**, selecione **Terminar cluster após o tempo limite spot** ou **Alternar para sob demanda após tempo limite spot**. Em seguida, especifique o período de tempo limite para provisionamento de instâncias spot. O valor padrão é uma hora. 1. Escolha qualquer outra opção que se aplique ao cluster. 1. Para iniciar o cluster com o tempo limite configurado, escolha **Criar cluster**. ------ #### [ AWS CLI ] **Especificar um tempo limite de provisionamento com o comando `create-cluster`** ``` aws emr create-cluster \ --release-label emr-5.35.0 \ --service-role EMR_DefaultRole \ --ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \ --instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"LaunchSpecifications":{"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]' ``` ------ # Personalizar um período de tempo limite de provisionamento para redimensionamento do cluster no Amazon EMR É possível definir um período de tempo limite para provisionar instâncias spot para cada frota do cluster. Se o Amazon EMR não conseguir provisionar a capacidade spot, ele cancelará a solicitação de redimensionamento e interromperá as tentativas de provisionar capacidade spot adicional. Ao criar um cluster, é possível configurar o tempo limite. Em um cluster em execução, é possível adicionar ou atualizar um tempo limite. Quando o período de tempo limite expira, o Amazon EMR envia automaticamente os eventos para um stream do Amazon Events. CloudWatch Com CloudWatch, você pode criar regras que correspondam aos eventos de acordo com um padrão especificado e, em seguida, rotear os eventos aos alvos para que sejam executadas ações. Por exemplo, é possível configurar uma regra para enviar uma notificação por e-mail. Para obter mais informações sobre como criar regras, consulte [Criação de regras para eventos do Amazon EMR com CloudWatch](emr-events-cloudwatch-console.md). Para obter mais informações sobre diferentes detalhes de evento, consulte [Eventos de alteração de estado da frota de instâncias](emr-manage-cloudwatch-events.md#emr-cloudwatch-instance-fleet-events). ## Exemplos de tempos limite de provisionamento para redimensionamento de clusters **Especifique um tempo limite de provisionamento para redimensionar usando a AWS CLI** O exemplo a seguir usa o comando `create-cluster` para adicionar um tempo limite de provisionamento para redimensionamento. ``` aws emr create-cluster \ --release-label emr-5.35.0 \ --service-role EMR_DefaultRole \ --ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \ --instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":20},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":25}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]' ``` O exemplo a seguir usa o comando `modify-instance-fleet` para adicionar um tempo limite de provisionamento para redimensionamento. ``` aws emr modify-instance-fleet \ --cluster-id j-XXXXXXXXXXXXX \ --instance-fleet '{"InstanceFleetId":"if-XXXXXXXXXXXX","ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":30},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":60}}}' \ --region us-east-1 ``` O exemplo a seguir usa `add-instance-fleet-command` para adicionar um tempo limite de provisionamento para redimensionamento. ``` aws emr add-instance-fleet \ --cluster-id j-XXXXXXXXXXXXX \ --instance-fleet '{"InstanceFleetType":"TASK","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"TaskFleet","ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":30},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":35}}}' \ --region us-east-1 ``` **Especifique um tempo limite de provisionamento para redimensionar e iniciar com o AWS CLI** O exemplo a seguir usa o comando `create-cluster` para adicionar um tempo limite de provisionamento para redimensionamento e inicialização. ``` aws emr create-cluster \ --release-label emr-5.35.0 \ --service-role EMR_DefaultRole \ --ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \ --instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"LaunchSpecifications":{"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":20},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":25}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]' ``` ## Considerações para redimensionamento dos tempos limite de provisionamento Ao configurar os tempos limite de provisionamento de clusters para suas frotas de instâncias, leve em consideração os comportamentos a seguir. + É possível configurar os tempos limite de provisionamento para instâncias spot e sob demanda. O tempo limite mínimo de provisionamento é de cinco minutos. O tempo limite máximo de provisionamento é de sete dias. + Só é possível configurar tempos limite de provisionamento para um cluster do EMR que usa frotas de instâncias. É necessário configurar cada frota central e de tarefa separadamente. + Ao criar um cluster, você pode configurar os tempos limite de provisionamento. É possível adicionar um tempo limite ou atualizar um tempo limite atual para um cluster em execução. + Se você enviar múltiplas operações de redimensionamento, o Amazon EMR rastreará os tempos limite de provisionamento para cada operação de redimensionamento. Por exemplo, defina o tempo limite de provisionamento em um cluster para minutos. *60* Em seguida, envie uma operação de redimensionamento *R1* por vez. *T1* Envie uma segunda operação de redimensionamento *R2* por vez. *T2* O tempo limite de provisionamento para R1 expira em. *T1 \$1 60 minutes* O tempo limite de provisionamento para R2 expira em. *T2 \$1 60 minutes* + Se você enviar uma nova operação de redimensionamento para aumentar a escala verticalmente antes que o tempo limite expire, o Amazon EMR continuará sua tentativa de provisionar capacidade para o cluster do EMR. # Opções de redução vertical da escala para os clusters do Amazon EMR **nota** Não há mais suporte para as opções de comportamento de redução da escala verticalmente desde o Amazon EMR versão 5.10.0. Por causa da introdução do faturamento por segundo no Amazon EC2, o comportamento padrão da redução da escala verticalmente para clusters do Amazon EMR agora é terminar na conclusão da tarefa. Com o Amazon EMR versões 5.1.0 a 5.9.1, há duas opções para o comportamento da redução da escala verticalmente: terminar no limite de instâncias por hora de acordo com o faturamento do Amazon EC2 ou terminar quando a tarefa for concluída. A partir do Amazon EMR versão 5.10.0, a configuração de término ao atingir o limite de hora de instância se torna defasada por causa da introdução do faturamento por segundo no Amazon EC2. Não recomendamos especificar o encerramento no limite de runtime da instância em que a opção está disponível. **Atenção** Se você usar o AWS CLI para emitir um `modify-instance-groups` com`EC2InstanceIdsToTerminate`, essas instâncias serão encerradas imediatamente, sem considerar essas configurações e independentemente do status dos aplicativos em execução nelas. O encerramento de uma instância dessa forma tem o risco de perda de dados e de comportamento imprevisível do cluster. Quando o término na conclusão da tarefa é especificado, o Amazon EMR colocas as tarefas em listas de negação e as remove dos nós antes de terminar as instâncias do Amazon EC2. Em ambos os comportamentos especificados, o Amazon EMR não termina as instâncias do Amazon EC2 em grupos de instâncias centrais se houver a possibilidade de danos ao HDFS. ## Terminar na conclusão de tarefas O Amazon EMR permite que você reduzir a escala verticalmente do cluster sem afetar a sua workload. O Amazon EMR tenta desativar gradualmente o YARN, o HDFS e os outros daemons nos nós centrais e nós de tarefa durante uma operação de redimensionamento para redução sem perder dados nem interromper trabalhos. O Amazon EMR reduzirá o tamanho de grupos de instâncias somente se o trabalho atribuído a eles tiver sido concluído e eles estiverem ociosos. Para o YARN NodeManager Graceful Decommission, você pode ajustar manualmente o tempo que um nó espera pelo descomissionamento. **nota** Quando ocorre um descomissionamento normal, pode haver perda de dados. Certifique-se de fazer backup dos seus dados. **Importante** É possível que os dados do HDFS sejam perdidos permanentemente durante a substituição normal de uma instância central não íntegra. Recomendamos sempre fazer backup dos dados. Este tempo é definido usando uma propriedade na a classificação de configuração `YARN-site`. Usando o Amazon EMR versão 5.12.0 e posterior, especifique a propriedade `YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs`. Ao usar versões anteriores do Amazon EMR, especifique a propriedade `YARN.resourcemanager.decommissioning.timeout`. Se ainda houver contêineres ou aplicativos do YARN em execução quando o tempo limite de desativação for ultrapassado, o nó será obrigatoriamente desativado e o YARN reprogramará os contêineres afetados em outros nós. O valor padrão é de 3.600 segundos (uma hora). Você pode definir esse tempo limite com um valor arbitrariamente alto para forçar a redução amigável a esperar mais tempo. Para obter mais informações, consulte [Graceful Decommission of YARN nodes](http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/GracefulDecommission.html) na documentação do Apache Hadoop. ### Grupos de nós de tarefa O Amazon EMR seleciona, de forma inteligente, as instâncias que não têm tarefas em execução relacionadas a etapas ou aplicações e as remove primeiro do cluster. Se todas as instâncias do cluster estiverem em uso, o Amazon EMR aguardará a conclusão das tarefas da instância antes de removê-la do cluster. O tempo de espera padrão é 1 hora. Esse valor pode ser alterado com a configuração `YARN.resourcemanager.decommissioning.timeout`. O Amazon EMR usa a nova configuração dinamicamente. Você pode definir isso como um número arbitrariamente grande para garantir que o Amazon EMR não termine nenhuma tarefa ao reduzir o tamanho do cluster. ### Grupos de nós centrais Nos nós principais, os DataNode daemons YARN NodeManager e HDFS devem ser desativados para que o grupo de instâncias seja reduzido. Para o YARN, a redução amigável garante que um nó marcado para desativação seja passado para o estado `DECOMMISSIONED` somente se não houver contêineres ou aplicações pendentes ou não concluídas. A desativação termina imediatamente se não há contêineres em execução no nó no início da desativação. Para o HDFS, a redução amigável certifica-se de que a capacidade de destino do HDFS é grande o suficiente para comportar todos os blocos existentes. Se a capacidade alvo não for grande o suficiente, apenas uma parte das instâncias core serão desativadas, de forma que os nós restantes possam lidar com os dados atuais residentes no HDFS. Você deve garantir o aumento da capacidade no HDFS para permitir uma desativação mais extensa. Você também deve tentar minimizar a gravação I/O antes de tentar reduzir os grupos de instâncias. A gravação excessiva I/O pode atrasar a conclusão da operação de redimensionamento. Outro limite é o fator de replicação padrão `dfs.replication` no `/etc/hadoop/conf/hdfs-site`. Ao criar um cluster, o Amazon EMR configura o valor com base no número de instâncias no cluster: `1` para clusters com uma a três instâncias, `2` para clusters com quatro a nove instâncias e `3` para clusters com mais de dez instâncias. **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. A redução amigável não permite reduzir os nós centrais abaixo do fator de replicação do HDFS. Isso permite que o HDFS feche arquivos devido à insuficiência de réplicas. Para contornar esse limite, diminua o fator de replicação e reinicie o daemon. NameNode # Configurar o comportamento de redução da escala verticalmente do Amazon EMR **nota** A opção de comportamento de redução da escala verticalmente de terminar na hora da instância não é mais compatível com o Amazon EMR 5.10.0 e versões posteriores. As opções de comportamento de redução da escala verticalmente a seguir são exibidas no console do Amazon EMR somente nas versões 5.1.0 a 5.9.1. Você pode usar a Console de gerenciamento da AWS AWS CLI, a ou a API do Amazon EMR para configurar o comportamento de redução ao criar um cluster. ------ #### [ Console ] **Para configurar o comportamento de redução da escala verticalmente usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters** e depois **Criar cluster**. 1. Na seção **Opção de ajuste de escala e provisionamento de clusters**, escolha **Usar ajuste de escala automático personalizado**. Em **Políticas personalizadas de ajuste de escala automático**, escolha o **botão de ação adicional** para adicionar políticas de **Redução horizontal da escala**. Recomendamos adicionar as políticas de **Redução horizontal da escala** e **Aumento horizontal da escala**. Adicionar apenas um conjunto de políticas significa que o Amazon EMR executará apenas o ajuste de escala unidirecional, e você precisará executar manualmente as outras ações. 1. Escolha qualquer outra opção que se aplique ao cluster. 1. Para iniciar o cluster, escolha **Criar cluster**. ------ #### [ AWS CLI ] **Para configurar o comportamento de redução de escala com o AWS CLI** + Use a opção `--scale-down-behavior` para especificar `TERMINATE_AT_INSTANCE_HOUR` ou `TERMINATE_AT_TASK_COMPLETION`. ------ # Encerramento de um cluster do Amazon EMR em estado iniciando, executando ou aguardando **Atenção** Um cluster do EMR encerrado é irrecuperável. Certifique-se de que o recurso e quaisquer dados nos notebooks HDFS ou Jupyter não sejam mais necessários antes da remoção. Os dados do HDFS são perdidos quando o cluster é encerrado. Esta seção descreve os métodos de encerramento de um cluster. Para obter informações sobre como habilitar a proteção contra encerramento e encerrar clusters automaticamente, consulte [Controlar o encerramento de cluster do Amazon EMR](emr-plan-termination.md). Você pode encerrar clusters nos estados `STARTING`, `RUNNING`ou `WAITING`. Um cluster no estado `WAITING` deve ser encerrado ou ele será executado indefinidamente, gerando encargos para sua conta. Você pode encerrar um cluster que não sai do estado `STARTING` ou que não consegue concluir uma etapa. Se quiser encerrar um cluster que possui proteção de encerramento, deve primeiro desativar essa proteção antes de encerrar o cluster. Os clusters podem ser encerrados usando o console AWS CLI, o ou programaticamente usando a API. `TerminateJobFlows` Dependendo da configuração do cluster, pode levar entre 5 a 20 minutos para concluir o encerramento e liberar recursos alocados tais como instâncias do EC2. **nota** Você não pode reiniciar um cluster terminado, mas pode clonar um cluster terminado para reutilizar a configuração dele em um novo cluster. Para obter mais informações, consulte [Como clonar um cluster do Amazon EMR usando o console](clone-console.md). **Importante** O Amazon EMR usa o [perfil de serviço do Amazon EMR](emr-iam-role.md) e a função `AWSServiceRoleForEMRCleanup` para limpar recursos de cluster em sua conta que você não usa mais, como instâncias do Amazon EC2. Você deve incluir ações nas políticas de função para excluir ou encerrar os recursos. Caso contrário, o Amazon EMR não poderá realizar essas ações de limpeza, e você poderá ter custos com recursos não utilizados que permanecem no cluster. ## Encerrrar um cluster com o console Você pode terminar um ou mais clusters usando o console do Amazon EMR. As etapas para encerrar um cluster no console variam de acordo com o estado da proteção de encerramento, ou seja, se a proteção está ativada ou não. Para encerrar um cluster protegido, você deve primeiro desativar a proteção de encerramento. ------ #### [ Console ] **Para encerrar um cluster usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Escolha **Clusters** e, em seguida, selecione o cluster que você deseja encerrar. 1. No menu suspenso **Ações**, escolha **Terminar cluster** para abrir o prompt **Terminar cluster**. 1. No prompt, escolha **Terminar**. Dependendo da configuração do cluster, o encerramento pode demorar de cinco a dez minutos. Para obter mais informações sobre os clusters do Amazon EMR, consulte [Encerramento de um cluster do Amazon EMR em estado iniciando, executando ou aguardando](#UsingEMR_TerminateJobFlow). ------ ## Encerre um cluster com o AWS CLI **Para encerrar um cluster desprotegido usando o AWS CLI** Para encerrar um cluster desprotegido usando o AWS CLI, use o `terminate-clusters` subcomando com o parâmetro --cluster-ids. + Digite o comando a seguir para encerrar um único cluster e *j-3KVXXXXXXX7UG* substituí-lo pelo ID do cluster. ``` 1. aws emr terminate-clusters --cluster-ids j-3KVXXXXXXX7UG ``` Para encerrar vários clusters, digite o comando a seguir e substitua *j-3KVXXXXXXX7UG* e *j-WJ2XXXXXX8EU* pelo seu cluster IDs. ``` 1. aws emr terminate-clusters --cluster-ids j-3KVXXXXXXX7UG j-WJ2XXXXXX8EU ``` Para obter mais informações sobre o uso dos comandos do Amazon EMR no AWS CLI, consulte. [https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr) **Para encerrar um cluster protegido usando o AWS CLI** Para encerrar um cluster protegido usando o AWS CLI, primeiro desative a proteção de encerramento usando o `modify-cluster-attributes` subcomando com o `--no-termination-protected` parâmetro. Em seguida, use o subcomando `terminate-clusters` com o parâmetro `--cluster-ids` para encerrá-lo. 1. Digite o comando a seguir para desativar a proteção contra encerramento e *j-3KVTXXXXXX7UG* substituí-la pela ID do cluster. ``` 1. aws emr modify-cluster-attributes --cluster-id j-3KVTXXXXXX7UG --no-termination-protected ``` 1. Para encerrar o cluster, digite o comando a seguir e *j-3KVXXXXXXX7UG* substitua pelo ID do cluster. ``` 1. aws emr terminate-clusters --cluster-ids j-3KVXXXXXXX7UG ``` Para encerrar vários clusters, digite o comando a seguir e substitua *j-3KVXXXXXXX7UG* e *j-WJ2XXXXXX8EU* pelo seu cluster IDs. ``` 1. aws emr terminate-clusters --cluster-ids j-3KVXXXXXXX7UG j-WJ2XXXXXX8EU ``` Para obter mais informações sobre o uso dos comandos do Amazon EMR no AWS CLI, consulte. [https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr) ## Encerrrar um cluster com a API A operação `TerminateJobFlows` interrompe o processamento da etapa, carrega dados de log do Amazon EC2 para o Amazon S3 (se configurado) e termina o cluster do Hadoop. Um cluster também é encerrado automaticamente se você definir `KeepJobAliveWhenNoSteps` como `False` em uma solicitação `RunJobFlows`. Você pode usar essa ação para encerrar um único cluster ou uma lista de clusters por cluster IDs. Para obter mais informações sobre os parâmetros de entrada exclusivos de`TerminateJobFlows`, consulte [ TerminateJobFlows](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_TerminateJobFlows.html). Para obter mais informações sobre os parâmetros genéricos na solicitação, consulte [Common request parameters](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/CommonParameters.html). # Como clonar um cluster do Amazon EMR usando o console Você pode usar o console do Amazon EMR para clonar um cluster, que faz uma cópia da configuração do cluster original para ser usada como base em um novo cluster. ------ #### [ Console ] **Para clonar um cluster usando o console** 1. [Faça login no e abra Console de gerenciamento da AWS o console do Amazon EMR em https://console.aws.amazon.com /emr.](https://console.aws.amazon.com/emr) 1. Em **EMR no EC2**, no painel de navegação esquerdo, escolha **Clusters**. 1. *Clonar um cluster da lista de clusters* 1. Use as opções de pesquisa e de filtro para encontrar o cluster que você deseja clonar na visualização de lista. 1. Marque a caixa de seleção à esquerda da linha do cluster que deseja clonar. 1. A opção **Clonar** já estará disponível na parte superior da visualização da lista. Selecione **Clonar** para iniciar o processo de clonagem. Se o cluster tiver etapas configuradas, escolha **Incluir etapas** e **Continuar** para clonar as etapas junto com as outras configurações do cluster. 1. Revise as configurações do novo cluster que foram copiadas do cluster clonado. Ajuste as configurações, se necessário. Quando a configuração do novo cluster estiver satisfatória, selecione **Criar cluster** para iniciar o novo cluster. 1. *Clonar um cluster na página de detalhes do cluster* 1. Para navegar até a página de detalhes do cluster que você deseja clonar, selecione o **ID do cluster** na visualização da lista de clusters. 1. Na parte superior da página de detalhes do cluster, selecione **Clonar cluster** no menu **Ações** para iniciar o processo de clonagem. Se o cluster tiver etapas configuradas, escolha **Incluir etapas** e **Continuar** para clonar as etapas junto com as outras configurações do cluster. 1. Revise as configurações do novo cluster que foram copiadas do cluster clonado. Ajuste as configurações, se necessário. Quando a configuração do novo cluster estiver satisfatória, selecione **Criar cluster** para iniciar o novo cluster. ------ # Automatize clusters recorrentes do Amazon EMR com AWS Data Pipeline **nota** AWS O Data Pipeline não está mais disponível para novos clientes. Os clientes existentes do AWS Data Pipeline podem continuar usando o serviço normalmente. AWS Data Pipeline é um serviço que automatiza a movimentação e a transformação dos dados. Você pode usá-lo para programar a movimentação de dados de entrada para o Amazon S3 e para programar a inicialização de clusters para processar dados. Por exemplo, considere o caso em que você tenha um servidor web gravando logs de tráfego. Se você quiser executar um cluster semanal para analisar os dados de tráfego, você pode usá-lo AWS Data Pipeline para programar esses clusters. AWS Data Pipeline é um fluxo de trabalho orientado por dados, de modo que uma tarefa (iniciar o cluster) pode depender de outra tarefa (mover os dados de entrada para o Amazon S3). Ele também tem uma funcionalidade de novas tentativas robusta. Para obter mais informações sobre AWS Data Pipeline, consulte o [Guia do AWS Data Pipeline desenvolvedor](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/what-is-datapipeline.html), especialmente os tutoriais sobre o Amazon EMR: + [Tutorial: iniciar um fluxo de trabalho do Amazon EMR](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-launch-emr-jobflow.html) + [Introdução: processe registros da web com o AWS Data Pipeline Amazon EMR e o Hive](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-process-logs.html) + [Tutorial: importação e exportação do Amazon DynamoDB usando AWS Data Pipeline](https://docs.aws.amazon.com/datapipeline/latest/DeveloperGuide/dp-importexport-ddb.html)