Fehlerbehandlung in Step Functions - AWS Step Functions

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.

Fehlerbehandlung in Step Functions

Bei jedem Zustand können Laufzeitfehler auftreten. Fehler können aus verschiedenen Gründen auftreten:

  • Probleme bei der Definition des Zustandsautomaten (z. B. keine übereinstimmende Regel in einem Choice-Zustand)

  • Aufgabenausfälle (z. B. eine Ausnahme in einer Lambda-Funktion)

  • Vorübergehende Probleme (z. B. Netzwerkpartitionsereignisse)

Standardmäßig gilt Folgendes: Wenn ein Zustand einen Fehler meldet, sorgt AWS Step Functions dafür, dass die Ausführung vollständig fehlschlägt.

Fehlernamen

Step Functions identifiziert Fehler in der Amazon States Language mithilfe von Zeichenfolgen, die alsFehlernamen. Die Amazon States Language definiert eine Gruppe von integrierten Zeichenfolgen, die bekannte Fehler benennen und deren Namen alle mit dem Namen beginnenStates.Präfix.

States.ALL

Ein Platzhalter, der mit jedem bekannten Fehlernamen übereinstimmt.

Anmerkung

Dieser Fehlertyp kann das nicht abfangenStates.DataLimitExceededTerminalfehlertyp und Laufzeitfehlertypen. Weitere Hinweise zu diesen Fehlertypen finden Sie unterStates.DataLimitExceededundStates.Runtime.

States.BranchFailed

Ein Zweig einesParallelStaat ist gescheitert.

States.DataLimitExceeded

EINStates.DataLimitExceededEine Ausnahme wird für Folgendes ausgelöst:

  • Wenn die Ausgabe eines Konnektors größer als das Payload-Größenkontingent ist.

  • Wenn die Ausgabe eines Status größer als das Kontingent für die Nutzlastgröße ist.

  • Wann, danachParametersBei der Verarbeitung ist die Eingabe eines Status größer als das Kontingent für die Nutzlastgröße.

Weitere Informationen zu Kontingenten finden Sie unterKontingente.

Anmerkung

Dies ist ein Terminalfehler, der nicht von derStates.ALLTyp des Fehlers.

States.HeartbeatTimeout

EINTaskZustand hat für längere Zeit keinen Herzschlag gesendet als imHeartbeatSecondsWert.

Anmerkung

Dieser Fehler ist nur innerhalb derCatchundRetryunterscheiden sich nicht.

States.IntrinsicFailure

Dieser Fehler tritt auf, wenn der Versuch, eine intrinsische Funktion innerhalb einer Payload-Vorlage aufzurufen, fehlschlägt.

States.NoChoiceMatched

Dieser Laufzeitfehler tritt auf, wenn einChoiceStatus stimmt die Eingabe nicht mit den in der Auswahlregel definierten Bedingungen überein, und es wurde kein Standardübergang angegeben.

States.ParameterPathFailure

Dieser Fehler tritt auf, wenn er sich innerhalb eines Bundesstaates befindetParametersFeld, ein Versuch, ein Feld zu ersetzen, dessen Name auf.$Die Verwendung eines Pfads schlägt fehl

States.Permissions

Ein Task-Zustand ist fehlgeschlagen, weil er nicht ausreichende Berechtigungen hatte, um den angegebenen Code auszuführen.

States.ResultPathMatchFailure

Die eines -ZustandesResultPathkann nicht auf die Eingabe angewendet werden, die der Status erhalten hat.

States.Runtime

Eine Ausführung ist aufgrund einer Ausnahme fehlgeschlagen, die nicht verarbeitet werden konnte. Oft werden diese durch Laufzeitfehler verursacht, z. B. durch den Versuch, InputPath oder OutputPath auf eine JSON-Nutzlast gleich Null anzuwenden. Ein States.Runtime-Fehler ist nicht abrufbar und führt immer dazu, dass die Ausführung fehlschlägt. Durch Wiederholen oder Auffangen für States.ALL werden keine States.Runtime-Fehler abgefangen.

States.TaskFailed

Ein Task-Zustand ist während der Ausführung fehlgeschlagen. Bei der Verwendung bei einem erneuten Versuch oder catchStates.TaskFailedfungiert als Platzhalter, der mit jedem bekannten Fehlernamen übereinstimmt, mit Ausnahme vonStates.Timeout.

States.Timeout

Ein Task-Zustand dauerte entweder länger als im Wert TimeoutSeconds festgelegt oder er hat für längere Zeit kein Heartbeat gesendet als im Wert HeartbeatSeconds festgelegt.

Zustände können Fehler mit anderen Namen melden. Diese dürfen allerdings nicht mit dem Präfix States. beginnen.

Stellen Sie als bewährte Methode sicher, dass der Produktionscode AWS Lambda-Service-Ausnahmen (Lambda.ServiceException und Lambda.SdkClientException) verarbeiten kann. Weitere Informationen finden Sie unter Behandeln von Lambda-Dienstausnahmen.

Anmerkung

Unbehandelte Fehler in Lambda werden gemeldet alsLambda.Unknownin der Fehlerausgabe. Dazu zählen out-of-memory Fehler und Funktions-Timeouts. Du kannst aufLambda.Unknown,States.ALL, oderStates.TaskFailedum mit diesen Fehlern umzugehen. Wenn Lambda die maximale Anzahl von Aufrufen erreicht, ist der FehlerLambda.TooManyRequestsException. Weitere Hinweise zu Lambda-Funktionsfehlern finden Sie unterFehlerbehandlung und automatische Wiederholungen in VersuchenimAWS LambdaEntwicklerhandbuch.

Erneut versuchen nach einem Fehler

Task- und Parallel-Zustände haben möglicherweise ein Feld mit der Bezeichnung Retry, deren Wert ein Array von Objekten sein muss, namens Retrier. Eine einzelner Retrier steht für eine bestimmte Anzahl von erneuten Versuchen, in der Regel in zunehmenden Zeitintervallen.

Anmerkung

Wiederholungen werden als Zustandsübergänge behandelt. Informationen dazu, wie sich Statusübergänge auf die Abrechnung auswirken, finden Sie unterStep Functions Preise.

Ein Retrier enthält die folgenden Felder.

ErrorEquals (Erforderlich)

Ein nicht leeres Array von Zeichenfolgen, die mit Fehlernamen übereinstimmen. Wenn ein Zustand einen Fehler meldet, scannt Step Functions durch die Retrier. Wenn der Fehlername in diesem Array erscheint, implementiert es die in diesem Retrier beschriebene Wiederholungsrichtlinie.

IntervalSeconds (Optional)

Eine Ganzzahl, die die Anzahl der Sekunden vor dem ersten erneuten Versuch angibt (1standardmäßig).IntervalSecondshat einen Maximalwert von99999999.

MaxAttempts (Optional)

Eine positive Ganzzahl, die die maximale Anzahl von erneuten Versuchen angibt (standardmäßig 3). Wenn der Fehler öfter als angegeben erneut auftritt, erfolgen keine erneuten Versuche und die normale Fehlerbehandlung wird fortgesetzt. Ein Wert von0gibt an, dass bei Fehlern nie erneute Versuche erfolgen.MaxAttemptshat einen Maximalwert von99999999.

BackoffRate (Optional)

Der Multiplikator, durch den das Intervall der erneuten Versuche gekennzeichnet ist durchIntervalSecondserhöht sich nach jedem Wiederholungsversuch. Standardmäßig ist derBackoffRateWert steigt um2.0.

Das folgende Beispiel für eineRetryführt 2 Wiederholungsversuche durch, wobei der erste Wiederholungsversuch nach 3 Sekunden und der zweite Wiederholungsversuch 4,5 Sekunden dauert. Das vollständige Beispiel finden Sie unterstepfunction-error-handling-examples-Repository auf GitHub.

"Retry": [ { "ErrorEquals": [ "States.Timeout" ], "IntervalSeconds": 3, "MaxAttempts": 2, "BackoffRate": 1.5 } ]

Der reservierte Name States.ALL, der im Feld ErrorEquals eines Retriers angezeigt wird, ist ein Platzhalter, der mit jedem Fehlernamen übereinstimmt. Er muss allein im Array ErrorEquals erscheinen und er muss im letzten Retrier im Array Retry erscheinen. Der NameStates.TaskFailedfungiert auch als Platzhalter und stimmt mit jedem Fehler überein, außerStates.Timeout.

In diesem Beispiel eines Retry-Felds werden alle Fehler mit Ausnahme von States.Timeout erneut versucht.

"Retry": [ { "ErrorEquals": [ "States.Timeout" ], "MaxAttempts": 0 }, { "ErrorEquals": [ "States.ALL" ] } ]

Komplexe Wiederholungen in Szenarien

Die Parameter eines Retriers gelten für alle Besuche des Retriers im Kontext einer einzelnen Zustandsausführung.

Beachten Sie den folgenden Task-Zustand.

"X": { "Type": "Task", "Resource": "arn:aws:states:us-east-1:123456789012:task:X", "Next": "Y", "Retry": [ { "ErrorEquals": [ "ErrorA", "ErrorB" ], "IntervalSeconds": 1, "BackoffRate": 2.0, "MaxAttempts": 2 }, { "ErrorEquals": [ "ErrorC" ], "IntervalSeconds": 5 } ], "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "Z" } ] }

Diese Aufgabe schlägt vier Mal in Folge fehl und gibt dabei diese Namen aus:ErrorA,ErrorB,ErrorC, undErrorB. Infolgedessen geschieht Folgendes:

  • Die ersten beiden Fehler stimmen mit dem ersten Retrier überein und verursachen Wartezeiten von einer und zwei Sekunden.

  • Die dritte Fehler stimmt mit dem zweiten Retrier überein und verursacht eine Wartezeit von fünf Sekunden.

  • Der vierte Fehler stimmt auch mit dem ersten Retrier überein. Es hat jedoch bereits sein Maximum von zwei Wiederholungen erreicht (MaxAttempts) für diesen speziellen Fehler. Daher schlägt dieser Retrier fehl und die Ausführung wird an denZStaat durch dieCatchfield.

Fallback-Zustände

Task,MapundParallel-Zustände können ein Feld namens habenCatch. Der Wert dieses Felds muss eine Reihe von Objekten sein, die als Catcher bekannt sind.

Ein Catcher enthält die folgenden Felder.

ErrorEquals (Erforderlich)

Ein nicht leeres Array von Zeichenfolgen, das mit Fehlernamen übereinstimmt, genauso angegeben wie bei dem Retrier-Feld desselben Namens.

Next (Erforderlich)

Eine Zeichenfolge, die mit genau einem der Zustandsnamen des Zustandsautomaten übereinstimmen muss.

ResultPath (Optional)

Ein Pfad, der festlegt, welche Eingabe an den im Feld Next angegebenen Zustand gesendet wird.

Wenn ein Zustand einen Fehler meldet und entweder keinRetry-Feld, oder erneute Versuche den Fehler nicht beheben können, scannt Step Functions die Catcher in der Reihenfolge, in der sie im Array aufgeführt sind. Wenn der Fehlername im Feld ErrorEquals eines Catchers erscheint, wechselt der Zustandsautomat in den Zustand, der im Feld Next genannt ist.

Der reservierte Name States.ALL, der im Feld ErrorEquals des Catchers erscheint, ist ein Platzhalter, der mit jedem Fehlernamen übereinstimmt. Er muss allein im Array ErrorEquals erscheinen und er muss im letzten Catcher im Array Catch erscheinen. Der NameStates.TaskFailedfungiert auch als Platzhalter und stimmt mit jedem Fehler überein, außerStates.Timeout.

Das folgende Beispiel für eineCatchFeldübergänge in den Zustand namensRecoveryStatewenn eine Lambda-Funktion eine nicht behandelte Java-Ausnahme ausgibt. Andernfalls wechselt das Feld in den Zustand EndState.

"Catch": [ { "ErrorEquals": [ "java.lang.Exception" ], "ResultPath": "$.error-info", "Next": "RecoveryState" }, { "ErrorEquals": [ "States.ALL" ], "Next": "EndState" } ]
Anmerkung

Jeder Catcher kann mehrere zu behandelnde Fehler angeben.

Fehlerausgabe

Wenn Step Functions in den Zustand übergeht, der in einem Catch-Namen angegeben ist, enthält das Objekt in der Regel das FeldCause. Der Wert dieses Felds ist eine für Menschen lesbare Beschreibung des Fehlers. Das Objekt ist als Fehlerausgabe bekannt.

In diesem Beispiel enthält der erste Catcher ein Feld ResultPath. Dies funktioniert ähnlich wie ein ResultPath-Feld im obersten Level eines Zustands, wodurch sich zwei Möglichkeiten ergeben:

  • Es nimmt die Ergebnisse der Ausführung des Zustands und überschreibt einen Teil der Eingabe des Zustands (oder die gesamte Eingabe des Zustands).

  • Es nimmt die Ergebnisse und fügt sie der Eingabe hinzu. Im Falle eines Fehlers, der von einem Catcher behandelt wird, ist das Ergebnis der Ausführung des Zustands die Fehlerausgabe.

Daher wird in diesem Beispiel für den ersten Catcher die Fehlerausgabe zur Eingabe als ein Feld mit dem Namen error-info hinzugefügt (wenn nicht bereits ein Feld mit diesem Namen in der Eingabe vorhanden ist). Dann wird die gesamte Eingabe an RecoveryState gesendet. Für den zweiten Catcher überschreibt die Fehlerausgabe die Eingabe, sodass nur die Fehlerausgabe an EndState gesendet wird.

Anmerkung

Wenn Sie das Feld ResultPath nicht angeben, wird es standardmäßig mit $ ausgefüllt, was die gesamte Eingabe auswählt und so überschreibt.

Wenn ein Staat beides hatRetryundCatch-Felder verwendet Step Functions alle geeigneten Retrier zuerst und wendet den übereinstimmenden Catcher-Übergang erst dann an, wenn die Wiederholungsrichtlinie zur Behebung des Fehlers fehlschlägt.

Verursachen von Payloads und Service-Integrationen

Ein Catcher gibt eine String-Payload als Ausgabe zurück. Bei der Arbeit mit Service-Integrationen wie Amazon Athena oderAWS CodeBuild, können Sie das konvertierenCauseZeichenfolge zu JSON. Das folgende Beispiel eines Pass-Status mit intrinsischen Funktionen zeigt, wie eine Cause-Zeichenfolge in JSON konvertiert wird.

"Handle escaped JSON with JSONtoString": { "Type": "Pass", "Parameters": { "Cause.$": "States.StringToJson($.Cause)" }, "Next": "Pass State with Pass Processing" },

Beispiele für die Verwendung von Retry und Catch

Bei den in den folgenden Beispielen definierten Zustandsautomaten wird davon ausgegangen, dass zwei Lambda-Funktionen vorliegen: eine, die immer fehlschlägt und eine, die lange genug wartet, damit es zu einem Timeout kommt, der im Zustandsautomaten definiert ist.

Dies ist eine Definition einer Node.js Lambda-Funktion, die stets fehlschlägt und die Meldung zurückgibterror. In den folgenden Beispielen für Zustandsautomaten wird diese Lambda-Funktion genanntFailFunction. Weitere Hinweise zur Erstellung einer Lambda-Funktion finden Sie unterSchritt 1: Erstellen einer Lambda-FunktionAbschnitts erstellt.

exports.handler = (event, context, callback) => { callback("error"); };

Dies ist eine Definition einer Node.js Lambda-Funktion, die sich für 10 Sekunden im Ruhezustand befindet. In den folgenden Beispielen für Zustandsautomaten wird diese Lambda-Funktion genanntsleep10.

Anmerkung

Denken Sie beim Erstellen dieser Lambda-Funktion in der Lambda-Konsole daran, die zu ändernZeitüberschreitungvalue in derErweiterte Einstellungenvon 3 Sekunden (Standard) bis 11 Sekunden.

exports.handler = (event, context, callback) => { setTimeout(function(){ }, 11000); };

Behandlung eines Fehlers mit Retry

Dieser Zustandsautomat verwendet ein Retry-Feld, das eine fehlgeschlagene Funktion erneut versucht und den Fehlernamen HandledError ausgibt. Die Funktion wird zweimal mit einem exponentiellem Backoff zwischen den Wiederholungen erneut versucht.

{ "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction", "Retry": [ { "ErrorEquals": ["HandledError"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } }

Diese Variante verwendet den vordefinierten FehlercodeStates.TaskFailed, der mit jedem Fehler übereinstimmt, den eine Lambda-Funktion ausgibt.

{ "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction", "Retry": [ { "ErrorEquals": ["States.TaskFailed"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } }
Anmerkung

Als bewährte Methode sollten Aufgaben, die auf eine Lambda-Funktion verweisen, Lambda-Dienstausnahmen verarbeiten. Weitere Informationen finden Sie unter Behandeln von Lambda-Dienstausnahmen.

Behandlung eines Fehlers mit Catch

In diesem Beispiel wird ein Catch-Feld verwendet. Wenn eine Lambda-Funktion einen Fehler ausgibt, wird der Fehler abgefangen und der Zustandsautomat wechselt in denfallbackZustand.

{ "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction", "Catch": [ { "ErrorEquals": ["HandledError"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } }

Diese Variante verwendet den vordefinierten FehlercodeStates.TaskFailed, der mit jedem Fehler übereinstimmt, den eine Lambda-Funktion ausgibt.

{ "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:FailFunction", "Catch": [ { "ErrorEquals": ["States.TaskFailed"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } }

Umgang mit einem Timeout mit Retry

Diese Zustandsmaschine verwendet eineRetryFeld, um es erneut zu versuchen aTaskZustand, bei dem ein Timeout basierend auf dem in angegebenen Timeout-Wert auftrittTimeoutSeconds. Der Aufruf der Lambda-Funktion in diesemTaskZustand wird zweimal mit einem exponentiellem Backoff zwischen den Wiederholungen erneut versucht.

{ "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:sleep10", "TimeoutSeconds": 2, "Retry": [ { "ErrorEquals": ["States.Timeout"], "IntervalSeconds": 1, "MaxAttempts": 2, "BackoffRate": 2.0 } ], "End": true } } }

Umgang mit einem Timeout mit Catch

In diesem Beispiel wird ein Catch-Feld verwendet. Wenn ein Timeout aufgetreten ist, wechsel der Zustandsautomat in den Zustand fallback.

{ "Comment": "A Hello World example of the Amazon States Language using an AWS Lambda function", "StartAt": "HelloWorld", "States": { "HelloWorld": { "Type": "Task", "Resource": "arn:aws:lambda:us-east-1:123456789012:function:sleep10", "TimeoutSeconds": 2, "Catch": [ { "ErrorEquals": ["States.Timeout"], "Next": "fallback" } ], "End": true }, "fallback": { "Type": "Pass", "Result": "Hello, AWS Step Functions!", "End": true } } }
Anmerkung

Sie können die Statuseingabe und den Fehler beibehalten, indem Sie ResultPath verwenden. Siehe Verwenden von ResultPath, um Fehler und Eingabe in einem Catch einzufügen.