Behebung von Problemen in Step Functions

Wenn Sie bei der Arbeit mit Step Functions auf Schwierigkeiten stoßen, verwenden Sie die folgenden Ressourcen zur Problembehandlung.

Die folgenden Themen enthalten Hinweise zur Fehlerbehebung bei Fehlern und Problemen, die im Zusammenhang mit Step Functions Functions-Zustandsmaschinen, Serviceintegrationen, Aktivitäten und Workflows auftreten können. Wenn Sie auf ein Problem stoßen, das hier nicht aufgeführt ist, können Sie die Schaltfläche Feedback auf dieser Seite verwenden, um es zu melden.

Weitere Tipps zur Fehlerbehebung und Antworten auf häufig gestellte Supportfragen finden Sie im AWS - Wissenscenter.

Allgemeine Problembehebung

Ich kann keine Zustandsmaschine erstellen.

Die der Zustandsmaschine zugeordnete IAM-Rolle verfügt möglicherweise nicht über ausreichende Berechtigungen. Überprüfen Sie die Berechtigungen der IAM-Rolle, einschließlich für AWS Serviceintegrationsaufgaben, X-Ray und CloudWatch Protokollierung. Für .sync Aufgabenstatus sind zusätzliche Berechtigungen erforderlich.

Ich kann a nicht verwenden, JsonPath um auf die Ausgabe der vorherigen Aufgabe zu verweisen.

Für a JsonPath muss ein JSON-Schlüssel enden mit.$. Das bedeutet, dass a JsonPath nur in einem Schlüssel-Wert-Paar verwendet werden kann. Wenn Sie eine JsonPath andere Stelle verwenden möchten, z. B. ein Array, können Sie systeminterne Funktionen verwenden. Sie könnten beispielsweise etwas Ähnliches wie das Folgende verwenden:

Ausgabe von Aufgabe A:

{
    "sample": "test"
}

Aufgabe B:

{
    "JsonPathSample.$": "$.sample"
}

Es gab eine Verzögerung bei den Zustandsübergängen.

Bei Standard-Workflows ist die Anzahl der Zustandsübergänge begrenzt. Wenn Sie das Limit für den Statusübergang überschreiten, verzögert Step Functions Statusübergänge, bis der Bucket für das Kontingent gefüllt ist. Die Drosselung der Grenzwerte für Statusübergänge kann überwacht werden, indem Sie die ExecutionThrottled Metrik im Ausführungsmetriken Abschnitt der CloudWatch Metrikseite überprüfen.

Wenn ich neue Standard-Workflow-Ausführungen starte, schlagen sie mit dem Fehler fehl. ExecutionLimitExceeded

Step Functions hat ein Limit von jeweils AWS-Konto 1.000.000 offenen Ausführungen. AWS-Region Wenn Sie dieses Limit überschreiten, gibt Step Functions einen ExecutionLimitExceeded Fehler aus. Dieses Limit gilt nicht für Express Workflows. Sie können den verwendenOpenExecutionCount, um zu verfolgen, wann Sie sich dem nähern, OpenExecutionLimit und Alarme einrichten, um Sie bei einem solchen Ereignis proaktiv zu benachrichtigen. OpenExecutionCountist eine ungefähre Anzahl offener Workflows. Weitere Informationen finden Sie unter Ausführungsmetriken.

Ein Ausfall in einem Zweig in einem parallel Zustand führt dazu, dass die gesamte Ausführung fehlschlägt.

Dies ist ein erwartetes Verhalten. Um Fehler bei der Verwendung eines parallel Zustands zu vermeiden, konfigurieren Sie Step Functions so, dass Fehler, die von jedem Zweig ausgelöst werden, abgefangen werden.

Fehlerbehebung bei Serviceintegrationen

Mein Job ist im Downstream-Service abgeschlossen, aber in Step Functions bleibt der Aufgabenstatus „In Bearbeitung“ oder ihr Abschluss verzögert sich.

Bei .sync Serviceintegrationsmustern verwendet Step Functions EventBridge Regeln APIs, Downstream-Regeln oder eine Kombination aus beidem, um den Status des Downstream-Jobs zu ermitteln. Für einige Dienste erstellt Step Functions keine EventBridge Regeln zur Überwachung. Für die AWS Glue Serviceintegration glue:GetJobRun ruft Step Functions beispielsweise statt EventBridge Regeln auf. Aufgrund der Häufigkeit von API-Aufrufen besteht ein Unterschied zwischen der Abschlusszeit der Downstream-Aufgabe und der Abschlusszeit der Step Functions Functions-Aufgabe. Step Functions benötigt IAM-Berechtigungen, um die EventBridge Regeln zu verwalten und Aufrufe an den Downstream-Service zu tätigen. Weitere Informationen darüber, wie sich unzureichende Berechtigungen für Ihre Ausführungsrolle auf die Ausführung von Aufgaben auswirken können, finden Sie unterZusätzliche Berechtigungen für Aufgaben, die .sync verwenden.

Ich möchte eine JSON-Ausgabe aus der Ausführung einer verschachtelten Zustandsmaschine zurückgeben.

Es gibt zwei synchrone Step Functions-Dienstintegrationen für Step Functions: startExecution.sync und. startExecution.sync:2 Beide warten, bis der Nested-State-Machine den Vorgang abgeschlossen hat, geben aber unterschiedliche Formate zurück. Output Sie können verwendenstartExecution.sync:2, um eine JSON-Ausgabe unter Output zurückzugeben.

Ich kann eine Lambda-Funktion nicht von einem anderen Konto aus aufrufen.

Zugriff auf die Lambda-Funktion mit kontoübergreifender Unterstützung

Wenn in Ihrer Region kontoübergreifender Zugriff auf AWS Ressourcen verfügbar ist, verwenden Sie die folgende Methode, um eine Lambda-Funktion von einem anderen Konto aus aufzurufen.

Gehen Sie wie folgt vor, um eine kontoübergreifende Ressource in Ihren Workflows aufzurufen:

1. Erstellen Sie eine IAM-Rolle in dem Zielkonto, das die Ressource enthält. Diese Rolle gewährt dem Quellkonto, das die Zustandsmaschine enthält, Berechtigungen für den Zugriff auf die Ressourcen des Zielkontos.

2. Geben Sie in der Definition des Task Status die IAM-Zielrolle an, die von der Zustandsmaschine übernommen werden soll, bevor die kontoübergreifende Ressource aufgerufen wird.

3. Ändern Sie die Vertrauensrichtlinie in der Ziel-IAM-Rolle, sodass das Quellkonto diese Rolle vorübergehend übernehmen kann. Die Vertrauensrichtlinie muss den Amazon-Ressourcennamen (ARN) der Zustandsmaschine enthalten, die im Quellkonto definiert ist. Definieren Sie außerdem die entsprechenden Berechtigungen in der IAM-Zielrolle, um die AWS Ressource aufzurufen.

4. Aktualisieren Sie die Ausführungsrolle des Quellkontos so, dass sie die erforderliche Berechtigung für die Übernahme der Ziel-IAM-Rolle enthält.

Ein Beispiel finden Sie Zugreifen auf kontenübergreifende AWS Ressourcen in Step Functions in den Tutorials.

Anmerkung

Sie können Ihren Zustandsmaschine so konfigurieren, dass er eine IAM-Rolle für den Zugriff auf Ressourcen von mehreren AWS-Kontenübernimmt. Eine Zustandsmaschine kann jedoch jeweils nur eine IAM-Rolle übernehmen.

Ein Beispiel für eine Task Statusdefinition, die eine kontoübergreifende Ressource spezifiziert, finden Sie unter. Beispiele für das Feld Anmeldeinformationen für den Aufgabenstatus

Zugriff auf die Lambda-Funktion ohne kontoübergreifende Unterstützung

Wenn der kontoübergreifende Zugriff auf AWS Ressourcen in Ihrer Region nicht verfügbar ist, verwenden Sie die folgende Methode, um eine Lambda-Funktion von einem anderen Konto aus aufzurufen.

Verwenden Sie im Resource Feld für den Task Bundesstaat die Parameter in arn:aws:states:::lambda:invoke und übergeben Sie sie. FunctionArn Die IAM-Rolle, die der Zustandsmaschine zugeordnet ist, muss über die richtigen Berechtigungen verfügen, um kontoübergreifende Lambda-Funktionen aufzurufen:. lambda:invokeFunction

{  
   "StartAt":"CallLambda",
   "States":{  
      "CallLambda":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke",
         "Parameters":{  
            "FunctionName":"arn:aws:lambda:us-west-2:123456789012:function:my-function"
         },
         "End":true
      }
   }
}

Ich kann keine Task-Token sehen, die von Staaten übergeben wurden. .waitForTaskToken

Im Parameters Feld für den Task Bundesstaat müssen Sie ein Aufgabentoken übergeben. Sie könnten beispielsweise etwas Ähnliches wie den folgenden Code verwenden.

{  
   "StartAt":"taskToken",
   "States":{  
      "taskToken":{  
         "Type":"Task",
         "Resource":"arn:aws:states:::lambda:invoke.waitForTaskToken",
         "Parameters":{  
            "FunctionName":"get-model-review-decision",
            "Payload":{  
               "token.$":"$$.Task.Token"
            },
         },
         "End":true
      }
   }
}

Anmerkung

Sie können versuchen, es .waitForTaskToken mit jeder API-Aktion zu verwenden. Einige haben jedoch APIs keine geeigneten Parameter.

Aktivitäten zur Fehlerbehebung

Die Ausführung meiner Zustandsmaschine steckt in einem Aktivitätsstatus fest.

Der Status einer Aktivitätsaufgabe beginnt erst, wenn Sie mithilfe der GetActivityTaskAPI-Aktion ein Aufgabentoken abfragen. Es hat sich bewährt, ein Timeout auf Aufgabenebene hinzuzufügen, um eine hängengebliebene Ausführung zu vermeiden. Weitere Informationen finden Sie unter Verwendung von Timeouts zur Vermeidung von festgefahrenen Step Functions Functions-Workflow-Ausführungen.

Wenn Ihr State-Machine bei diesem ActivityScheduledEreignis nicht weiterkommt, deutet dies darauf hin, dass bei Ihrer Activity Worker-Flotte Probleme aufgetreten sind oder dass sie zu wenig skaliert ist. Sie sollten die ActivityScheduleTime CloudWatch Messwerte überwachen und einen Alarm einstellen, wenn diese Zeit länger wird. Definieren Sie jedoch ein Timeout auf State-Machine-Ebene, um bei der Ausführung von Zustandsmaschinen, bei denen der Activity Status nicht in den ActivityStarted Status übergeht, ein Timeout zu erreichen. Geben Sie dazu am Anfang der Zustandsmaschinen-Definition ein TimeoutSeconds Feld außerhalb des Feldes an. States

Mein Activity Worker hat eine Zeitüberschreitung, während er auf ein Task-Token wartet.

Worker verwenden die GetActivityTaskAPI-Aktion, um eine Aufgabe mit dem angegebenen Aktivitäts-ARN abzurufen, deren Ausführung durch eine laufende Zustandsmaschine geplant ist. GetActivityTaskstartet eine lange Abfrage, sodass der Dienst die HTTP-Verbindung geöffnet hält und antwortet, sobald eine Aufgabe verfügbar wird. Die maximale Zeit, in der der Dienst die Anfrage hält, bevor er antwortet, beträgt 60 Sekunden. Wenn innerhalb von 60 Sekunden keine Aufgabe verfügbar ist, gibt die Umfrage eine taskToken mit einer Nullzeichenfolge zurück. Um dieses Timeout zu vermeiden, konfigurieren Sie im AWS SDK oder in dem Client, den Sie für den API-Aufruf verwenden, einen clientseitigen Socket mit einem Timeout von mindestens 65 Sekunden.

Fehlerbehebung bei Express-Workflows

Meine Anwendung läuft ab, bevor sie eine Antwort von einem StartSyncExecution API-Aufruf erhält.

Konfigurieren Sie im AWS SDK oder Client, den Sie für den API-Aufruf verwenden, ein clientseitiges Socket-Timeout. Um eine Antwort zu erhalten, muss das Timeout einen Wert haben, der höher ist als die Dauer der Express Workflow-Ausführungen.

Ich kann den Ausführungsverlauf zur Behebung von Express Workflow-Fehlern nicht einsehen.

Express Workflows zeichnet den Ausführungsverlauf nicht auf AWS Step Functions. Stattdessen müssen Sie die CloudWatch Protokollierung aktivieren. Nachdem die Protokollierung aktiviert wurde, können Sie CloudWatch Logs Insights-Abfragen verwenden, um Ihre Express Workflow-Ausführungen zu überprüfen. Sie können den Ausführungsverlauf für Express Workflow-Ausführungen auch in der Step Functions Functions-Konsole anzeigen, wenn Sie auf der Registerkarte Ausführungen auf die Schaltfläche Aktivieren klicken. Weitere Informationen finden Sie unter Ausführungsdetails in der Step Functions-Konsole anzeigen.

Um Ausführungen nach Dauer aufzulisten:

fields ispresent(execution_arn) as exec_arn
| filter exec_arn 
| filter type in ["ExecutionStarted", "ExecutionSucceeded", "ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]
| stats latest(type) as status, 
  tomillis(earliest(event_timestamp)) as UTC_starttime, 
  tomillis(latest(event_timestamp)) as UTC_endtime, 
  latest(event_timestamp) - earliest(event_timestamp) as duration_in_ms  by execution_arn
| sort duration_in_ms desc

Um fehlgeschlagene und abgebrochene Ausführungen aufzulisten:

fields ispresent(execution_arn) as isRes | filter type in ["ExecutionFailed", "ExecutionAborted", "ExecutionTimedOut"]