Surveiller les workflows

Cette page fournit des informations pour vous aider à surveiller les déploiements de workflows et exécutions.

Accéder aux journaux de déploiement et de suppression de workflow

Vous pouvez accéder aux journaux d'erreurs liés au déploiement et à la suppression d'un workflow dans la console Google Cloud.

1. Dans la console Google Cloud, accédez à la page Workflows :

   Accéder à "Workflows"

2. Cliquez sur le nom du workflow pour afficher la page Workflow details (Détails du workflow).

3. Cliquez sur l'onglet Journaux.

4. Pour filtrer les journaux par gravité, sélectionnez le type de journal à afficher dans la liste Default (Par défaut).

Accéder aux résultats d'exécution d'un workflow

Vous pouvez accéder aux résultats de l'exécution du workflow dans la console Google Cloud ou à l'aide de la gcloud CLI.

Console

1. Dans la console Google Cloud, accédez à la page Workflows :

   Accéder à "Workflows"

2. Pour accéder aux résultats d'exécution d'un workflow, cliquez sur son nom à la page Détails du workflow correspondante.

3. Pour en savoir plus sur une exécution spécifique, dans l'onglet Exécutions, cliquez sur l'ID de l'exécution dans la liste pour accéder à la page Détails de l'exécution.

   Remarque:Pour accéder à la page Détails de l'exécution, vous devez disposer d'un rôle contenant les champs workflows.workflows.get, workflows.executions.get et Autorisations workflows.stepEntries.list. Pour en savoir plus, consultez Rôles et les autorisations Gérer l'accès :

4. Dans l'onglet Summary (Résumé), chaque exécution contient les informations suivantes:

   • État d'exécution : indique l'état de fin du workflow, y compris l'étape actuelle ou finale du workflow.
   • Début de l'exécution : date de début de l'exécution.
   • Execution end (Fin de l'exécution) : date et heure de fin de l'exécution.
   • Durée d'exécution : durée totale écoulée. Cela peut indiquer des erreurs réseau ou des problèmes de connectivité.
   • Nom du workflow : nom du workflow.
   • Révision du workflow: révision en cours au moment de l'exécution.
   • Niveau de journalisation des appels : niveau de journalisation des appels appliqué lors de l'exécution. Dans ce document, consultez la section Journalisation des appels.
   • Entrée : arguments d'exécution transmis au workflow, le cas échéant.
   • Sortie : sortie du workflow. Si l'exécution a échoué, inclut l'exception qui a entraîné l'échec de l'exécution. Dans ce document, consultez la section Messages d'erreur d'exécution.

5. Pour afficher l'historique d'exécution du workflow sous la forme d'une liste d'entrées d'étape, cliquez sur le bouton Onglet Steps (Étapes). Pour en savoir plus, consultez la section Afficher l'historique des étapes d'exécution.

6. Pour afficher les journaux d'une exécution de workflow, cliquez sur l'onglet Journaux.

7. Pour filtrer les journaux d'exécution, utilisez le champ Filtrer en haut du tableau. Par exemple, pour n'afficher que les tentatives d'exécution ayant échoué, saisissez failed dans le champ de texte du filtre.

gcloud

1. Pour afficher la liste complète des exécutions d'un workflow, saisissez la commande suivante:

   gcloud workflows executions list WORKFLOW_NAME
   

   Remplacez WORKFLOW_NAME par le nom de votre workflow. Copiez l'ID de l'exécution qui vous intéresse.

2. Pour afficher les journaux d'exécution d'un workflow, saisissez la commande suivante:

   gcloud workflows executions describe \
       --workflow=WORKFLOW_NAME \
       EXECUTION_ID
   

   Remplacez les éléments suivants :

   • WORKFLOW_NAME: nom du workflow
   • EXECUTION_ID: ID unique de l'exécution

   La commande renvoie un résultat semblable à celui-ci :

   argument: 'null'
   endTime: '2022-07-19T12:40:07.070039707Z'
   error:
    context: |-
       The argument of 'in' must be a dict or an array; got: null
       in step "checkSearchTermInInput", routine "main", line: 12
    payload: "{"message":"The argument of 'in' must be a dict or an array; got: null"
   
       ,"tags":["TypeError"]}"
    stackTrace:
       elements:
       - position:
          column: '26'
          length: '24'
          line: '12'
          routine: main
          step: checkSearchTermInInput
   name: projects/1051295516635/locations/us-central1/workflows/myFirstWorkflow/executions/17ffc89c-0a27-4d2f-8356-e681d949a3d3
   startTime: '2022-07-19T12:40:07.024823663Z'
   state: FAILED
   status:
    currentSteps:
    - routine: main
       step: checkSearchTermInInput
   workflowRevisionId: 000001-ac2

   Le résultat contient les informations suivantes :
   • argument: arguments d'exécution transmis au workflow, le cas échéant
   • endTime: date de fin de l'exécution
   • error: message d'erreur généré avec l'exception qui a entraîné l'échec de l'exécution.
   • name: nom complet de l'exécution, y compris le nom du projet, l'emplacement du workflow, le nom du workflow et l'ID d'exécution
   • startTime: début de l'exécution
   • state: indique l'état de fin du workflow.
   • status : étape de workflow actuelle ou finale de l'exécution
   • workflowRevisionID: révision actuelle au moment de l'exécution

Cartes d'erreurs d'exécution

Lorsqu'un workflow génère une erreur lors de l'exécution qui n'est pas interceptée dans un bloc try/except, l'exécution échoue et une carte d'erreur (un dictionnaire JSON) décrivant l'erreur est renvoyée.

Les erreurs générées lors de l'exécution du workflow contiennent des tags permettant d'identifier l'origine de l'erreur. Par exemple, l'erreur renvoyée par un connecteur peut avoir deux clés (tags et message) semblables à celles-ci :

{'tags': ['SystemError'], 'message': 'an error has occurred'}

Il peut y avoir plusieurs balises. Pour rechercher une balise spécifique, vous pouvez utiliser une expression. Exemple :

${'SystemError' in e.tags}

Données d'erreur d'accès renvoyées sous forme de chaîne

Certains connecteurs et API HTTP sérialisent les erreurs sous forme de chaînes avant de renvoyer les erreurs. Vous pouvez utiliser les fonctions de bibliothèque standard pour restaurer une charge utile dans le erreur d'origine. Par exemple, pour convertir une chaîne d'erreur en mappage, vous pouvez utiliser le json.decode et text.encode:

json.decode(text.encode(ERROR_FROM_API))

Balises d'erreur

Le tableau suivant décrit la signification des différentes balises d'erreur.

Tag	Description
AuthError	Générée lors de l'échec de la génération d'identifiants pour une requête HTTP.
ConnectionError	Générée lorsqu'une connexion est établie avec le point de terminaison mais il y a un problème de connexion lors du transfert de données. La est interrompue avant qu'une réponse complète ne soit reçue et qu'un message n'ont peut-être pas été livrés au point de terminaison. Il est possible que les nouvelles tentatives idempotente.
ConnectionFailedError	Générée lorsqu'une connexion n'est pas établie avec le point de terminaison de l'API, par exemple en raison d'un nom de domaine incorrect, de problèmes de résolution DNS ou d'autres problèmes de réseau. Les nouvelles tentatives sont idempotentes.
HttpError	Générée lorsqu'une requête HTTP échoue avec un état d'erreur HTTP. Lorsque cette exception est générée, le est une carte contenant les éléments suivants: tags : liste avec la chaîne HttpError message : message d'erreur lisible par l'utilisateur code Code d'état de réponse HTTP. headers-En-têtes de réponse bodyCorps de la réponse
IndexError	Générée lorsqu'un indice de séquence est un entier hors de la plage.
KeyError	Générée lorsqu'une clé de mappage est introuvable dans l'ensemble de clés existantes.
OperationError	Généré lorsqu'une opération de longue durée se termine sans succès.
ParallelNestingError	Générée lorsque la profondeur maximale à laquelle les étapes parallèles peuvent être imbriquées est dépassée.
RecursionError	Générée lorsque l'interpréteur détecte que la profondeur maximale de la pile d'appels est dépassée.
ResourceLimitError	Générée lorsque la limite d'une ressource est épuisée. Lorsqu'il est généré en interne, ce type d'erreur ne peut pas être intercepté et entraîne une défaillance immédiate de l'exécution.
ResponseTypeError	Générée lorsqu'une opération de longue durée renvoie une réponse de mauvais type.
SystemError	Générée lorsque l'interpréteur détecte une erreur interne.
TimeoutError	Générée lorsqu'une fonction système expire au niveau du système.
TypeError	Générée lorsqu'une opération ou une fonction est appliquée à un objet de type incompatible. La valeur associée est une chaîne qui donne des détails sur l'incohérence de type.
UnhandledBranchError	Générée lorsqu'une ou plusieurs branches ou itérations rencontrent une erreur d'exécution non gérée jusqu'à un nombre maximal.
ValueError	Générée lorsqu'une opération ou une fonction reçoit un argument dont le type est correct, mais d'une valeur incorrecte, et que la situation n'est pas décrite par une exception plus précise, telle que IndexError.
ZeroDivisionError	Générée lorsque le deuxième argument d'une opération de division ou de modulo est égale à zéro. La valeur associée est une chaîne indiquant le type des opérandes et de l'opération.

Vous pouvez également générer des erreurs personnalisées à l'aide de la syntaxe raise.

Vérifier l'état des exécutions

Plusieurs commandes vous permettent de vérifier l'état d'exécution d'un workflow.

• Pour récupérer la liste des tentatives d'exécution d'un workflow et de leurs ID, saisissez la commande suivante:

  gcloud workflows executions list WORKFLOW_NAME

  Remplacez WORKFLOW_NAME par le nom du workflow.

  La commande renvoie une valeur NAME semblable à la suivante :

  projects/PROJECT_NUMBER/locations/REGION/workflows/WORKFLOW_NAME/executions/EXECUTION_ID

  Copiez l'ID d'exécution à utiliser dans la commande suivante.

• Pour vérifier l'état d'une tentative d'exécution et attendre la fin de la tentative, saisissez la commande suivante:

  gcloud workflows executions wait EXECUTION_ID

  Remplacez EXECUTION_ID par l'ID de la tentative d'exécution.

  La commande attend la fin de la tentative d'exécution, puis renvoie les résultats.

• Pour attendre la fin de la dernière exécution, puis renvoyer le résultat de l'exécution terminée, saisissez la commande suivante :

  gcloud workflows executions wait-last

  Si vous avez effectué une tentative d'exécution précédente dans la même session gcloud, la commande attend la fin de la tentative d'exécution précédente, puis renvoie les résultats de l'exécution terminée. Si aucune tentative précédente n'existe, gcloud renvoie l'erreur suivante :

  ERROR: (gcloud.workflows.executions.wait-last) [NOT FOUND] There are no cached executions available.
  

• Pour connaître l'état de la dernière exécution, saisissez le la commande suivante:

  gcloud workflows executions describe-last

  Si vous avez effectué une tentative d'exécution précédente dans la même session gcloud, la commande renvoie les résultats de la dernière exécution, même si elle est en cours d'exécution. Si aucune tentative précédente n'existe, gcloud renvoie l'erreur suivante:

  ERROR: (gcloud.beta.workflows.executions.describe-last) [NOT FOUND] There are no cached executions available.
  

Filtrer les exécutions

Vous pouvez appliquer des filtres à la liste des exécutions de workflow renvoyées par Méthode workflows.executions.list.

Vous pouvez filtrer les données en fonction des champs suivants:

• createTime
• disableOverflowBuffering
• duration
• endTime
• executionId
• label
• startTime
• state
• stepName
• workflowRevisionId

Par exemple, pour filtrer les données à l'aide d'un libellé (labels."fruit":"apple"), vous pouvez définir une Requête d'API semblable à celle-ci:

GET https://workflowexecutions.googleapis.com/v1/projects/MY_PROJECT/locations/MY_LOCATION/workflows/MY_WORKFLOW/executions?view=full&filter=labels.%22fruit%22%3A%22apple%22"

Où :

• view=full spécifie une vue qui définit les champs à renseigner dans les exécutions renvoyées. Dans ce cas, toutes les données
• labels.%22fruit%22%3A%22apple%22 est la syntaxe du filtre encodée au format URL.

Pour en savoir plus, consultez la page Filtrage AIP-160.

Envoyer des journaux à Cloud Logging.

Les workflows génèrent automatiquement des journaux d'exécution pour les exécutions de workflows dans Cloud Logging.

Vous pouvez également activer la journalisation des appels. Vous pouvez également créer des journaux personnalisés qui utilisent la fonction sys.log dans votre source. La journalisation des appels et les journaux personnalisés vous permettent de contrôler le moment où les journaux sont envoyés à Logging lors de l'exécution d'un workflow. Ils peuvent être particulièrement utiles lors du débogage de votre workflow.

Pour plus d'informations, y compris les fichiers proto de journalisation engine_call et executions_system, consultez ce dépôt GitHub.

Journaux d'exécution

Chaque exécution de workflow déclenche automatiquement au moins deux journaux d'exécution : l'un au début et l'autre à la fin.

Pour en savoir plus sur les journaux de la plate-forme Workflows disponibles dans Logging, consultez la page Journaux Google Cloud Platform.

Journalisation des appels

Vous pouvez définir un indicateur pour que chaque étape d'appel lors de l'exécution de votre workflow soit journalisée et que les noms des étapes, les noms des fonctions, les arguments des fonctions et les réponses aux appels soient renvoyés. Vous pouvez également consigner les exceptions détectées ou qui interrompent un appel.

Seules les étapes explicites des appels sont consignées. par exemple des appels à des sous-workflows ou à des fonctions de bibliothèque. Les appels provenant des expressions ou des fonctions standards de la bibliothèque (par exemple, http.post dans sys.log) et des connecteurs internes ne sont pas enregistrés.

Les en-têtes de requête HTTP Authorization sont masqués dans les journaux des appels HTTP.

Lorsque vous appliquez la journalisation des appels à une définition de workflow ou à l'exécution d'un workflow, vous pouvez spécifier le niveau de journalisation requis. Le niveau de journalisation d'exécution est prioritaire sur tout niveau de journalisation de workflow, sauf si celui-ci n'est pas spécifié (valeur par défaut). Dans ce cas, le niveau de journalisation du workflow s'applique.

Notez que la taille maximale des entrées de journal définie par Cloud Logging s'applique également à la journalisation des appels.

Journaux personnalisés

Pour créer une entrée de journal dans Logging lors de l'exécution d'un workflow, définissez une étape dans le workflow qui appelle la fonction sys.log de la bibliothèque standard:

YAML

  - step1:
      assign:
          - varA: "Hello"
          - varB: "World"
  - logStep:
      call: sys.log
      args:
          text: TEXT
          severity: SEVERITY 
  - step2:
      return: ${varA + " " + varB}
    

JSON

    [
      {
        "step1": {
          "assign": [
            {
              "varA": "Hello"
            },
            {
              "varB": "World"
            }
          ]
        }
      },
      {
        "logStep": {
          "call": "sys.log",
          "args": {
            "text": "TEXT",
            "severity": "SEVERITY"
          }
        }
      },
      {
        "step2": {
          "return": "${varA + " " + varB}"
        }
      }
    ]
      

Lors de la création d'une entrée de journal, définissez les éléments suivants:

• TEXT : Obligatoire. Texte à consigner. Si vous devez consigner les valeurs d'une carte, utilisez ${json.encode_to_string(myMap)}.
• SEVERITY : Facultatif. Niveau de gravité de l'entrée de journal. Par exemple, INFO, WARNING ou CRITICAL.

Pour en savoir plus, consultez la documentation de référence sur la fonction sys.log.

Autorisations requises

Pour appliquer la journalisation des appels ou envoyer des journaux personnalisés à Logging, un workflow doit être associé à un compte de service incluant l'autorisation logging.logEntries.create (par exemple, le rôle roles/logging.logWriter). Si vous devez modifier le compte de service mis à jour avec votre workflow, consultez la section Mettre à jour un workflow. Pour en savoir plus sur la création de comptes de service et l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Afficher les journaux de workflow

Vous pouvez afficher les journaux dans Workflows ou Logging. Pour afficher les journaux d'un seul workflow, utilisez l'onglet Logs (Journaux) de Workflows. Pour obtenir une vue globale des journaux de tous vos workflows, utilisez la page Explorateur de journaux de Logging.

Afficher les journaux dans Workflows

Pour afficher les journaux d'un workflow dans Workflows, procédez comme suit:

1. Dans Google Cloud Console, accédez à la page Workflows :

   Accéder à "Workflows"

2. Pour accéder aux journaux d'un workflow, cliquez sur le nom de ce dernier pour accéder à la page Détails correspondante.

3. Pour afficher les journaux, cliquez sur Journaux.

4. Pour filtrer les journaux par gravité, sélectionnez le type de journal à afficher dans la liste Default (Par défaut). Les journaux de tous les niveaux de gravité sont affichés par défaut.

L'onglet Journaux de la page Détails d'un workflow affiche les types de journaux suivants:

• Journaux envoyés à Logging

• Journaux d'audit de toutes les opérations effectuées sur le workflow, telles que des mises à jour de la définition du workflow

Afficher les journaux dans Logging

Pour afficher les journaux dans Logging, procédez comme suit:

1. Dans la console Google Cloud, accédez à la page Explorateur de journaux :
   

   Accéder à l'explorateur de journaux

2. Dans Générateur de requêtes, cliquez sur Ressource, puis saisissez workflow. Sélectionnez Cloud Workflow dans la liste, puis cliquez sur Ajouter.

   

3. Cliquez sur Run query.

Pour en savoir plus sur l'affichage des journaux dans Logging, consultez la page Utiliser l'explorateur de journaux.

Étape suivante

• Présentation du débogage
• Résoudre les problèmes
• Problèmes connus liés à Workflows