Cette page fournit des informations pour vous aider à surveiller les déploiements et les exécutions des workflows.
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.
Dans la console Google Cloud, accédez à la page Workflows :
Cliquez sur le nom du workflow pour afficher la page Workflow details (Détails du workflow).
Cliquez sur l'onglet Journaux.
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
Dans la console Google Cloud, accédez à la page Workflows :
Pour accéder aux résultats d'exécution d'un workflow, cliquez sur son nom. Vous accédez alors à la page Détails du workflow.
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.
Dans l'onglet Summary (Résumé), chaque exécution comporte les informations suivantes:
- État d'exécution: indique l'état final du workflow, y compris l'étape actuelle ou finale.
- Execution start (Début de l'exécution) : début de l'exécution.
- Execution end (Fin de l'exécution) : date à laquelle l'exécution s'est terminée.
- Execution duration (Durée de l'exécution) : temps total écoulé. 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 page Journal des appels.
- Entrée: les 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. Consultez la section Messages d'erreur d'exécution dans ce document.
Pour afficher l'historique des exécutions du workflow sous la forme d'une liste d'entrées d'étape, cliquez sur l'onglet Étapes. Pour en savoir plus, consultez la section Afficher l'historique des étapes d'exécution.
Pour afficher les journaux d'une exécution de workflow, cliquez sur l'onglet Journaux.
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
faileddans le champ de texte du filtre.
gcloud
Pour afficher la liste complète des exécutions d'un workflow, saisissez la commande suivante:
gcloud workflows executions list WORKFLOW_NAMERemplacez
WORKFLOW_NAMEpar le nom de votre workflow. Copiez l'ID de l'exécution qui vous intéresse.Pour afficher les journaux d'exécution d'un workflow, saisissez la commande suivante:
gcloud workflows executions describe \ --workflow=WORKFLOW_NAME \ EXECUTION_IDRemplacez les éléments suivants :
WORKFLOW_NAME: nom du workflowEXECUTION_ID: ID unique de l'exécution
La commande renvoie un résultat semblable à celui-ci :
Le résultat contient les informations suivantes :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-ac2argument: arguments d'exécution transmis au workflow, le cas échéantendTime: date de fin de l'exécutionerror: 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écutionstartTime: début de l'exécutionstate: indique l'état de fin du workflow.status: étape actuelle ou finale du workflow de l'exécutionworkflowRevisionID: révision actuelle au moment de l'exécution
Cartes des erreurs d'exécution
Lorsqu'un workflow génère, lors de l'exécution, une erreur qui n'est pas détectée dans un bloc try/except, l'exécution échoue et un mappage d'erreurs (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 à celle-ci:
{'tags': ['SystemError'], 'message': 'an error has occurred'}
Il peut y en avoir plusieurs. Pour rechercher un tag spécifique, vous pouvez utiliser une expression. Exemple :
${'SystemError' in e.tags}
Accéder aux données d'erreur 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 standards pour restaurer une charge utile sur l'erreur d'origine. Par exemple, pour convertir une chaîne d'erreur en carte, vous pouvez utiliser les fonctions json.decode et text.encode:
json.decode(text.encode(ERROR_FROM_API))
Tags 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'il y a un problème de connexion lors du transfert de données. La connexion prend fin avant qu'une réponse complète ne soit reçue et qu'un message n'ait peut-être pas été distribué au point de terminaison. Les nouvelles tentatives peuvent ne pas être idempotentes. |
| 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 une erreur HTTP. Lorsque cette exception est générée, la réponse est un mappage avec les éléments suivants :
|
| 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 se termine sans succès. |
| ParallelNestingError | Générée lorsque la profondeur maximale d'imbrication d'étapes parallèles est dépassée. |
| RecursionError | Générée lorsque l'interpréteur détecte que la profondeur maximale de pile d'appel 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_NAMEpar le nom du workflow.La commande renvoie une valeur
NAMEsemblable à celle-ci:projects/PROJECT_NUMBER/locations/REGION/workflows/WORKFLOW_NAME/executions/EXECUTION_IDCopiez 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_IDpar 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 avant de renvoyer le résultat, 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. S'il n'existe aucune tentative précédente,gcloudrenvoie 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,gcloudrenvoie l'erreur suivante:ERROR: (gcloud.beta.workflows.executions.describe-last) [NOT FOUND] There are no cached executions available.
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 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ête 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 prévaut sur tous les niveaux de journalisation du workflow, sauf si le niveau de journalisation de l'exécution n'est pas spécifié (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,WARNINGouCRITICAL.
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:
Dans Google Cloud Console, accédez à la page Workflows :
Pour accéder aux journaux d'un workflow, cliquez sur le nom de ce dernier pour accéder à la page Détails correspondante.
Pour afficher les journaux, cliquez sur Journaux.
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:
Dans la console Google Cloud, accédez à la page Explorateur de journaux:
Dans Générateur de requêtes, cliquez sur Ressource, puis saisissez
workflow. Sélectionnez Cloud Workflow dans la liste, puis cliquez sur Ajouter.
Cliquez sur Run query.
Pour en savoir plus sur l'affichage des journaux dans Logging, consultez la page Utiliser l'explorateur de journaux.