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 AWS de services, X-Ray et la CloudWatch journalisation. 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 Métriques d'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 Métriques d'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 APIs, 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 :

1. Créez un rôle IAM dans le compte cible qui contient la ressource. Ce rôle accorde au compte source, contenant la machine d'état, l'autorisation d'accéder aux ressources du compte cible.

2. Dans la définition de Task l'état, spécifiez le rôle IAM cible à assumer par la machine d'état avant d'appeler la ressource entre comptes.

3. Modifiez la politique de confiance dans le rôle IAM cible pour permettre au compte source d'assumer temporairement ce rôle. La politique de confiance doit inclure l'Amazon Resource Name (ARN) de la machine d'état définie dans le compte source. Définissez également les autorisations appropriées dans le rôle IAM cible pour appeler la AWS ressource.

4. Mettez à jour le rôle d'exécution du compte source pour inclure l'autorisation requise pour assumer le rôle IAM cible.

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

Note

Vous pouvez configurer votre machine d'état pour qu'elle assume un rôle IAM afin d'accéder à des ressources à partir de plusieurs Comptes AWS. Cependant, une machine d'état ne peut assumer qu'un seul rôle IAM à la fois.

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:us-west-2:123456789012:function:my-function"
         },
         "End":true
      }
   }
}

Je ne parviens pas à voir les jetons de tâches transmis par .waitForTaskToken les États.

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
      }
   }
}

Note

Vous pouvez essayer de l'utiliser .waitForTaskToken avec n'importe quelle action d'API. Cependant, certains APIs n'ont pas de paramètres appropriés.

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

Mon application expire avant de recevoir une réponse à un appel d'StartSyncExecutionAPI.

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"]