

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Gestione delle esecuzioni di processi Amazon EMR su EKS
<a name="emr-eks-jobs-manage"></a>

Le sezioni seguenti trattano argomenti che semplificano la gestione delle esecuzioni di processi Amazon EMR su EKS. Queste includono la configurazione dei parametri di esecuzione dei job quando si utilizza il AWS CLI, la configurazione della modalità di archiviazione dei dati di log, l'esecuzione degli script SQL Spark per eseguire le query, la comprensione degli stati di esecuzione dei job e la conoscenza di come monitorare i job. Puoi esaminare questi argomenti, generalmente con ordine, se desideri configurare e completare un'esecuzione di job per elaborare i dati.

**Topics**
+ [La gestione dei job viene eseguita con AWS CLI](emr-eks-jobs-CLI.md)
+ [Esecuzione degli script SQL StartJobRun di Spark tramite l'API](emr-eks-jobs-spark-sql-parameters.md)
+ [Stati delle esecuzioni di processi](emr-eks-jobs-states.md)
+ [Visualizzazione dei processi nella console Amazon EMR](emr-eks-jobs-console.md)
+ [Errori comuni durante l'esecuzione di processi](emr-eks-jobs-error.md)

# La gestione dei job viene eseguita con AWS CLI
<a name="emr-eks-jobs-CLI"></a>

In questo argomento viene illustrato come gestire le esecuzioni dei job con AWS Command Line Interface (AWS CLI). Approfondisce le proprietà, come i parametri di sicurezza, il driver e varie impostazioni di override. Include anche argomenti secondari che coprono vari modi per configurare la registrazione.

**Topics**
+ [Opzioni per la configurazione di un'esecuzione di processo](#emr-eks-jobs-parameters)
+ [Configurazione di un'esecuzione di processo per utilizzare i log Amazon S3](emr-eks-jobs-s3.md)
+ [Configurare un job run per usare Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md)
+ [Elenco delle esecuzioni di processi](#emr-eks-jobs-list)
+ [Descrizione di un'esecuzione di processo](#emr-eks-jobs-describe)
+ [Annullamento di un'esecuzione di processo](#emr-eks-jobs-cancel)

## Opzioni per la configurazione di un'esecuzione di processo
<a name="emr-eks-jobs-parameters"></a>

Utilizza le seguenti opzioni per configurare i parametri dell'esecuzione di processo:
+ `--execution-role-arn`: è necessario fornire un ruolo IAM per eseguire i processi. Per ulteriori informazioni, consulta [Uso dei ruoli di esecuzione di processo con Amazon EMR su EKS](iam-execution-role.md). 
+ `--release-label`: è possibile implementare Amazon EMR su EKS con le versioni Amazon EMR 5.32.0, 6.2.0 e versioni successive. Amazon EMR su EKS non è supportato nelle versioni precedenti di Amazon EMR. Per ulteriori informazioni, consulta [Rilasci di Amazon EMR su EKS](emr-eks-releases.md). 
+ `--job-driver`: il driver di processo viene utilizzato per fornire input sul processo principale. Si tratta di un campo di tipo unione in cui è possibile far passare solo uno dei valori per il tipo di processo che si desidera eseguire. I tipi di processo supportati includono:
  + Processi Spark Submit: utilizzati per eseguire un comando tramite Spark Submit. Puoi usare questo tipo di lavoro per eseguire Scala, SparkR PySpark, SparkSQL e qualsiasi altro lavoro supportato tramite Spark Submit. Questo tipo di processo include i seguenti parametri:
    + Entrypoint - Questo è il riferimento HCFS (file system compatibile con Hadoop) al file principale che desideri eseguire. jar/py 
    + EntryPointArguments - Questa è una serie di argomenti da passare al file principale. jar/py Dovrai gestire la lettura di questi parametri con il tuo codice di entrypoint. Ogni argomento nell'array deve essere separato da una virgola. EntryPointArguments non può contenere parentesi o parentesi, come (), \$1\$1 o []. 
    + SparkSubmitParameters - Questi sono i parametri spark aggiuntivi che desideri inviare al job. Utilizza questo parametro per sovrascrivere le proprietà Spark di default, come la memoria del driver o il numero di executor, tra cui —conf o —class. Per ulteriori informazioni, consulta [Avvio delle applicazioni con spark-submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit).
  + Processi Spark SQL: utilizzati per eseguire un file di query SQL tramite Spark SQL. Questo tipo di processo può essere utilizzato per eseguire i processi SparkSQL. Questo tipo di processo include i seguenti parametri:
    + Punto d'ingresso: riferimento HCFS (file system compatibile con Hadoop) al file di query SQL da eseguire.

      Per l'elenco dei parametri Spark aggiuntivi da utilizzare nei processi Spark SQL, vedere [Esecuzione degli script SQL StartJobRun di Spark tramite l'API](emr-eks-jobs-spark-sql-parameters.md).
+ `--configuration-overrides`: puoi sovrascrivere le configurazioni predefinite per le applicazioni fornendo un oggetto di configurazione. Puoi utilizzare una sintassi abbreviata per fornire la configurazione oppure fare riferimento all'oggetto di configurazione in un file JSON. Gli oggetti di configurazione sono composti da una classificazione, proprietà e configurazioni nidificate opzionali. Le proprietà sono costituite dalle impostazioni da ignorare in un dato file. Puoi specificare diverse classificazioni per più applicazioni in un singolo oggetto JSON. Le classificazioni di configurazione disponibili variano a seconda della versione di rilascio di Amazon EMR. Per un elenco delle classificazioni di configurazione disponibili per ciascuna versione di rilascio di Amazon EMR, consulta [Rilasci di Amazon EMR su EKS](emr-eks-releases.md).

  Se si passa la stessa configurazione nella sostituzione di un'applicazione e nei parametri Spark Submit, i parametri Spark Submit hanno la precedenza. Segue l'elenco completo delle priorità di configurazione, ordinate dalla più alta alla più bassa.
  + Configurazione fornita durante la creazione di `SparkSession`.
  + Configurazione fornita come parte di `sparkSubmitParameters` tramite `—conf`.
  + Configurazione fornita come parte delle sostituzioni dell'applicazione.
  + Configurazioni ottimizzate scelte da Amazon EMR per il rilascio.
  + Configurazioni open source predefinite per l'applicazione.

  Per monitorare le esecuzioni dei job utilizzando Amazon CloudWatch o Amazon S3, devi fornire i dettagli di configurazione per. CloudWatch Per ulteriori informazioni, consultare [Configurazione di un'esecuzione di processo per utilizzare i log Amazon S3](emr-eks-jobs-s3.md) e [Configurare un job run per usare Amazon CloudWatch Logs](emr-eks-jobs-cloudwatch.md). Se il bucket o il gruppo di CloudWatch log S3 non esiste, Amazon EMR lo crea prima di caricare i log nel bucket.
+ Per un elenco aggiuntivo delle opzioni di configurazione di Kubernetes, consulta [Proprietà Spark su Kubernetes](https://spark.apache.org/docs/latest/running-on-kubernetes.html#configuration). 

  Le seguenti configurazioni Spark non sono supportate:
  + `spark.kubernetes.authenticate.driver.serviceAccountName`
  + `spark.kubernetes.authenticate.executor.serviceAccountName`
  + `spark.kubernetes.namespace`
  + `spark.kubernetes.driver.pod.name`
  + `spark.kubernetes.container.image.pullPolicy`
  + `spark.kubernetes.container.image`
**Nota**  
È possibile utilizzare `spark.kubernetes.container.image` per immagini Docker personalizzate. Per ulteriori informazioni, consulta [Personalizzazione delle immagini Docker per Amazon EMR su EKS](docker-custom-images.md).

# Configurazione di un'esecuzione di processo per utilizzare i log Amazon S3
<a name="emr-eks-jobs-s3"></a>

Per monitorare l'avanzamento del lavoro e risolvere gli errori, devi configurare i lavori per inviare informazioni di log ad Amazon S3, Amazon CloudWatch Logs o entrambi. Questo argomento fornisce le nozioni di base per inviare i log dell'applicazione ad Amazon S3 sui processi avviati con Amazon EMR su EKS.

**Policy IAM dei registri S3**

Prima che i processi possano inviare i dati dei log ad Amazon S3, nella policy delle autorizzazioni per il ruolo di esecuzione di processo devono essere incluse le seguenti autorizzazioni. Sostituisci *amzn-s3-demo-logging-bucket* con il nome del bucket di accesso.

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

****  

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

------

**Nota**  
Amazon EMR su EKS può anche creare un bucket Amazon S3. Se un bucket Amazon S3 non è disponibile, includi l'autorizzazione `“s3:CreateBucket”` nella policy IAM.

Dopo aver assegnato al ruolo di esecuzione le autorizzazioni appropriate per l'invio dei log ad Amazon S3, i dati dei log vengono inviati alle seguenti posizioni Amazon S3 quando `s3MonitoringConfiguration` viene trasmesso nella sezione `monitoringConfiguration` di una richiesta `start-job-run`, come mostrato in [La gestione dei job viene eseguita con AWS CLI](emr-eks-jobs-CLI.md).
+ Registri degli utenti -//jobs/ /containers//(stderr.gz/stdout.gz) *logUri* *virtual-cluster-id* *job-id* *pod-name*
+ Registri dei driver -/*logUri**virtual-cluster-id*/jobs/ *job-id* /containers/ /spark- *spark-application-id* -driver/ *job-id* (stderr.gz/stdout.gz)
+ Registri degli esecutori -*logUri*/*virtual-cluster-id*/jobs/ *job-id* /containers/*executor-pod-name*/(*spark-application-id*stderr.gz/stdout.gz)

# Configurare un job run per usare Amazon CloudWatch Logs
<a name="emr-eks-jobs-cloudwatch"></a>

Per monitorare l'avanzamento dei lavori e risolvere i problemi, devi configurare i lavori per inviare informazioni di log ad Amazon S3, Amazon CloudWatch Logs o entrambi. Questo argomento ti aiuta a iniziare a utilizzare CloudWatch i log sui tuoi lavori lanciati con Amazon EMR su EKS. Per ulteriori informazioni sui CloudWatch log, consulta [Monitoring Log Files](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html) nella Amazon CloudWatch User Guide.

**CloudWatch Registra la politica IAM**

Affinché i lavori inviino i dati di registro a CloudWatch Logs, è necessario includere le seguenti autorizzazioni nella politica delle autorizzazioni per il ruolo di esecuzione del lavoro. Sostituisci *my\$1log\$1group\$1name* e *my\$1log\$1stream\$1prefix* con i nomi rispettivamente del gruppo di CloudWatch log e dei nomi dei flussi di log. Amazon EMR su EKS crea il gruppo di log e il flusso di log se non esistono ancora, purché l'ARN del ruolo di esecuzione disponga delle autorizzazioni appropriate. 

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

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Resource": [
        "arn:aws:logs:*:*:*"
      ],
      "Sid": "AllowLOGSCreatelogstream"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:PutLogEvents"
      ],
      "Resource": [
        "arn:aws:logs:*:*:log-group:my_log_group_name:log-stream:my_log_stream_prefix/*"
      ],
      "Sid": "AllowLOGSPutlogevents"
    }
  ]
}
```

------

**Nota**  
Amazon EMR su EKS può anche creare un flusso di log. Se un flusso di log non esiste, la policy IAM deve includere l'autorizzazione `"logs:CreateLogGroup"`.

Dopo aver assegnato al ruolo di esecuzione le autorizzazioni appropriate, l'applicazione invia i dati di registro a CloudWatch Logs quando `cloudWatchMonitoringConfiguration` vengono passati nella `monitoringConfiguration` sezione di una `start-job-run` richiesta, come mostrato in. [La gestione dei job viene eseguita con AWS CLI](emr-eks-jobs-CLI.md)

Nell'`StartJobRun`API, *log\$1group\$1name * è il nome del gruppo di log e *log\$1stream\$1prefix* il prefisso del nome del flusso di log per CloudWatch. CloudWatch Puoi visualizzare e ricercare tali log in Console di gestione AWS.
+ Registri dell'utente -*logGroup*/*virtual-cluster-id*/jobs/ /containers/*logStreamPrefix*/(stderr/stdout*job-id*) *pod-name*
+ Registri dei driver -*logGroup*/*logStreamPrefix**virtual-cluster-id*/jobs/ *job-id* /containers/ /spark- *spark-application-id* -driver/ *job-id* (stderrstdout)
+ Registri degli esecutori - *logGroup**logStreamPrefix*/*virtual-cluster-id*/jobs/ *job-id* /containers/*executor-pod-name*/(*spark-application-id*stderr/stdout)

## Elenco delle esecuzioni di processi
<a name="emr-eks-jobs-list"></a>

Puoi eseguire `list-job-run` per visualizzare gli stati delle esecuzioni di processi, come illustrato nell'esempio seguente. 

```
aws emr-containers list-job-runs --virtual-cluster-id <cluster-id>
```

## Descrizione di un'esecuzione di processo
<a name="emr-eks-jobs-describe"></a>

Puoi eseguire `describe-job-run` per ottenere ulteriori dettagli sul processo, ad esempio lo stato del processo, i dettagli dello stato e il nome del processo, come illustrato nell'esempio seguente. 

```
aws emr-containers describe-job-run --virtual-cluster-id cluster-id --id job-run-id
```

## Annullamento di un'esecuzione di processo
<a name="emr-eks-jobs-cancel"></a>

Puoi eseguire `cancel-job-run` per annullare i processi in esecuzione, come illustrato nell'esempio seguente.

```
aws emr-containers cancel-job-run --virtual-cluster-id cluster-id --id job-run-id
```

# Esecuzione degli script SQL StartJobRun di Spark tramite l'API
<a name="emr-eks-jobs-spark-sql-parameters"></a>

Amazon EMR su EKS versione 6.7.0 e successive include un nuovo driver di processi Spark SQL che permette di eseguire gli script Spark SQL attraverso l'API `StartJobRun`. PUoi fornire i file entry-point SQL per eseguire le query Spark SQL in Amazon EMR su EKS con l'API `StartJobRun`, senza modifiche agli script Spark SQL esistenti. La tabella seguente elenca i parametri Spark supportati per i job SQL di Spark tramite l'API. StartJobRun 

Puoi scegliere tra i seguenti parametri Spark da inviare a un processo Spark SQL. Utilizza questi parametri per sovrascrivere le proprietà Spark predefinite.


| Opzione | Description | 
| --- | --- | 
|  --name NAME  | Nome applicazione | 
| --jars JARS | Elenco separato da virgole dei jar da includere nel classpath di driver ed esecuzione. | 
| --packages | Elenco separato da virgole delle coordinate maven dei jar, da includere nei classpath di driver ed executor. | 
| --exclude-packages | Elenco separato da virgole di groupId:artifactId, da escludere durante la risoluzione delle dipendenze fornite in –packages per evitare conflitti di dipendenze. | 
| --repositories | Elenco separato da virgole di repository remoti aggiuntivi per la ricerca delle coordinate maven fornite con –packages. | 
| --files FILES | Elenco separato da virgole di file da inserire nella directory di lavoro di ogni executor. | 
| --conf PROP=VALUE | Proprietà di configurazione Spark. | 
| --properties-file FILE | Percorso verso un file da cui caricare proprietà aggiuntive. | 
| --driver-memory MEM | Memoria per il driver. Valore predefinito: 1.024 MB. | 
| --driver-java-options | Opzioni Java extra da passare al driver. | 
| --driver-library-path | Voci aggiuntive percorso libreria da passare al driver. | 
| --driver-class-path | Voci aggiuntive classpath da passare al driver. | 
| --executor-memory MEM | Memoria per ogni executor. Valore predefinito 1 GB. | 
| --driver-cores NUM | Numero di core utilizzati dal driver. | 
| -- NUM total-executor-cores  | Numero totale di core per tutti gli executor. | 
| --executor-cores NUM | Numero di core utilizzati da ogni executor. | 
| --num-executors NUM | Numero di executor da avviare. | 
| -hivevar <key=value> | Sostituzione di variabile da applicare ai comandi Hive, ad esempio -hivevar A=B | 
| -hiveconf <property=value> | Valore da usare per la proprietà data. | 

Per un job SQL Spark, crea un start-job-run-request file.json e specifica i parametri richiesti per l'esecuzione del job, come nell'esempio seguente:

```
{
  "name": "myjob", 
  "virtualClusterId": "123456",  
  "executionRoleArn": "iam_role_name_for_job_execution", 
  "releaseLabel": "emr-6.7.0-latest", 
  "jobDriver": {
    "sparkSqlJobDriver": {
      "entryPoint": "entryPoint_location",
       "sparkSqlParameters": "--conf spark.executor.instances=2 --conf spark.executor.memory=2G --conf spark.executor.cores=2 --conf spark.driver.cores=1"
    }
  }, 
  "configurationOverrides": {
    "applicationConfiguration": [
      {
        "classification": "spark-defaults", 
        "properties": {
          "spark.driver.memory":"2G"
         }
      }
    ], 
    "monitoringConfiguration": {
      "persistentAppUI": "ENABLED", 
      "cloudWatchMonitoringConfiguration": {
        "logGroupName": "my_log_group", 
        "logStreamNamePrefix": "log_stream_prefix"
      }, 
      "s3MonitoringConfiguration": {
        "logUri": "s3://my_s3_log_location"
      }
    }
  }
}
```

# Stati delle esecuzioni di processi
<a name="emr-eks-jobs-states"></a>

Quando invii un'esecuzione di processo nella coda di processi di Amazon EMR su EKS, il suo stato diventa `PENDING`. Dopodiché passa per i seguenti stati fino a quando non ha esito positivo (codice di uscita `0`) o negativo (codice di uscita diverso da zero). 

Le esecuzioni di processi possono avere i seguenti stati:
+ `PENDING`: lo stato iniziale del processo quando l'esecuzione di processo viene inviata ad Amazon EMR su EKS. Il processo è in attesa di essere inviato al cluster virtuale e Amazon EMR su EKS sta lavorando per inviare questo processo.
+ `SUBMITTED`: un'esecuzione di processo che è stata inviata correttamente al cluster virtuale. Il pianificatore di cluster tenta quindi di eseguire questo processo nel cluster.
+ `RUNNING`: un processo in esecuzione nel cluster virtuale. Nelle applicazioni Spark, ciò significa che il processo del driver Spark si trova nello stato `running`.
+ `FAILED`: un'esecuzione di processo che non è stato possibile inviare al cluster virtuale o il cui completamento ha avuto esito negativo. Guarda StateDetails e FailureReason per trovare ulteriori informazioni su questo errore di lavoro.
+ `COMPLETED`: un'esecuzione di processo completata con successo.
+ `CANCEL_PENDING`: un'esecuzione di processo per la quale è stato richiesto l'annullamento. Amazon EMR su EKS sta tentando di annullare il processo nel cluster virtuale.
+ `CANCELLED`: un'esecuzione di processo annullata correttamente.

# Visualizzazione dei processi nella console Amazon EMR
<a name="emr-eks-jobs-console"></a>

È possibile visualizzare i dati relativi all'esecuzione del job, in modo da poter monitorare ogni processo mentre attraversa gli stati. Per visualizzare i processi nella console Amazon EMR, completa la procedura seguente.

1. Nel menu a destra della console Amazon EMR, in Amazon EMR su EKS, seleziona **Cloud virtuali**.

1. Dall'elenco dei cluster virtuali seleziona il cluster virtuale per il quale desideri visualizzare i processi.

1. Nella tabella **Esecuzioni dei processi**, seleziona **Visualizza log** per visualizzare i dettagli di un'esecuzione di processo.

**Nota**  
Il supporto per l'esperienza con un clic è abilitato per impostazione predefinita. Può essere disattivato impostando `persistentAppUI` su `DISABLED` in `monitoringConfiguration` durante l'invio del processo. Per ulteriori informazioni, consulta [Visualizzazione delle interfacce utente dell'applicazione persistente](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html).

# Errori comuni durante l'esecuzione di processi
<a name="emr-eks-jobs-error"></a>

Quando si esegue l'API `StartJobRun`, possono verificarsi i seguenti errori. La tabella elenca ogni errore e fornisce le misure di mitigazione in modo da poter risolvere rapidamente i problemi.


| Messaggio di errore | Condizione di errore | Fase successiva consigliata | 
| --- | --- | --- | 
|  errore: argomento -- *argument* è obbligatorio  | Parametri obbligatori mancanti. | Aggiungere gli argomenti mancanti alla richiesta API. | 
| Si è verificato un errore (AccessDeniedException) durante la chiamata dell' StartJobRunoperazione: User: ARN is not authorized to perform: emr-containers: StartJobRun | Ruolo di esecuzione mancante. | Consulta Utilizzo di [Uso dei ruoli di esecuzione di processo con Amazon EMR su EKS](iam-execution-role.md).  | 
|  Si è verificato un errore (AccessDeniedException) durante la chiamata dell' StartJobRunoperazione: User: *ARN* is not authorized to perform: emr-containers: StartJobRun  |  Il chiamante non dispone dell'autorizzazione per il ruolo di esecuzione [formato valido/non valido] tramite le chiavi di condizione.  | Per informazioni, consulta [Uso dei ruoli di esecuzione di processo con Amazon EMR su EKS](iam-execution-role.md).  | 
|  Si è verificato un errore (AccessDeniedException) durante la chiamata dell' StartJobRunoperazione: User: *ARN* is not authorized to perform: emr-containers: StartJobRun  |  Il mittente di processi e l'ARN del ruolo di esecuzione provengono da account diversi.  | Assicurati che il mittente di processi e l'ARN del ruolo di esecuzione provengano dallo stesso account AWS . | 
|  È stato rilevato 1 errore di convalida: il valore *Role* in 'executionRoleArn' non è riuscito a soddisfare il modello di espressione regolare ARN: ^arn :( aws [a-zA-Z0-9-] \$1) :iam: :(\$1 d \$112\$1)? : (ruolo ((\$1 u002F) \$1 (\$1 u002F [\$1 u0021-\$1 u007F] \$1\$1 u002F)) [\$1 w\$1=, .@-] \$1)  |  Il chiamante dispone delle autorizzazioni per il ruolo di esecuzione tramite chiavi di condizione, ma il ruolo non soddisfa i vincoli del formato ARN.  | Fornisci il ruolo di esecuzione seguendo il formato ARN. Per informazioni, consulta [Uso dei ruoli di esecuzione di processo con Amazon EMR su EKS](iam-execution-role.md).  | 
|  Si è verificato un StartJobRun errore () durante la chiamata dell'operazione: Il cluster virtuale non esiste. ResourceNotFoundException *Virtual Cluster ID*  |  L'ID del cluster virtuale non è stato trovato.  | Fornisci un ID del cluster virtuale registrato con Amazon EMR su EKS. | 
|  Si è verificato un errore (ValidationException) durante la chiamata dell' StartJobRunoperazione: lo stato del cluster virtuale non *state* è valido per creare la risorsa JobRun.  |  Il cluster virtuale non è pronto per eseguire il processo.  | Per informazioni, consulta [Stati dei cluster virtuali](virtual-cluster.md#virtual-cluster-states).  | 
|  Si è verificato un errore (ResourceNotFoundException) durante la chiamata dell' StartJobRunoperazione: Release *RELEASE* doesn't exist.  |  Il rilascio specificato nell'invio del processo non è corretto.  | Per informazioni, consulta [Rilasci di Amazon EMR su EKS](emr-eks-releases.md).  | 
|  Si è verificato un errore (AccessDeniedException) durante la chiamata all' StartJobRunoperazione: User: *ARN* is not authorized to perform: emr-containers: StartJobRun on resource: *ARN* con una negazione esplicita. Si è verificato un errore (AccessDeniedException) durante la chiamata all' StartJobRunoperazione: User: *ARN* is not authorized to perform: emr-containers: on resource: StartJobRun *ARN*  | L'utente non è autorizzato a chiamare. StartJobRun | Per informazioni, consulta [Uso dei ruoli di esecuzione di processo con Amazon EMR su EKS](iam-execution-role.md).  | 
|  Si è verificato un errore (ValidationException) durante la chiamata dell' StartJobRunoperazione: configurationOverrides.MonitoringConfiguration.s3 MonitoringConfiguration .LogURI non è riuscito a soddisfare il vincolo: %s  |  Sintassi URI del percorso S3 non valida.  | logUri dovrebbe essere nel formato di s3://...  | 

Quando si esegue l'API di `DescribeJobRun` prima di eseguire un processo, possono verificarsi i seguenti errori.


| Messaggio di errore | Condizione di errore | Fase successiva consigliata | 
| --- | --- | --- | 
|   JobRun StateDetails: invio non riuscito.  Classificazione *classification* non supportata. failureReason: VALIDATION\$1ERROR (ERRORE DI CONVALIDA) state: FAILED (NON RIUSCITO)  | I parametri inseriti non StartJobRun sono validi. | Per informazioni, consulta [Rilasci di Amazon EMR su EKS](emr-eks-releases.md).  | 
|  StateDetails: il cluster *EKS Cluster ID* non esiste. failureReason: CLUSTER\$1UNAVAILABLE (CLUSTER NON DISPONIBILE) state: FAILED (NON RIUSCITO)  | Il cluster EKS non è disponibile. | Verifica se il cluster EKS esiste e dispone delle autorizzazioni corrette. Per ulteriori informazioni, consulta [Configurazione di Amazon EMR su EKS](setting-up.md). | 
|  StateDetails: il cluster *EKS Cluster ID* non dispone di autorizzazioni sufficienti. failureReason: CLUSTER\$1UNAVAILABLE (CLUSTER NON DISPONIBILE) state: FAILED (NON RIUSCITO)  |  Amazon EMR non dispone delle autorizzazioni per accedere al cluster EKS.  | Verifica che le autorizzazioni siano impostate per Amazon EMR nello spazio dei nomi registrato. Per ulteriori informazioni, consulta [Configurazione di Amazon EMR su EKS](setting-up.md). | 
|  StateDetails: Il cluster *EKS Cluster ID* non è attualmente raggiungibile. failureReason: CLUSTER\$1UNAVAILABLE (CLUSTER NON DISPONIBILE) state: FAILED (NON RIUSCITO)  |  Il cluster EKS non è raggiungibile.  | Verifica se il cluster EKS esiste e dispone delle autorizzazioni corrette. Per ulteriori informazioni, consulta [Configurazione di Amazon EMR su EKS](setting-up.md). | 
|  StateDetails: JobRun invio non riuscito a causa di un errore interno. failureReason: INTERNAL\$1ERROR (ERRORE INTERNO) state: FAILED (NON RIUSCITO)  |  Si è verificato un errore interno nel cluster EKS.  | N/D | 
|  StateDetails: il cluster *EKS Cluster ID* non dispone di risorse sufficienti. failureReason: USER\$1ERROR (ERRORE UTENTE) state: FAILED (NON RIUSCITO)  |  Le risorse presenti nel cluster EKS sono insufficienti per eseguire il processo.  | Aggiungi più capacità al gruppo di nodi EKS o imposta EKS Autoscaler. Per ulteriori informazioni, consulta [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/cluster-autoscaler.html). | 

Quando si esegue l'API di `DescribeJobRun` dopo aver eseguito un processo, possono verificarsi i seguenti errori.


| Messaggio di errore | Condizione di errore | Fase successiva consigliata | 
| --- | --- | --- | 
|  StateDetails: Problemi nel monitoraggio del tuo. JobRun  *EKS Cluster ID*Il cluster non esiste. failureReason: CLUSTER\$1UNAVAILABLE (CLUSTER NON DISPONIBILE) state: FAILED (NON RIUSCITO)  | Il cluster EKS non esiste. | Verifica se il cluster EKS esiste e dispone delle autorizzazioni corrette. Per ulteriori informazioni, consulta [Configurazione di Amazon EMR su EKS](setting-up.md). | 
|  StateDetails: Problemi nel monitoraggio del tuo. JobRun *EKS Cluster ID*Il cluster non dispone di autorizzazioni sufficienti. failureReason: CLUSTER\$1UNAVAILABLE (CLUSTER NON DISPONIBILE) state: FAILED (NON RIUSCITO)  | Amazon EMR non dispone delle autorizzazioni per accedere al cluster EKS. | Verifica che le autorizzazioni siano impostate per Amazon EMR nello spazio dei nomi registrato. Per ulteriori informazioni, consulta [Configurazione di Amazon EMR su EKS](setting-up.md). | 
|  StateDetails: Problemi nel monitoraggio del tuo. JobRun *EKS Cluster ID*Il cluster non è attualmente raggiungibile. failureReason: CLUSTER\$1UNAVAILABLE (CLUSTER NON DISPONIBILE) state: FAILED (NON RIUSCITO)  |  Il cluster EKS non è raggiungibile.  | Verifica se il cluster EKS esiste e dispone delle autorizzazioni corrette. Per ulteriori informazioni, consulta [Configurazione di Amazon EMR su EKS](setting-up.md). | 
|  StateDetails: problemi di monitoraggio JobRun dovuti a un errore interno failureReason: INTERNAL\$1ERROR (ERRORE INTERNO) state: FAILED (NON RIUSCITO)  |  Si è verificato un errore interno che impedisce JobRun il monitoraggio.  | N/D | 

Il seguente errore può verificarsi quando un processo non può essere avviato e il processo rimane in attesa nello stato INVIATO per 15 minuti. Ciò può essere causato dalla mancanza di risorse del cluster.


| Messaggio di errore | Condizione di errore | Fase successiva consigliata | 
| --- | --- | --- | 
|  timeout del cluster  | Il lavoro è rimasto nello stato INVIATO per 15 minuti o più. | È possibile sovrascrivere l'impostazione predefinita di 15 minuti per questo parametro con l'override della configurazione mostrato di seguito.  | 

Utilizza la seguente configurazione per modificare l'impostazione predefinita di 30 minuti per il timeout del cluster. Tieni presente il fatto che il nuovo valore `job-start-timeout` è fornito in secondi:

```
{
"configurationOverrides": {
  "applicationConfiguration": [{
      "classification": "emr-containers-defaults",
      "properties": {
          "job-start-timeout":"1800"
      }
  }]
}
```