Surveiller les workflows

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

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 pour accéder à la page Workflow details (Détails du workflow).

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

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

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

   • État de l'exécution: indique l'état final du workflow, y compris l'étape en cours ou finale.
   • Execution start (Démarrage de l'exécution) : date à laquelle l'exécution a commencé.
   • Execution end (Fin de l'exécution) : date et heure de fin de l'exécution.
   • Execution duration (Durée de l'exécution) : temps total écoulé. Cela peut indiquer des erreurs réseau ou des problèmes de connectivité.
   • Workflow name (Nom du workflow) : nom du workflow.
   • Révision du workflow: révision en cours au moment de l'exécution.
   • Call logging level (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.
   • Résultat: résultat 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 l'onglet Steps (Étapes). Pour en savoir plus, consultez la section Afficher l'historique des étapes d'exécution.

6. Pour afficher les journaux d'exécution d'un 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 du workflow en cours 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 pendant l'exécution qui n'est pas interceptée dans un bloc try/except, l'exécution échoue et un mappage d'erreurs (un dictionnaire JSON) décrivant l'erreur est renvoyé.

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 les renvoyer. Vous pouvez utiliser les fonctions de bibliothèque standard pour restaurer une charge utile à l'erreur d'origine. Par exemple, pour convertir une chaîne d'erreur en mappage, vous pouvez utiliser les fonctions 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 qu'un problème survient lors du transfert de données. La connexion est interrompue avant la réception d'une réponse complète, et il est possible qu'aucun message n'ait été distribué au point de terminaison. Il est possible que les tentatives ne soient pas idempotentes.
ConnectionFailedError	Générée lorsqu'aucune connexion n'est é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 réseau). Les 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, la réponse est un mappage 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ée lorsqu'une opération de longue durée n'aboutit pas.
ParallelNestingError	Générée lorsque la profondeur maximale pouvant être imbriquée avec des étapes parallèles 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 d'un type incorrect.
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 à ce qui suit:

  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 et renvoyer le résultat de l'exécution, 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 obtenir l'état de la dernière exécution, saisissez 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ée par la méthode workflows.executions.list.

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

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

Par exemple, pour filtrer les résultats à l'aide d'une étiquette (labels."fruit":"apple"), vous pouvez envoyer une requête 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 définissant 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 qui sont interceptées ou qui arrêtent 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êtes HTTP Authorization sont masqués dans les journaux pour les 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 de l'exécution est prioritaire sur tout niveau de journalisation du workflow, sauf si le niveau de journalisation d'exécution n'est pas spécifié (valeur par défaut). Dans ce cas, le niveau de journalisation du workflow s'applique.

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

de 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.

Étapes suivantes

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