

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
<a name="troubleshooting"></a>

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](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda).

**Topics**
+ [Allgemeine Probleme](#troubleshooting-general)
+ [Service-Integrationen](#troubleshooting-service-integrations)
+ [Aktivitäten](#troubleshooting-activities)
+ [Express-Workflows](#troubleshooting-express-workflows)

## Allgemeine Problembehebung
<a name="troubleshooting-general"></a>

### Ich kann keine Zustandsmaschine erstellen.
<a name="troubleshooting-general-unable-to-create"></a>

Die der Zustandsmaschine zugeordnete IAM-Rolle verfügt möglicherweise nicht über [ausreichende Berechtigungen](auth-and-access-control-sfn.md#auth-and-access-control-sfn.title). Ü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.
<a name="troubleshooting-general-unable-to-use-json"></a>

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](intrinsic-functions.md) 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.
<a name="troubleshooting-general-state-transition-delay"></a>

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 [Execution Metrics (Ausführungsmetriken)](procedure-cw-metrics.md#cloudwatch-step-functions-execution-metrics) Abschnitt der CloudWatch Metrikseite überprüfen.

### Wenn ich neue Standard-Workflow-Ausführungen starte, schlagen sie mit dem Fehler fehl. `ExecutionLimitExceeded`
<a name="troubleshooting-general-unable-to-start-standard-workflows"></a>

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 verwenden`OpenExecutionCount`, um zu verfolgen, wann Sie sich dem nähern, `OpenExecutionLimit` und Alarme einrichten, um Sie bei einem solchen Ereignis proaktiv zu benachrichtigen. `OpenExecutionCount`ist eine ungefähre Anzahl offener Workflows. Weitere Informationen finden Sie unter [Execution Metrics (Ausführungsmetriken)](procedure-cw-metrics.md#cloudwatch-step-functions-execution-metrics). 

### Ein Ausfall in einem Zweig in einem parallel Zustand führt dazu, dass die gesamte Ausführung fehlschlägt.
<a name="troubleshooting-general-branch-failure-causes-execution-failure"></a>

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](concepts-error-handling.md#error-handling-fallback-states.title) werden. 

## Fehlerbehebung bei Serviceintegrationen
<a name="troubleshooting-service-integrations"></a>

### Mein Job ist im Downstream-Service abgeschlossen, aber in Step Functions bleibt der Aufgabenstatus „In Bearbeitung“ oder ihr Abschluss verzögert sich.
<a name="troubleshooting-service-integrations-task-delay"></a>

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 unter[Zusätzliche Berechtigungen für Aufgaben, die .sync verwenden](service-integration-iam-templates.md#connect-iam-sync-async). 

### Ich möchte eine JSON-Ausgabe aus der Ausführung einer verschachtelten Zustandsmaschine zurückgeben.
<a name="troubleshooting-service-integrations-json-from-nested"></a>

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 verwenden`startExecution.sync:2`, um eine JSON-Ausgabe unter `Output` zurückzugeben. 

### Ich kann eine Lambda-Funktion nicht von einem anderen Konto aus aufrufen.
<a name="troubleshooting-service-integrations-invoke-lambda-from-account"></a>

**Zugriff auf die Lambda-Funktion mit kontoübergreifender Unterstützung**  
Wenn in Ihrer Region [kontoübergreifender Zugriff auf](concepts-access-cross-acct-resources.md) 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.

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

1. Ä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.

1. 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](tutorial-access-cross-acct-resources.md) 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“ des Aufgabenstatus](state-task.md#task-state-example-credentials)

**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:{{region}}:{{account-id}}:function:my-function"
         },
         "End":true
      }
   }
}
```

### Ich kann keine Task-Token sehen, die von Staaten übergeben wurden. `.waitForTaskToken`
<a name="troubleshooting-service-integrations-unable-to-see-task-tokens"></a>

 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
<a name="troubleshooting-activities"></a>

### Die Ausführung meiner Zustandsmaschine steckt in einem Aktivitätsstatus fest.
<a name="troubleshooting-activities-stuck-state-machine"></a>

Der Status einer Aktivitätsaufgabe wird erst gestartet, wenn Sie mithilfe der [GetActivityTask](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html)API-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](sfn-best-practices.md#sfn-stuck-execution). 

Wenn Ihr State-Machine bei diesem [ActivityScheduled](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ActivityScheduledEventDetails.html)Ereignis nicht weiterkommt, deutet dies darauf hin, dass Ihre Mitarbeiterflotte Probleme hat oder zu wenig skaliert ist. Sie sollten die [`ActivityScheduleTime`](procedure-cw-metrics.md#cloudwatch-step-functions-activity-metrics) 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.
<a name="troubleshooting-activity-worker-times-out"></a>

Worker verwenden die [GetActivityTask](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html)API-Aktion, um eine Aufgabe mit dem angegebenen Aktivitäts-ARN abzurufen, deren Ausführung durch eine laufende Zustandsmaschine geplant ist. `GetActivityTask`startet 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](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetActivityTask.html) Sekunden. 

## Fehlerbehebung bei Express-Workflows
<a name="troubleshooting-express-workflows"></a>

### Bei meiner Anwendung tritt ein Timeout auf, bevor ich eine Antwort von einem `[StartSyncExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartSyncExecution.html)` API-Aufruf erhalte.
<a name="troubleshooting-express-workflows-timeouts"></a>

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.
<a name="troubleshooting-express-workflows-no-execution-history"></a>

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](concepts-view-execution-details.md).

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