Behebung von Problemen in Step Functions - AWS Step Functions
Allgemeine ProblemeService-IntegrationenAktivitätenExpress-Workflows

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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 Support-Fragen finden Sie auf AWS Wissenszentrum.

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, unter anderem für AWS Aufgaben zur Serviceintegration, 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 1.000.000 offenen Ausführungen AWS-Konto in jedem 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 RegelnAPIs, 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. Zum Beispiel für AWS Glue Service-Integration, anstatt EventBridge Regeln zu verwenden, glue:GetJobRun ruft Step Functions 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 den Abschluss von Aufgaben auswirken können, finden Sie unterZusätzliche Berechtigungen für Aufgaben, die das Run a Job-Muster verwenden.

Ich möchte eine JSON Ausgabe einer 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 auf den Abschluss der Nested-State-Machine, 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 kontoübergreifender Zugriff von AWS Ressourcen sind in Ihrer Region verfügbar. 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 IAM Zielrolle, 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 für den Aufruf von AWS Ressource.

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

Ein Beispiel finden Sie Kontenübergreifender Zugriff 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 aus mehreren Quellen übernimmt AWS-Konten. 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 unterBeispiele für das Feld „Anmeldeinformationen“ des Aufgabenstatus.

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

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

Verwenden Sie im Resource Feld des Task Bundesstaates die In-Parameter 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 GetActivityTaskAPIAktion 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 beim Warten auf ein Task-Token eine Zeitüberschreitung.

Worker verwenden die GetActivityTaskAPIAktion, um eine Aufgabe mit der angegebenen Aktivität abzurufenARN, deren Ausführung durch einen laufenden Zustandsmaschine geplant ist. GetActivityTaskstartet eine lange Abfrage, sodass der Dienst die HTTP Verbindung offen hält und reagiert, sobald eine Aufgabe verfügbar ist. 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 einen clientseitigen Socket mit einem Timeout von mindestens 65 Sekunden in der AWS SDKoder in dem Client, den Sie für den API Anruf verwenden.

Problembehandlung bei Express-Workflows

Bei meiner Anwendung wird das Timeout überschritten, bevor ich eine Antwort von einem StartSyncExecution API Anruf erhalte.

Konfigurieren Sie ein clientseitiges Socket-Timeout in AWS SDKoder den Client, den Sie für den API Anruf verwenden. 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 in AWS Step Functions. Stattdessen müssen Sie die CloudWatch Protokollierung aktivieren. Sobald die Protokollierung aktiviert ist, 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 desc

Um fehlgeschlagene und abgebrochene Ausführungen aufzulisten:

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