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.
Verwenden der Lambda-Laufzeit-API für benutzerdefinierte Laufzeiten
AWS Lambda bietet eine HTTP-API für benutzerdefinierte Laufzeiten, um Aufrufereignisse von Lambda zu empfangen und Antwortdaten innerhalb der Lambda-Ausführungsumgebung zurückzusenden. Dieser Abschnitt enthält die API-Referenz für die Lambda-Laufzeiten-API.
Lambda Managed Instances unterstützen gleichzeitige Anfragen
Lambda Managed Instances verwenden dieselbe Laufzeit-API wie Lambda-Funktionen (Standard). Der Hauptunterschied besteht darin, dass Managed Instances gleichzeitige /response Anfragen /next und Anfragen bis zum konfigurierten Limit akzeptieren können. AWS_LAMBDA_MAX_CONCURRENCY Dadurch können mehrere Aufrufe gleichzeitig in einer einzigen Ausführungsumgebung verarbeitet werden. Weitere Informationen zu verwalteten Instanzen finden Sie unter. Grundlegendes zur Lambda Managed Instance-Ausführungsumgebung
Die OpenAPI-Spezifikation für die Laufzeit-API-Version 2018-06-01 ist unter runtime-api.zip verfügbar.
Um eine API-Anforderungs-URL zu erstellen, rufen Laufzeitumgebungen den API-Endpunkt aus der AWS_LAMBDA_RUNTIME_API-Umgebungsvariablen ab, fügen die API-Version und dann den gewünschten Ressourcenpfad hinzu.
Beispiel Anforderung
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next"
API-Methoden
Nächster Aufruf
Pfad – /runtime/invocation/next
Methode – GET
Die Laufzeit sendet diese Meldung an Lambda, um ein Aufrufereignis anzufordern. Der Antworttext enthält die Nutzlast aus dem Aufruf. Dabei handelt es sich um ein JSON-Dokument, das Ereignisdaten aus dem Funktionsauslöser enthält. Die Antwort-Header enthalten zusätzliche Daten zum Aufruf.
Antwort-Header
-
Lambda-Runtime-Aws-Request-Id— Das Ereignis, das den Funktionsaufruf ausgelöst hat. Ereignisquellen stellen Anforderungs-IDs bereit, oder Lambda generiert sie automatisch bei der Aufnahme. Eine einzelne Anforderungs-ID kann zu mehreren Aufrufversuchen führen. Verwenden Sie sie im URL-Pfad, wenn Sie die Antwort oder den Fehler senden.Beispiel,
8476a536-e9f4-11e8-9739-2dfe598c3fcd. -
Lambda-Runtime-Deadline-Ms– Das Datum, an dem eine Zeitüberschreitung für die Funktion eintritt (in Unix-Millisekunden).Beispiel,
1542409706888. -
Lambda-Runtime-Invoked-Function-Arn– Der ARN der/des Lambda-Funktion, -Version oder -Alias, die/der im Aufruf angegeben ist.Beispiel,
arn:aws:lambda:us-east-2:123456789012:function:custom-runtime. -
Lambda-Runtime-Trace-Id– Der AWS X-Ray -Nachverfolgungs-Header.Beispiel,
Root=1-5bef4de7-ad49b0e87f6ef6c87fc2e700;Parent=9a9197af755a6419;Sampled=1. -
Lambda-Runtime-Client-Context— Bei Aufrufen aus dem AWS Mobile SDK Daten über die Client-Anwendung und das Gerät. -
Lambda-Runtime-Cognito-Identity— Bei Aufrufen aus dem AWS Mobile SDK Daten über den Amazon Cognito-Identitätsanbieter. -
Lambda-Runtime-Invocation-Id— Eine eindeutige Kennung für diesen Aufrufversuch.
Legen Sie kein Timeout für die GET-Anfrage fest, da sich die Antwort verzögern könnte. Zwischen dem Zeitpunkt, an dem Lambda die Laufzeit bootet, und dem Zeitpunkt, zu dem die Laufzeit ein Ereignis zurückgibt, wird der Laufzeitprozess möglicherweise für mehrere Sekunden eingefroren.
Eine Anforderungs-ID (Lambda-Runtime-Aws-Request-Id) identifiziert ein eindeutiges Ereignis. Anforderungs-IDs werden von Ereignisquellen bereitgestellt oder von Lambda bei der Aufnahme automatisch generiert. Verwenden Sie die Anforderungs-ID im URL-Pfad, wenn Sie die Antwort oder den Fehler senden.
Eine Aufruf-ID (Lambda-Runtime-Invocation-Id) steht für einen einzelnen Aufrufversuch für ein Ereignis. Eine einzelne Anforderungs-ID kann zu mehreren Aufrufversuchen führen, von denen jeder seine eigene eindeutige Aufruf-ID hat. Lambda verwendet jede Aufruf-ID genau einmal und verwendet sie nie wieder. Gibt diesen Wert erneut an und ruft auf. /response /error Der Header ist aus Gründen der Abwärtskompatibilität mit vorhandenen Laufzeiten optional. Wenn Sie ihn weglassen, wird keine Ablehnung ausgelöst. Lambda lehnt nur ab, 400 InvalidInvocationId wenn der Header vorhanden ist, sein Wert aber nicht mit dem aktiven Aufruf übereinstimmt.
Der Nachverfolgungs-Header enthält die Nachverfolgungs-ID, die ID des übergeordneten Segments und die Erfassungsentscheidung Wenn die Anforderung erfasst wurde, wurde die Anforderung von Lambda oder einem Upstream-Service erfasst. Die Laufzeit sollte die _X_AMZN_TRACE_ID auf den Wert des Headers festlegen. Das X-Ray SDK liest dies, um die IDs abzurufen und zu bestimmen, ob die Anfrage verfolgt werden soll.
Aufrufantwort
Pfad – /runtime/invocation/AwsRequestId/response
Methode – POST
Nachdem die Funktion bis zum Abschluss ausgeführt wurde, schickt die Laufzeitumgebung eine Aufrufantwort an Lambda. Im Fall synchroner Aufrufe schickt Lambda die Antwort anschließend an den Client zurück.
Anfordern von Headern
Lambda-Runtime-Invocation-Id— Gibt den Wert zurück, der von empfangen wurde/next. Lambda lehnt die Anfrage ab, 400 InvalidInvocationId wenn der Wert nicht mit dem aktiven Aufruf übereinstimmt.
Beispiel Erfolg für Anforderung
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9 INVOCATION_ID=<value from Lambda-Runtime-Invocation-Id response header> curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "SUCCESS" --header "Lambda-Runtime-Invocation-Id: $INVOCATION_ID"
Initialisierungsfehler
Wenn die Funktion einen Fehler zurückgibt oder die Laufzeit während der Initialisierung auf einen Fehler stößt, verwendet die Laufzeit diese Methode, um den Fehler an Lambda zu melden.
Pfad – /runtime/init/error
Methode – POST
Header
Lambda-Runtime-Function-Error-Type – Der Fehlertyp, auf den die Laufzeit gestoßen ist. Dieser Header ist optional. Lambda akzeptiert jeden Zeichenkettenwert. Wir empfehlen, das Format zu verwenden<Category.Reason>, in dem Kategorie Runtime oder ist Function und Reason mit einem Großbuchstaben beginnt. Beispiel:
Runtime.NoSuchHandlerRuntime.APIKeyNotFoundRuntime.ConfigInvalidRuntime.BeforeSnapshotError(für) SnapStartRuntime.UnknownReason
Werte, die diesem Muster nicht entsprechen, werden auf Runtime.Unknown oder Function.Unknown normalisiert.
Body-Parameter
ErrorRequest – Informationen über den Fehler. Erforderlich: Nein
Dieses Feld ist ein JSON-Objekt mit der folgenden Struktur:
{ errorMessage: string (text description of the error), errorType: string, stackTrace: array of strings }
Beachten Sie, dass Lambda jeden Wert für errorType akzeptiert.
Das folgende Beispiel zeigt eine Lambda-Funktionsfehlermeldung, in der die Funktion die im Aufruf bereitgestellten Ereignisdaten nicht analysieren konnte.
Beispiel Funktionsfehler
{ "errorMessage" : "Error parsing event data.", "errorType" : "InvalidEventDataException", "stackTrace": [ ] }
Antworttextparameter:
StatusResponse– Zeichenfolge. Statusinformationen, gesendet mit 202 Antwortcodes.ErrorResponse— Zusätzliche Fehlerinformationen, die zusammen mit den Fehlerantwortcodes gesendet werden. ErrorResponse enthält einen Fehlertyp und eine Fehlermeldung.
Antwortcodes
-
202 – Akzeptiert
-
403 – Verboten
-
500 — Containerfehler. Non-recoverable Bundesstaat. Die Laufzeit sollte umgehend beendet werden.
Beispiel Initialisierungsfehleranforderung
ERROR="{\"errorMessage\" : \"Failed to load function.\", \"errorType\" : \"InvalidFunctionException\"}" curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/init/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
Aufruffehler
Wenn die Funktion einen Fehler zurückgibt oder die Laufzeit auf einen Fehler stößt, verwendet die Laufzeitumgebung diese Methode, um den Fehler an Lambda zu melden.
Pfad – /runtime/invocation/AwsRequestId/error
Methode – POST
Header
Lambda-Runtime-Function-Error-Type – Der Fehlertyp, auf den die Laufzeit gestoßen ist. Erforderlich: Nein.
Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, aber wir empfehlen ein Format von <category.reason>. Beispiel:
Runtime.NoSuchHandler
Runtime.APIKeyNotFound
Runtime.ConfigInvalid
Runtime.UnknownReason
Lambda-Runtime-Invocation-Id— Gibt den Wert zurück, der von empfangen wurde/next. Lambda lehnt die Anfrage ab, 400 InvalidInvocationId wenn der Wert nicht mit dem aktiven Aufruf übereinstimmt.
Body-Parameter
ErrorRequest – Informationen über den Fehler. Erforderlich: Nein
Dieses Feld ist ein JSON-Objekt mit der folgenden Struktur:
{ errorMessage: string (text description of the error), errorType: string, stackTrace: array of strings }
Beachten Sie, dass Lambda jeden Wert für errorType akzeptiert.
Das folgende Beispiel zeigt eine Lambda-Funktionsfehlermeldung, in der die Funktion die im Aufruf bereitgestellten Ereignisdaten nicht analysieren konnte.
Beispiel Funktionsfehler
{ "errorMessage" : "Error parsing event data.", "errorType" : "InvalidEventDataException", "stackTrace": [ ] }
Antworttextparameter:
StatusResponse– Zeichenfolge. Statusinformationen, gesendet mit 202 Antwortcodes.ErrorResponse— Zusätzliche Fehlerinformationen, die zusammen mit den Fehlerantwortcodes gesendet werden. ErrorResponse enthält einen Fehlertyp und eine Fehlermeldung.
Antwortcodes
-
202 – Akzeptiert
-
400 – Ungültige Anfrage
-
403 – Verboten
-
500 — Containerfehler. Non-recoverable Bundesstaat. Die Laufzeit sollte umgehend beendet werden.
Beispiel Fehler für Anforderung
REQUEST_ID=156cb537-e2d4-11e8-9b34-d36013741fb9 ERROR="{\"errorMessage\" : \"Error parsing event data.\", \"errorType\" : \"InvalidEventDataException\"}" curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/error" -d "$ERROR" --header "Lambda-Runtime-Function-Error-Type: Unhandled"
After-Restore (gilt nur für SnapStart)
Pfad – /runtime/restore/next
Methode – GET
Nachdem die Pre-Snapshot-Hooks abgeschlossen sind, wird die Runtime aufgerufen. GET /runtime/restore/next Dies ist ein Blockierungsaufruf im Iterator-Stil, ähnlich dem/runtime/invocation/next, der Lambda signalisiert, dass die Laufzeit bereit ist, einen Snapshot der Ausführungsumgebung zu erstellen. Die Anforderung wird blockiert, bis Lambda die Ausführungsumgebung anhand eines Snapshots wiederherstellt, und gibt dann eine HTTP 200-Antwort mit leerem Text zurück.
Header
Keine Header erforderlich.
Antwortcodes
-
200 — Lambda hat die Ausführungsumgebung wiederhergestellt. Führen Sie Hooks nach der Wiederherstellung aus. Der Antworttext ist leer.
-
403 — Verboten. Die Laufzeit befindet sich nicht in einem Zustand, der dies zulässt
/restore/next(z. B. hat die Laufzeit/invocation/nextoder bereits aufgerufen/restore/next). -
404 — SnapStart ist für diese Funktion nicht aktiviert.
-
500 – Container-Fehler. Die Ausführungsumgebung befindet sich in einem nicht wiederherstellbaren Zustand. Beenden Sie den Laufzeitprozess.
Erforderliche Syntax
GET /2018-06-01/runtime/restore/next HTTP/1.1 Host: ${AWS_LAMBDA_RUNTIME_API}
Antwortsyntax
HTTP/1.1 200 OK Content-Length: 0
Anmerkung
Legen Sie für diese (oder jede andere) Runtime-API-Anforderung keinen clientseitigen Socket- oder Lesezeitlimit fest. Dies ist ein blockierender Aufruf im Iterator-Stil. Lambda friert die Ausführungsumgebung ein, während die Anforderung geöffnet ist. Die Anfrage kann während der gesamten Lebensdauer des Snapshots (möglicherweise Tage, Wochen oder länger) geöffnet bleiben, ohne dass die Verbindung vom Lambda-Service als inaktiv betrachtet wird.
Wiederherstellungsfehler (gilt nur für SnapStart)
Wenn ein Hook nach der Wiederherstellung fehlschlägt oder die Laufzeit während der Wiederherstellung auf einen Fehler stößt, verwendet die Runtime diese Methode, um den Fehler an Lambda zu melden. Lambda schlägt den In-Flight-Aufruf fehl und zerstört die Ausführungsumgebung.
Pfad – /runtime/restore/error
Methode – POST
Header
Lambda-Runtime-Function-Error-Type – Der Fehlertyp, auf den die Laufzeit gestoßen ist. Dieser Header ist optional. Lambda akzeptiert jeden Zeichenkettenwert. Wir empfehlen, das Format zu verwenden<Category.Reason>, in dem Kategorie Runtime oder ist Function und Reason mit einem Großbuchstaben beginnt (z. B.Runtime.AfterRestoreError). Werte, die diesem Muster nicht entsprechen, werden auf oder normalisiert. Runtime.Unknown Function.Unknown
Antwortcodes
-
202 — Akzeptiert. Der Antworttext ist
{"status":"OK"}. Die Laufzeit sollte den Prozess beenden. -
403 — Verboten. Die Laufzeit befindet sich nicht in einem Zustand, der dies zulässt
/restore/error(sie wurde beispielsweise nicht aufgerufen)./restore/next -
404 — SnapStart ist für diese Funktion nicht aktiviert.
-
500 – Container-Fehler. Die Ausführungsumgebung befindet sich in einem nicht wiederherstellbaren Zustand. Beenden Sie den Laufzeitprozess.
Beispiel Beispielanforderung
POST /2018-06-01/runtime/restore/error HTTP/1.1 Host: ${AWS_LAMBDA_RUNTIME_API} Lambda-Runtime-Function-Error-Type: Runtime.AfterRestoreError
Beispiel Beispielantwort
HTTP/1.1 202 Accepted Content-Type: application/json {"status":"OK"}