Résolution des problèmes liés aux opérations par lots S3 Batch - Amazon Simple Storage Service
NoSuchJobExceptionInvalidManifestContent

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Résolution des problèmes liés aux opérations par lots S3 Batch

Amazon S3 Batch Operations vous permet d'effectuer des opérations à grande échelle sur des objets Amazon S3. Ce guide vous aide à résoudre les problèmes courants que vous pourriez rencontrer.

Pour résoudre les problèmes liés à la réplication par lot S3, consultez Résolution des problèmes de réplication.

Il existe deux principaux types de défaillances qui entraînent des erreurs de fonctionnement du mode Batch :

  1. Échec de l'API — L'API demandée (telle queCreateJob) n'a pas pu être exécutée.

  2. Échec de la tâche : la demande d'API initiale a réussi, mais la tâche a échoué, par exemple en raison de problèmes liés au manifeste ou aux autorisations d'accès aux objets spécifiés dans le manifeste.

NoSuchJobException

Type : échec de l'API

Cela se NoSuchJobException produit lorsque S3 Batch Operations ne parvient pas à localiser la tâche spécifiée. Cette erreur peut se produire dans plusieurs scénarios autres que la simple expiration d'une tâche. Les causes courantes sont les suivantes.

  1. Expiration des tâches : les tâches sont automatiquement supprimées 90 jours après avoir atteint l'état terminal (CompleteCancelled, ouFailed).

  2. ID de tâche incorrect : l'identifiant de tâche utilisé DescribeJob ou UpdateJobStatus ne correspond pas à l'identifiant renvoyé parCreateJob.

  3. Mauvaise région : tentative d'accès à une offre d'emploi dans une région différente de celle où elle a été créée.

  4. Mauvais compte — Utilisation d'un identifiant de poste provenant d'un autre AWS compte.

  5. Erreurs de format de l'ID de tâche : fautes de frappe, caractères supplémentaires ou mise en forme incorrecte dans l'ID de tâche.

  6. Problèmes de calendrier : vérification du statut de la tâche immédiatement après sa création avant que la tâche ne soit complètement enregistrée.

Les messages d'erreur associés sont les suivants.

  1. No such job

  2. The specified job does not exist

Bonnes pratiques pour éviter les défaillances des NoSuchJobException API

  1. Stocker la tâche IDs immédiatement : enregistrez l'ID de la tâche dans la CreateJob réponse avant d'effectuer les appels d'API suivants.

  2. Implémenter une logique de nouvelle tentative : ajoutez un délai exponentiel lors de la vérification de l'état de la tâche immédiatement après sa création.

  3. Configuration de la surveillance : créez des CloudWatch alarmes pour suivre l'achèvement des tâches avant l'expiration des 90 jours. Pour plus de détails, consultez la section Utilisation CloudWatch des alarmes dans le guide de CloudWatch l'utilisateur Amazon.

  4. Utiliser des régions cohérentes — Assurez-vous que toutes les opérations liées à l'emploi utilisent la même région pour la création d'emplois.

  5. Valider la saisie : vérifiez le format de l'ID de tâche avant d'effectuer des appels d'API.

Quand les offres d'emploi expirent

Les tâches dans les états terminaux sont automatiquement supprimées au bout de 90 jours. Pour éviter de perdre des informations sur l'emploi, tenez compte des points suivants.

  1. Téléchargez les rapports d'achèvement avant leur expiration : pour obtenir des instructions sur la récupération et le stockage des résultats des tâches, consultez.

  2. Archivez les métadonnées des tâches dans vos propres systèmes : stockez les informations critiques sur les tâches dans vos bases de données ou vos systèmes de surveillance.

  3. Configurez des notifications automatiques avant la date limite de 90 jours : utilisez Amazon EventBridge pour créer des règles qui déclenchent des notifications lorsque les tâches sont terminées. Pour de plus amples informations, veuillez consulter Notifications d'événements Amazon S3.

Résolution des problèmes liés à NoSuchJobException

  1. Utilisez la commande suivante pour vérifier que le job existe dans votre compte et dans votre région.

    
aws s3control list-jobs --account-id 111122223333 --region us-east-1

  2. Utilisez la commande suivante pour effectuer une recherche dans tous les statuts de travail. Les statuts de poste possibles incluent ActiveCancelled,Cancelling,Complete,,Completing,Failed,Failing,New,Paused,Pausing, PreparingReady, etSuspended.

    
aws s3control list-jobs --account-id 111122223333 --job-statuses your-job-status

  3. Utilisez la commande suivante pour vérifier si la tâche existe dans d'autres régions où vous créez fréquemment des tâches.

    
aws s3control list-jobs --account-id 111122223333 --region job-region-1 aws s3control list-jobs --account-id 111122223333 --region job-region-2

  4. Validez le format de l'ID de tâche. Job contient IDs généralement 36 caractères, tels que12345678-1234-1234-1234-123456789012. Vérifiez s'il n'y a pas d'espaces supplémentaires, de caractères manquants ou de distinction majuscules/minuscules et vérifiez que vous utilisez l'identifiant de tâche complet renvoyé par la CreateJob commande.

  5. Utilisez la commande suivante pour vérifier les événements liés à la création de tâches dans les CloudTrail journaux.

    
    aws logs filter-log-events --log-group-name CloudTrail/S3BatchOperations \ --filter-pattern "{ $.eventName = CreateJob }" \ --start-time timestamp

AccessDeniedException

Type : échec de l'API

Cela se AccessDeniedException produit lorsqu'une demande S3 Batch Operations est bloquée en raison d'autorisations insuffisantes, d'opérations non prises en charge ou de restrictions politiques. Il s'agit de l'une des erreurs les plus courantes dans Batch Operations. Elle a les causes communes suivantes :

  1. Autorisations IAM manquantes — L'identité IAM ne dispose pas des autorisations requises pour les opérations par lots. APIs

  2. Autorisations S3 insuffisantes : autorisations manquantes pour accéder aux compartiments et aux objets source ou de destination.

  3. Problèmes liés au rôle d'exécution des tâches : le rôle d'exécution des tâches ne dispose pas des autorisations nécessaires pour effectuer l'opération spécifiée.

  4. Opérations non prises en charge : tentative d'utilisation d'opérations non prises en charge dans la région ou le type de compartiment actuel.

  5. Problèmes d'accès entre comptes : autorisations manquantes pour l'accès aux compartiments ou aux objets entre comptes.

  6. Restrictions de politique basées sur les ressources : politiques de compartiment ou objets ACLs bloquant l'opération.

  7. Restrictions de la politique de contrôle des services (SCP) : politiques au niveau de l'organisation empêchant l'opération.

Messages d'erreur associés :

  1. Access Denied

  2. User: arn:aws:iam::account:user/username is not authorized to perform: s3:operation

  3. Cross-account pass role is not allowed

  4. The bucket policy does not allow the specified operation

Bonnes pratiques pour éviter les défaillances des AccessDeniedException API

  1. Utilisez le principe du moindre privilège : accordez uniquement les autorisations minimales requises pour vos opérations spécifiques.

  2. Tester les autorisations avant les tâches volumineuses : exécutez de petites tâches de test pour valider les autorisations avant de traiter des milliers d'objets.

  3. Utiliser le simulateur de politique IAM : testez les politiques avant le déploiement à l'aide du simulateur de politique IAM. Pour plus d'informations, consultez la section Test des politiques IAM avec le simulateur de politique IAM dans le guide de l'utilisateur IAM.

  4. Mettez en œuvre une configuration inter-comptes appropriée : vérifiez votre configuration d'accès multicompte pour les configurations de tâches entre comptes. Pour plus d'informations, consultez le didacticiel IAM : Déléguer l'accès entre AWS comptes à l'aide de rôles IAM dans le guide de l'utilisateur IAM.

  5. Surveiller les modifications des autorisations : configurez CloudTrail des alertes pour les modifications de la politique IAM susceptibles d'affecter les opérations par lots.

  6. Documentez les exigences relatives aux rôles : conservez une documentation claire des autorisations requises pour chaque type de travail.

  7. Utilisez des modèles d'autorisation courants : utilisez les exemples d'autorisations et les modèles de politiques :

    1. Octroi d’autorisations pour les opérations par lots

    2. Ressources multicomptes dans IAM dans le guide de l'utilisateur IAM.

    3. Contrôlez l'accès aux points de terminaison VPC à l'aide des politiques relatives aux points de terminaison décrites dans le Guide. AWS PrivateLink

AccessDeniedException résolution des problèmes

Suivez systématiquement ces étapes pour identifier et résoudre les problèmes d'autorisation.

  1. Vérifiez Opérations prises en charge par les opérations par lot S3 les opérations prises en charge par région. Vérifiez que les opérations de bucket d'annuaire ne sont disponibles que sur les points de terminaison régionaux et zonaux. Vérifiez que l'opération est prise en charge pour la classe de stockage de votre bucket.

  2. Utilisez la commande suivante pour déterminer si vous pouvez répertorier les tâches.

    
 aws s3control list-jobs --account-id 111122223333

  3. Utilisez la commande suivante pour vérifier les autorisations IAM associées à l'identité demandeuse. Le compte exécutant le job doit disposer des autorisations suivantes :s3:CreateJob,s3:DescribeJob,s3:ListJobs-s3:UpdateJobPriority,s3:UpdateJobStatus-iam:PassRole.

    
aws sts get-caller-identity 111122223333

  4. Utilisez la commande suivante pour vérifier si le rôle existe et s'il est assumé.

    
aws iam get-role --role-name role-name

  5. Utilisez la commande suivante pour vérifier la politique de confiance du rôle. Le rôle exécutant la tâche doit avoir les caractéristiques suivantes :

    1. Une relation de confiance batchoperations.s3.amazonaws.com permettant d'assumer le rôle.

    2. Les opérations effectuées par l'opération par lots (par exemple s3:PutObjectTagging pour les opérations de marquage).

    3. Accès aux compartiments source et de destination.

    4. Autorisation de lire le fichier manifeste.

    5. Autorisation de rédiger des rapports d'achèvement.

    
aws iam get-role --role-name role-name --query 'Role.AssumeRolePolicyDocument'

  6. Utilisez la commande suivante pour rétablir l'accès au manifeste et aux compartiments source.

    
aws s3 ls s3://bucket-name

  7. Testez l'opération effectuée par l'opération par lots. Par exemple, si l'opération par lots effectue un balisage, balisez un exemple d'objet dans le compartiment source.

  8. Passez en revue les politiques relatives aux compartiments pour détecter les politiques susceptibles de refuser l'opération.

    1. Vérifiez l'objet ACLs si vous travaillez avec des contrôles d'accès existants.

    2. Vérifiez qu'aucune politique de contrôle des services (SCPs) ne bloque l'opération.

    3. Vérifiez que les politiques de point de terminaison VPC autorisent les opérations par lots si vous utilisez des points de terminaison VPC.

  9. Utilisez la commande suivante pour identifier CloudTrail les échecs d'autorisation.

    
aws logs filter-log-events --log-group-name CloudTrail/S3BatchOperations \
    --filter-pattern "{ $.errorCode = AccessDenied }" \
    --start-time timestamp

SlowDownError

Type : échec de l'API

L'SlowDownErrorexception se produit lorsque votre compte a dépassé la limite de taux de demandes pour S3 Batch Operations APIs. Il s'agit d'un mécanisme de régulation destiné à empêcher le service d'être submergé par un trop grand nombre de demandes. Elle a les causes communes suivantes :

  1. Fréquence de demandes d'API élevée — Effectuer trop d'appels d'API en peu de temps.

  2. Opérations de tâches simultanées : creating/managing tâches simultanées pour plusieurs applications ou utilisateurs.

  3. Scripts automatisés sans limitation de débit : scripts qui ne mettent pas en œuvre de stratégies de backoff appropriées.

  4. Interrogation trop fréquente du statut du poste : vérification du statut du poste plus souvent que nécessaire.

  5. Modèles de trafic en rafale : pics soudains d'utilisation des API pendant les périodes de traitement de pointe.

  6. Limites de capacité régionales — Dépassement de la capacité de demande allouée pour votre région.

Messages d'erreur associés :

  1. SlowDown

  2. Please reduce your request rate

  3. Request rate exceeded

Bonnes pratiques pour éviter les défaillances des SlowDownError API

  1. Implémentez la limitation du débit côté client : ajoutez des délais entre les appels d'API dans vos applications.

  2. Utilisez un recul exponentiel associé à la nervosité : répartissez de manière aléatoire les délais de relance pour éviter de graves problèmes avec le troupeau.

  3. Configurez une logique de nouvelle tentative appropriée : implémentez des tentatives automatiques avec des délais croissants pour les erreurs transitoires.

  4. Utilisez des architectures axées sur les événements : remplacez les sondages par des EventBridge notifications concernant les changements de statut des tâches.

  5. Répartissez la charge dans le temps : échelonnez la création de tâches et les vérifications de statut sur différentes périodes.

  6. Surveillez les limites de débit et émettez des CloudWatch alertes : configurez des alarmes pour détecter l'approche des limites.

La plupart AWS SDKs incluent une logique de nouvelle tentative intégrée pour limiter les erreurs de débit. Configurez-les comme suit :

  1. AWS CLI— Utilisation cli-read-timeout et cli-connect-timeout paramètres

  2. AWS SDK pour Python (Boto3) — Configurez les modes de nouvelle tentative et le nombre maximum de tentatives dans la configuration de votre client.

  3. AWS SDK pour Java — RetryPolicy Utilisation ClientConfiguration et paramètres.

  4. AWS SDK pour JavaScript — Configurer maxRetries et. retryDelayOptions

Pour plus d'informations sur les modèles de nouvelles tentatives et les meilleures pratiques, consultez la section Réessayer avec un schéma d'annulation dans le guide AWS prescriptif.

SlowDownError résolution des problèmes

  1. Dans votre code, implémentez immédiatement un ralentissement exponentiel.

    Exemple du recul exponentiel dans bash
    
for attempt in {1..5}; do
    if aws s3control describe-job --account-id 111122223333 --job-id job-id; then 
        break
    else 
        wait_time=$((2**attempt)) echo "Rate limited, waiting ${wait_time} seconds..." sleep $wait_time
        fi
done

  2. CloudTrail À utiliser pour identifier la source du volume élevé de demandes.

    
aws logs filter-log-events \
    --log-group-name CloudTrail/S3BatchOperations \
    --filter-pattern "{ $.eventName = CreateJob || $.eventName = DescribeJob }" \
    --start-time timestamp \
    --query 'events[*].[eventTime,sourceIPAddress,userIdentity.type,eventName]'

  3. Vérifiez la fréquence des sondages.

    1. Évitez de vérifier le statut des tâches plus d'une fois toutes les 30 secondes pour les tâches actives.

    2. Utilisez les notifications d'achèvement des tâches au lieu de les interroger lorsque cela est possible.

    3. Intégrez de la gigue dans vos intervalles d'interrogation pour éviter les demandes synchronisées.

  4. Optimisez les modèles d'utilisation de vos API.

    1. Batch de plusieurs opérations lorsque cela est possible.

    2. ListJobsÀ utiliser pour obtenir le statut de plusieurs tâches en un seul appel.

    3. Mettez en cache les informations relatives aux tâches afin de réduire les appels d'API redondants.

    4. Répartissez la création d'emplois dans le temps plutôt que de créer plusieurs emplois simultanément.

  5. Utilisez CloudWatch des métriques pour les appels d'API afin de surveiller vos modèles de demandes.

    
   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

Type : Échec du Job

L'InvalidManifestContentexception se produit lorsque des problèmes liés au format, au contenu ou à la structure du fichier manifeste empêchent S3 Batch Operations de traiter le travail. Elle a les causes communes suivantes :

  1. Violations de format : colonnes obligatoires manquantes, délimiteurs incorrects ou structure CSV mal formée.

  2. Problèmes d'encodage du contenu : codage de caractères incorrect, marqueurs BOM ou caractères non UTF-8.

  3. Problèmes liés à la clé d'objet : caractères non valides, encodage d'URL incorrect ou clés dépassant les limites de longueur maximale.

  4. Limites de taille — Le manifeste contient plus d'objets que ce que l'opération prend en charge.

  5. Erreurs de format de l'ID de version : version mal formée ou non valide IDs pour les objets versionnés.

  6. ETag problèmes de format — ETag Format incorrect ou guillemets manquants pour les opérations qui nécessitent ETags.

  7. Données incohérentes : formats mixtes dans le même manifeste ou nombre de colonnes incohérent.

Messages d'erreur associés :

  1. Required fields are missing in the schema: + missingFields

  2. Invalid Manifest Content

  3. The S3 Batch Operations job failed because it contains more keys than the maximum allowed in a single job

  4. Invalid object key format

  5. Manifest file is not properly formatted

  6. Invalid version ID format

  7. ETag format is invalid

Les meilleures pratiques pour prévenir les échecs au InvalidManifestContent travail

  1. Valider avant le téléchargement : testez le format du manifeste avec de petites tâches avant de traiter de grands ensembles de données.

  2. Utiliser un codage cohérent — Utilisez toujours le codage UTF-8 sans BOM pour les fichiers manifestes.

  3. Mettre en œuvre les normes de génération de manifestes — Créez des modèles et des procédures de validation pour la création de manifestes.

  4. Gérez correctement les caractères spéciaux : codez par URL les clés d'objet contenant des caractères spéciaux.

  5. Surveillez le nombre d'objets : suivez la taille du manifeste et répartissez les tâches volumineuses de manière proactive.

  6. Valider l'existence des objets : vérifiez que les objets existent avant de les inclure dans les manifestes.

  7. Utiliser AWS des outils pour la génération de manifestes — Tirez parti AWS CLI s3api list-objects-v2 de ces outils pour générer des listes d'objets correctement formatées.

Problèmes courants liés aux manifestes et solutions :

  1. Colonnes obligatoires manquantes — Assurez-vous que votre manifeste inclut toutes les colonnes requises pour votre type d'opération. Les colonnes manquantes les plus courantes sont Bucket et Key.

  2. Format CSV incorrect : utilisez des séparateurs par des virgules, assurez-vous que le nombre de colonnes est cohérent sur toutes les lignes et évitez les sauts de ligne intégrés dans les champs.

  3. Caractères spéciaux dans les clés d'objet : les clés d'objet codées par URL contiennent des espaces, des caractères Unicode ou des caractères spéciaux XML (<, >, &, «, ').

  4. Fichiers manifestes volumineux : divisez les manifestes dont le nombre d'opérations est supérieur à la limite d'opérations en plusieurs manifestes plus petits et créez des tâches distinctes.

  5. Version non valide IDs : assurez-vous que les chaînes alphanumériques de la version IDs sont correctement formatées. Supprimez la colonne d'ID de version si cela n'est pas nécessaire.

  6. Problèmes d'encodage — Enregistrez les fichiers manifestes au format UTF-8 sans BOM. Évitez de copier des manifestes via des systèmes susceptibles de modifier le codage.

Pour obtenir des spécifications détaillées et des exemples de format de manifeste, consultez ce qui suit :

  1. Spécification d’un manifeste

  2. Opérations prises en charge par les opérations par lot S3

  3. Attribution d’un nom aux objets Amazon S3

InvalidManifestContent résolution des problèmes

  1. Téléchargez et inspectez le fichier manifeste. Vérifiez manuellement que le manifeste répond aux exigences de format :

    1. Format CSV avec séparateurs par des virgules.

    2. Encodage UTF-8 sans BOM.

    3. Nombre constant de colonnes sur toutes les lignes.

    4. Pas de lignes vides ni d'espaces de fin.

    5. Les clés d'objet sont correctement codées en URL si elles contiennent des caractères spéciaux.

    Utilisez la commande suivante pour télécharger le fichier manifeste.

    
aws s3 cp s3://amzn-s3-demo-bucket1/manifest-key ./manifest.csv

  2. Vérifiez les colonnes requises pour votre opération :

    1. Toutes les opérations :Bucket, Key

    2. Opérations de copie : VersionId (facultatif)

    3. Opérations de restauration : VersionId (facultatif)

    4. Opérations de remplacement des balises : aucune colonne supplémentaire n'est requise.

    5. Remplacer les opérations ACL : aucune colonne supplémentaire n'est requise.

    6. Lancer la restauration : VersionId (facultatif)

  3. Vérifiez les limites du nombre d'objets :

    1. Copie : 1 milliard d'objets maximum.

    2. Supprimer : 1 milliard d'objets maximum.

    3. Restauration : 1 milliard d'objets maximum.

    4. Marquage : 1 milliard d'objets maximum.

    5. ACL : 1 milliard d'objets maximum.

  4. Créez un manifeste de test avec quelques objets de votre manifeste d'origine.

  5. Utilisez la commande suivante pour vérifier s'il existe un échantillon d'objets du manifeste.

    
aws s3 ls s3://amzn-s3-demo-bucket1/object-key

  6. Vérifiez les détails de l'échec de la tâche et examinez la raison de l'échec et les détails de toute erreur spécifique dans la description du poste.

    
aws s3control describe-job --account-id 111122223333 --job-id job-id