Workflows überwachen

Diese Seite enthält Informationen zum Monitoring von Workflowbereitstellungen und -ausführungen.

Auf Bereitstellungs- und Löschlogs für Workflows zugreifen

In der Google Cloud Console können Sie auf Fehlerlogs zugreifen, die sich auf das Deployment und das Löschen eines Workflows beziehen.

1. Öffnen Sie in der Google Cloud Console die Seite Workflows.

   Zur Seite "Workflows"

2. Klicken Sie auf den Namen des Workflows, um die zugehörige Seite Workflowdetails aufzurufen.

3. Klicken Sie auf den Tab Logs.

4. Wählen Sie in der Liste Standard den Logtyp aus, der angezeigt werden soll, um die Logs nach Schweregrad zu filtern.

Auf Ergebnisse der Workflow-Ausführung zugreifen

Sie können über die Google Cloud Console oder die gcloud CLI auf die Ergebnisse der Workflowausführung zugreifen.

Console

1. Öffnen Sie in der Google Cloud Console die Seite Workflows.

   Zur Seite "Workflows"

2. Wenn Sie auf die Ausführungsergebnisse eines Workflows zugreifen möchten, klicken Sie auf den Namen des Workflows, um die zugehörige Seite Workflowdetails aufzurufen.

3. Wenn Sie Details zu einer bestimmten Ausführung benötigen, klicken Sie auf dem Tab Ausführungen in der Liste auf die Ausführungs-ID, um die Seite Ausführungsdetails aufzurufen.

   Hinweis: Für den Zugriff auf die Seite Ausführungsdetails benötigen Sie eine Rolle mit den Berechtigungen workflows.workflows.get, workflows.executions.get und workflows.stepEntries.list. Weitere Informationen finden Sie unter Rollen und Berechtigungen für Workflows und Zugriff verwalten.

4. Auf dem Tab Summary (Zusammenfassung) finden Sie für jede Ausführung die folgenden Informationen:

   • Ausführungsstatus: Gibt den Endstatus des Workflows an, einschließlich des aktuellen oder letzten Workflowschritts.
   • Ausführungsbeginn: Zeitpunkt, an dem die Ausführung begonnen hat.
   • Ausführungsende: Zeitpunkt, zu dem die Ausführung beendet wurde.
   • Ausführungsdauer: insgesamt verstrichene Zeit Dies kann ein Hinweis auf Netzwerkfehler oder Verbindungsprobleme sein.
   • Workflowname: Der Name des Workflows.
   • Workflowüberarbeitung: die aktuelle Version zum Zeitpunkt der Ausführung.
   • Aufruf-Logging-Ebene: Die Ebene des Aufruf-Loggings, die während der Ausführung angewendet wird. Weitere Informationen finden Sie in diesem Dokument im Abschnitt Anrufprotokollierung.
   • Eingabe: Die Laufzeitargumente, die gegebenenfalls an den Workflow übergeben werden.
   • Ausgabe: Die Ausgabe des Workflows. Wenn die Ausführung fehlgeschlagen ist, ist hier die Ausnahme enthalten, die zum Fehler der Ausführung geführt hat. Weitere Informationen finden Sie in diesem Dokument im Abschnitt Fehlermeldungen bei der Ausführung.

5. Klicken Sie auf den Tab Schritte, um den Workflowausführungsverlauf als Liste von Schritteinträgen anzusehen. Weitere Informationen finden Sie unter Verlauf der Ausführungsschritte ansehen.

6. Zum Aufrufen der Logs für eine Workflowausführung klicken Sie auf den Tab Logs.

7. Verwenden Sie das Feld Filter oben in der Tabelle, um die Ausführungslogs zu filtern. Wenn Sie beispielsweise nur fehlgeschlagene Ausführungsversuche anzeigen möchten, geben Sie in das Textfeld des Filters failed ein.

gcloud

1. Geben Sie den folgenden Befehl ein, um eine vollständige Liste der Ausführungen eines Workflows aufzurufen:

   gcloud workflows executions list WORKFLOW_NAME
   

   Ersetzen Sie WORKFLOW_NAME durch den Namen Ihres Workflows. Kopieren Sie die Ausführungs-ID der Ausführung, für die Sie Informationen erhalten möchten.

2. Geben Sie den folgenden Befehl ein, um die Ausführungslogs eines Workflows aufzurufen:

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

   Ersetzen Sie Folgendes:

   • WORKFLOW_NAME: der Name des Workflows
   • EXECUTION_ID: die eindeutige ID der Ausführung

   Die Ausgabe dieses Befehls sieht in etwa so aus:

   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
   

   Die Ausgabe enthält die folgenden Informationen:
   • argument: die Laufzeitargumente, die an den Workflow übergeben wurden, sofern vorhanden
   • endTime: der Zeitpunkt, an dem die Ausführung beendet wurde
   • error: die Fehlermeldung, die als Teil der Ausnahme ausgelöst wurde, die zum Fehler bei der Ausführung geführt hat
   • name: der vollständige Name der Ausführung, einschließlich Projektname, Speicherort des Workflows, Name des Workflows und Ausführungs-ID
   • startTime: der Zeitpunkt, an dem die Ausführung gestartet wurde
   • state: gibt den Endstatus des Workflows an
   • status: der aktuelle oder letzte Workflowschritt der Ausführung
   • workflowRevisionID: die aktuelle Überarbeitung zum Zeitpunkt der Ausführung

Zuordnung von Ausführungsfehlern

Wenn ein Workflow während der Ausführung einen Fehler ausgibt, der nicht in einem try/except-Block enthalten ist, schlägt die Ausführung fehl und eine Fehlerzuordnung (ein JSON-Wörterbuch) wird zurückgegeben, die den Fehler beschreibt.

Fehler, die während der Workflowausführung ausgelöst werden, enthalten Tags, anhand derer Sie die Fehlerursache ermitteln können. Beispiel: Der von einem Connector zurückgegebene Fehler kann zwei Schlüssel (tags und message) haben, die in etwa so aussehen:

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

Es kann mehrere Tags geben. Sie können einen Ausdruck verwenden, um nach einem bestimmten Tag zu suchen. Beispiel:

${'SystemError' in e.tags}

Als String zurückgegebene Zugriffsfehlerdaten

Einige Connectors und HTTP APIs serialisieren Fehler als Strings, bevor sie zurückgegeben werden. Mit den Funktionen der Standardbibliothek können Sie eine Nutzlast im ursprünglichen Fehler wiederherstellen. Wenn Sie beispielsweise einen Fehlerstring in eine Zuordnung konvertieren möchten, können Sie die Funktionen json.decode und text.encode verwenden:

json.decode(text.encode(ERROR_FROM_API))

Fehler-Tags

In der folgenden Tabelle wird die Bedeutung der verschiedenen Fehler-Tags beschrieben.

Tag	Beschreibung
AuthError	Wird ausgelöst, wenn Anmeldedaten für eine HTTP-Anfrage generiert werden.
ConnectionError	Wird ausgelöst, wenn eine Verbindung mit dem Endpunkt erfolgreich hergestellt wurde, aber während der Datenübertragung ein Problem mit der Verbindung auftritt. Die Verbindung wird beendet, bevor eine vollständige Antwort empfangen wurde und eine Nachricht möglicherweise nicht an den Endpunkt zugestellt wurde. Wiederholungsversuche sind möglicherweise nicht idempotent.
ConnectionFailedError	Wird ausgelöst, wenn keine Verbindung mit dem API-Endpunkt hergestellt wird, beispielsweise aufgrund eines falschen Domainnamens, Problemen mit der DNS-Auflösung oder anderen Netzwerkproblemen. Wiederholungsversuche sind idempotent.
HttpError	Wird ausgelöst, wenn eine HTTP-Anfrage mit einem HTTP-Fehlerstatus fehlschlägt. Wenn diese Ausnahme ausgelöst wird, ist die Antwort eine Karte mit den folgenden Elementen: tags: Liste mit dem String HttpError message: Für Menschen lesbare Fehlermeldung code: HTTP-Antwortstatuscode headers: Antwortheader body: Antworttext
IndexError	Wird ausgelöst, wenn ein Sequenzunterskript außerhalb des Bereichs liegt.
KeyError	Wird ausgelöst, wenn ein Zuordnungsschlüssel nicht in den vorhandenen Schlüsseln gefunden wird.
OperationError	Wird ausgelöst, wenn ein lang andauernder Vorgang nicht erfolgreich abgeschlossen wird.
ParallelNestingError	Wird ausgelöst, wenn die maximale Tiefe, die parallele Schritte verschachtelt werden können, überschritten wird.
RecursionError	Wird ausgelöst, wenn der Interpreter erkennt, dass die maximale Aufrufstacktiefe überschritten ist.
ResourceLimitError	Wird ausgelöst, wenn ein Ressourcenlimit aufgebraucht ist. Bei internen Fehlern kann dieser Fehlertyp nicht erfasst werden und führt zu einem sofortigen Ausführungsfehler.
ResponseTypeError	Wird ausgelöst, wenn ein Vorgang mit langer Ausführungszeit eine Antwort des falschen Typs zurückgibt.
SystemError	Wird ausgelöst, wenn der Interpreter einen internen Fehler findet.
TimeoutError	Wird ausgelöst, wenn eine Systemfunktion auf Systemebene das Zeitlimit überschreitet.
TypeError	Wird ausgelöst, wenn ein Vorgang oder eine Funktion auf ein Objekt mit nicht kompatiblem Typ angewendet wird. Der verknüpfte Wert ist ein String mit Details zur Typabweichung.
UnhandledBranchError	Wird ausgelöst, wenn in einer oder mehreren Zweigen oder Iterationen ein unbehandelter Laufzeitfehler bis zu einer maximalen Anzahl auftritt.
ValueError	Wird ausgelöst, wenn ein Vorgang oder eine Funktion ein Argument mit dem richtigen Typ, aber einem falschen Wert erhält, und die Situation nicht durch eine präzisere Ausnahme beschrieben wird, z. B. durch IndexError.
ZeroDivisionError	Wird ausgelöst, wenn das zweite Argument eines Divisions- oder Modulo-Vorgangs null ist. Der zugehörige Wert ist ein String, der den Typ der Operanden und den Vorgang angibt.

Mit der Syntax raise können Sie auch benutzerdefinierte Fehler auslösen.

Status von Ausführungen prüfen

Es gibt mehrere Befehle, mit denen Sie den Status einer Workflowausführung prüfen können.

• Geben Sie den folgenden Befehl ein, um eine Liste der Ausführungsversuche eines Workflows und ihrer IDs abzurufen:

  gcloud workflows executions list WORKFLOW_NAME
  

  Ersetzen Sie WORKFLOW_NAME durch den Namen des Workflows.

  Der Befehl gibt einen NAME-Wert zurück, der in etwa so aussieht:

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

  Kopieren Sie die Ausführungs-ID, die im nächsten Befehl verwendet werden soll.

• Geben Sie den folgenden Befehl ein, um den Status eines Ausführungsversuchs zu prüfen und auf den Abschluss des Versuchs zu warten:

  gcloud workflows executions wait EXECUTION_ID
  

  Ersetzen Sie EXECUTION_ID durch die ID des Ausführungsversuchs.

  Der Befehl wartet, bis der Ausführungsversuch abgeschlossen ist, und gibt dann die Ergebnisse zurück.

• Wenn Sie auf den Abschluss der letzten Ausführung warten und dann das Ergebnis der abgeschlossenen Ausführung zurückgeben möchten, geben Sie den folgenden Befehl ein:

  gcloud workflows executions wait-last
  

  Wenn Sie in derselben gcloud-Sitzung bereits einen Ausführungsversuch unternommen haben, wartet der Befehl, bis der vorherige Ausführungsversuch beendet ist, und gibt dann die Ergebnisse der abgeschlossenen Ausführung zurück. Falls kein vorheriger Versuch vorhanden ist, gibt gcloud den folgenden Fehler zurück:

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

• Geben Sie den folgenden Befehl ein, um den Status der letzten Ausführung abzurufen:

  gcloud workflows executions describe-last
  

  Wenn Sie in derselben gcloud-Sitzung bereits einen Ausführungsversuch unternommen haben, gibt der Befehl die Ergebnisse der letzten Ausführung zurück, auch wenn diese noch ausgeführt wird. Wenn kein vorheriger Versuch vorhanden ist, gibt gcloud den folgenden Fehler zurück:

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

Filterausführungen

Sie können Filter auf die Liste der Workflowausführungen anwenden, die von der Methode workflows.executions.list zurückgegeben werden.

Sie können nach folgenden Feldern filtern:

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

Wenn Sie beispielsweise nach einem Label (labels."fruit":"apple") filtern möchten, können Sie eine API-Anfrage ähnlich der folgenden stellen:

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"

Wobei:

• view=full gibt eine Ansicht an, mit der definiert wird, welche Felder in den zurückgegebenen Ausführungen gefüllt werden sollen. In diesem Fall werden alle Daten
• labels.%22fruit%22%3A%22apple%22 ist die URL-codierte Filtersyntax.

Weitere Informationen finden Sie unter AIP-160-Filterung.

Logs an Cloud Logging senden

Workflows generiert automatisch Ausführungslogs für Workflowausführungen in Cloud Logging.

Sie können auch das Aufruf-Logging aktivieren. Alternativ können Sie benutzerdefinierte Logs erstellen, die die Funktion sys.log in Ihrer Quelle verwenden. Mit Logging und benutzerdefinierten Logs können Sie steuern, wann Logs während der Ausführung eines Workflows an Logging gesendet werden. Dies kann besonders hilfreich sein, wenn Sie Ihren Workflow debuggen.

Weitere Informationen, einschließlich der Proto-Dateien engine_call und executions_system, finden Sie in diesem GitHub-Repository.

Ausführungsprotokolle

Jede Workflowausführung löst automatisch mindestens zwei Ausführungslogs aus: eines zu Beginn einer Ausführung und eines am Ende.

Weitere Informationen zu den Logs der Workflow-Plattform, die in Logging verfügbar sind, finden Sie unter Logs der Google Cloud Platform.

Anruf-Logging

Sie können ein Flag festlegen, damit jeder Aufrufschritt während der Ausführung Ihres Workflows protokolliert wird und Schrittnamen, Funktionsnamen, Funktionsargumente und Aufrufantworten zurückgegeben werden. Sie können auch alle Ausnahmen protokollieren, die erfasst werden oder einen Anruf beenden.

Es werden nur explizite Aufrufschritte protokolliert. beispielsweise Aufrufe an untergeordnete Workflows oder Bibliotheksfunktionen. Aufrufe innerhalb von Ausdrücken oder innerhalb von Standardbibliotheksfunktionen (z. B. http.post in sys.log) und innerhalb von Connectors werden nicht in Logs erfasst.

HTTP-Anfrageheader Authorization werden aus den Logs für HTTP-Aufrufe entfernt.

Wenn Sie das Anruf-Logging auf eine Workflowdefinition oder die Ausführung eines Workflows anwenden, können Sie die erforderliche Logging-Ebene angeben. Die Ausführungslogebene hat Vorrang vor allen Workflowlogebenen, es sei denn, die Ausführungsprotokollebene ist nicht angegeben (Standardeinstellung). In diesem Fall gilt die Workflowlogebene.

Das von Cloud Logging festgelegte Größenlimit für Logeinträge gilt auch für das Aufruf-Logging.

Benutzerdefinierte Logs

Zum Erstellen eines Logeintrags in Logging während einer Workflow-Ausführung definieren Sie einen Schritt im Workflow, der einen Aufruf der Funktion sys.log der Standardbibliothek ausführt:

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

Definieren Sie beim Erstellen eines Logeintrags Folgendes:

• TEXT: erforderlich. Der zu protokollierende Text. Wenn Sie die Werte einer Karte protokollieren müssen, verwenden Sie ${json.encode_to_string(myMap)}.
• SEVERITY: Optional. Der Schweregrad des Logeintrags. Beispiel: INFO, WARNING oder CRITICAL.

Weitere Informationen finden Sie in der sys.logFunktionsreferenz.

Erforderliche Berechtigungen

Zum Anwenden von Aufruf-Logging oder zum Senden benutzerdefinierter Logs an Logging muss ein Workflow mit einem Dienstkonto verknüpft sein, das die Berechtigung logging.logEntries.create enthält (z. B. die Rolle roles/logging.logWriter). Informationen zum Ändern des mit Ihrem Workflow aktualisierten Dienstkontos finden Sie unter Workflow aktualisieren. Weitere Informationen zum Erstellen von Dienstkonten und Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

Workflow-Logs ansehen

Sie können Logs in Workflows oder in Logging aufrufen. Wenn Sie die Logs für einen einzelnen Workflow aufrufen möchten, verwenden Sie den Tab Logs in Workflows. Eine zusammengefasste Ansicht der Logs für alle Ihre Workflows erhalten Sie auf der Seite Log-Explorer in Logging.

Logs in Workflows aufrufen

So rufen Sie die Logs eines Workflows in Workflows auf:

1. Öffnen Sie in der Google Cloud Console die Seite Workflows.

   Zur Seite "Workflows"

2. Klicken Sie zum Aufrufen der Logs eines Workflows auf dessen Namen, um dessen Seite Details aufzurufen.

3. Klicken Sie zum Anzeigen der Logs auf Logs.

4. Wählen Sie in der Liste Standard den Logtyp aus, der angezeigt werden soll, um die Logs nach Schweregrad zu filtern. Standardmäßig werden Logs aller Schweregrade angezeigt.

Auf dem Tab Logs auf der Seite Details eines Workflows werden die folgenden Logtypen angezeigt:

• An Logging gesendete Logs

• Audit-Logs aller Vorgänge, die für den Workflow ausgeführt werden, z. B. Aktualisierungen der Workflow-Definition

Logs in Logging aufrufen

So rufen Sie Logs in Logging auf:

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf:
   

   Zum Log-Explorer

2. Klicken Sie im Query Builder auf Ressource und geben Sie workflow ein. Wählen Sie Cloud Workflow aus der Liste aus und klicken Sie auf Add.

   

3. Klicken Sie auf Abfrage ausführen.

Weitere Informationen zum Anzeigen von Logs in Logging finden Sie unter Log-Explorer verwenden.

Nächste Schritte

• Fehlerbehebung – Übersicht
• Fehlerbehebung
• Bekannte Probleme bei Workflows