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à. # Job stati Quando si invia un lavoro a una coda di AWS Batch lavoro, il lavoro entra nello `SUBMITTED` stato. Dopodiché passa per gli stati successivi, fino a quando non ha esito positivo (codice di uscita `0`) o negativo (codice di uscita diverso da zero). I processi di AWS Batch hanno gli stati seguenti: `SUBMITTED` Un lavoro che è stato inviato alla coda e non è stato ancora valutato dallo scheduler. Il pianificatore valuta il processo per stabilire se presenta dipendenze in sospeso relative al corretto completamento di altri processi. Se sono presenti dipendenze, il processo passa allo stato `PENDING`. Se non sono presenti dipendenze, il processo passa allo stato `RUNNABLE`. `PENDING` Un lavoro che si trova in coda e non è ancora in grado di essere eseguito a causa della dipendenza da un altro lavoro o risorsa. Quando le dipendenze sono state soddisfatte, il processo passa allo stato `RUNNABLE`. I genitori di Array job vengono aggiornati a `PENDING` quando un job secondario viene aggiornato `RUNNABLE` e rimangono attivi mentre i job `PENDING` secondari sono in esecuzione. Per visualizzare questi lavori, filtra per `PENDING` stato finché tutti i lavori secondari non raggiungono lo stato terminale. `RUNNABLE` Un processo che si trova nella coda, che non presenta dipendenze in sospeso e che è quindi pronto per essere pianificato per un host. I lavori in questo stato vengono avviati non appena sono disponibili risorse sufficienti in uno degli ambienti di elaborazione mappati sulla coda del lavoro. Tuttavia, i processo possono rimanere in questo stato in modo indefinito se le risorse sufficienti non sono disponibili. Se i tuoi lavori non procedono`STARTING`, consulta la sezione relativa alla risoluzione dei [Lavori bloccati in uno `RUNNABLE` status](job_stuck_in_runnable.md) problemi. `STARTING` Questi processi sono stati pianificati per un host e le operazioni di avvio del container pertinente sono in corso. Una volta che l'immagine del container è stata estratta e il container è in esecuzione, il processo passa allo stato `RUNNING`. La durata del pull dell'immagine, la durata del completamento di Amazon EKS InitContainer e la durata della risoluzione di Amazon ECS ContainerDependency si verificano nello stato STARTING. La quantità di tempo necessaria per estrarre un'immagine per il tuo lavoro è equivalente alla quantità di tempo in cui il lavoro rimarrà nello stato INIZIALE. Ad esempio, se occorrono tre minuti per estrarre l'immagine del lavoro, quest'ultimo rimarrà nello stato INIZIALE per tre minuti. Se InitContainers impiega un totale di dieci minuti per essere completato, il processo Amazon EKS rimarrà in modalità STARTING per dieci minuti. Se hai impostato Amazon ECS ContainerDependencies nel tuo job Amazon ECS, il processo rimarrà in STARTING fino a quando tutte le dipendenze del contenitore (il loro runtime) non saranno risolte. STARTING non è incluso nei timeout; la durata inizia da RUNNING. Per ulteriori informazioni, consulta [Job states](https://docs.aws.amazon.com/batch/latest/userguide/job_states.html). `RUNNING` Il processo viene eseguito come processo container su un'istanza di container Amazon ECS all'interno di un ambiente di calcolo. Al momento dell'uscita del container, il codice di uscita del processo determina l'esito positivo o negativo di quest'ultimo. Il codice di uscita `0` indica che il processo ha avuto esito positivo, mentre un codice di uscita diverso da zero indica che ha avuto esito negativo. Se il processo associato a un tentativo non riuscito presenta tentativi rimanenti nella sua configurazione opzionale della strategia relativa ai nuovi tentativi, il processo passa nuovamente allo stato `RUNNABLE`. Per ulteriori informazioni, consulta [Ritentativi di lavoro automatizzati](job_retries.md). I registri dei `RUNNING` lavori sono disponibili in Logs. CloudWatch Il gruppo di log è`/aws/batch/job`, e il formato del nome del flusso di log è il seguente:. `first200CharsOfJobDefinitionName/default/ecs_task_id` Questo formato potrebbe cambiare in futuro. Dopo che un processo raggiunge lo `RUNNING` stato, è possibile recuperare a livello di codice il nome del flusso di log con l'[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)operazione API. Per ulteriori informazioni, consulta [Visualizza i dati di log inviati ai CloudWatch registri nella Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) *User* Guide. Per impostazione predefinita, questi log non scadono mai. Tuttavia, è possibile modificare il periodo di conservazione. Per ulteriori informazioni, consulta [Change Log Data Retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) nella *Amazon CloudWatch Logs User Guide.* `SUCCEEDED` Il processo è stato completato correttamente e ha ricevuto il codice di uscita `0`. Lo stato del lavoro per i `SUCCEEDED` lavori viene mantenuto invariato AWS Batch per almeno 7 giorni. I registri dei `SUCCEEDED` lavori sono disponibili in CloudWatch Registri. Il gruppo di log è`/aws/batch/job`, e il formato del nome del flusso di log è il seguente:. `first200CharsOfJobDefinitionName/default/ecs_task_id` Questo formato potrebbe cambiare in futuro. Dopo che un processo raggiunge lo `RUNNING` stato, è possibile recuperare a livello di codice il nome del flusso di log con l'[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)operazione API. Per ulteriori informazioni, consulta [Visualizza i dati di log inviati ai CloudWatch registri nella Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) *User* Guide. Per impostazione predefinita, questi log non scadono mai. Tuttavia, è possibile modificare il periodo di conservazione. Per ulteriori informazioni, consulta [Change Log Data Retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) nella *Amazon CloudWatch Logs User Guide.* `FAILED` Il processo ha ottenuto un esito negativo per tutti i tentativi disponibili. Lo stato del lavoro per i `FAILED` lavori viene mantenuto invariato AWS Batch per almeno 7 giorni. I registri dei `FAILED` lavori sono disponibili in CloudWatch Registri. Il gruppo di log è`/aws/batch/job`, e il formato del nome del flusso di log è il seguente:. `first200CharsOfJobDefinitionName/default/ecs_task_id` Questo formato potrebbe cambiare in futuro. Dopo che un lavoro raggiunge lo `RUNNING` stato, è possibile recuperarne il flusso di log a livello di codice con l'[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)operazione API. Per ulteriori informazioni, consulta [Visualizza i dati di log inviati ai CloudWatch registri nella Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#ViewingLogData) *User* Guide. Per impostazione predefinita, questi log non scadono mai. Tuttavia, è possibile modificare il periodo di conservazione. Per ulteriori informazioni, consulta [Change Log Data Retention in CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SettingLogRetention.html) nella *Amazon CloudWatch Logs User Guide.*