AWS Data Pipeline n'est plus disponible pour les nouveaux clients. Les clients existants de AWS Data Pipeline peuvent continuer à utiliser le service normalement. En savoir plus

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 courants

Cette rubrique présente divers symptômes de problèmes AWS Data Pipeline et les étapes recommandées pour les résoudre.

Pipeline bloqué à l'état Pending (en suspens)

Un pipeline qui semble bloqué à l'état PENDING (en suspens) indique qu'un pipeline n'a pas encore été activé ou que l'activation a échoué en raison d'une erreur dans la définition du pipeline. Vérifiez que vous n'avez reçu aucune erreur lorsque vous avez envoyé votre pipeline à l'aide de l'interface de ligne de commande AWS Data Pipeline ou lorsque vous avez tenté d'enregistrer ou d'activer votre pipeline à l'aide de la console AWS Data Pipeline. Vérifiez également que la définition de votre pipeline est valide.

Pour afficher votre définition de pipeline à l'écran à l'aide de l'interface de ligne de commande :

aws datapipeline --get-pipeline-definition --pipeline-id df-EXAMPLE_PIPELINE_ID

Assurez-vous que la définition de pipeline est complète, vérifiez les accolades fermantes, les virgules requises, et assurez-vous qu'il ne manque aucune référence et qu'il n'y a pas d'autres erreurs de syntaxe. Il est préférable d'utiliser un éditeur de texte qui permet de valider visuellement la syntaxe des fichiers JSON.

Composant de pipeline bloqué à l'état Waiting for Runner

Si votre pipeline a l'état SCHEDULED et qu'une ou plusieurs tâches semblent bloquées à l'état WAITING_FOR_RUNNER, vérifiez que vous avez affecté une valeur valide aux champs runsOn et workerGroup de ces tâches. Si ces deux valeurs sont vides ou manquantes, la tâche ne peut pas commencer car il n'y a aucune association entre la tâche et un programme d'exécution devant effectuer les tâches. Dans ce cas, vous avez défini le travail mais vous n'avez pas défini l'ordinateur qui doit effectuer ce travail. Le cas échéant, vérifiez que la valeur WorkerGroup attribuée au composant du pipeline correspond exactement au même nom et à la même majuscule que la valeur WorkerGroup que vous avez configurée pour Task Runner.

Une autre cause potentielle de ce problème est que le point de terminaison et la clé d'accès fournis à Task Runner ne sont pas les mêmes que ceux de la AWS Data Pipeline console ou de l'ordinateur sur lequel les outils AWS Data Pipeline CLI sont installés. Vous avez peut-être créé de nouveaux pipelines sans erreur visible, mais Task Runner interroge le mauvais emplacement en raison de la différence entre les informations d'identification, ou interroge le bon emplacement avec des autorisations insuffisantes pour identifier et exécuter le travail spécifié par la définition du pipeline.

Composant de pipeline bloqué à l'état WAITING_ON_DEPENDENCIES

Si votre pipeline est à l'état SCHEDULED et qu'une ou plusieurs tâches semblent bloquées à l'état WAITING_ON_DEPENDENCIES, vérifiez que les conditions préalables initiales de votre pipeline ont été remplies. Si les conditions préalables du premier objet de la chaîne logique ne sont pas remplies, aucun des objets qui dépendent de ce premier objet ne peut quitter l'état WAITING_ON_DEPENDENCIES.

Par exemple, étudiez l'extrait suivant d'une définition de pipeline. Dans ce cas, l'InputDataobjet possède une précondition « Prêt » qui indique que les données doivent exister avant que l'InputDataobjet ne soit terminé. Si les données n'existent pas, l'InputDataobjet reste dans l'WAITING_ON_DEPENDENCIESétat en attendant que les données spécifiées par le champ de chemin soient disponibles. Tous les objets qui en InputData dépendent restent dans un WAITING_ON_DEPENDENCIES état en attendant InputData qu'ils atteignent FINISHED cet état.

{
    "id": "InputData",
    "type": "S3DataNode",
    "filePath": "s3://elasticmapreduce/samples/wordcount/wordSplitter.py",
    "schedule":{"ref":"MySchedule"},
    "precondition": "Ready"      
},
{
    "id": "Ready",
    "type": "Exists"
...

Par ailleurs, vérifiez que vos objets disposent des autorisations nécessaires pour accéder aux données. Dans l'exemple précédent, si les informations du champ d'identification n'étaient pas autorisées à accéder aux données spécifiées dans le champ de chemin, l'InputDataobjet resterait bloqué dans un WAITING_ON_DEPENDENCIES état car il ne pouvait pas accéder aux données spécifiées par le champ de chemin, même si ces données existent.

Il est également possible qu'aucune adresse IP publique ne soit associée à une ressource communiquant avec Amazon S3. Par exemple, une ressource Ec2Resource d'un sous-réseau public doit avoir une adresse IP publique associée.

Enfin, dans certaines conditions, les instances de ressource peuvent atteindre l'état WAITING_ON_DEPENDENCIES beaucoup plus tôt que le début planifié de leurs activités associées, ce qui peut donner l'impression que la ressource ou l'activité échoue.

L'exécution ne démarre pas au moment planifié

Vérifiez que vous avez sélectionné le type de planification correct qui détermine si votre tâche démarre au début de l'intervalle de planification (planification de type cron) ou à la fin de l'intervalle de planification (planification de type séries chronologiques).

Vérifiez également que vous avez correctement spécifié les dates dans vos objets de calendrier et que les endDateTime valeurs startDateTime et sont au format UTC, comme dans l'exemple suivant :

{
    "id": "MySchedule",
    "startDateTime": "2012-11-12T19:30:00",
    "endDateTime":"2012-11-12T20:30:00",
    "period": "1 Hour",
    "type": "Schedule"
},

Les composants du pipeline s'exécutent dans le mauvais ordre

Vous pouvez remarquer que les heures de début et de fin de vos composants de pipeline s'exécutent dans le mauvais ordre ou dans une séquence différente de celle que vous attendez. Il est important de comprendre que les composants de pipeline peuvent commencer à s'exécuter simultanément si leurs conditions préalables sont remplies au démarrage. En d'autres termes, les composants de pipeline ne s'exécutent pas de manière séquentielle par défaut ; si vous avez besoin d'un ordre d'exécution spécifique, vous devez contrôler l'ordre d'exécution à l'aide de conditions préalables et de champs dependsOn.

Vérifiez que vous utilisez le champ dependsOn renseigné avec une référence aux composants de pipeline avec conditions préalables adéquats et que tous les pointeurs nécessaires entre les composants sont présents pour atteindre l'ordre souhaité.

Le cluster EMR échoue en renvoyant l'erreur suivante : Le jeton de sécurité inclus dans la demande n'est pas valide

Vérifiez vos rôles IAM, vos politiques et vos relations de confiance comme décrit dansRôles IAM pour AWS Data Pipeline.

Autorisations insuffisantes pour accéder aux ressources

Les autorisations que vous définissez sur les rôles IAM déterminent si vous AWS Data Pipeline pouvez accéder à vos clusters EMR et à vos instances EC2 pour exécuter vos pipelines. De plus, IAM propose le concept de relations de confiance qui va plus loin pour permettre la création de ressources en votre nom. Par exemple, lorsque vous créez un pipeline qui utilise une instance EC2 pour exécuter une commande afin de déplacer des données, AWS Data Pipeline peut mettre automatiquement cette instance EC2 en service. Si vous rencontrez des problèmes, en particulier ceux impliquant des ressources auxquelles vous pouvez accéder manuellement mais que vous AWS Data Pipeline ne pouvez pas, vérifiez vos rôles IAM, vos politiques et vos relations de confiance comme décrit dansRôles IAM pour AWS Data Pipeline.

Code d'état : 400 Code d'erreur : PipelineNotFoundException

Cette erreur signifie que vos rôles IAM par défaut ne disposent peut-être pas des autorisations requises AWS Data Pipeline pour fonctionner correctement. Pour plus d'informations, veuillez consulter Rôles IAM pour AWS Data Pipeline.

La création d'un pipeline provoque une erreur de jeton de sécurité

Vous recevez le message d'erreur suivant lorsque vous essayez de créer un pipeline :

Échec de la création de pipeline avec 'pipeline_name'. Erreur : UnrecognizedClientException - Le jeton de sécurité inclus dans la demande n'est pas valide.

Impossible de voir les détails du pipeline dans la console

Le filtre de pipeline de la console AWS Data Pipeline s'applique à la date de début planifiée d'un pipeline, sans tenir compte du moment où le pipeline a été envoyé. Il est possible d'envoyer un nouveau pipeline en utilisant une date de début planifiée qui appartient au passé, que le filtre de date par défaut ne peut pas afficher. Pour voir les détails du pipeline, modifiez votre filtre de date afin de garantir que la date de début planifiée du pipeline soit prise en compte dans le filtre de plage de dates.

Erreur du programme d'exécution à distance - Code d'état : 404, service AWS : Amazon S3

Cette erreur signifie que Task Runner n'a pas pu accéder à vos fichiers dans Amazon S3. Vérifiez que :

Accès refusé - Vous n'êtes pas autorisé à exécuter la fonction datapipeline :

Dans les journaux de Task Runner, vous pouvez voir une erreur similaire à la suivante :

Ce message d'erreur indique que le rôle IAM que vous avez spécifié nécessite des autorisations supplémentaires pour interagir avec AWS Data Pipeline celui-ci. Assurez-vous que votre politique de rôle IAM contient les lignes suivantes, où elles PollForTask sont remplacées par le nom de l'autorisation que vous souhaitez ajouter (utilisez* pour accorder toutes les autorisations). Pour plus d'informations sur la façon de créer un nouveau rôle IAM et de lui appliquer une politique, consultez la section Gestion des politiques IAM dans le guide Using IAM.

{
"Action": [ "datapipeline:PollForTask" ],
"Effect": "Allow",
"Resource": ["*"]
}

Les anciennes AMI Amazon EMR peuvent créer de fausses données pour les fichiers CSV volumineux

Sur les AMI Amazon EMR antérieures à la version 3.9 (3.8 et antérieures), elle AWS Data Pipeline utilise une fonctionnalité personnalisée InputFormat pour lire et écrire des fichiers CSV à utiliser avec des MapReduce tâches. Ceci est utilisé lorsque le service transfère des tables vers et depuis Amazon S3. Ce problème a InputFormat été découvert : la lecture d'enregistrements à partir de fichiers CSV volumineux peut entraîner la production de tableaux qui ne sont pas correctement copiés. Ce problème a été résolu dans les versions ultérieures d'Amazon EMR. Veuillez utiliser Amazon EMR AMI 3.9 ou une version Amazon EMR 4.0.0 ou ultérieure.

Augmentation des limites pour AWS Data Pipeline

De temps en temps, il est possible que vous dépassiez des limites spécifiques du système AWS Data Pipeline. Par exemple, la limite de pipelines par défaut est 20 pipelines contenant chacun 50 objets. Si vous découvrez que vous avez besoin d'un nombre de pipelines supérieur à la limite, envisagez de fusionner plusieurs pipelines pour créer moins de pipelines contenant chacun davantage d'objets. Pour plus d'informations sur les limites d'AWS Data Pipeline, consultez Limites AWS Data Pipeline. Toutefois, si vous n'êtes pas en mesure de contourner les limites à l'aide de la technique de fusion de pipelines, demandez une augmentation de votre capacité à l'aide de ce formulaire : Augmentation de limite Data Pipeline.