Probleme beheben

Hier finden Sie Strategien zur Fehlerbehebung, wenn Sie Probleme mit Workflows haben.

Bereitstellungsfehler

Wenn ein Workflow bereitgestellt wird, überprüft Workflows, ob der Quellcode fehlerfrei ist und der Sprachsyntax entspricht. Workflows geben einen Fehler zurück, wenn einer gefunden wird. Die häufigsten Arten von Bereitstellungsfehlern sind:

  • Verweis auf eine nicht definierte Variable, einen nicht definierten Schritt oder untergeordneten Workflow
  • Falsche Syntax
    • Falscher Einzug
    • Fehlende oder irrelevante {, }, ", - oder :

Der folgende Quellcode gibt beispielsweise einen Bereitstellungsfehler aus, da die Rückgabeanweisung auf die nicht definierte Variable varC verweist:

- step1:
    assign:
    - varA: "Hello"
    - varB: "World"
- step2:
    return: ${varC + varB}

Dieser falsche Quellcode wird in den folgenden Beispielen für die Google Cloud Console und Cloud SDK verwendet.

Console

Wenn ein Bereitstellungsfehler auftritt, wird in Workflows die Fehlermeldung in einem roten Banner über dem Quellcode des Workflows angezeigt:

Bereitstellungsfehler

Die Fehlermeldung kennzeichnet das Problem im Quellcode und gibt nach Möglichkeit den Ursprung des Fehlers an:

Could not deploy workflow: failed to build: error in step step2: error
evaluating return value: symbol 'varC' is neither a variable nor a
sub-workflow name (Code: 3)

gcloud

Wenn Sie den Befehl gcloud workflows deploy ausführen, gibt Workflows eine Fehlermeldung an die Befehlszeile zurück, wenn die Bereitstellung fehlschlägt. Die Fehlermeldung kennzeichnet das Problem im Quellcode und gibt nach Möglichkeit den Ursprung des Fehlers an:

ERROR: (gcloud.workflows.deploy) [INVALID_ARGUMENT] failed to build:
error in step step2: error evaluating return value: symbol 'varC' is neither
a variable nor a sub-workflow name

Bearbeiten Sie den Quellcode des Workflows, um das Problem zu beheben. Verweisen Sie in diesem Fall auf varA anstelle von varC.

Ausdrücke mit Doppelpunkten

In YAML können Ausdrücke mit Doppelpunkten unerwartetes Verhalten verursachen, wenn der Doppelpunkt als Definition einer Zuordnung interpretiert wird. Es ist zwar möglich, den Workflow bereitzustellen und auszuführen, aber dessen Ausgabe wird nicht wie erwartet ausfallen.

Wenn Sie einen Workflow mit der Google Cloud Console erstellen, kann der Workflow in der Cloud Console nicht visuell gerendert werden. Sie erhalten dann möglicherweise eine Warnung wie die folgende:

Warnung bei der Workflowerstellung

Sie können dieses Problem beheben, indem Sie den YAML-Ausdruck in einfache Anführungszeichen setzen:

Empfohlen: '${"a: " +string(a)}'

Nicht empfohlen: ${"a: " +string(a)}

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

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

  1. Öffnen Sie in der Cloud Console die Seite "Workflows":
    Zur Seite "Workflows"

  2. Klicken Sie auf den Namen des Workflows, um die Seite Workflow-Details 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 auf die Ergebnisse der Workflow-Ausführung in der Cloud Console oder mithilfe des Cloud SDK zugreifen.

Console

  1. Öffnen Sie in der Cloud Console die Seite "Workflows":
    Zur Seite "Workflows"

  2. Klicken Sie auf den Namen des Workflows, um auf die Seite Details zuzugreifen und so die Ausführungsergebnisse des Workflows anzuzeigen.

  3. Klicken Sie in der Liste auf die ID der Ausführung, um Details zu einer bestimmten Ausführung zu erhalten. Jede Ausführung hat folgende Informationen:

    • Ausführungsstatus: Gibt den Endstatus des Workflows an.
    • Ausführungsstart: Der Beginn der Ausführung.
    • Ausführungsende: Der Zeitpunkt, an 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.
    • 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 im Abschnitt Ausführungsfehlermeldungen.
    • Eingabe: Die Laufzeitargumente, die an den Workflow übergeben wurden, sofern vorhanden.
  4. Klicken Sie zum Anzeigen der Logs für alle Ausführungen eines Workflows auf Logs, um den Tab Logs zu öffnen.

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

    Ausführungslogs filtern

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: '{"message":"I love it so much!"}'
endTime: '2020-07-21T17:48:16.438109757Z'
error: 'in step "sentimentCheck": {"message":"KeyError: key not found: messaage","tags":["KeyError","LookupError"]}'
name: projects/********/locations/us-central1/workflows/sentimentCheck/executions/e8103c53-72ba-4af7-8996-f5a8337c2a7
startTime: '2020-10-12T17:48:16.342177302Z'
state: FAILED
workflowRevisionId: '000009-e6d'

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
  • workflowRevisionID: die aktuelle Überarbeitung zum Zeitpunkt der Ausführung

Fehlermeldungen zur Ausführung

Wenn ein Workflow während der Ausführung einen Fehler auslöst, der nicht in einem try/except-Block erfasst wird, schlägt die Ausführung fehl und eine Zuordnung, die den Fehler beschreibt, wird zurückgegeben.

Fehler, die während der Workflowausführung ausgelöst werden, enthalten Tags, anhand derer Sie die Fehlerursache ermitteln können. Die Bedeutung verschiedener Fehlertags wird in der folgenden Tabelle beschrieben.

Fehler-Tag Beschreibung
AuthError Wird ausgelöst, wenn Anmeldedaten für eine HTTP-Anfrage generiert werden.
ConnectionError Wird ausgelöst, wenn keine Verbindung zum API-Endpunkt hergestellt werden kann. Zum Beispiel aufgrund eines falschen Domainnamens, aufgrund von Problemen mit der DNS-Auflösung oder aufgrund anderer Netzwerkprobleme.
HttpError Wird ausgelöst, wenn eine HTTP-Anfrage mit einem HTTP-Fehlerstatus fehlschlägt. Wenn diese Ausnahme ausgelöst wird, ist die Antwort eine Zuordnung 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.
RecursionError Wird ausgelöst, wenn der Interpreter erkennt, dass die maximale Rekursionstiefe überschritten wurde.
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.
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.
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 lang andauernden 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.

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

  • Geben Sie den folgenden Befehl ein, um den Status des letzten Ausführungsversuchs zu prüfen:

    gcloud workflows executions wait-last
    

    Wenn Sie einen vorherigen Ausführungsversuch in derselben gcloud-Sitzung durchgeführt haben, wartet der Befehl auf den Abschluss des vorherigen Ausführungsversuchs und gibt dann die Ergebnisse zurück. Wenn 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 abgeschlossenen Ausführung abzurufen:

    gcloud workflows executions describe-last
    

    Wenn Sie in derselben gcloud-Sitzung einen vorherigen Ausführungsversuch ausgeführt haben, gibt der Befehl die Ergebnisse der letzten abgeschlossenen Ausführung zurück. 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.
    

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 einen Aufruf 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.

Sie können das Aufruf-Logging entweder mit der Google Cloud Console oder mit dem gcloud-Befehlszeilentool anwenden.

Console

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

  2. Wählen Sie auf der Seite "Workflows" einen Workflow aus, um dessen Detailseite aufzurufen.

  3. Klicken Sie auf der Seite Workflow-Details auf Ausführen.

  4. Optional können Sie auf der Seite Workflow ausführen die Ebene des Aufruf-Loggings festlegen, die Sie während der Ausführung des Workflows anwenden möchten.

    Wählen Sie in der Drop-down-Liste Logaufrufe eine der folgenden Optionen aus:

    • none: Kein Aufruf-Logging. Dies ist die Standardstufe.
    • log-all-calls: Alle Aufrufe von untergeordneten Workflows oder Bibliotheksfunktionen und deren Ergebnisse werden in Logs erfasst.
    • log-errors-only: Wird nur protokolliert, wenn ein Aufruf aufgrund einer Ausnahme beendet wird.
  5. Klicken Sie auf Ausführen.

gcloud

Geben Sie den folgenden Befehl ein, um einen Workflow auszuführen und auf den Abschluss der Ausführung zu warten:

gcloud workflows run WORKFLOW_NAME \
    --call-log-level=CALL_LOGGING_LEVEL \
    --data=DATA

Wenn Sie einen Workflow ausführen möchten, ohne auf den Abschluss des Ausführungsversuchs zu warten, geben Sie folgenden Befehl ein:

gcloud workflows execute WORKFLOW_NAME \
    --call-log-level=CALL_LOGGING_LEVEL \
    --data=DATA

Ersetzen Sie Folgendes:

  • WORKFLOW_NAME: Der Name des Workflows.
  • CALL_LOGGING_LEVEL: Optional. Ebene des Aufruf-Loggings, das während der Ausführung angewendet werden soll. Kann einer der folgenden Werte sein:
    • none: Kein Aufruf-Logging. Dies ist die Standardstufe.
    • log-all-calls: Alle Aufrufe von untergeordneten Workflows oder Bibliotheksfunktionen und deren Ergebnisse werden in Logs erfasst.
    • log-errors-only: Wird nur protokolliert, wenn ein Aufruf aufgrund einer Ausnahme beendet wird.
  • DATA: Optional. Laufzeitargumente für Ihren Workflow im JSON-Format.

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öchten, 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 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. Öffnen Sie in der Cloud Console die Seite Log-Explorer:
    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.

    Workflow-Logging

  3. Klicken Sie auf Abfrage ausführen.

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