

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á.

# Registro em log e monitoramento
<a name="logging-monitoring"></a>

O monitoramento é uma parte importante para manter a confiabilidade, a disponibilidade e a performance de aplicações e trabalhos do Amazon Sem Servidor. Você deve coletar dados de monitoramento de todas as partes de suas soluções EMR Sem Servidor para que falhas multiponto possam ser depuradas mais facilmente, caso ocorram.

**Topics**
+ [Armazenamento de logs](logging.md)
+ [Logs alternados](rotating-logs.md)
+ [Criptografia de logs](jobs-log-encryption.md)
+ [Configuração das propriedades do Apache Log4j2 para o Amazon EMR Sem Servidor](log4j2.md)
+ [Monitoramento do EMR Sem Servidor](metrics.md)
+ [Automatizando o EMR sem servidor com Amazon EventBridge](using-eventbridge.md)

# Armazenamento de logs
<a name="logging"></a>

Para monitorar o progresso do seu trabalho no EMR Sem Servidor e solucionar falhas de trabalho, escolha como o EMR Sem Servidor armazena e veicula os logs de aplicações. Ao enviar uma execução de trabalho, especifique armazenamento gerenciado, Amazon S3 e Amazon CloudWatch como suas opções de registro.

Com CloudWatch, especifique os tipos e locais de registro que você deseja usar ou aceite os tipos e locais padrão. Para obter mais informações sobre CloudWatch registros, consulte[Registro no EMR Serverless com a Amazon CloudWatch](#jobs-log-storage-cw). Com o armazenamento gerenciado e os logs do S3, a tabela a seguir lista os locais de log e a disponibilidade da interface do usuário que você pode esperar se escolher [armazenamento gerenciado](#jobs-log-storage-managed-storage), [buckets do Amazon S3](#jobs-log-storage-s3-buckets) ou ambos.


| Opção | Logs de eventos | Logs de contêineres | Interfaces de usuário de aplicações | 
| --- | --- | --- | --- | 
|  Armazenamento gerenciado  |  Armazenamento gerenciado  |  Armazenamento gerenciado  |  Compatível  | 
|  Armazenamento gerenciado e bucket do S3  |  Armazenado em ambos os locais  |  Armazenado no bucket do S3  |  Compatível  | 
|  Bucket do Amazon S3.  |  Armazenado no bucket do S3  |  Armazenado no bucket do S3  |  Sem suporte1  | 

1 Sugerimos manter a opção **Armazenamento gerenciado** selecionada. Caso contrário, você não poderá usar o aplicativo integrado UIs.

## Registro em log do EMR Sem Servidor com armazenamento gerenciado
<a name="jobs-log-storage-managed-storage"></a>

Por padrão, o EMR Sem Servidor armazena logs de aplicações com segurança no armazenamento gerenciado do Amazon EMR por no máximo 30 dias.

**nota**  
Se você desativar a opção padrão, o Amazon EMR não poderá solucionar problemas de trabalhos em seu nome. Exemplo: você não pode acessar a Spark-UI a partir do console do ERM sem Servidor.

Para desativar essa opção no EMR Studio, **desmarque AWS a caixa de seleção Permitir reter registros por 30 dias** na seção **Configurações adicionais** da página **Enviar** trabalho. 

Para desativar essa opção no AWS CLI, use a `managedPersistenceMonitoringConfiguration` configuração ao enviar uma execução de trabalho.

```
{
    "monitoringConfiguration": {
        "managedPersistenceMonitoringConfiguration": {
            "enabled": false
        }
    }
}
```

Se a sua aplicação do EMR Sem Servidor estiver em uma sub-rede privada com endpoints de VPC para o Amazon S3 e você anexar uma política de endpoint para controlar o acesso, adicione as seguintes permissões para que o EMR Sem Servidor armazene e forneça logs de aplicações. Substitua `Resource` pelos buckets `AppInfo` da tabela de regiões disponíveis em [Exemplos de políticas para sub-redes privadas que acessam o Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/private-subnet-iampolicy.html#private-subnet-iampolicy-regions).

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "EMRServerlessManagedLogging",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:s3:::prod.us-east-1.appinfo.src",
        "arn:aws:s3:::prod.us-east-1.appinfo.src/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalServiceName": "emr-serverless.amazonaws.com",
          "aws:SourceVpc": "vpc-12345678"
        }
      }
    }
  ]
}
```

------

Além disso, use a chave de condição `aws:SourceVpc` para garantir que a solicitação passe pela VPC à qual o endpoint da VPC está conectado.

## Registro em log do EMR Sem Servidor com buckets do Amazon S3
<a name="jobs-log-storage-s3-buckets"></a>

Antes que os trabalhos possam enviar dados de log ao Amazon S3, as permissões apresentadas a seguir devem ser incluídas na política de permissões para o perfil de runtime do trabalho. Substitua `amzn-s3-demo-logging-bucket` pelo nome do bucket de registro em log.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket/*"
      ],
      "Sid": "AllowS3Putobject"
    }
  ]
}
```

------

Para configurar um bucket do Amazon S3 para armazenar registros do AWS CLI, use a `s3MonitoringConfiguration` configuração ao iniciar a execução de um trabalho. Para fazer isso, forneça o `--configuration-overrides` a seguir na configuração. 

```
{
    "monitoringConfiguration": {
        "s3MonitoringConfiguration": {
            "logUri": "s3://amzn-s3-demo-logging-bucket/logs/"
        }
    }
}
```

Em trabalhos em lotes que não têm novas tentativas habilitadas, o EMR Sem Servidor envia os logs para o seguinte caminho:

```
'/applications/<applicationId>/jobs/<jobId>'
```

Os logs do driver do Spark são armazenados no seguinte caminho pelo EMR Sem Servidor

```
'/applications/<applicationId>/jobs/<jobId>/SPARK_DRIVER/'
```

Os logs do executor do Spark são armazenados no seguinte caminho pelo EMR Sem Servidor

```
'/applications/<applicationId>/jobs/<jobId>/SPARK_EXECUTOR/<EXECUTOR-ID>'
```

O <EXECUTOR-ID> é um número inteiro.

As versões 7.1.0 e posteriores do EMR Sem Servidor oferecem suporte a novas tentativas para trabalhos de streaming e em lote. Se você executar um trabalho com novas tentativas habilitadas, o EMR Sem Servidor adicionará automaticamente um número de tentativas ao prefixo do caminho do log, para que você possa distinguir e rastrear melhor os logs.

```
'/applications/<applicationId>/jobs/<jobId>/attempts/<attemptNumber>/'
```

## Registro no EMR Serverless com a Amazon CloudWatch
<a name="jobs-log-storage-cw"></a>

Ao enviar um trabalho para um aplicativo EMR Serverless, escolha a Amazon CloudWatch como uma opção para armazenar os registros do seu aplicativo. Isso permite que você use recursos de análise de CloudWatch registros, como CloudWatch Logs Insights e Live Tail. Você também pode transmitir registros CloudWatch para outros sistemas, por exemplo, OpenSearch para análise posterior.

O EMR Sem Servidor fornece registro em log em tempo real para logs de drivers. Você pode acessar os registros em tempo real com o recurso de cauda ao CloudWatch vivo ou por meio de comandos de cauda da CloudWatch CLI.

Por padrão, o CloudWatch registro está desativado para o EMR Serverless. Para habilitá-lo, use a configuração em [AWS CLI](#jobs-log-storage-cw-cli).

**nota**  
A Amazon CloudWatch publica registros em tempo real, portanto, gera mais recursos dos trabalhadores. Se você escolher uma baixa capacidade de trabalhador, o impacto no runtime do trabalho poderá aumentar. Se você ativar o CloudWatch registro, sugerimos que escolha uma capacidade de trabalho maior. Também é possível que a publicação de logs faça controle de utilização se a taxa de transações por segundo (TPS) for muito baixa para `PutLogEvents`. A configuração de CloudWatch limitação é global para todos os serviços, incluindo o EMR Serverless. Para obter mais informações, consulte [Como determino a limitação em meus registros? CloudWatch ](https://repost.aws/knowledge-center/cloudwatch-logs-throttling) em *AWS re:post*.

### Permissões necessárias para fazer login com CloudWatch
<a name="jobs-log-storage-cw-permissions"></a>

Antes que seus trabalhos possam enviar dados de log para a Amazon CloudWatch, inclua as seguintes permissões na política de permissões para a função de tempo de execução do trabalho.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:DescribeLogGroups"
      ],
      "Resource": [
        "arn:aws:logs:*:123456789012:*"
      ],
      "Sid": "AllowLOGSDescribeloggroups"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:123456789012:log-group:my-log-group-name:*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

### AWS CLI
<a name="jobs-log-storage-cw-cli"></a>

Para configurar a Amazon CloudWatch para armazenar registros do EMR Serverless a partir do AWS CLI, use a `cloudWatchLoggingConfiguration` configuração ao iniciar a execução de um trabalho. Para fazer isso, forneça as substituições de configuração a seguir. Opcionalmente, forneça um nome de grupo de logs, nome de prefixo de fluxo de logs, tipos de log e um ARN de chave de criptografia.

Se você não especificar os valores opcionais, CloudWatch publicará os registros em um grupo de registros padrão`/aws/emr-serverless`, com o fluxo `/applications/applicationId/jobs/jobId/worker-type` de registros padrão.

As versões 7.1.0 e posteriores do EMR Sem Servidor oferecem suporte a novas tentativas para trabalhos de streaming e em lote. Se você habilitou novas tentativas para um trabalho, o EMR Sem Servidor adiciona automaticamente um número de tentativas ao prefixo do caminho do log, para que você possa distinguir e rastrear melhor os logs. 

```
'/applications/<applicationId>/jobs/<jobId>/attempts/<attemptNumber>/worker-type'
```

O seguinte demonstra a configuração mínima necessária para ativar o Amazon CloudWatch Logging com as configurações padrão para o EMR Serverless:

```
{
    "monitoringConfiguration": {
        "cloudWatchLoggingConfiguration": {
            "enabled": true
         }
     }
}
```

O exemplo a seguir mostra todas as configurações obrigatórias e opcionais que especificam quando você ativa o Amazon CloudWatch Logging para o EMR Serverless. Os valores de `logTypes` aceitos também estão listados no exemplo a seguir.

```
{
    "monitoringConfiguration": {
        "cloudWatchLoggingConfiguration": {
            "enabled": true, // Required
            "logGroupName": "Example_logGroup", // Optional
            "logStreamNamePrefix": "Example_logStream", // Optional 
            "encryptionKeyArn": "key-arn", // Optional 
            "logTypes": { 
                "SPARK_DRIVER": ["stdout", "stderr"] //List of values
             }
         }
     }
}
```

Por padrão, o EMR Serverless publica somente os registros do driver stdout e stderr em. CloudWatch Se quiser outros logs, especifique um perfil de contêiner e os tipos de log correspondentes com o campo `logTypes`.

A seguinte lista mostra os tipos de trabalhadores compatíveis que você pode especificar na configuração `logTypes`:

**Spark**  
+ `SPARK_DRIVER : ["STDERR", "STDOUT"]`
+ `SPARK_EXECUTOR : ["STDERR", "STDOUT"]`

**Hive**  
+ `HIVE_DRIVER : ["STDERR", "STDOUT", "HIVE_LOG", "TEZ_AM"]`
+ `TEZ_TASK : ["STDERR", "STDOUT", "SYSTEM_LOGS"]`

# Logs alternados
<a name="rotating-logs"></a>

O Amazon EMR Sem Servidor pode alternar logs de aplicações e logs de eventos do Spark. A alternância de logs ajuda com o problema de trabalhos de longa execução, gerando grandes arquivos de log que podem ocupar todo o espaço em disco. A alternância de logs ajuda a economizar armazenamento em disco e reduz a quantidade de falhas de trabalho por não haver mais espaço no disco. 

A alternância de logs está habilitada por padrão e disponível somente para trabalhos do Spark.

**Logs de eventos do Spark**

**nota**  
A alternância de logs de eventos do Spark está disponível em todos os rótulos de lançamento do Amazon EMR.

Em vez de gerar um único arquivo de log de eventos, o EMR Sem Servidor alterna o log de eventos em um intervalo de tempo regular e remove os arquivos de log de eventos mais antigos. A alternância de logs não afeta os logs enviados ao bucket do S3.

**Logs de aplicação do Spark**

**nota**  
A alternância de logs de aplicação do Spark está disponível em todos os rótulos de lançamento do Amazon EMR.

O EMR Sem Servidor também alterna os logs de aplicação do Spark para drivers e executores, como arquivos `stdout` e `stderr`. Você pode acessar os arquivos de log mais recentes escolhendo os links de log no Studio e usando os links da interface de usuário do Live e do servidor de histórico do Spark. Os arquivos de log são as versões truncadas dos logs mais recentes. Para consultar os logs alternados mais antigos, especifique uma localização do Amazon S3 ao armazenar os logs. Consulte [Registro em log para o EMR Sem Servidor com buckets do S3](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html#jobs-log-storage-s3-buckets) para obter mais informações.

Você encontrará os arquivos de log mais recentes no local a seguir. O EMR Sem Servidor atualiza os arquivos a cada 15 segundos. Esses arquivos podem variar de 0 MB a 128 MB.

```
<example-S3-logUri>/applications/<application-id>/jobs/<job-id>/SPARK_DRIVER/stderr.gz
```

O local a seguir contém os arquivos alternados mais antigos. Cada arquivo tem 128 MB.

```
<example-S3-logUri>/applications/<application-id>/jobs/<job-id>/SPARK_DRIVER/archived/stderr_<index>.gz 
```

O mesmo comportamento também se aplica aos executores do Spark. Essa alteração é aplicável somente ao registro em log do S3. A rotação de registros não introduz nenhuma alteração nos fluxos de registros enviados para a Amazon CloudWatch.

As versões 7.1.0 e posteriores do EMR Sem Servidor oferecem suporte a novas tentativas para trabalhos de streaming e em lote. Se você habilitou novas tentativas no trabalho, o EMR Sem Servidor adiciona um prefixo ao caminho de log para esses trabalhos, para que você possa rastrear e distinguir melhor os logs uns dos outros. Esse caminho contém todos os logs alternados.

```
'/applications/<applicationId>/jobs/<jobId>/attempts/<attemptNumber>/'.
```

# Criptografia de logs
<a name="jobs-log-encryption"></a>

## Criptografia de logs do EMR Sem Servidor com armazenamento gerenciado
<a name="jobs-log-encryption-managed-storage"></a>

Para criptografar logs no armazenamento gerenciado com sua própria chave do KMS, use a configuração `managedPersistenceMonitoringConfiguration` ao enviar uma execução de trabalho.

```
{
    "monitoringConfiguration": {
        "managedPersistenceMonitoringConfiguration" : {
            "encryptionKeyArn": "key-arn"
        }
    }
}
```

## Criptografia de logs do EMR Sem Servidor com buckets do Amazon S3
<a name="jobs-log-encryption-s3-buckets"></a>

Para criptografar logs no bucket do Amazon S3 com sua própria chave do KMS, use a configuração `s3MonitoringConfiguration` ao enviar uma execução de trabalho.

```
{
    "monitoringConfiguration": {
        "s3MonitoringConfiguration": {
            "logUri": "s3://amzn-s3-demo-logging-bucket/logs/",
            "encryptionKeyArn": "key-arn"
        }
    }
}
```

## Criptografando registros sem servidor do EMR com a Amazon CloudWatch
<a name="jobs-log-encryption-cw"></a>

Para criptografar registros na Amazon CloudWatch com sua própria chave KMS, use a `cloudWatchLoggingConfiguration` configuração ao enviar uma execução de trabalho.

```
{
    "monitoringConfiguration": {
        "cloudWatchLoggingConfiguration": {
            "enabled": true,
            "encryptionKeyArn": "key-arn"
         }
     }
}
```

## Permissões necessárias para criptografia de logs
<a name="jobs-log-encryption-permissions"></a>

**Topics**
+ [Permissões obrigatórias do usuário](#jobs-log-encryption-permissions-user)
+ [Permissões de chave de criptografia para Amazon S3 e armazenamento gerenciado](#jobs-log-encryption-permissions-s3)
+ [Permissões de chave de criptografia para a Amazon CloudWatch](#jobs-log-encryption-permissions-cw)

### Permissões obrigatórias do usuário
<a name="jobs-log-encryption-permissions-user"></a>

O usuário que envia o trabalho ou visualiza os registros ou o aplicativo UIs deve ter permissões para usar a chave. Você pode especificar as permissões na política de chave do KMS ou na política do IAM para o usuário, grupo ou perfil. Se o usuário que envia o trabalho não tiver as permissões da chave do KMS, o EMR Sem Servidor rejeitará o envio da execução do trabalho.

**Exemplo de política de chaves**

A seguinte política de chave fornece permissões para `kms:GenerateDataKey` e `kms:Decrypt`:

```
{
    "Effect": "Allow",
    "Principal":{
       "AWS": "arn:aws:iam::111122223333:user/user-name"
     },
     "Action": [
       "kms:GenerateDataKey",       
       "kms:Decrypt"
      ],
     "Resource": "*"
 }
```

**Exemplo de política do IAM**

A seguinte política do IAM fornece as permissões para `kms:GenerateDataKey` e `kms:Decrypt`:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
      ],
      "Resource": [
        "arn:aws:kms:*:123456789012:key/12345678-1234-1234-1234-123456789012"
      ],
      "Sid": "AllowKMSGeneratedatakey"
    }
  ]
}
```

------

Para iniciar a interface de usuário do Spark ou Tez, conceda aos usuários, grupos ou perfis permissões para acessar a API `emr-serverless:GetDashboardForJobRun` da seguinte forma:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "emr-serverless:GetDashboardForJobRun"
      ],
      "Resource": [
        "*"
      ],
      "Sid": "AllowEMRSERVERLESSGetdashboardforjobrun"
    }
  ]
}
```

------

### Permissões de chave de criptografia para Amazon S3 e armazenamento gerenciado
<a name="jobs-log-encryption-permissions-s3"></a>

Ao criptografar logs com sua própria chave de criptografia no armazenamento gerenciado ou nos buckets do S3, configure as permissões da chave do KMS da forma a seguir.

A entidade principal do `emr-serverless.amazonaws.com` deve ter as seguintes permissões na política da chave do KMS:

```
{
    "Effect": "Allow",
    "Principal":{
       "Service": "emr-serverless.amazonaws.com" 
     },
     "Action": [
       "kms:Decrypt",
       "kms:GenerateDataKey"
      ],
     "Resource": "*"
     "Condition": {
       "StringLike": {
         "aws:SourceArn": "arn:aws:emr-serverless:region:aws-account-id:/applications/application-id"
       }
     }
 }
```

Como uma prática recomendada de segurança, sugerimos adicionar uma chave de condição `aws:SourceArn` à política de chave do KMS. A chave de condição global do IAM `aws:SourceArn` ajuda a garantir que o EMR Sem Servidor use a chave do KMS somente para o ARN da aplicação. 

O perfil de runtime do trabalho deve ter as seguintes permissões na política do IAM:

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:GenerateDataKey",
        "kms:Decrypt"
      ],
      "Resource": [
        "arn:aws:kms:*:123456789012:key/12345678-1234-1234-1234-123456789012"
      ],
      "Sid": "AllowKMSGeneratedatakey"
    }
  ]
}
```

------

### Permissões de chave de criptografia para a Amazon CloudWatch
<a name="jobs-log-encryption-permissions-cw"></a>

Para associar o ARN da chave do KMS ao seu grupo de logs, use a política do IAM a seguir no perfil de runtime do trabalho.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:AssociateKmsKey"
      ],
      "Resource": [
        "arn:aws:logs:*:123456789012:log-group:my-log-group-name:*"
      ],
      "Sid": "AllowLOGSAssociatekmskey"
    }
  ]
}
```

------

Configure a política de chaves do KMS para conceder permissões de KMS à Amazon: CloudWatch

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Id": "key-default-1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": [
        "*"
      ],
      "Condition": {
        "ArnLike": {
          "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:*:123456789012:*"
        }
      },
      "Sid": "AllowKMSDecrypt"
    }
  ]
}
```

------

# Configuração das propriedades do Apache Log4j2 para o Amazon EMR Sem Servidor
<a name="log4j2"></a>

Esta página descreve como configurar propriedades personalizadas do [Apache Log4j 2.x](https://logging.apache.org/log4j/2.x/) para trabalhos do EMR Sem Servidor em `StartJobRun`. Se quiser configurar as classificações do Log4j no nível da aplicação, consulte [Configuração padrão de aplicações do EMR Sem Servidor](default-configs.md).

## Configuração das propriedades do Log4j2 do Spark para o Amazon EMR Sem Servidor
<a name="log4j2-spark"></a>

Com as versões 6.8.0 e posteriores do Amazon EMR, você pode personalizar as propriedades do [Apache Log4j 2.x](https://logging.apache.org/log4j/2.x/) e especificar configurações de log refinadas. Isso simplifica a solução de problemas dos tranalhos do Spark no EMR Sem Servidor. Para configurar essas propriedades, use as classificações `spark-driver-log4j2` e `spark-executor-log4j2`.

**Topics**
+ [Classificações do Log4j2 para o Spark](#log4j2-spark-class)
+ [Exemplo de configuração do Log4j2 para o Spark](#log4j2-spark-example)
+ [Log4j2 em exemplos de trabalhos do Spark](#log4j2-spark-jobs)
+ [Considerações sobre o Log4j2 para o Spark](#log4j2-spark-considerations)

### Classificações do Log4j2 para o Spark
<a name="log4j2-spark-class"></a>

Para personalizar as configurações de log do Spark, use as classificações a seguir com [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_ConfigurationOverrides.html#emrserverless-Type-ConfigurationOverrides-applicationConfiguration). Para configurar as propriedades do Log4j 2.x, use as [https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_Configuration.html#emrserverless-Type-Configuration-properties](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_Configuration.html#emrserverless-Type-Configuration-properties) a seguir.

**`spark-driver-log4j2`**  
Essa classificação define os valores no arquivo `log4j2.properties` do driver.

**`spark-executor-log4j2`**  
Essa classificação define os valores no arquivo `log4j2.properties` do executor.

### Exemplo de configuração do Log4j2 para o Spark
<a name="log4j2-spark-example"></a>

O exemplo a seguir mostra como enviar um trabalho do Spark com `applicationConfiguration` para personalizar as configurações do Log4j2 para o driver e o executor do Spark.

Para configurar as classificações do Log4j no nível da aplicação, em vez de quando você envia o trabalho, consulte [Configuração padrão de aplicações do EMR Sem Servidor](default-configs.md).

```
aws emr-serverless start-job-run \
    --application-id application-id \
    --execution-role-arn job-role-arn \
    --job-driver '{
        "sparkSubmit": {
            "entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
            "entryPointArguments": ["1"],
            "sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi --conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
        }
    }'
    --configuration-overrides '{
        "applicationConfiguration": [
             {
                "classification": "spark-driver-log4j2",
                "properties": {
                    "rootLogger.level":"error", // will only display Spark error logs
                    "logger.IdentifierForClass.name": "classpath for setting logger",
                    "logger.IdentifierForClass.level": "info"
                   
                }
            },
            {
                "classification": "spark-executor-log4j2",
                "properties": {
                    "rootLogger.level":"error", // will only display Spark error logs
                    "logger.IdentifierForClass.name": "classpath for setting logger",
                    "logger.IdentifierForClass.level": "info"
                }
            }
       ]
    }'
```

### Log4j2 em exemplos de trabalhos do Spark
<a name="log4j2-spark-jobs"></a>

Os exemplos de código a seguir demonstram como criar uma aplicação do Spark enquanto você inicializa uma configuração personalizada do Log4j2 para a aplicação.

------
#### [ Python ]

**Example - Usando o Log4j2 para um trabalho do Spark com Python**  

```
import os
import sys

from pyspark import SparkConf, SparkContext
from pyspark.sql import SparkSession

app_name = "PySparkApp"
if __name__ == "__main__":
    spark = SparkSession\
        .builder\
        .appName(app_name)\
        .getOrCreate()
    
    spark.sparkContext._conf.getAll()
    sc = spark.sparkContext
    log4jLogger = sc._jvm.org.apache.log4j
    LOGGER = log4jLogger.LogManager.getLogger(app_name)

    LOGGER.info("pyspark script logger info")
    LOGGER.warn("pyspark script logger warn")
    LOGGER.error("pyspark script logger error")
    
    // your code here
    
    spark.stop()
```
Para personalizar o Log4j2 do driver ao executar um trabalho do Spark, use a seguinte configuração:  

```
{
   "classification": "spark-driver-log4j2",
      "properties": {
          "rootLogger.level":"error", // only display Spark error logs
          "logger.PySparkApp.level": "info", 
          "logger.PySparkApp.name": "PySparkApp"
      }
}
```

------
#### [ Scala ]

**Example - Usando o Log4j2 para um trabalho do Spark com Scala**  

```
import org.apache.log4j.Logger
import org.apache.spark.sql.SparkSession

object ExampleClass {
  def main(args: Array[String]): Unit = {
    val spark = SparkSession
    .builder
    .appName(this.getClass.getName)
    .getOrCreate()

    val logger = Logger.getLogger(this.getClass);
    logger.info("script logging info logs")
    logger.warn("script logging warn logs")
    logger.error("script logging error logs")

// your code here
    spark.stop()
  }
}
```
Para personalizar o Log4j2 do driver ao executar um trabalho do Spark, use a seguinte configuração:  

```
{
   "classification": "spark-driver-log4j2",
      "properties": {
          "rootLogger.level":"error", // only display Spark error logs
          "logger.ExampleClass.level": "info", 
          "logger.ExampleClass.name": "ExampleClass"
      }
}
```

------

### Considerações sobre o Log4j2 para o Spark
<a name="log4j2-spark-considerations"></a>

As seguintes propriedades do Log4j2.x não são configuráveis para processos do Spark:
+ `rootLogger.appenderRef.stdout.ref`
+ `appender.console.type`
+ `appender.console.name`
+ `appender.console.target`
+ `appender.console.layout.type`
+ `appender.console.layout.pattern`

[Para obter informações detalhadas sobre as propriedades do Log4j2.x que configuram, consulte o arquivo em. `log4j2.properties.template`](https://github.com/apache/spark/blob/v3.3.0/conf/log4j2.properties.template) GitHub

# Monitoramento do EMR Sem Servidor
<a name="metrics"></a>

Esta seção aborda as maneiras para monitorar aplicações e trabalhos do Amazon EMR Sem Servidor.

**Topics**
+ [Monitoramento de aplicações e trabalhos do EMR Sem Servidor](app-job-metrics.md)
+ [Monitoramento de métricas do Spark com o Amazon Managed Service para Prometheus](monitor-with-prometheus.md)
+ [Métricas de uso do EMR Sem Servidor](monitoring-usage.md)

# Monitoramento de aplicações e trabalhos do EMR Sem Servidor
<a name="app-job-metrics"></a>

Com CloudWatch as métricas da Amazon para EMR Serverless, você pode receber CloudWatch métricas de 1 minuto e acessar CloudWatch painéis para acessar near-real-time as operações e o desempenho de seus aplicativos EMR Serverless.

O EMR Serverless envia métricas a cada minuto. CloudWatch O EMR Serverless emite essas métricas no nível do aplicativo, bem como no cargo, no tipo de funcionário e nos níveis. capacity-allocation-type

Para começar, use o modelo de CloudWatch painel do EMR Serverless fornecido no repositório do [EMR](https://github.com/aws-samples/emr-serverless-samples/tree/main/cloudformation/emr-serverless-cloudwatch-dashboard/) Serverless e implante-o. GitHub 

**nota**  
As [workloads interativas do EMR Sem Servidor](interactive-workloads.md) têm apenas o monitoramento em nível de aplicação habilitado e uma nova dimensão de tipo de trabalhador, `Spark_Kernel`. Para monitorar e depurar suas workloads interativas, acesse os logs e a interface do usuário do Apache Spark no [Workspace do EMR Studio](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-studio-debug.html#emr-studio-debug-serverless).

## Monitoramento de métricas
<a name="app-job-metrics-versions"></a>

**Importante**  
Estamos reestruturando nossa exibição de métricas para adicionar `ApplicationName` e `JobName` como dimensões. Para a versão 7.10 e posteriores, as métricas mais antigas não serão mais atualizadas. Para versões do EMR abaixo de 7.10, as métricas mais antigas ainda estão disponíveis.

**Dimensões atuais**

A tabela abaixo descreve as dimensões do EMR Sem Servidor disponíveis no namespace `AWS/EMR Serverless`.


**Dimensões para métricas do EMR Sem Servidor**  

| Dimensão | Description | 
| --- | --- | 
| ApplicationId | Filtros para todas as métricas de uma aplicação EMR Sem Servidor usando o ID da aplicação. | 
| ApplicationName | Filtros para todas as métricas de uma aplicação EMR Sem Servidor usando o nome. Se o nome não for fornecido ou contiver caracteres não ASCII, ele será publicado como **[Unspecified]**. | 
| JobId | Filtros para todas as métricas da execução de um ID de execução de trabalho do EMR Sem Servidor. | 
| JobName | Filtros para todas as métricas de um trabalho EMR Sem Servidor executado usando o nome. Se o nome não for fornecido ou contiver caracteres não ASCII, ele será publicado como **[Unspecified]**. | 
| WorkerType | Filtros para todas as métricas de um determinado tipo de trabalhador. Por exemplo, você pode filtrar por `SPARK_DRIVER` e `SPARK_EXECUTORS` para trabalhos do Spark. | 
| CapacityAllocationType | Filtros para todas as métricas de um determinado tipo de alocação de capacidade. Por exemplo, você pode filtrar por `PreInitCapacity` para capacidade pré-inicializada e `OnDemandCapacity` para todo o resto. | 

## Monitoramento em nível de aplicações
<a name="app-level-metrics"></a>

Você pode monitorar o uso da capacidade no nível do aplicativo EMR Serverless com as métricas da Amazon. CloudWatch Você também pode configurar um único monitor para monitorar o uso da capacidade do aplicativo em um CloudWatch painel.


**Métricas de aplicações do EMR Sem Servidor**  

| Métrica | Description | Unidade | Dimensão | 
| --- | --- | --- | --- | 
| MaxCPUAllowed |  O máximo de CPU permitido para a aplicação.  | vCPU | ApplicationId, ApplicationName | 
| MaxMemoryAllowed |  A memória máxima em GB permitida para a aplicação.  | Gigabytes (GB) | ApplicationId, ApplicationName | 
| MaxStorageAllowed |  O armazenamento máximo em GB permitido para a aplicação.  | Gigabytes (GB) | ApplicationId, ApplicationName | 
| CPUAllocated |  Os números totais de v CPUs alocados.  | vCPU | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | 
| IdleWorkerCount |  O número total de trabalhadores ociosos.  | Contagem | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | 
| MemoryAllocated |  A memória total em GB alocada.  | Gigabytes (GB) | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | 
| PendingCreationWorkerCount |  O número total de trabalhadores pendentes de criação.  | Contagem | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | 
| RunningWorkerCount |  O número total de trabalhadores em uso pela aplicação.  | Contagem | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | 
| StorageAllocated |  O armazenamento total em disco em GB alocado.  | Gigabytes (GB) | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | 
| TotalWorkerCount |  O número total de trabalhadores disponíveis.  | Contagem | ApplicationId, ApplicationName, WorkerType, CapacityAllocationType | 

## Monitoramento no nível do trabalho
<a name="job-level-metrics"></a>

O Amazon EMR Sem Servidor envia as métricas de nível de trabalho a seguir a cada minuto ao Amazon CloudWatch . Você pode acessar os valores das métricas para execuções de trabalhos agregadas por estado de execução de trabalhos. A unidade para cada uma das métricas é *contagem*.


**Métricas de nível de trabalho do EMR Sem Servidor**  

| Métrica | Description | Dimensão | 
| --- | --- | --- | 
| SubmittedJobs | O número de trabalhos no estado Enviado. | ApplicationId, ApplicationName | 
| PendingJobs | O número de trabalhos em um estado Pendente. | ApplicationId, ApplicationName | 
| ScheduledJobs | O número de trabalhos em um estado Programado. | ApplicationId, ApplicationName | 
| RunningJobs | O número de trabalhos em um estado Em execução. | ApplicationId, ApplicationName | 
| SuccessJobs | O número de trabalhos em um estado Com êxito. | ApplicationId, ApplicationName | 
| FailedJobs | O número de trabalhos em um estado de Falha. | ApplicationId, ApplicationName | 
| CancellingJobs | O número de trabalhos em um estado de Cancelamento. | ApplicationId, ApplicationName | 
| CancelledJobs | O número de trabalhos em um estado Cancelado. | ApplicationId, ApplicationName | 

Você pode monitorar métricas específicas do mecanismo para executar e concluir trabalhos do EMR Serverless com um aplicativo específico do mecanismo. UIs Quando você acessa a interface do usuário para um trabalho em execução, a interface do usuário da aplicação ao vivo é exibida com atualizações em tempo real. Quando você acessa a interface do usuário para um trabalho concluído, a interface do usuário persistente da aplicação é exibida.

**Execução de trabalhos**

Para trabalhos do EMR Sem Servidor em execução, acesse uma interface em tempo real que fornece métricas específicas do mecanismo. Você pode usar a interface do usuário do Apache Spark ou a interface do usuário do Hive Tez para monitorar e depurar trabalhos. Para acessá-los UIs, use o console do EMR Studio ou solicite um endpoint de URL seguro com o. AWS Command Line Interface

**Trabalhos concluídos**

Para trabalhos concluídos do EMR Sem Servidor, use o Spark History Server ou a interface de usuário persistente do Hive Tez para acessar detalhes, estágios, tarefas e métricas das execuções de trabalhos do Spark ou do Hive. Para acessá-los UIs, use o console do EMR Studio ou solicite um endpoint de URL seguro com o. AWS Command Line Interface

## Monitoramento em nível de trabalhador para trabalhos
<a name="job-worker-level-metrics"></a>

O Amazon EMR Serverless envia as seguintes métricas de nível de funcionário que estão disponíveis no `AWS/EMRServerless` namespace e no grupo de métricas para a Amazon. `Job Worker Metrics` CloudWatch O EMR Serverless coleta pontos de dados de trabalhadores individuais durante a execução do trabalho no nível do cargo, no tipo de trabalhador e no nível. capacity-allocation-type Você pode usar `ApplicationId` como uma dimensão para monitorar vários trabalhos que pertencem à mesma aplicação.

**nota**  
Para visualizar o total de CPU e memória usadas por um trabalho sem servidor do EMR ao visualizar as métricas no CloudWatch console da Amazon, use a estatística como soma e o período como 1 minuto.


**Métricas do EMR Sem Servidor em nível de trabalhador**  

| Métrica | Description | Unidade | Dimensão | 
| --- | --- | --- | --- | 
| WorkerCpuAllocated | O número total de núcleos de vCPU alocados para trabalhadores em uma execução de trabalho. | vCPU | JobId, JobName, ApplicationId, ApplicationName, WorkerType, e CapacityAllocationType | 
| WorkerCpuUsed | O número total de núcleos de vCPU utilizados pelos trabalhadores em uma execução de trabalho. | vCPU | JobId, JobName, ApplicationId, ApplicationName, WorkerType, e CapacityAllocationType | 
| WorkerMemoryAllocated | A memória total em GB alocada para trabalhadores em uma execução de trabalho. | Gigabytes (GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, e CapacityAllocationType | 
| WorkerMemoryUsed | A memória total em GB utilizada pelos trabalhadores em uma execução de trabalho. | Gigabytes (GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, e CapacityAllocationType | 
| WorkerEphemeralStorageAllocated | O número de bytes de armazenamento temporário alocados para trabalhadores em uma execução de trabalho. | Gigabytes (GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, e CapacityAllocationType | 
| WorkerEphemeralStorageUsed | O número de bytes de armazenamento temporário usados pelos trabalhadores em uma execução de trabalho. | Gigabytes (GB) | JobId, JobName, ApplicationId, ApplicationName, WorkerType, e CapacityAllocationType | 
| WorkerStorageReadBytes | O número de bytes lidos do armazenamento por trabalhadores durante uma execução de trabalho. | Bytes | JobId, JobName, ApplicationId, ApplicationName, WorkerType, e CapacityAllocationType | 
| WorkerStorageWriteBytes | O número de bytes gravados no armazenamento por trabalhadores durante uma execução de trabalho. | Bytes | JobId, JobName, ApplicationId, ApplicationName, WorkerType, e CapacityAllocationType | 

As etapas abaixo descrevem como acessar os vários tipos de métricas.

------
#### [ Console ]

**Para acessar a interface do usuário da aplicação com o console**

1. Navegue até a aplicação do EMR Sem Servidor no EMR Studio com as instruções em [Getting started from the console](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html#gs-console). 

1. Para acessar aplicativos UIs e registros específicos do mecanismo para um trabalho em execução: 

   1. Escolha um trabalho com um status `RUNNING`.

   1. Selecione o trabalho na página de **Detalhes da aplicação** ou navegue até a página **Detalhes do trabalho** do seu trabalho.

   1. No menu suspenso **Exibir interface do usuário**, escolha **Interface do usuário do Spark** ou **Interface do usuário do Hive Tez** para navegar até a interface da aplicação do seu tipo de trabalho. 

   1. Para acessar os logs do mecanismo do Spark, navegue até a guia **Executores** na interface do usuário do Spark e escolha o link **Logs** do driver. Para acessar os logs do mecanismo do Hive, escolha o link **Logs** do DAG apropriado na interface do usuário do Hive Tez.

1. Para acessar aplicativos UIs e registros específicos do motor para um trabalho concluído: 

   1. Escolha um trabalho com um status `SUCCESS`.

   1. Selecione o trabalho na página **Detalhes da aplicação** ou navegue até a página **Detalhes do trabalho**.

   1. No menu suspenso **Exibir interface do usuário**, escolha **Servidor de histórico do Spark** ou **Interface de usuário persistente do Hive Tez** para navegar até a interface da aplicação do seu tipo de trabalho. 

   1. Para acessar os logs do mecanismo do Spark, navegue até a guia **Executores** na interface do usuário do Spark e escolha o link **Logs** do driver. Para acessar os logs do mecanismo do Hive, escolha o link **Logs** do DAG apropriado na interface do usuário do Hive Tez.

------
#### [ AWS CLI ]

**Para acessar a interface do usuário do seu aplicativo com o AWS CLI**
+ Para gerar um URL usado para acessar a interface do usuário da aplicação para trabalhos em execução e concluídos, chame a API `GetDashboardForJobRun`. 

  ```
  aws emr-serverless get-dashboard-for-job-run /
  --application-id <application-id> /
  --job-run-id <job-id>
  ```

  O URL gerado é válido por uma hora.

------

# Monitoramento de métricas do Spark com o Amazon Managed Service para Prometheus
<a name="monitor-with-prometheus"></a>

Com as versões 7.1.0 e posteriores do Amazon EMR, você pode integrar o EMR Sem Servidor ao Amazon Managed Service for Prometheus para coletar métricas do Apache Spark para trabalhos e aplicações do EMR Sem Servidor. Essa integração está disponível quando você envia um trabalho ou cria um aplicativo usando o AWS console, a API do EMR Serverless ou o. AWS CLI

## Pré-requisitos
<a name="monitoring-with-prometheus-prereqs"></a>

Antes de fornecer as métricas do Spark para o Amazon Managed Service for Prometheus, conclua os pré-requisitos a seguir.
+ [Crie um Workspace do Amazon Managed Service para Prometheus.](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-create-workspace.html) Este Workspace serve como um endpoint de ingestão. Anote o URL exibido em **Endpoint: URL de gravação remota**. Você precisará especificar o URL ao criar sua aplicação do EMR Sem Servidor.
+ Para conceder acesso aos seus trabalhos ao Amazon Managed Service for Prometheus para fins de monitoramento, adicione a política a seguir ao perfil de execução de tarefas.

  ```
  {
      "Sid": "AccessToPrometheus",
      "Effect": "Allow",
      "Action": ["aps:RemoteWrite"],
      "Resource": "arn:aws:aps:<AWS_REGION>:<AWS_ACCOUNT_ID>:workspace/<WORKSPACE_ID>"
  }
  ```

## Configuração
<a name="monitoring-with-prometheus-setup"></a>

**Para usar o AWS console para criar um aplicativo integrado ao Amazon Managed Service for Prometheus**

1. Consulte [Getting started with Amazon EMR Sem Servidor](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html                             ) para criar uma aplicação.

1. Ao criar uma aplicação, escolha **Usar configurações personalizadas** e, em seguida, configure-a especificando as informações nos campos que deseja configurar.

1. Em **Logs e métricas da aplicação**, escolha **Fornecer métricas do mecanismo ao Amazon Managed Service for Prometheus** e, em seguida, especifique o URL de gravação remota.

1. Especifique todas as outras configurações desejadas e escolha **Criar e iniciar aplicação**.

**Use a API AWS CLI sem servidor do EMR**

Você também pode usar a API AWS CLI ou EMR Serverless para integrar seu aplicativo EMR Serverless ao Amazon Managed Service for Prometheus ao executar o ou os comandos. `create-application` `start-job-run`

------
#### [ create-application ]

```
aws emr-serverless create-application \
--release-label emr-7.1.0 \
--type "SPARK" \
--monitoring-configuration '{ 
    "prometheusMonitoringConfiguration": {
        "remoteWriteUrl": "https://aps-workspaces.<AWS_REGION>.amazonaws.com/workspaces/<WORKSPACE_ID>/api/v1/remote_write"
    }
}'
```

------
#### [ start-job-run ]

```
aws emr-serverless start-job-run \
--application-id <APPPLICATION_ID> \
--execution-role-arn <JOB_EXECUTION_ROLE> \
--job-driver '{
    "sparkSubmit": {
        "entryPoint": "local:///usr/lib/spark/examples/src/main/python/pi.py",
        "entryPointArguments": ["10000"],
        "sparkSubmitParameters": "--conf spark.dynamicAllocation.maxExecutors=10"
    }
}' \
--configuration-overrides '{
     "monitoringConfiguration": {
        "prometheusMonitoringConfiguration": {
            "remoteWriteUrl": "https://aps-workspaces.<AWS_REGION>.amazonaws.com/workspaces/<WORKSPACE_ID>/api/v1/remote_write"
        }
    }
}'
```

------

Incluir `prometheusMonitoringConfiguration` no comando indica que o EMR Sem Servidor deve executar o trabalho do Spark com um agente que coleta as métricas do Spark e as grava no endpoint `remoteWriteUrl` para o Amazon Managed Service for Prometheus. Em seguida, você pode usar as métricas do Spark no Amazon Managed Service for Prometheus para exibição, alertas e análises.

## Propriedades de configuração avançada
<a name="monitoring-with-prometheus-config-options"></a>

O EMR Sem Servidor usa um componente do Spark chamado `PrometheusServlet` para coletar métricas do Spark e traduzir dados de performance em dados compatíveis com o Amazon Managed Service for Prometheus. Por padrão, o EMR Sem Servidor define valores padrão no Spark e analisa as métricas do driver e do executor quando você envia um trabalho usando `PrometheusMonitoringConfiguration`. 

A tabela a seguir descreve todas as propriedades que você pode configurar ao enviar um trabalho do Spark que envia métricas ao Amazon Managed Service for Prometheus.


| Propriedade do Spark | Valor padrão  | Description | 
| --- | --- | --- | 
| spark.metrics.conf.\$1.sink.prometheusServlet.class | org.apache.spark.metrics.sink. PrometheusServlet | A classe que o Spark usa para enviar métricas ao Amazon Managed Service for Prometheus. Para substituir o comportamento padrão, especifique sua própria classe personalizada. | 
| spark.metrics.conf.\$1.source.jvm.class | org.apache.spark.metrics.source. JvmSource | A classe que o Spark usa para coletar e enviar métricas cruciais da máquina virtual Java subjacente. Para parar de coletar métricas da JVM, desabilite essa propriedade definindo-a como uma string vazia, como `""`. Para substituir o comportamento padrão, especifique sua própria classe personalizada.  | 
| spark.metrics.conf.driver.sink.prometheusServlet.path | /metrics/prometheus | O URL distinto que o Amazon Managed Service for Prometheus usa para coletar métricas do driver. Para substituir o comportamento padrão, especifique seu próprio caminho. Para parar de coletar métricas do driver, desabilite essa propriedade definindo-a como uma string vazia, como `""`. | 
| spark.metrics.conf.executor.sink.prometheusServlet.path | /metrics/executor/prometheus | O URL distinto que o Amazon Managed Service for Prometheus usa para coletar métricas do executor. Para substituir o comportamento padrão, especifique seu próprio caminho. Para parar de coletar métricas do executor, desabilite essa propriedade definindo-a como uma string vazia, como `""`. | 

Para obter mais informações sobre as métricas do Spark, consulte [Métricas do Apache Spark](https://spark.apache.org/docs/3.5.0/monitoring.html#metrics).

## Considerações e limitações
<a name="monitoring-with-prometheus-limitations"></a>

Ao usar o Amazon Managed Service for Prometheus para coletar métricas do EMR Sem Servidor, considere as informações e limitações a seguir.
+ O suporte para o uso do Amazon Managed Service for Prometheus com o EMR Sem Servidor está disponível somente nas [Regiões da AWS onde o Amazon Managed Service for Prometheus encontra-se disponível ao público geral](https://docs.aws.amazon.com/general/latest/gr/prometheus-service.html).
+ Executar o agente para coletar métricas do Spark no Amazon Managed Service para Prometheus exige mais recursos dos trabalhadores. Se você escolher um trabalhador menor, como um trabalhador de uma vCPU, o runtime do trabalho poderá aumentar.
+ O suporte para o uso do Amazon Managed Service para Prometheus com o EMR Sem Servidor está disponível somente nas versões 7.1.0 e posteriores do Amazon EMR.
+ O Amazon Managed Service para Prometheus deve ser implantado na mesma conta em que você executa o EMR Sem Servidor para coletar métricas.

# Métricas de uso do EMR Sem Servidor
<a name="monitoring-usage"></a>

Você pode usar as métricas CloudWatch de uso da Amazon para dar visibilidade aos recursos que sua conta usa. Use essas métricas para visualizar seu uso do serviço em CloudWatch gráficos e painéis.

As métricas de uso do EMR Sem Servidor correspondem ao Service Quotas. Também é possível configurar alarmes que alertem você quando o uso se aproximar de uma cota de serviço. Para obter mais informações, consulte [Service Quotas e CloudWatch alarmes da Amazon](https://docs.aws.amazon.com/servicequotas/latest/userguide/configure-cloudwatch.html) no *Service* Quotas User Guide.

Para obter mais informações sobre as cotas de serviço do EMR Sem Servidor, consulte [Endpoints e cotas do EMR Serverless](endpoints-quotas.md).

## Métricas de uso da cota de serviço do EMR Sem Servidor
<a name="usage-metrics"></a>

O EMR Sem servidor publica as métricas de uso da cota de serviço a seguir no namespace `AWS/Usage`.


****  

| Métrica | Description | 
| --- | --- | 
| `ResourceCount`  | O número total dos recursos especificados em execução na conta. O recurso é definido pelas [dimensões](#usage-metrics-dimensions) associadas à métrica. | 

## Dimensões das métricas de uso da cota de serviço do EMR Sem Servidor
<a name="usage-metrics-dimensions"></a>

Você pode usar as dimensões a seguir para refinar as métricas de uso que o EMR Sem Servidor publica.


****  

| Dimensão | Valor | Description | 
| --- | --- | --- | 
|  `Service`  |  EMR Sem Servidor  | O nome do AWS service (Serviço da AWS) que contém o recurso. | 
|  `Type`  |  Recurso  | O tipo de entidade que o EMR Sem Servidor está relatando. | 
|  `Resource`  |  vCPU  | O tipo de recurso que o EMR Sem Servidor está rastreando. | 
|  `Class`  |  Nenhum  | A classe de recurso que o EMR Sem Servidor está rastreando. | 

# Automatizando o EMR sem servidor com Amazon EventBridge
<a name="using-eventbridge"></a>

Você pode usar Amazon EventBridge para automatizar Serviços da AWS e responder automaticamente aos eventos do sistema, como problemas de disponibilidade de aplicativos ou alterações de recursos. EventBridge fornece um fluxo quase em tempo real de eventos do sistema que descrevem as mudanças em seus AWS recursos. Você pode escrever regras simples para indicar quais eventos são do seu interesse, e as ações automatizadas a serem tomadas quando um evento corresponder à regra. Com EventBridge, você pode automaticamente:
+ Invocar uma função AWS Lambda 
+ Retransmissão de um evento para o Amazon Kinesis Data Streams
+ Ativar uma máquina de AWS Step Functions estado
+ Notificação de um tópico do Amazon SNS ou de uma fila do Amazon SQS

Por exemplo, ao usar EventBridge com o EMR Serverless, você pode ativar uma AWS Lambda função quando uma tarefa de ETL for bem-sucedida ou notificar um tópico do Amazon SNS quando uma tarefa de ETL falhar.

O EMR Sem Servidor emite quatro tipos de eventos:
+ Eventos de mudança de estado da aplicação: eventos que emitem todas as alterações de estado de uma aplicação. Para obter mais informações sobre estados da aplicação, consulte [Estados da aplicação](applications.md#application-states).
+ Eventos de mudança de estado de execução de um trabalho: eventos que emitem cada mudança de estado da execução de um trabalho. Para obter mais informações, consulte [Estados de execução de trabalho](job-states.md).
+ Eventos de repetição da execução de um trabalho: eventos que emitem cada nova tentativa de um trabalho executado nas versões 7.1.0 e posteriores do Amazon EMR Sem Servidor.
+ Eventos de atualização de utilização de recursos de trabalho: eventos que emitem atualizações de utilização de recursos para um trabalho executado em intervalos de aproximadamente 30 minutos.

## Exemplos de eventos do EMR Serverless EventBridge
<a name="using-eventbridge-examples"></a>

Os eventos relatados pelo EMR Sem Servidor têm um valor de `aws.emr-serverless` atribuído a `source`, como nos exemplos a seguir.

**Evento de alteração do estado da aplicação**

O exemplo de evento a seguir mostra uma aplicação no estado `CREATING`.

```
{
    "version": "0",
    "id": "9fd3cf79-1ff1-b633-4dd9-34508dc1e660",
    "detail-type": "EMR Serverless Application State Change",
    "source": "aws.emr-serverless",
    "account": "123456789012",
    "time": "2022-05-31T21:16:31Z",
    "region": "us-east-1",
    "resources": [],
    "detail": {
        "applicationId": "00f1cbsc6anuij25",
        "applicationName": "3965ad00-8fba-4932-a6c8-ded32786fd42",
        "arn": "arn:aws:emr-serverless:us-east-1:111122223333:/applications/00f1cbsc6anuij25",
        "releaseLabel": "emr-6.6.0",
        "state": "CREATING",
        "type": "HIVE",
        "createdAt": "2022-05-31T21:16:31.547953Z",
        "updatedAt": "2022-05-31T21:16:31.547970Z",
        "autoStopConfig": {
            "enabled": true,
            "idleTimeout": 15
        },
        "autoStartConfig": {
            "enabled": true
        }
    }
}
```

**Eventos de alteração de estado em execuções de trabalhos**

O exemplo de evento a seguir mostra uma execução de trabalho que se move de um estado `SCHEDULED` para `RUNNING`.

```
{
    "version": "0",
    "id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0",
    "detail-type": "EMR Serverless Job Run State Change",
    "source": "aws.emr-serverless",
    "account": "123456789012",
    "time": "2022-05-31T21:07:42Z",
    "region": "us-east-1",
    "resources": [],
    "detail": {
        "jobRunId": "00f1cbn5g4bb0c01",
        "applicationId": "00f1982r1uukb925",
        "arn": "arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01",
        "releaseLabel": "emr-6.6.0",
        "state": "RUNNING",
        "previousState": "SCHEDULED",
        "createdBy": "arn:aws:sts::123456789012:assumed-role/TestRole-402dcef3ad14993c15d28263f64381e4cda34775/6622b6233b6d42f59c25dd2637346242",
        "updatedAt": "2022-05-31T21:07:42.299487Z",
        "createdAt": "2022-05-31T21:07:25.325900Z"
    }
}
```

**Evento de repetição de execução de trabalho**

Confira a seguir um exemplo de um evento de nova tentativa de execução de trabalho.

```
{
    "version": "0",
    "id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0",
    "detail-type": "EMR Serverless Job Run Retry",
    "source": "aws.emr-serverless",
    "account": "123456789012",
    "time": "2022-05-31T21:07:42Z",
    "region": "us-east-1",
    "resources": [],
    "detail": {
        "jobRunId": "00f1cbn5g4bb0c01",
        "applicationId": "00f1982r1uukb925",
        "arn": "arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01",
        "releaseLabel": "emr-6.6.0",
        "createdBy": "arn:aws:sts::123456789012:assumed-role/TestRole-402dcef3ad14993c15d28263f64381e4cda34775/6622b6233b6d42f59c25dd2637346242",
        "updatedAt": "2022-05-31T21:07:42.299487Z",
        "createdAt": "2022-05-31T21:07:25.325900Z",
        //Attempt Details
        "previousAttempt": 1,
        "previousAttemptState": "FAILED",
        "previousAttemptCreatedAt": "2022-05-31T21:07:25.325900Z",
        "previousAttemptEndedAt": "2022-05-31T21:07:30.325900Z",
        "newAttempt": 2,
        "newAttemptCreatedAt": "2022-05-31T21:07:30.325900Z"
    }
}
```

**Atualização da utilização de recursos de trabalho**

O exemplo de evento a seguir mostra a atualização final da utilização de recursos para um trabalho que foi transferido para um estado terminal após a execução.

```
{
    "version": "0",
    "id": "00df3ec6-5da1-36e6-ab71-20f0de68f8a0",
    "detail-type": "EMR Serverless Job Resource Utilization Update",
    "source": "aws.emr-serverless",
    "account": "123456789012",
    "time": "2022-05-31T21:07:42Z",
    "region": "us-east-1",
    "resources": [
        "arn:aws:emr-serverless:us-east-1:123456789012:/applications/00f1982r1uukb925/jobruns/00f1cbn5g4bb0c01"
    ],
    "detail": {
        "applicationId": "00f1982r1uukb925",
        "jobRunId": "00f1cbn5g4bb0c01",
        "attempt": 1,
        "mode": "BATCH",
        "createdAt": "2022-05-31T21:07:25.325900Z",
        "startedAt": "2022-05-31T21:07:26.123Z",
        "calculatedFrom": "2022-05-31T21:07:42.299487Z",
        "calculatedTo": "2022-05-31T21:07:30.325900Z",
        "resourceUtilizationFinal": true,
        "resourceUtilizationForInterval": {
            "vCPUHour": 0.023,
            "memoryGBHour": 0.114,
            "storageGBHour": 0.228
        },
        "billedResourceUtilizationForInterval": {
            "vCPUHour": 0.067,
            "memoryGBHour": 0.333,
            "storageGBHour": 0
        },
        "totalResourceUtilization": {
            "vCPUHour": 0.023,
            "memoryGBHour": 0.114,
            "storageGBHour": 0.228
        },
        "totalBilledResourceUtilization": {
            "vCPUHour": 0.067,
            "memoryGBHour": 0.333,
            "storageGBHour": 0
        }
    }
}
```

O campo **startedAt** só estará presente no caso de o trabalho ter sido movido para um estado de execução.