Utiliser CloudWatch les journaux pour enregistrer l'historique des exécutions dans Step Functions - AWS Step Functions

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.

Utiliser CloudWatch les journaux pour enregistrer l'historique des exécutions dans Step Functions

Les flux de travail standard enregistrent l'historique d'exécution dans AWS Step Functions, mais vous pouvez éventuellement configurer la journalisation sur Amazon CloudWatch Logs.

Contrairement aux workflows standard, les workflows express n'enregistrent pas l'historique d'exécution dans AWS Step Functions. Pour consulter l'historique d'exécution et les résultats d'un flux de travail express, vous devez configurer la journalisation sur Amazon CloudWatch Logs. La publication des journaux ne bloque pas ou ne ralentit pas les exécutions.

Garanties de livraison de journaux

Les Amazon CloudWatch Logs sont fournis dans la mesure du possible. L'exhaustivité et l'actualité des entrées du journal ne sont pas garanties. Si vous avez besoin d'un historique des flux de travail garanti dans Express Workflows, nous vous recommandons de mettre en œuvre des étapes de flux de travail pour enregistrer les données dans un service de stockage de données approprié tel qu'Amazon DynamoDB. Vous pouvez également envisager d'utiliser des flux de travail standard pour garantir un historique d'exécution.

Informations sur la tarification

Lorsque vous configurez la journalisation, CloudWatch les frais de journalisation s'appliquent et vous serez facturé au tarif des journaux vendus. Pour plus d'informations, consultez la section Vended Logs sous l'onglet Logs de la page de CloudWatch tarification.

Configurer la journalisation

Lorsque vous créez un flux de travail standard à l'aide de la console Step Functions, cette machine d'état ne sera pas configurée pour envoyer des CloudWatch journaux à Logs. Lorsque vous créez un flux de travail express à l'aide de la console Step Functions, cette machine d'état est configurée par défaut pour envoyer des CloudWatch journaux à Logs.

Pour les flux de travail Express, Step Functions peut créer un rôle avec la politique AWS Identity and Access Management (IAM) nécessaire pour les CloudWatch journaux. Si vous créez un flux de travail standard ou un flux de travail express à l'aide de l'API, de la CLI ou AWS CloudFormation de Step Functions n'activera pas la journalisation par défaut et vous devrez vous assurer que votre rôle dispose des autorisations nécessaires.

Pour chaque exécution démarrée depuis la console, Step Functions fournit un lien vers CloudWatch les journaux, configuré avec le filtre approprié pour récupérer les événements de journal spécifiques à cette exécution.

Vous pouvez éventuellement configurer des AWS KMS clés gérées par le client pour chiffrer vos journaux. Consultez Chiffrement des données au repos pour plus de détails et les paramètres d'autorisation.

Pour configurer la journalisation, vous pouvez transmettre le LoggingConfigurationparamètre lorsque vous utilisez CreateStateMachineou UpdateStateMachine. Vous pouvez approfondir l'analyse de vos données dans CloudWatch Logs à l'aide de CloudWatch Logs Insights. Pour plus d'informations, voir Analyse des données de journal avec CloudWatch Logs Insights.

CloudWatch Enregistre les charges utiles

Les événements de l'historique d'exécution peuvent contenir des propriétés d'entrée ou de sortie dans leurs définitions. Si l'entrée échappée ou la sortie échappée envoyée à CloudWatch Logs dépasse 248 KiB, elle sera tronquée en raison des quotas de CloudWatch Logs.

Politiques IAM pour la connexion aux journaux CloudWatch

Vous devrez également configurer le rôle IAM d'exécution de votre machine à états afin de disposer de l'autorisation appropriée pour vous connecter à CloudWatch Logs, comme indiqué dans l'exemple suivant.

Exemple de politique IAM

Voici un exemple de stratégie que vous pouvez utiliser pour configurer vos autorisations. Comme le montre l'exemple suivant, vous devez spécifier* dans le Resource champ. CloudWatch Les actions d'API, telles que CreateLogDelivery et DescribeLogGroups, ne prennent pas en charge les types de ressources définis par Amazon CloudWatch Logs. Pour plus d'informations, consultez la section Actions définies par Amazon CloudWatch Logs.

  • Pour plus d'informations sur CloudWatch les ressources, consultez la section CloudWatch LogsRessources et opérations dans le Guide de CloudWatch l'utilisateur Amazon.

  • Pour plus d'informations sur les autorisations dont vous avez besoin pour configurer l'envoi de CloudWatch journaux à Logs, consultez la section Autorisations utilisateur dans la section intitulée Journaux envoyés à CloudWatch Logs.

{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogDelivery", "logs:CreateLogStream", "logs:GetLogDelivery", "logs:UpdateLogDelivery", "logs:DeleteLogDelivery", "logs:ListLogDeliveries", "logs:PutLogEvents", "logs:PutResourcePolicy", "logs:DescribeResourcePolicies", "logs:DescribeLogGroups" ], "Resource": "*" } ] }

Niveaux de journalisation des événements d'exécution de Step Functions

Les niveaux de journalisation vont de ALL ERROR à FATAL àOFF. Tous les types d'événements sont enregistrésALL, aucun type d'événement n'est enregistré lorsqu'il est défini surOFF. Pour ERROR et FATAL, voir le tableau suivant.

Pour plus d'informations sur les données d'exécution affichées pour les exécutions d'Express Workflow basées sur ces niveaux de journalisation, consultezDifférences d'expérience entre les consoles Standard et Express.

Type d’événement ALL ERROR FATAL OFF

ChoiceStateEntered

Connecté Non connecté Non connecté Non connecté

ChoiceStateExited

Connecté Non connecté Non connecté Non connecté

ExecutionAborted

Connecté Connecté Connecté Non connecté

ExecutionFailed

Connecté Connecté Connecté Non connecté

ExecutionStarted

Connecté Non connecté Non connecté Non connecté

ExecutionSucceeded

Connecté Non connecté Non connecté Non connecté

ExecutionTimedOut

Connecté Connecté Connecté Non connecté

FailStateEntered

Connecté Connecté Non connecté Non connecté

LambdaFunctionFailed

Connecté Connecté Non connecté Non connecté
LambdaFunctionScheduled Connecté Non connecté Non connecté Non connecté

LambdaFunctionScheduleFailed

Connecté Connecté Non connecté Non connecté

LambdaFunctionStarted

Connecté Non connecté Non connecté Non connecté

LambdaFunctionStartFailed

Connecté Connecté Non connecté Non connecté

LambdaFunctionSucceeded

Connecté Non connecté Non connecté Non connecté

LambdaFunctionTimedOut

Connecté Connecté Non connecté Non connecté

MapIterationAborted

Connecté Connecté Non connecté Non connecté

MapIterationFailed

Connecté Connecté Non connecté Non connecté

MapIterationStarted

Connecté Non connecté Non connecté Non connecté

MapIterationSucceeded

Connecté Non connecté Non connecté Non connecté

MapRunAborted

Connecté Connecté Non connecté Non connecté

MapRunFailed

Connecté Connecté Non connecté Non connecté

MapStateAborted

Connecté Connecté Non connecté Non connecté

MapStateEntered

Connecté Non connecté Non connecté Non connecté

MapStateExited

Connecté Non connecté Non connecté Non connecté

MapStateFailed

Connecté Connecté Non connecté Non connecté

MapStateStarted

Connecté Non connecté Non connecté Non connecté

MapStateSucceeded

Connecté Non connecté Non connecté Non connecté

ParallelStateAborted

Connecté Connecté Non connecté Non connecté

ParallelStateEntered

Connecté Non connecté Non connecté Non connecté

ParallelStateExited

Connecté Non connecté Non connecté Non connecté
ParallelStateFailed Connecté Connecté Non connecté Non connecté

ParallelStateStarted

Connecté Non connecté Non connecté Non connecté

ParallelStateSucceeded

Connecté Non connecté Non connecté Non connecté

PassStateEntered

Connecté Non connecté Non connecté Non connecté

PassStateExited

Connecté Non connecté Non connecté Non connecté

SucceedStateEntered

Connecté Non connecté Non connecté Non connecté

SucceedStateExited

Connecté Non connecté Non connecté Non connecté

TaskFailed

Connecté Connecté Non connecté Non connecté

TaskScheduled

Connecté Non connecté Non connecté Non connecté
TaskStarted Connecté Non connecté Non connecté Non connecté

TaskStartFailed

Connecté Connecté Non connecté Non connecté

TaskStateAborted

Connecté Connecté Non connecté Non connecté

TaskStateEntered

Connecté Non connecté Non connecté Non connecté
TaskStateExited Connecté Non connecté Non connecté Non connecté
TaskSubmitFailed Connecté Connecté Non connecté Non connecté
TaskSubmitted Connecté Non connecté Non connecté Non connecté
TaskSucceeded Connecté Non connecté Non connecté Non connecté
TaskTimedOut Connecté Connecté Non connecté Non connecté
WaitStateAborted Connecté Connecté Non connecté Non connecté
WaitStateEntered Connecté Non connecté Non connecté Non connecté
WaitStateExited Connecté Non connecté Non connecté Non connecté

Résolution des problèmes liés à la connexion aux CloudWatch journaux

Si votre machine d'état ne parvient pas à envoyer les CloudWatch journaux à Logs ou si vous recevez le message d'erreur : AccessDeniedException : The state machine IAM Role is not authorized to access the Log Destination « », essayez les étapes suivantes :

  1. Vérifiez que le rôle d'exécution de votre machine d'état est autorisé à se connecter à CloudWatch Logs.

    Lorsque vous appelez CreateStateMachinedes points de terminaison d'UpdateStateMachineAPI, assurez-vous que le rôle IAM spécifié dans le roleArn paramètre fournit les autorisations nécessaires, comme indiqué dans l'exemple de politique IAM précédent.

  2. Vérifiez que la politique de ressources CloudWatch Logs ne dépasse pas la limite de 5 120 caractères.

    Si la politique dépasse la limite de caractères, préfixez les noms de vos groupes de journaux avec /aws/vendedlogs/states pour accorder des autorisations à vos machines d'état et éviter cette limite.

    Lorsque vous créez un groupe de journaux dans la console Step Functions, les noms de groupes de journaux suggérés sont déjà préfixés par/aws/vendedlogs/states. Pour plus d'informations sur les meilleures pratiques de journalisation, consultezÉviter les limites de taille CloudWatch des politiques de ressources.

  3. Vérifiez que le nombre de politiques de ressources du journal CloudWatch Logs dans le compte est inférieur à dix.

    CloudWatch Logs dispose d'un quota de dix politiques de ressources par région et par compte. Si vous essayez d'activer la journalisation sur une machine à états qui possède déjà dix politiques de ressources, la machine à états ne sera ni créée ni mise à jour, et vous recevrez un message d'erreur. Pour plus d'informations sur les quotas de journalisation, voir Quotas de CloudWatch journalisation

    Pour vérifier le problème, vérifiez le nombre de politiques de ressources à l'aide de la commande CLI :

    aws logs describe-resource-policies

    Pour résoudre le problème, modifiez vos politiques de ressources existantes.

    Tout d'abord, sauvegardez les politiques existantes. Ensuite, associez des actions ou des ressources similaires dans une nouvelle politique et utilisez la commande CLI suivante pour créer une nouvelle source de diffusion dans le compte :

    aws logs put-delivery-source

    Après avoir sauvegardé et mis à jour les politiques, supprimez toutes les politiques inutilisées à l'aide de la commande suivante :

    aws logs delete-resource-policy --policy-name <PolicyNameToBeDeleted>