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 dans Step Functions

Si vous rencontrez des difficultés lors de l'utilisation de Step Functions, utilisez les ressources de résolution des problèmes suivantes.

Les rubriques suivantes fournissent des conseils de dépannage en cas d'erreurs et de problèmes liés aux machines d'état Step Functions, aux intégrations de services, aux activités et aux flux de travail. Si vous rencontrez un problème qui n’est pas répertorié ici, vous pouvez utiliser le bouton Commentaire sur cette page pour le signaler.

Pour plus de conseils de dépannage et de réponses aux questions courantes de support, visitez le Centre de connaissances AWS.

Résolution de problème généraux

Je ne parviens pas à créer une machine à états.

Le rôle IAM associé à la machine d'état ne dispose peut-être pas d'autorisations suffisantes. Vérifiez les autorisations du rôle IAM, notamment pour les tâches d'intégration de AWS services et la CloudWatch journalisation. X-Ray Des autorisations supplémentaires sont requises pour les états des .sync tâches.

Je ne parviens pas à utiliser a JsonPath pour faire référence à la sortie de la tâche précédente.

Pour un JsonPath, une clé JSON doit se terminer par.$. Cela signifie que a ne JsonPath peut être utilisé que dans une paire clé-valeur. Si vous souhaitez utiliser un JsonPath autre emplacement, tel qu'un tableau, vous pouvez utiliser des fonctions intrinsèques. Par exemple, vous pouvez utiliser quelque chose de similaire à ce qui suit :

Résultat de la tâche A :

{
    "sample": "test"
}

Tâche B :

{
    "JsonPathSample.$": "$.sample"
}

Il y a eu un retard dans les transitions entre États.

Pour les flux de travail standard, le nombre de transitions d'état est limité. Lorsque vous dépassez la limite de transition d'état, Step Functions retarde les transitions d'état jusqu'à ce que le compartiment correspondant au quota soit rempli. La limitation des limites de transition entre états peut être surveillée en consultant la ExecutionThrottled métrique dans la Execution Metrics (Métriques de l'exécution) section de la page CloudWatch Mesures.

Lorsque je lance de nouvelles exécutions de flux de travail standard, elles échouent avec l'ExecutionLimitExceedederreur.

Step Functions a une limite de 1 000 000 d'exécutions ouvertes pour chacune Compte AWS d'elles Région AWS. Si vous dépassez cette limite, Step Functions génère une ExecutionLimitExceeded erreur. Cette limite ne s'applique pas aux flux de travail express. Vous pouvez utiliser le OpenExecutionCount pour savoir quand vous vous en approchez OpenExecutionLimit et créer des alarmes pour vous avertir de manière proactive en cas d'événement. OpenExecutionCountest un nombre approximatif de flux de travail ouverts. Pour de plus amples informations, veuillez consulter Execution Metrics (Métriques de l'exécution).

Une défaillance d'une branche dans un état parallèle entraîne l'échec de toute l'exécution.

Il s'agit d'un comportement attendu. Pour éviter de rencontrer des défaillances lors de l'utilisation d'un état parallèle, configurez Step Functions pour détecter les erreurs générées par chaque branche.

Résolution des problèmes liés aux intégrations de services

Ma tâche est terminée dans le service en aval, mais dans Step Functions, l'état de la tâche reste « En cours » ou son achèvement est retardé.

Pour les modèles d'intégration des .sync services, Step Functions utilise des EventBridge règles, des API en aval ou une combinaison des deux pour détecter le statut des tâches en aval. Pour certains services, Step Functions ne crée pas de EventBridge règles à surveiller. Par exemple, pour l'intégration des AWS Glue services, au lieu d'utiliser des EventBridge règles, Step Functions passe un glue:GetJobRun appel. En raison de la fréquence des appels d'API, il existe une différence entre le temps d'achèvement des tâches en aval et le délai d'achèvement des tâches Step Functions. Step Functions nécessite des autorisations IAM pour gérer les EventBridge règles et passer des appels au service en aval. Pour plus de détails sur la façon dont des autorisations insuffisantes sur votre rôle d'exécution peuvent affecter l'exécution des tâches, consultezAutorisations supplémentaires pour les tâches utilisant .sync.

Je souhaite renvoyer une sortie JSON à partir d'une exécution de machine à états imbriqués.

Il existe deux intégrations de services synchrones Step Functions pour Step Functions : startExecution.sync et. startExecution.sync:2 Les deux attendent que la machine à états imbriqués soit terminée, mais ils renvoient des Output formats différents. Vous pouvez l'utiliser startExecution.sync:2 pour renvoyer une sortie JSON sousOutput.

Je ne peux pas appeler une fonction Lambda depuis un autre compte.

Accès à la fonction Lambda avec support multi-comptes

Si l'accès aux AWS ressources entre comptes est disponible dans votre région, utilisez la méthode suivante pour appeler une fonction Lambda depuis un autre compte.

Pour invoquer une ressource multi-comptes dans vos flux de travail, procédez comme suit :

Pour un exemple, consultez Accès aux AWS ressources multi-comptes dans Step Functions les didacticiels.

Pour un exemple de définition d'Taskétat spécifiant une ressource entre comptes, consultezExemples de champs d'informations d'identification de l'état de la tâche.

Accès à la fonction Lambda sans support multi-comptes

Si l'accès aux AWS ressources entre comptes n'est pas disponible dans votre région, utilisez la méthode suivante pour appeler une fonction Lambda depuis un autre compte.

Dans le Resource champ de Task l'État, utilisez arn:aws:states:::lambda:invoke et transmettez les paramètres FunctionArn in. Le rôle IAM associé à la machine d'état doit disposer des autorisations appropriées pour invoquer des fonctions Lambda entre comptes :. lambda:invokeFunction

{  
   "StartAt":"CallLambda",
   "States":{  
      "CallLambda":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke",
         "Parameters":{  
            "FunctionName":"arn:aws:lambda:region:account-id:function:my-function"
         },
         "End":true
      }
   }
}

Je ne parviens pas à voir les jetons de tâche transmis depuis les ForTaskToken états .wait.

Dans le Parameters champ de Task l'État, vous devez transmettre un jeton de tâche. Par exemple, vous pouvez utiliser un code similaire au code suivant.

{  
   "StartAt":"taskToken",
   "States":{  
      "taskToken":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke.waitForTaskToken",
         "Parameters":{  
            "FunctionName":"get-model-review-decision",
            "Payload":{  
               "token.$":"$$.Task.Token"
            },
         },
         "End":true
      }
   }
}

Activités de résolution des problèmes

L'exécution de ma machine à états est bloquée à un état d'activité.

L'état d'une tâche d'activité ne démarre que lorsque vous interrogez un jeton de tâche à l'aide de l'action de l'GetActivityTaskAPI. Il est recommandé d'ajouter un délai d'expiration au niveau de la tâche afin d'éviter une exécution bloquée. Pour de plus amples informations, veuillez consulter Utiliser les délais d'attente pour éviter le blocage des exécutions de flux de travail Step Functions.

Si votre machine d'état est bloquée pendant l'ActivityScheduledévénement, cela indique que le parc de travailleurs de votre activité rencontre des problèmes ou qu'il est sous-dimensionné. Vous devez surveiller la ActivityScheduleTime CloudWatch métrique et définir une alarme lorsque ce temps augmente. Toutefois, pour temporiser les exécutions de machines à états bloqués dans lesquelles l'Activityétat ne passe pas à l'ActivityStartedétat, définissez un délai d'expiration au niveau de la machine à états. Pour ce faire, spécifiez un TimeoutSeconds champ au début de la définition de la machine à états, en dehors du States champ.

Mon agent d'activité expire en attendant un jeton de tâche.

Les travailleurs utilisent l'action GetActivityTaskAPI pour récupérer une tâche avec l'ARN d'activité spécifié qui est planifiée pour être exécutée par une machine à états en cours d'exécution. GetActivityTasklance un long sondage, de sorte que le service maintient la connexion HTTP ouverte et répond dès qu'une tâche devient disponible. La durée maximale pendant laquelle le service conserve la demande avant de répondre est de 60 secondes. Si aucune tâche n'est disponible dans les 60 secondes, le sondage renvoie un taskToken avec une chaîne nulle. Pour éviter ce délai, configurez un socket côté client avec un délai d'au moins 65 secondes dans le AWS SDK ou dans le client que vous utilisez pour effectuer l'appel d'API.

Résolution des problèmes liés aux workflows express

Ma candidature expire avant de recevoir une réponse d'un StartSyncExecutionAppel d'API.

Configurez un délai d'expiration du socket côté client dans le AWS SDK ou le client que vous utilisez pour effectuer l'appel d'API. Pour recevoir une réponse, le délai d'attente doit avoir une valeur supérieure à la durée des exécutions d'Express Workflow.

Je ne parviens pas à consulter l'historique des exécutions afin de résoudre les problèmes d'Express Workflow.

Express Workflows n'enregistre pas l'historique d'exécution dans AWS Step Functions. Vous devez plutôt activer la CloudWatch journalisation. Une fois la journalisation activée, vous pouvez utiliser CloudWatch les requêtes Logs Insights pour examiner vos exécutions d'Express Workflow. Vous pouvez également consulter l'historique des exécutions d'Express Workflow sur la console Step Functions si vous cliquez sur le bouton Activer dans l'onglet Executions. Pour de plus amples informations, veuillez consulter Afficher les détails de l'exécution dans la console Step Functions.

Pour répertorier les exécutions en fonction de leur durée :

fields ispresent(execution_arn) as exec_arn
| filter exec_arn 
| filter type in ["ExecutionStarted", "ExecutionSucceeded", "ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]
| stats latest(type) as status, 
  tomillis(earliest(event_timestamp)) as UTC_starttime, 
  tomillis(latest(event_timestamp)) as UTC_endtime, 
  latest(event_timestamp) - earliest(event_timestamp) as duration_in_ms  by execution_arn
| sort duration_in_ms desc

Pour répertorier les exécutions annulées ou ayant échoué, procédez comme suit :

fields ispresent(execution_arn) as isRes | filter type in ["ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]

Résolution des problèmes liés aux cartes distribuées

Ma diffusion sur la carte est bloquée.

Il existe un quota de service pour le nombre maximum d'exécutions de carte ouvertes. Une fois ce quota épuisé, des séries de cartes supplémentaires attendent qu'un quota supplémentaire soit disponible au fur et à mesure que les autres séries de cartes sont terminées. Les courses de carte en attente attendent l'MapRunStartedévénement, avant de lire leur entrée. Vous verrez donc que le nombre d'éléments en attente de la course de carte reste à 0. Une fois qu'une exécution cartographique en retard est en mesure d'obtenir un quota, elle commence à lire ses entrées. Vous verrez alors le nombre d'éléments en attente augmenter et le fonctionnement de la carte se poursuivra normalement pendant le reste de son cycle de vie. Au fur et à mesure que le quota devient disponible, il n'existe aucun ordre particulier quant à la manière dont il est réparti entre les séries de cartes en attente.

Il existe un risque de blocage lors de l'utilisation de courses de carte imbriquées. Dans ce cas, vous avez une exécution de flux de travail parent contenant une exécution de carte « parent », qui à son tour lance une exécution de flux de travail enfant contenant une exécution de carte « enfant », qui à son tour lance l'exécution d'un flux de travail petit-enfant. Si aucun quota maximum d'exécutions de carte ouvertes n'est maintenu lorsque l'exécution du flux de travail enfant commence son exécution de carte enfant, cette exécution de carte enfant sera enregistrée en attente. Si la totalité du quota est consommée par les courses de carte parent et que toutes les parties de la carte enfant sont en retard, aucun des deux groupes ne pourra progresser et le groupe restera bloqué jusqu'à ce que le quota soit à nouveau disponible. Une exécution de carte est interrompue et son quota est de nouveau disponible lorsque l'exécution de son parent prend fin, par exemple en cas d'expiration du délai, d'échec dû à une erreur non détectée ou à un StopExecution appel d'API.

Lorsque vous envisagez d'utiliser des séquences de carte imbriquées dans la conception de votre flux de travail, estimez si le nombre attendu d'exécutions de carte ouvertes risque de dépasser le quota maximal d'exécutions de carte ouvertes et de vous exposer à des risques de retards ou de blocages. Si tel est le cas, vous pouvez envisager d'autres modèles. Par exemple, au lieu d'utiliser une exécution de carte parent pour parcourir une liste d'objets Amazon S3 et une exécution de carte enfant pour lire leur contenu, vous pouvez utiliser la LOAD_AND_FLATTENtransformation de votre exécution de carte ReaderConfig pour effectuer ces deux opérations en une seule exécution de carte. Un autre modèle courant consiste à inclure une étape de prétraitement, telle qu'une fonction Lambda, qui effectue une itération sur vos données imbriquées et produit un fichier qui peut être utilisé comme entrée pour l'exécution de la carte.

Vous pouvez surveiller votre utilisation du quota maximal de courses de carte ouvertes à l'aide des ApproximateMapRunBacklogSize métriques ApproximateOpenMapRunCountOpenMapRunLimit, et incluses dans CloudWatch.