Risoluzione dei problemi relativi a Operazioni in batch S3
Operazioni in batch Amazon S3 consente di eseguire operazioni in batch su larga scala su oggetti Amazon S3. Questa guida ti aiuta a risolvere i problemi più comuni che potresti riscontrare.
Per risolvere i problemi con S3 Batch Replication, consulta Risoluzione dei problemi nella replica.
Sono disponibili due tipi principali di errori relativi a Operazioni in batch:
-
Errore dell’API: l’API richiesta (ad esempio
CreateJob) non è stata eseguita. -
Errore del processo: la richiesta API iniziale è stata completata ma il processo non è riuscito, ad esempio, a causa di problemi con il manifesto o le autorizzazioni agli oggetti specificati nel manifesto.
NoSuchJobException
Tipo: errore dell’API
NoSuchJobException si verifica quando Operazioni in batch S3 non riesce a individuare il processo specificato. Questo errore può verificarsi in diversi scenari oltre la semplice scadenza del processo. Le cause più comuni sono descritte di seguito.
Scadenza del processo: i processi vengono eliminati automaticamente 90 giorni dopo aver raggiunto lo stato terminale (
Complete,CancelledoFailed).ID del processo errato: l’ID del processo utilizzato in
DescribeJoboUpdateJobStatusnon corrisponde all’ID restituito daCreateJob.Regione errata: tentativo di accedere a un processo in una Regione diversa da quella in cui è stato creato.
Account errato: utilizzo di un ID del processo di un account AWS diverso.
Errori di formato dell’ID del processo: errori di battitura, caratteri aggiuntivi o formattazione errata nell’ID del processo.
Problemi relativi alla tempistica: verifica dello stato del processo subito dopo la creazione, prima che il processo sia completamente registrato.
I messaggi di errore correlati sono descritti di seguito.
No such jobThe specified job does not exist
Best practice per prevenire errori delle API NoSuchJobException
Archivia immediatamente gli ID del processo: salva l’ID del processo dalla risposta
CreateJobprima di effettuare le chiamate API successive.Implementa la logica dei tentativi: aggiungi un backoff esponenziale quando controlli lo stato del processo subito dopo la creazione.
Configura il monitoraggio: crea allarmi CloudWatch per monitorare il completamento del processo prima della scadenza dei 90 giorni. Per i dettagli, consulta Utilizzo degli allarmi Amazon CloudWatch nella Guida per l’utente di Amazon CloudWatch.
Utilizza Regioni coerenti: assicurati che tutte le operazioni del processo utilizzino la stessa Regione per la creazione del processo.
Convalida l’input: controlla il formato dell’ID del processo prima di effettuare chiamate API.
Scadenza dei processi
I processi nello stato terminale vengono eliminati automaticamente dopo 90 giorni. Per evitare di perdere informazioni del processo, considera quanto segue.
Scarica i report di completamento prima della scadenza: per istruzioni su come recuperare e archiviare i risultati del processo, consulta .
Archivia i metadati del processo nei tuoi sistemi: archivia le informazioni critiche del processo nei database o nei sistemi di monitoraggio.
Imposta notifiche automatizzate prima della scadenza di 90 giorni: utilizza Amazon EventBridge per creare regole che attivano le notifiche al completamento del processo. Per ulteriori informazioni, consulta Notifiche di eventi Amazon S3.
NoSuchJobExceptionRisoluzione dei problemi di
Utilizza il comando seguente per verificare che il processo sia presente nell’account e nella Regione.
aws s3control list-jobs --account-id111122223333--regionus-east-1Utilizza il seguente comando per cercare tutti gli stati del processo. I possibili stati del processo sono
Active,Cancelled,Cancelling,Complete,Completing,Failed,Failing,New,Paused,Pausing,Preparing,ReadyeSuspended.aws s3control list-jobs --account-id111122223333--job-statusesyour-job-statusUtilizza il comando seguente per verificare se il processo è presente in altre Regioni in cui di solito si creano processi.
aws s3control list-jobs --account-id111122223333--regionjob-region-1aws s3control list-jobs --account-id111122223333--regionjob-region-2-
Convalida il formato dell’ID del processo. Gli ID del processo in genere contengono 36 caratteri, ad esempio
12345678-1234-1234-1234-123456789012. Verifica la presenza di spazi aggiuntivi, caratteri mancanti o problemi di distinzione tra maiuscole e minuscole e verifica di utilizzare l’ID del processo completo restituito dal comandoCreateJob. -
Utilizza il comando seguente per verificare la presenza di eventi di creazione di processi nei log di CloudTrail.
aws logs filter-log-events --log-group-name CloudTrail/S3BatchOperations \ --filter-pattern "{ $.eventName = CreateJob }" \ --start-timetimestamp
AccessDeniedException
Tipo: errore dell’API
AccessDeniedException si verifica quando una richiesta di Operazioni in batch S3 viene bloccata a causa di autorizzazioni insufficienti, operazioni non supportate o restrizioni delle policy. Questo è uno degli errori più comuni in Operazioni in batch. Le cause comuni sono le seguenti:
Autorizzazioni IAM mancanti: l’identità IAM non dispone delle autorizzazioni necessarie per le API di Operazioni in batch.
Autorizzazioni S3 insufficienti: autorizzazioni mancanti per accedere ai bucket di origine o destinazione e agli oggetti.
Problemi relativi al ruolo di esecuzione del processo: il ruolo di esecuzione del processo non dispone delle autorizzazioni per eseguire l’operazione specificata.
Operazioni non supportate: tentativo di utilizzare operazioni non supportate nella Regione o nel tipo di bucket correnti.
Problemi di accesso multi-account: autorizzazioni mancanti per l’accesso multi-account a bucket o oggetti.
Restrizioni delle policy basate sulle risorse: policy di bucket o ACL degli oggetti bloccano l’operazione.
Restrizioni delle policy di controllo dei servizi: policy a livello di organizzazione impediscono l’operazione.
Messaggi di errore correlati:
Access DeniedUser: arn:aws:iam::account:user/username is not authorized to perform: s3:operationCross-account pass role is not allowedThe bucket policy does not allow the specified operation
Best practice per prevenire errori delle API AccessDeniedException
Utilizza il principio del privilegio minimo: concedi solo le autorizzazioni minime richieste per le operazioni specifiche.
Verifica le autorizzazioni prima di eseguire processi di grandi dimensioni: esegui piccoli processi di test per convalidare le autorizzazioni prima di elaborare migliaia di oggetti.
Utilizza il simulatore di policy IAM: testa le policy prima dell’implementazione utilizzando il simulatore di policy IAM. Per ulteriori informazioni, consulta Test delle policy IAM con il simulatore di policy IAM nella Guida per l’utente IAM.
Implementa una corretta configurazione multi-account: controlla la configurazione dell’accesso multi-account per le configurazioni dei processi multi-account. Per ulteriori informazioni, consulta Tutorial IAM: delega dell’accesso tra account AWS tramite i ruoli IAM nella Guida per l’utente IAM.
Monitora le modifiche alle autorizzazioni: configura gli avvisi CloudTrail per le modifiche alle policy IAM che potrebbero influire su Operazioni in batch.
Documenta i requisiti dei ruoli: mantieni una documentazione chiara delle autorizzazioni richieste per ogni tipo di processo.
Utilizza modelli di autorizzazione comuni: utilizza gli esempi di autorizzazione e i modelli di policy:
Risorse multi-account in IAM nella Guida per l’utente IAM.
Controllo dell’accesso agli endpoint VPC utilizzando le policy degli endpoint nella Guida di AWS PrivateLink.
Risoluzione dei problemi relativi ad AccessDeniedException
Segui sistematicamente queste fasi per identificare e risolvere i problemi di autorizzazione.
Consulta Operazioni supportate dalle operazioni in batch S3 per le operazioni supportate per Regione. Verifica che le operazioni del bucket di directory siano disponibili solo negli endpoint regionali e zonali. Verifica che l’operazione sia supportata per la classe di archiviazione del bucket.
Utilizza il seguente comando per determinare se puoi elencare i processi.
aws s3control list-jobs --account-id111122223333Utilizza il comando seguente per verificare le autorizzazioni IAM per l’identità richiedente. L’account che esegue il processo richiede le seguenti autorizzazioni:
s3:CreateJob,s3:DescribeJob,s3:ListJobs-s3:UpdateJobPriority,s3:UpdateJobStatus-iam:PassRole.aws sts get-caller-identity111122223333Utilizza il comando seguente per verificare che il ruolo sia presente e utilizzabile.
aws iam get-role --role-namerole-name-
Utilizza il comando seguente per esaminare la policy di attendibilità del ruolo. Il ruolo che esegue il processo deve disporre di:
Una relazione di attendibilità che consente a
batchoperations---s3.amazonaws.com.rproxy.govskope.cadi assumere il ruolo.Le operazioni eseguite da Operazioni in batch (ad esempio
s3:PutObjectTaggingper le operazioni di tagging).Accesso ai bucket di origine e di destinazione.
Autorizzazione a leggere il file manifesto.
Autorizzazione a scrivere report di completamento.
aws iam get-role --role-namerole-name--query 'Role.AssumeRolePolicyDocument' Utilizza il comando seguente per testare l’accesso ai bucket di origine e al manifesto.
aws s3 ls s3://bucket-name-
Testa l’operazione eseguita da Operazioni in batch. Ad esempio, se Operazioni in batch esegue il tagging, applica un tag a un oggetto di esempio nel bucket di origine.
Esamina le policy di bucket per individuare quelle che potrebbero negare l’operazione.
Controlla le ACL degli oggetti se utilizzi controlli degli accessi legacy.
Verifica che nessuna policy di controllo dei servizi blocchi l’operazione.
Verifica che le policy degli endpoint VPC consentano Operazioni in batch se si utilizzano endpoint VPC.
Utilizza il comando seguente per utilizzare CloudTrail per identificare gli errori di autorizzazione.
aws logs filter-log-events --log-group-name CloudTrail/S3BatchOperations \ --filter-pattern "{ $.errorCode = AccessDenied }" \ --start-timetimestamp
SlowDownError
Tipo: errore dell’API
L’eccezione SlowDownError si verifica quando l’account ha superato il limite di velocità delle richieste per le API di Operazioni in batch S3. Questo è un meccanismo di limitazione (della larghezza di banda della rete) per proteggere il servizio dal sovraccarico dovuto a troppe richieste. Le cause comuni sono le seguenti:
Elevata frequenza di richieste API: troppe chiamate API in un breve periodo di tempo.
Operazioni sul processo simultanee: più applicazioni o utenti creano e gestiscono processi contemporaneamente.
Script automatizzati senza limiti di velocità: script che non implementano strategie di backoff adeguate.
Polling troppo frequenti dello stato del processo: verifica dello stato del processo eseguita più spesso del necessario.
Modelli di traffico aumentato: picchi improvvisi nell’utilizzo delle API durante i periodi di elaborazione di punta.
Limiti di capacità regionale: superamento della capacità di richiesta allocata per la Regione.
Messaggi di errore correlati:
SlowDownPlease reduce your request rateRequest rate exceeded
Best practice per prevenire errori delle API SlowDownError
Implementa la limitazione della velocità sul lato client: aggiungi ritardi tra le chiamate API nelle applicazioni.
Utilizza il backoff esponenziale con jitter: applica la randomizzazione dei ritardi dei tentativi per evitare problemi di thundering herd.
Imposta una logica dei tentativi adeguata: implementa tentativi automatici con ritardi crescenti per gli errori transitori.
Utilizza architetture basate sugli eventi: sostituisci il polling con le notifiche EventBridge per le modifiche allo stato del processo.
Distribuisci il carico nel tempo: organizza la creazione di processi e i controlli dello stato in diversi periodi di tempo.
Monitora e avvisa ai limiti di velocità: configura gli allarmi CloudWatch per rilevare quando ti stai avvicinando ai limiti.
La maggior parte degli AWS SDK include una logica dei tentativi integrata per gli errori di limitazione della velocità. Configurali come segue:
AWS CLI: utilizza i parametri
cli-read-timeoutecli-connect-timeout.AWS SDK per Python (Boto3): configura le modalità dei tentativi e il numero massimo di tentativi nella configurazione del client.
AWS SDK per Java: utilizza le impostazioni
RetryPolicyeClientConfiguration.AWS SDK per JavaScript: configura
maxRetrieseretryDelayOptions.
Per ulteriori informazioni sui modelli dei tentativi e sulle best practice, consulta Nuovo tentativo con schema di backoff nel Prontuario AWS.
Risoluzione dei problemi relativi a SlowDownError
Nel codice, implementa immediatamente il backoff esponenziale.
Esempio di backoff esponenziale in bash
for attempt in {1..5}; do if aws s3control describe-job --account-id111122223333--job-idjob-id; then break else wait_time=$((2**attempt)) echo "Rate limited, waiting ${wait_time} seconds..." sleep $wait_time fi done-
Utilizza CloudTrail per identificare l’origine dell’elevato volume di richieste.
aws logs filter-log-events \ --log-group-name CloudTrail/S3BatchOperations \ --filter-pattern "{ $.eventName = CreateJob || $.eventName = DescribeJob }" \ --start-timetimestamp\ --query 'events[*].[eventTime,sourceIPAddress,userIdentity.type,eventName]' Verifica la frequenza di polling.
Evita di controllare lo stato del processo più di una volta ogni 30 secondi per i processi attivi.
Se possibile, utilizza le notifiche di completamento del processo anziché il polling.
Implementa jitter negli intervalli di polling per evitare richieste sincronizzate.
-
Ottimizza i modelli di utilizzo delle API.
Se possibile, esegui più operazioni in batch.
Utilizza
ListJobsper ottenere lo stato di più processi in una sola chiamata.Memorizza nella cache le informazioni sui processi per ridurre le chiamate API ridondanti.
Suddividi la creazione dei processi nel tempo anziché crearne molti contemporaneamente.
-
Utilizza le metriche CloudWatch per le chiamate API per monitorare i modelli di richiesta.
aws logs put-metric-filter \ --log-group-name CloudTrail/S3BatchOperations \ --filter-name S3BatchOpsAPICallCount \ --filter-pattern "{ $.eventSource = s3.amazonaws.com && $.eventName = CreateJob }" \ --metric-transformations \ metricName=S3BatchOpsAPICalls,metricNamespace=Custom/S3BatchOps,metricValue=1
InvalidManifestContent
Tipo: errore del processo
L’eccezione InvalidManifestContent si verifica quando ci sono problemi con il formato, il contenuto o la struttura del file manifesto che impediscono a Operazioni in batch S3 di elaborare il processo. Le cause comuni sono le seguenti:
Violazioni del formato: colonne obbligatorie mancanti, delimitatori errati o struttura CSV non valida.
Problemi di codifica del contenuto: codifica errata dei caratteri, indicatori BOM o caratteri non UTF-8.
Problemi con le chiavi dell’oggetto: caratteri non validi, codifica URL non corretta o chiavi che superano i limiti di lunghezza.
Limiti relativi alle dimensioni: il manifesto contiene più oggetti di quelli supportati dall’operazione.
Errori di formato dell’ID della versione: ID della versione non validi o non corretti per gli oggetti con controllo delle versioni.
Problemi relativi al formato di ETag: formato di ETag errato o virgolette mancanti per le operazioni che richiedono ETag.
Dati incoerenti: formati misti all’interno dello stesso manifesto o numero di colonne non coerente.
Messaggi di errore correlati:
Required fields are missing in the schema: + missingFieldsInvalid Manifest ContentThe S3 Batch Operations job failed because it contains more keys than the maximum allowed in a single jobInvalid object key formatManifest file is not properly formattedInvalid version ID formatETag format is invalid
Best practice per prevenire gli errori dei processi InvalidManifestContent
Convalida prima del caricamento: testa il formato del manifesto con piccoli processi prima di elaborare set di dati di grandi dimensioni.
Utilizza una codifica coerente: utilizza sempre la codifica UTF-8 senza BOM per i file manifesto.
Implementa gli standard di generazione dei manifesti: crea modelli e procedure di convalida per la creazione di manifesti.
Gestisci correttamente i caratteri speciali: gli URL codificano le chiavi degli oggetti che contengono caratteri speciali.
Monitora il numero di oggetti: monitora le dimensioni del manifesto e suddividi i lavori di grandi dimensioni in modo proattivo.
Convalida la presenza degli oggetti: verifica la presenza degli oggetti prima di includerli nei manifesti.
Utilizza strumenti AWS per la generazione di manifesti: utilizza AWS CLI
s3api list-objects-v2per generare elenchi di oggetti formattati correttamente.
Problemi e soluzioni comuni relativi ai manifesti:
Colonne obbligatorie mancanti: assicurati che il manifesto includa tutte le colonne obbligatorie per il tipo di operazione. Le colonne mancanti più comuni sono Bucket e Chiave.
Formato CSV non corretto: utilizza le virgole come delimitatori, assicura un numero di colonne uniforme su tutte le righe ed evita gli embedding delle interruzioni di riga nei campi.
Caratteri speciali nelle chiavi degli oggetti: gli URL codificano le chiavi degli oggetti che contengono spazi, caratteri Unicode o caratteri speciali XML (<, >, &, ", ').
File manifesti di grandi dimensioni: suddividi i manifesti con un numero di operazioni superiore al limite in diversi manifesti più piccoli e crea processi separati.
ID della versione non validi: assicurati che gli ID della versione siano stringhe alfanumeriche formattate correttamente. Rimuovi la colonna ID della versione se non è necessaria.
Problemi di codifica: salva i file manifesto come UTF-8 senza BOM. Evita di copiare i manifesti attraverso sistemi che potrebbero alterare la codifica.
Per le specifiche dettagliate e gli esempi relativi al formato del manifesto, consulta quanto segue:
Risoluzione dei problemi relativi a InvalidManifestContent
Scarica e controlla il file manifesto. Verifica manualmente che il manifesto soddisfi i requisiti di formato:
Formato CSV con virgola come delimitatore.
Codifica UTF-8 senza BOM.
Numero coerente di colonne per tutte le righe.
Senza righe vuote o spazi finali.
Le chiavi dell’oggetto sono codificate correttamente nell’URL se contengono caratteri speciali.
Utilizza il seguente comando per scaricare il file manifesto.
aws s3 cp s3://amzn-s3-demo-bucket1/manifest-key./manifest.csv-
Controlla le colonne obbligatorie per l’operazione:
Tutte le operazioni:
Bucket,KeyOperazioni di copia:
VersionId(facoltativo)Operazioni di ripristino:
VersionId(facoltativo)Operazioni di sostituzione di tag: non sono necessarie colonne aggiuntive.
Operazioni di sostituzione di ACL: non sono necessarie colonne aggiuntive.
Avvia ripristino:
VersionId(facoltativo)
-
Controlla i limiti del numero di oggetti:
Copia: massimo 1 miliardo di oggetti.
Eliminazione: massimo 1 miliardo di oggetti.
Ripristino: massimo 1 miliardo di oggetti.
Tagging: massimo 1 miliardo di oggetti.
ACL: massimo 1 miliardo di oggetti.
-
Crea un manifesto di test con alcuni oggetti del manifesto originale.
-
Utilizza il seguente comando per verificare se esiste un esempio di oggetti del manifesto.
aws s3 ls s3://amzn-s3-demo-bucket1/object-key -
Controlla i dettagli dell’errore del processo e verifica il motivo ed eventuali dettagli specifici dell’errore nella descrizione del processo.
aws s3control describe-job --account-id111122223333--job-idjob-id