Diese Seite wurde von der Cloud Translation API übersetzt.

Workflows überwachen

Diese Seite enthält Informationen zum Überwachen von Workflowbereitstellungen und Ausführungen.

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

Fehlerlogs im Zusammenhang mit dem Deployment und Löschen eines Workflows finden Sie in der Google Cloud Console

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

Zur Seite "Workflows"
Klicken Sie auf den Namen des Workflows, um die zugehörige Seite Workflowdetails aufzurufen.
Klicken Sie auf den Tab Logs.
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 in der Google Cloud Console auf die Ergebnisse der Workflowausführung zugreifen oder über die gcloud CLI.

Console

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

Zur Seite "Workflows"
Klicken Sie auf den Namen des Workflows, um auf die Seite Workflow-Details zuzugreifen und so die Ausführungsergebnisse des Workflows anzuzeigen.
Wenn Sie Details zu einer bestimmten Ausführung aufrufen möchten, klicken Sie im Tab Ausführungen auf die Ausführungs-ID in der Liste, um die Seite Ausführungsdetails aufzurufen.

Hinweis:Sie benötigen eine Rolle, um auf die Seite Ausführungsdetails zuzugreifen die workflows.workflows.get, workflows.executions.get und workflows.stepEntries.list-Berechtigungen. Weitere Informationen finden Sie unter Workflows-Rollen und Berechtigungen und Zugriff verwalten
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 der aktuellen oder letzten Schritt des Workflows.
- Ausführungsbeginn: Zeitpunkt, an dem die Ausführung begonnen hat.
- Ausführungsende: Zeitpunkt, zu dem die Ausführung beendet wurde.
- Ausführungsdauer: Gesamtzeit, die während der Ausführung verstrichen ist. Dies kann ein Hinweis auf Netzwerkfehler oder Verbindungsprobleme sein.
- Workflowname: Der Name des Workflows.
- Workflowüberarbeitung: die aktuelle Version zum Zeitpunkt der Ausführung.
- Aufruflogebene: 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. In diesem Dokument Fehlermeldungen bei der Ausführung:
Um den Workflowausführungsverlauf als Liste von Schritteinträgen anzuzeigen, klicken Sie auf das Schritte. Weitere Informationen finden Sie unter Verlauf der Ausführungsschritte ansehen
Zum Aufrufen der Logs für eine Workflowausführung klicken Sie auf den Tab Logs.
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

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.

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 von einem try/except-Block, der die Ausführung fehlschlägt, und eine Fehlerzuordnung (ein JSON-Wörterbuch), die den Fehler beschreibt, zurückgegeben.

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

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

Es kann mehrere Tags geben. Um nach einem bestimmten Tag zu suchen, können Sie ein expression zurück. Beispiel:

${'SystemError' in e.tags}

Als String zurückgegebene Zugriffsfehlerdaten

Einige Connectors und HTTP APIs serialisieren Fehler als Strings, bevor sie zu den Fehlern. Mit den Standardbibliotheksfunktionen können Sie eine Nutzlast im ursprünglicher Fehler. Wenn Sie beispielsweise einen Fehlerstring in eine Karte 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 es gibt ein Verbindungsproblem während der Datenübertragung. Die Verbindung wird beendet, bevor eine vollständige Antwort empfangen wird, und eine Nachricht wird möglicherweise nicht an den Endpunkt gesendet. Wiederholungsversuche sind möglicherweise nicht idempotent.
ConnectionFailedError	Wird ausgelöst, wenn keine Verbindung mit dem API-Endpunkt hergestellt wird. für z. B. aufgrund eines falschen Domainnamens, Probleme bei der DNS-Auflösung oder anderen Problemen, Netzwerkprobleme. Wiederholungsversuche sind idempotent.
HttpError	Wird ausgelöst, wenn ein HTTP-Anfrage schlägt fehl mit einem HTTP-Fehlerstatus. Wenn diese Ausnahme ausgelöst wird, Antwort ist 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 das maximale die Tiefe überschritten wird, in der parallele Schritte verschachtelt werden können.
RecursionError	Wird ausgelöst, wenn der Interpreter erkennt, dass der Maximale Aufrufstacktiefe wurde überschritten.
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 mit der falschen Typ.
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 eine oder mehrere Zweige oder Iterationen auf einen unbehandelter Laufzeitfehler bis zu maximale Anzahl.
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 der folgenden Ausgabe ähnelt:

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

Kopieren Sie die Ausführungs-ID, um sie im nächsten Befehl zu verwenden.
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.
Um zu warten, bis die letzte Ausführung abgeschlossen ist, und dann das Ergebnis Ausführung abgeschlossen haben, geben Sie den folgenden Befehl ein:
```
gcloud workflows executions wait-last
```
Falls Sie in derselben gcloud-Sitzung bereits einen Ausführungsversuch unternommen haben, -Befehl wartet, bis der vorherige Ausführungsversuch abgeschlossen ist, und gibt dann die Ergebnisse der abgeschlossenen Ausführung. Wenn kein vorheriger Versuch vorhanden ist, gcloud gibt den folgenden Fehler zurück:
```
ERROR: (gcloud.workflows.executions.wait-last) [NOT FOUND] There are no cached executions available.
```
Um den Status der letzten Ausführung abzurufen, geben Sie den Parameter folgenden Befehl:
```
gcloud workflows executions describe-last
```
Falls Sie in derselben gcloud-Sitzung bereits einen Ausführungsversuch unternommen haben, -Befehl gibt 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 vom workflows.executions.list-Methode.

Sie können nach folgenden Feldern filtern:

createTime
disableOverflowBuffering
duration
endTime
executionId
label
startTime
state
stepName
workflowRevisionId

Um beispielsweise nach einem Label (labels."fruit":"apple") zu filtern, können Sie einen Die folgende API-Anfrage sieht ungefähr so aus:

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 der Ausführungen zurückgegeben; in diesem Fall 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 beliebige oder Ausnahmen, die erfasst werden oder einen Anruf stoppen.

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 die Anrufprotokollierung auf eine Workflow – Definition oder die Ausführung eines Workflows, können Sie den erforderlichen Logging-Level festlegen. Die Ebene des Ausführungsprotokolls Vorrang vor Workflowlogebenen, es sei denn, die Ausführungslogebene ist angegeben (Standardeinstellung); In diesem Fall gilt die Workflow-Logebene.

Das von Cloud Logging festgelegte Größenlimit für Logeinträge auch für die Anrufprotokollierung.

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. Bei Bedarf die Werte einer Karte protokollieren, verwenden Sie ${json.encode_to_string(myMap)}.
SEVERITY: Optional. Die Wichtigkeitsstufe des Logs zu erstellen. 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:

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

Zur Seite "Workflows"
Klicken Sie zum Aufrufen der Logs eines Workflows auf dessen Namen, um dessen Seite Details aufzurufen.
Klicken Sie zum Anzeigen der Logs auf Logs.
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:

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

Zum Log-Explorer
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.
Klicken Sie auf Abfrage ausführen.

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