Verwenden der Lambda Extensions API zum Erstellen von Erweiterungen

Lambda-Funktionsautoren verwenden Erweiterungen, um Lambda in ihre bevorzugten Tools zur Überwachung, Beobachtbarkeit, Sicherheit und Governance zu integrieren. Funktionsautoren können Erweiterungen von AWS, AWS Partnern und Open-Source-Projekten verwenden. Weitere Informationen zur Verwendung von Erweiterungen finden Sie unter Einführung in AWS Lambda Erweiterungen im AWS Compute-Blog. In diesem Abschnitt wird beschrieben, wie Sie die Lambda-Erweiterungs-API, den Lebenszyklus der Lambda-Ausführungsumgebung und die Lambda-Erweiterungs-API-Referenz verwenden.

Als Erweiterungsautor können Sie die Lambda-Erweiterungs-API verwenden, um sich tief in die Lambda-Ausführungsumgebung zu integrieren. Ihre Erweiterung kann sich für Lebenszyklusereignisse für Funktions- und Ausführungsumgebung registrieren. Als Reaktion auf diese Ereignisse können Sie neue Prozesse starten, Logik ausführen und alle Phasen des Lambda-Lebenszyklus steuern und an ihnen teilnehmen: Initialisierung, Aufruf und Herunterfahren. Darüber hinaus können Sie die Laufzeitprotokoll-API verwenden, um einen Stream von Protokollen zu erhalten.

Eine Erweiterung wird als unabhängiger Prozess in der Ausführungsumgebung ausgeführt und kann weiterhin ausgeführt werden, nachdem der Funktionsaufruf vollständig verarbeitet wurde. Da Erweiterungen als Prozesse ausgeführt werden, können Sie diese in einer anderen Sprache als die Funktion schreiben. Es wird empfohlen, Erweiterungen mit einer kompilierten Sprache zu implementieren. In diesem Fall handelt es sich bei der Erweiterung um eine eigenständige Binärdatei, die mit unterstützten Laufzeiten kompatibel ist. Alle Lambda-Laufzeiten unterstützen Erweiterungen. Wenn Sie eine nicht kompilierte Sprache verwenden, stellen Sie sicher, dass Sie eine kompatible Laufzeit in die Erweiterung aufnehmen.

Lambda unterstützt auch interne Erweiterungen. Eine interne Erweiterung wird als separater Thread im Laufzeitprozess ausgeführt. Die Laufzeit startet und stoppt die interne Erweiterung. Eine alternative Möglichkeit zur Integration in die Lambda-Umgebung ist die Verwendung sprachspezifischer Umgebungsvariablen und Wrapper-Skripte. Sie können diese nutzen, um die Laufzeitumgebung zu konfigurieren und das Startup-Verhalten des Laufzeitprozesses zu verändern.

Sie können einer Funktion auf zwei Arten Erweiterungen hinzufügen. Bei einer Funktion, die als .zip-Dateiarchivbereitgestellt wird, stellen Sie Ihre Erweiterung als Ebenebereit. Bei einer Funktion, die als Container-Image definiert ist, fügen Sie die Erweiterungen Ihrem Container-Image hinzu.

Anmerkung

Beispiele für Erweiterungen und Wrapper-Skripte finden Sie unter AWS Lambda Erweiterungen im AWS GitHub Samples-Repository.

Lebenszyklus der Lambda-Ausführungsumgebung

Der Lebenszyklus der Ausführungsumgebung umfasst die folgenden Phasen:

• Init: In dieser Phase erstellt oder hebt Lambda eine Ausführungsumgebung mit den konfigurierten Ressourcen auf, lädt den Code für die Funktion und alle Ebenen herunter, initialisiert alle Erweiterungen, initialisiert die Laufzeit und führt dann den Initialisierungscode der Funktion (der Code außerhalb des Haupthandlers) aus. Die Phase Init erfolgt entweder während des ersten Aufrufs oder vor Funktionsaufrufen, wenn Sie die bereitgestellte Parallelität aktiviert haben.

  Die Init-Phase ist in drei Unterphasen unterteilt: Extension init, Runtime init und Function init. Diese Unterphasen stellen sicher, dass alle Erweiterungen und die Laufzeit ihre Einrichtungs-Aufgaben abschließen, bevor der Funktionscode ausgeführt wird.

• Invoke: In dieser Phase ruft Lambda den Funktionshandler auf. Nachdem die Funktion vollständig ausgeführt wurde, bereitet sich Lambda auf die Verarbeitung eines weiteren Funktionsaufrufs vor.

• Shutdown: Diese Phase wird ausgelöst, wenn die Lambda-Funktion für einen bestimmten Zeitraum keine Aufrufe empfängt. In dieser Shutdown-Phase fährt Lambda die Laufzeit herunter, warnt die Erweiterungen, damit sie sauber beendet werden können und entfernt dann die Umgebung. Lambda sendet ein Shutdown-Ereignis an jede Erweiterung, das der Erweiterung mitteilt, dass die Umgebung beendet wird.

Jede Phase beginnt mit einem Ereignis von Lambda zur Laufzeit und zu allen registrierten Erweiterungen. Die Laufzeit und jede Erweiterung zeigen den Abschluss durch Senden einer Next-API-Anfrage an. Lambda friert die Ausführungsumgebung ein, wenn jeder Prozess abgeschlossen ist und keine ausstehenden Ereignisse vorhanden sind.

Themen

• Init-Phase
• Invoke-Phase
• Shutdown-Phase
• Berechtigungen und Konfiguration
• Fehlerbehandlung
• Fehlerbehebung bei Erweiterungen

Init-Phase

Während dieser Extension init-Phase muss sich jede Erweiterung bei Lambda registrieren, um Ereignisse zu empfangen. Lambda verwendet den vollständigen Dateinamen der Erweiterung, um zu überprüfen, ob die Erweiterung die Bootstrap-Sequenz abgeschlossen hat. Daher muss jeder Register-API-Aufruf den Lambda-Extension-Name-Header mit dem vollständigen Dateinamen der Erweiterung enthalten.

Sie können bis zu 10 Erweiterungen für eine Funktion registrieren. Dieses Limit wird durch den Register-API-Aufruf erzwungen.

Nachdem jede Erweiterung registriert ist, startet Lambda die Runtime init-Phase. Der Laufzeitprozess ruft functionInit auf, um die Function init-Phase zu starten.

Die Init-Phase wird nach der Laufzeit abgeschlossen und jede registrierte Erweiterung zeigt den Abschluss durch Senden einer Next-API-Anforderung an.

Anmerkung

Erweiterungen können ihre Initialisierung an jedem beliebigen Punkt in der Init-Phase abschließen.

Invoke-Phase

Wenn eine Lambda-Funktion als Antwort auf eine Next-API-Anforderung aufgerufen wird, sendet Lambda ein Invoke-Ereignis an die Laufzeitumgebung und an jede Erweiterung, die für das Invoke-Ereignis registriert ist.

Während des Aufrufs werden externe Erweiterungen parallel zur Funktion ausgeführt. Sie werden auch weiter ausgeführt, nachdem die Funktion abgeschlossen ist. Auf diese Weise können Sie Diagnoseinformationen erfassen oder Protokolle, Metriken und Traces an einen Ort Ihrer Wahl senden.

Nachdem Erhalt der Funktionsantwort von der Laufzeitumgebung wird die Antwort von Lambda an den Client zurückgegeben, selbst wenn noch Erweiterungen ausgeführt werden.

Die Invoke-Phase endet nach der Laufzeit und alle Erweiterungen signalisieren durch Senden einer Next-API-Anforderung, dass sie ausgeführt wurden.

Ereignisnutzlast: Das Ereignis, das an die Laufzeit (und die Lambda-Funktion) gesendet wird, trägt die gesamte Anforderung, Header (z. B. RequestId) und Nutzlast. Das an jede Erweiterung gesendete Ereignis enthält Metadaten, die den Ereignisinhalt beschreiben. Dieses Lebenszyklusereignis umfasst den Typ des Ereignisses, die Zeit, zu der das Timeout der Funktion (deadlineMs), das requestId, die aufgerufene Funktion, den Amazon Resource Name (ARN) der aufgerufenen Funktion und die Tracing-Header.

Erweiterungen, die auf den Funktionsereigniskörper zugreifen möchten, können ein In-Laufzeit-SDK verwenden, das mit der Erweiterung kommuniziert. Funktionsentwickler verwenden das In-Laufzeit-SDK, um die Nutzlast an die Erweiterung zu senden, wenn die Funktion aufgerufen wird.

Hier ist ein Beispiel für eine Nutzlast:

{
    "eventType": "INVOKE",
    "deadlineMs": 676051,
    "requestId": "3da1f2dc-3222-475e-9205-e2e6c6318895",
    "invokedFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:ExtensionTest",
    "tracing": {
        "type": "X-Amzn-Trace-Id",
        "value": "Root=1-5f35ae12-0c0fec141ab77a00bc047aa2;Parent=2be948a625588e32;Sampled=1"
    }
 }          

Begrenzung der Dauer: Die Timeout-Einstellung der Funktion begrenzt die Dauer der gesamten Invoke-Phase. Wenn Sie beispielsweise die Zeitüberschreitung für die Funktion auf 360 Sekunden festlegen, müssen die Funktion und alle Erweiterungen innerhalb von 360 Sekunden abgeschlossen werden. Beachten Sie, dass es keine unabhängige Post-Invoke-Phase gibt. Die Dauer ist die Gesamtzeit, die Ihre Laufzeit und alle Aufrufe Ihrer Erweiterungen benötigen. Sie wird erst berechnet, wenn die Funktion und alle Erweiterungen vollständig ausgeführt wurden.

Performance impact and extension overhead (Leistungsauswirkungen und Erweiterungsoverhead): Erweiterungen können sich auf die Funktionsleistung auswirken. Als Autor einer Erweiterung haben Sie die Kontrolle über die Auswirkungen Ihrer Erweiterung auf die Leistung. Ein Beispiel: Eine Erweiterung führt rechenintensive Operationen aus. In diesem Fall könnten Sie feststellen, dass die Dauer des Aufrufs Ihrer Funktion zunimmt, da Erweiterung und Funktion sich CPU-Ressourcen teilen. Wenn Ihre Erweiterung umfangreiche Operationen ausführt, nachdem der Funktionsaufruf abgeschlossen ist, verlängert sich die Dauer des Funktionsaufrufs, da die Invoke-Phase fortgesetzt wird, bis alle Erweiterungen signalisieren, dass sie abgeschlossen sind.

Anmerkung

Lambda weist CPU-Leistung im Verhältnis zur Speichereinstellung der Funktion zu. Bei niedrigeren Speichereinstellungen wird möglicherweise eine erhöhte Ausführungs- und Initialisierungsdauer angezeigt, da die Funktions- und Erweiterungsprozesse um die gleichen CPU-Ressourcen konkurrieren. Erhöhen Sie die Speichereinstellung, um die Ausführungs- und Initialisierungsdauer zu reduzieren.

Um die Leistungsbeeinträchtigung zu identifizieren, die durch Erweiterungen in der Invoke-Phase verursacht wird, gibt Lambda die PostRuntimeExtensionsDuration-Metrik aus. Diese Metrik misst die kumulative Zeit, die zwischen der Next-Laufzeit-API-Anforderung und der letzten Next-Erweiterungs-API-Anforderung vergeht. Verwenden Sie die MaxMemoryUsed-Metrik, um die Zunahme des verwendeten Speichers zu messen. Weitere Informationen zu Funktionsmetriken finden Sie unter Arbeiten mit Lambda-Funktionsmetriken.

Funktionsentwickler können verschiedene Versionen ihrer Funktionen nebeneinander ausführen, um die Auswirkungen einer bestimmten Erweiterung zu verstehen. Wir empfehlen, dass Erweiterungsautoren den erwarteten Ressourcenverbrauch veröffentlichen, um Funktionsentwicklern die Auswahl einer geeigneten Erweiterung zu erleichtern.

Shutdown-Phase

Wenn Lambda dabei ist, die Laufzeit zu beenden, sendet es ein Shutdown an die Laufzeitumgebung und dann an jede registrierte externe Erweiterung. Erweiterungen können diese Zeit für abschließende Bereinigungsaufgaben verwenden. Das Shutdown-Ereignis wird als Antwort auf eine Next-API-Anforderung gesendet.

Duration Limit (Begrenzung der Dauer): Die maximale Dauer der Shutdown-Phase hängt von der Konfiguration der registrierten Erweiterungen ab:

• 0 ms – Eine Funktion ohne registrierte Erweiterungen

• 500 ms – Eine Funktion mit einer registrierten internen Erweiterung

• 2.000 ms – Eine Funktion mit einer oder mehreren registrierten externen Erweiterungen

Für eine Funktion mit externen Erweiterungen reserviert Lambda bis zu 300 ms (500 ms für eine Laufzeit mit einer internen Erweiterung) für den Laufzeitprozess, um ein ordnungsgemäßes Abschalten durchführen zu können. Lambda weist den Rest der 2.000-ms-Grenze für das Herunterfahren externer Erweiterungen zu.

Wenn die Laufzeit oder eine Erweiterung nicht innerhalb des Limits auf das Shutdown-Ereignis reagiert, beendet Lambda den Prozess mit einem SIGKILL-Signal.

Event Payload (Ereignis-Nutzlast): Das Shutdown-Ereignis enthält den Grund für das Abschalten und die verbleibende Zeit in Millisekunden.

Das shutdownReason beinhaltet die folgenden Werte:

• SPINDOWN – Normale Abschaltung

• TIMEOUT – Zeitlimit abgelaufen

• FAILURE – Fehlerzustand, etwa ein out-of-memory-Ereignis

{ 
  "eventType": "SHUTDOWN", 
  "shutdownReason": "reason for shutdown", 
  "deadlineMs": "the time and date that the function times out in Unix time milliseconds" 
}        
      

Berechtigungen und Konfiguration

Erweiterungen werden in derselben Ausführungsumgebung wie die Lambda-Funktion ausgeführt. Erweiterungen teilen auch Ressourcen mit der Funktion, wie CPU, Arbeitsspeicher und /tmp-Datenträgerspeicher. Darüber hinaus verwenden Erweiterungen dieselbe AWS Identity and Access Management (IAM-) Rolle und denselben Sicherheitskontext wie die Funktion.

File system and network access permissions (Dateisystem- und Netzwerkzugriffsberechtigungen): Erweiterungen werden in demselben Dateisystem- und Netzwerk-Namespace wie die Funktionslaufzeit ausgeführt. Dies bedeutet, dass Erweiterungen mit dem zugehörigen Betriebssystem kompatibel sein müssen. Wenn für eine Erweiterung zusätzliche ausgehende Netzwerkverkehrsregeln erforderlich sind, müssen Sie diese Regeln auf die Funktionskonfiguration anwenden.

Anmerkung

Da das Funktionscode-Verzeichnis schreibgeschützt ist, können Erweiterungen den Funktionscode nicht ändern.

Environment variables (Umgebungsvariablen): Erweiterungen können auf die Umgebungsvariablen der Funktion zugreifen, mit Ausnahme der folgenden Variablen, die für den Laufzeitprozess spezifisch sind:

• AWS_EXECUTION_ENV

• AWS_LAMBDA_LOG_GROUP_NAME

• AWS_LAMBDA_LOG_STREAM_NAME

• AWS_XRAY_CONTEXT_MISSING

• AWS_XRAY_DAEMON_ADDRESS

• LAMBDA_RUNTIME_DIR

• LAMBDA_TASK_ROOT

• _AWS_XRAY_DAEMON_ADDRESS

• _AWS_XRAY_DAEMON_PORT

• _HANDLER

Fehlerbehandlung

Initialization failures (Initialisierungsfehler): Wenn eine Erweiterung fehlschlägt, startet Lambda die Ausführungsumgebung neu, um konsistentes Verhalten zu erzwingen und Fail Fast für Erweiterungen zu unterstützen. Für einige Kunden müssen die Erweiterungen auch geschäftskritische Anforderungen wie Protokollierung, Sicherheit, Governance und Telemetrieerfassung erfüllen.

Invoke failures (Aufruffehler) (z. B. kein Speicher mehr, Funktions-Timeout): Da Erweiterungen Ressourcen mit der Laufzeit gemeinsam nutzen, sind sie eventuell von Speichermangel betroffen. Wenn die Laufzeit ausfällt, nehmen alle Erweiterungen und die Laufzeit selbst an der Shutdown-Phase teil. Darüber hinaus wird die Laufzeitumgebung entweder automatisch als Teil des aktuellen Aufrufs oder über einen verzögerten Neuinitialisierungsmechanismus neu gestartet.

Wenn bei Invoke ein Fehler (z. B. eine Funktions-Zeitüberschreitung oder Laufzeitfehler) auftritt, führt der Lambda-Service einen Neustart durch. Der Reset verhält sich wie ein Shutdown-Ereignis. Zuerst beendet Lambda die Laufzeit und sendet dann ein Shutdown-Ereignis an jede registrierte externe Erweiterung. Das Ereignis enthält den Grund für das Abschalten. Wenn diese Umgebung für einen neuen Aufruf verwendet wird, werden die Erweiterung und die Laufzeit als Teil des nächsten Aufrufers neu initialisiert.

Eine ausführlichere Erläuterung des vorherigen Diagramms finden Sie unter Fehler während der Aufrufphase.

Erweiterungsprotokolle: Lambda sendet die Protokollausgabe von Erweiterungen an CloudWatch Logs. Lambda generiert auch ein zusätzliches Protokollereignis für jede Erweiterung während Init. Das Protokollereignis zeichnet den Namen und die Registrierungseinstellung (Ereignis, Konfiguration) bei Erfolg oder die Fehlerursache bei einem Fehler auf.

Fehlerbehebung bei Erweiterungen

• Wenn eine Register-Anforderung fehlschlägt, stellen Sie sicher, dass der Lambda-Extension-Name-Header im Register-API-Aufruf den vollständigen Dateinamen der Erweiterung enthält.

• Wenn die Register-Anforderung für eine interne Erweiterung fehlschlägt, stellen Sie sicher, dass sich die Anforderung nicht für das Shutdown-Ereignis registriert.

Erweiterungs-API-Referenz

Die OpenAPI-Spezifikation für die Erweiterungs-API Version 2020-01-01 finden Sie hier: extensions-api.zip

Sie können den Wert des API-Endpunkts aus der AWS_LAMBDA_RUNTIME_API-Umgebungsvariablen abrufen. Um eine Register-Anforderung zu senden, verwenden Sie das Präfix 2020-01-01/ vor jedem API-Pfad. Zum Beispiel:

http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension/register 

API-Methoden

• Registrieren
• Next
• Init-Fehler
• Exit-Fehler

Registrieren

Während Extension init müssen sich alle Erweiterungen bei Lambda registrieren, um Ereignisse zu empfangen. Lambda verwendet den vollständigen Dateinamen der Erweiterung, um zu überprüfen, ob die Erweiterung die Bootstrap-Sequenz abgeschlossen hat. Daher muss jeder Register-API-Aufruf den Lambda-Extension-Name-Header mit dem vollständigen Dateinamen der Erweiterung enthalten.

Interne Erweiterungen werden vom Laufzeitprozess gestartet und gestoppt, sodass sie sich nicht für das Shutdown-Ereignis registrieren können.

Pfad – /extension/register

Methode – POST

Anfordern von Headern

• Lambda-Extension-Name – Der vollständige Dateiname der Erweiterung. Erforderlich: ja Typ: Zeichenkette

• Lambda-Extension-Accept-Feature – Verwenden Sie dies, um optionale Erweiterungsfunktionen bei der Registrierung anzugeben. Erforderlich: Nein. Typ: durch Kommas getrennte Zeichenfolge. Funktionen, die mit dieser Einstellung angegeben werden können:

  • accountId – Falls angegeben, enthält die Registrierungsantwort der Erweiterung die Konto-ID, die der Lambda-Funktion zugeordnet ist, für die Sie die Erweiterung registrieren.

Anfrage von Textparametern

• events – Array der Ereignisse, für die die Registrierung durchgeführt werden soll. Erforderlich: Nein Typ: Zeichenfolge-Array Gültige Zeichenfolgen: INVOKE, SHUTDOWN.

Antwort-Header

• Lambda-Extension-Identifier – Generierte eindeutige Agent-ID (UUID-Zeichenfolge), die für alle nachfolgenden Anforderungen erforderlich ist.

Antwortcodes

• 200 – Antworttext enthält den Funktionsnamen, die Funktionsversion und den Namen des Handlers.

• 400 – Ungültige Anfrage

• 403 – Verboten

• 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Erweiterung sollte umgehend beendet werden.

Beispielanfragetext

{
    'events': [ 'INVOKE', 'SHUTDOWN']
}             

Beispielantworttext

{
    "functionName": "helloWorld",
    "functionVersion": "$LATEST",
    "handler": "lambda_function.lambda_handler"
}               

Beispiel-Antworttext mit optionaler AccountID-Funktion

{
    "functionName": "helloWorld",
    "functionVersion": "$LATEST",
    "handler": "lambda_function.lambda_handler",
    "accountId": "123456789012"
}

Next

Erweiterungen senden eine Next-API-Anforderung für den Empfang des nächsten Ereignisses, bei dem es sich um ein Invoke-Ereignis oder ein Shutdown-Ereignis handeln kann. Der Antworttext enthält die Nutzlast, bei der es sich um ein JSON-Dokument handelt, das Ereignisdaten enthält.

Die Erweiterung sendet eine Next-API-Anforderung, um zu signalisieren, dass sie bereit ist, neue Ereignisse zu empfangen. Das ist ein blockierender Aufruf.

Legen Sie für den GET-Aufruf kein Timeout fest, da die Erweiterung für einen bestimmten Zeitraum angehalten werden kann, bis ein Ereignis zurückgegeben werden soll.

Pfad – /extension/event/next

Methode – GET

Anfordern von Headern

• Lambda-Extension-Identifier – Eindeutiger Bezeichner für die Erweiterung (UUID-Zeichenfolge). Erforderlich: ja Typ: UUID-Zeichenfolge

Antwort-Header

• Lambda-Extension-Event-Identifier – Eindeutiger Bezeichner für das Ereignis (UUID-Zeichenfolge).

Antwortcodes

• 200 – Die Antwort enthält Informationen über das nächste Ereignis (EventInvoke oder EventShutdown).

• 403 – Verboten

• 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Erweiterung sollte umgehend beendet werden.

Init-Fehler

Die Erweiterung verwendet diese Methode, um einen Initialisierungsfehler an Lambda zu melden. Rufen Sie sie auf, wenn die Erweiterung nach der Registrierung nicht initialisiert werden kann. Nachdem der Fehler von Lambda empfangen wurde, sind keine weiteren API-Aufrufe erfolgreich. Die Erweiterung sollte beendet werden, nachdem sie die Antwort von Lambda erhalten hat.

Pfad – /extension/init/error

Methode – POST

Anfordern von Headern

• Lambda-Extension-Identifier – Eindeutiger Bezeichner für die Erweiterung. Erforderlich: ja Typ: UUID-Zeichenfolge

• Lambda-Extension-Function-Error-Type – Der Fehlertyp, auf den die Erweiterung gestoßen ist. Erforderlich: ja Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, aber wir empfehlen ein Format von <category.reason>. Beispielsweise:

  • Erweiterung. NoSuchHandler

  • Erweiterung.API gefunden KeyNot

  • Erweiterung. ConfigInvalid

  • Erweiterung. UnknownReason

Anfrage von Textparametern

• 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": [ ]
}      

Antwortcodes

• 202 – Akzeptiert

• 400 – Ungültige Anfrage

• 403 – Verboten

• 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Erweiterung sollte umgehend beendet werden.

Exit-Fehler

Die Erweiterung verwendet diese Methode, um Lambda vor dem Beenden einen Fehler zu melden. Rufen Sie sie auf, wenn ein unerwarteter Fehler auftritt. Nachdem der Fehler von Lambda empfangen wurde, sind keine weiteren API-Aufrufe erfolgreich. Die Erweiterung sollte beendet werden, nachdem sie die Antwort von Lambda erhalten hat.

Pfad – /extension/exit/error

Methode – POST

Anfordern von Headern

• Lambda-Extension-Identifier – Eindeutiger Bezeichner für die Erweiterung. Erforderlich: ja Typ: UUID-Zeichenfolge

• Lambda-Extension-Function-Error-Type – Der Fehlertyp, auf den die Erweiterung gestoßen ist. Erforderlich: ja Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, aber wir empfehlen ein Format von <category.reason>. Beispielsweise:

  • Erweiterung. NoSuchHandler

  • Erweiterung.API gefunden KeyNot

  • Erweiterung. ConfigInvalid

  • Erweiterung. UnknownReason

Anfrage von Textparametern

• 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": [ ]
}      

Antwortcodes

• 202 – Akzeptiert

• 400 – Ungültige Anfrage

• 403 – Verboten

• 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Erweiterung sollte umgehend beendet werden.