Lambda-Telemetrie-API - AWS Lambda

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.

Lambda-Telemetrie-API

Über die Telemetry API können Ihre Erweiterungen Telemetriedaten direkt von Lambda empfangen. Während der Initialisierung und des Aufrufs von Funktionen erfasst Lambda automatisch Telemetriedaten wie Protokolle, Plattform-Metriken und Plattform-Ablaufverfolgungen. Über die Telemetry API können Erweiterungen diese Telemetriedaten direkt von Lambda in nahezu Echtzeit abrufen.

Sie können die Telemetrie-Streams für Ihre Lambda-Erweiterungen direkt in der Lambda-Ausführungsumgebung abonnieren. Nach dem Abonnement sendet Lambda automatisch alle Telemetriedaten an Ihre Erweiterungen. Sie können diese Daten dann verarbeiten, filtern und an Ihr bevorzugtes Ziel senden, z. B. einen Amazon Simple Storage Service (Amazon S3)-Bucket oder einen Drittanbieter von Beobachtbarkeits-Tools.

Das folgende Diagramm zeigt, wie die Extension API und die Telemetry API Erweiterungen von der Ausführungsumgebung aus mit Lambda verbinden. Die Runtime API verbindet zudem die Laufzeit und Funktion mit Lambda.

Die Erweiterungs-, Telemetrie- und Laufzeit-APIs, die Lambda mit Prozessen in der Ausführungsumgebung verbinden.
Wichtig

Die Lambda-Telemetrie-API ersetzt die Lambda-Protokoll-API. Die Protokoll-API bleibt zwar voll funktionsfähig, wir empfehlen jedoch, in Zukunft nur die Telemetrie-API zu verwenden. Sie können Ihre Erweiterung für einen Telemetrie-Stream entweder über die Telemetrie-API oder die Protokoll-API abonnieren. Nach dem Abonnieren mithilfe einer dieser APIs gibt jeder Versuch, über die andere API zu abonnieren, einen Fehler zurück.

Erweiterungen können die Telemetrie-API verwenden, um drei verschiedene Telemetrie-Streams zu abonnieren:

  • Plattformtelemetrie – Protokolle, Metriken und Ablaufverfolgungen, die Ereignisse und Fehler im Zusammenhang mit dem Laufzeitlebenszyklus der Ausführungsumgebung, dem Erweiterungslebenszyklus und Funktionsaufrufen beschreiben.

  • Funktionsprotokolle – Benutzerdefinierte Protokolle, die der Lambda-Funktionscode generiert.

  • Erweiterungsprotokolle – Benutzerdefinierte Protokolle, die der Lambda-Erweiterungscode generiert.

Anmerkung

Lambda sendet Protokolle und Metriken an CloudWatchund Ablaufverfolgungen an X-Ray (wenn Sie die Nachverfolgung aktiviert haben), auch wenn eine Erweiterung Telemetrie-Streams abonniert.

Erstellen von Erweiterungen mithilfe der Telemetrie-API

Lambda-Erweiterungen werden als unabhängige Prozesse in der Ausführungsumgebung ausgeführt. Erweiterungen können nach Abschluss des Funktionsaufrufs weiter ausgeführt werden. Da Erweiterungen separate Prozesse sind, können Sie diese in einer anderen Sprache als dem Funktionscode schreiben. Es wird empfohlen, Erweiterungen mit einer kompilierten Sprache wie Golang oder Rust zu schreiben. Auf diese Weise ist die Erweiterung eine in sich geschlossene Binärdatei, die mit jeder unterstützten Laufzeitumgebung kompatibel sein kann.

Das folgende Diagramm zeigt einen vierstufigen Prozess zum Erstellen einer Erweiterung, die Telemetriedaten mithilfe der Telemetrie-API empfängt und verarbeitet.

Registrieren Sie Ihre Erweiterung, erstellen Sie einen Listener, abonnieren Sie einen Stream und erhalten Sie anschließend Telemetriedaten.

Hier sind die einzelnen Schritte im Detail:

  1. Registrieren Sie Ihre Erweiterung mithilfe von Verwenden der Lambda Extensions API zum Erstellen von Erweiterungen. Dadurch erhalten Sie einen Lambda-Extension-Identifier, den Sie in den folgenden Schritten benötigen. Weitere Informationen zum Registrieren einer Erweiterung finden Sie unter Registrieren Ihrer Erweiterung.

  2. Erstellen eines Telemetrie-Listeners. Dies kann ein einfacher HTTP- oder TCP-Server sein. Lambda verwendet den URI des Telemetrie-Listeners, um Telemetriedaten an Ihre Erweiterung zu senden. Weitere Informationen finden Sie unter Erstellen eines Telemetrie-Listeners.

  3. Verwenden Sie die Subscribe API in der Telemetry API, um die gewünschten Telemetrie-Streams für Ihre Erweiterung zu abonnieren. Für diesen Schritt benötigen Sie den URI Ihres Telemetrie-Listeners. Weitere Informationen finden Sie unter Senden einer Abonnementanfrage an die Telemetrie-API.

  4. Rufen Sie Telemetriedaten von Lambda über den Telemetrie-Listener ab. Sie können diese Daten beliebig weiterverarbeiten, z. B. die Daten an Amazon S3 oder an einen externen Beobachtbarkeits-Service weiterleiten.

Anmerkung

Die Ausführungsumgebung einer Lambda-Funktion kann im Rahmen ihres Lebenszyklus mehrmals gestartet und angehalten werden. Im Allgemeinen wird Ihr Erweiterungscode während Funktionsaufrufen und auch bis zu 2 Sekunden während der Herunterfahrphase ausgeführt. Wir empfehlen, Telemetriedaten zu Batches zusammenzufassen, sobald sie bei Ihrem Listener eingehen. Verwenden Sie dann die Lebenszyklusereignisse Invoke und Shutdown, um jeden Batch an die gewünschten Ziele zu senden.

Registrieren Ihrer Erweiterung

Bevor Sie Telemetriedaten abonnieren können, müssen Sie Ihre Lambda-Erweiterung registrieren. Die Registrierung erfolgt während der Initialisierungsphase der Erweiterung. Das folgende Beispiel zeigt eine HTTP-Anfrage zur Registrierung einer Erweiterung.

POST http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension/register Lambda-Extension-Name: lambda_extension_name { 'events': [ 'INVOKE', 'SHUTDOWN'] }

Wenn die Anfrage erfolgreich ist, erhält der Subscriber eine Erfolgsantwort von HTTP 200. Der Antwort-Header enthält den Lambda-Extension-Identifier. Der Antworttext enthält weitere Eigenschaften der Funktion.

HTTP/1.1 200 OK Lambda-Extension-Identifier: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 { "functionName": "lambda_function", "functionVersion": "$LATEST", "handler": "lambda_handler", "accountId": "123456789012" }

Weitere Informationen hierzu finden Sie unter Erweiterungs-API-Referenz.

Erstellen eines Telemetrie-Listeners

Ihre Lambda-Erweiterung muss über einen Listener verfügen, der eingehende Anfragen der Telemetrie-API verarbeitet. Der folgende Code zeigt eine Beispielimplementierung eines Telemetrie-Listeners in Golang:

// Starts the server in a goroutine where the log events will be sent func (s *TelemetryApiListener) Start() (string, error) { address := listenOnAddress() l.Info("[listener:Start] Starting on address", address) s.httpServer = &http.Server{Addr: address} http.HandleFunc("/", s.http_handler) go func() { err := s.httpServer.ListenAndServe() if err != http.ErrServerClosed { l.Error("[listener:goroutine] Unexpected stop on Http Server:", err) s.Shutdown() } else { l.Info("[listener:goroutine] Http Server closed:", err) } }() return fmt.Sprintf("http://%s/", address), nil } // http_handler handles the requests coming from the Telemetry API. // Everytime Telemetry API sends log events, this function will read them from the response body // and put into a synchronous queue to be dispatched later. // Logging or printing besides the error cases below is not recommended if you have subscribed to // receive extension logs. Otherwise, logging here will cause Telemetry API to send new logs for // the printed lines which may create an infinite loop. func (s *TelemetryApiListener) http_handler(w http.ResponseWriter, r *http.Request) { body, err := ioutil.ReadAll(r.Body) if err != nil { l.Error("[listener:http_handler] Error reading body:", err) return } // Parse and put the log messages into the queue var slice []interface{} _ = json.Unmarshal(body, &slice) for _, el := range slice { s.LogEventsQueue.Put(el) } l.Info("[listener:http_handler] logEvents received:", len(slice), " LogEventsQueue length:", s.LogEventsQueue.Len()) slice = nil }

Festlegen eines Zielprotokolls

Wenn Sie den Empfang von Telemetrie mithilfe der Telemetrie-API abonnieren, können Sie zusätzlich zur Ziel-URI ein Zielprotokoll angeben:

{ "destination": { "protocol": "HTTP", "URI": "http://sandbox.localdomain:8080" } }

Lambda akzeptiert zwei Protokolle für den Empfang von Telemetrie:

  • HTTP (empfohlen) – Lambda übermittelt Telemetrie an einen lokalen HTTP-Endpunkt (http://sandbox.localdomain:${PORT}/${PATH}) als ein Array von Datensätzen im JSON-Format. Der Parameter $PATH ist optional. Lambda-unterstützt nur HTTP, nicht HTTPS. Lambda übermittelt Telemetrie über POST-Anfragen.

  • TCP – Lambda übermittelt Telemtrie an einen TCP-Anschluss im Newline-delimited-JSON-(NDJSON)-Format.

Anmerkung

Wir empfehlen dringend, HTTP und nicht TCP zu verwenden. Mit TCP kann die Lambda-Plattform nicht bestätigen, dass es Telemetrie an die Anwendungsebene übermittelt. Wenn Ihre Erweiterung abstürzt, verlieren Sie möglicherweise Telemetriedaten. Bei HTTP gibt es diese Einschränkung nicht.

Bevor Sie sich für den Empfang von Telemetriedaten registrieren, richten Sie den lokalen HTTP-Listener oder TCP-Port ein. Beachten Sie bei der Einrichtung Folgendes:

  • Lambda sendet Telemetriedaten nur an Ziele, die sich innerhalb der Ausführungsumgebung befinden.

  • Lambda wiederholt den Versuch, die Telemetriedaten (mit Backoff) zu senden, wenn es keinen Listener gibt oder wenn die POST-Anfrage zu einem Fehler führt. Wenn der Telemetrie-Listener abstürzt, erhält er nach dem Neustart der Ausführungsumgebung durch Lambda wieder Telemetriedaten.

  • Lambda reserviert Port 9001. Es gibt keine weiteren Einschränkungen oder Empfehlungen für Portnummern.

Konfiguration der Speichernutzung und Pufferung

Der Speicherverbrauch in einer Ausführungsumgebung wächst linear mit der Anzahl der Abonnenten. Abonnements verbrauchen Speicherressourcen, da jedes einen neuen Speicherpuffer zum Speichern von Telemetriedaten öffnet. Die Pufferspeichernutzung wird zum Gesamtspeicherverbrauch in der Ausführungsumgebung gezählt.

Wenn Sie den Empfang von Telemetriedaten mithilfe der Telemetry API abonnieren, können Sie Telemetriedaten puffern und sie in Batches an Abonnenten übermitteln. Um die Speichernutzung zu optimieren, können Sie eine Pufferungskonfiguration angeben:

{ "buffering": { "maxBytes": 256*1024, "maxItems": 1000, "timeoutMs": 100 } }
Pufferkonfigurations-Einstellungen
Parameter Beschreibung Standardwerte und Limits

maxBytes

Das maximale Telemetrievolumen (in Bytes), das im Speicher gepuffert werden soll.

Standard: 262 144

Mindestwert: 262 144

Höchstwert: 1 048 576

maxItems

Die maximale Anzahl von Ereignissen, die im Speicher gepuffert werden sollen.

Standard: 10 000

Mindestwert 1 000

Höchstwert: 10 000.

timeoutMs

Die maximale Zeit (in Millisekunden) zum Puffern eines Batches.

Standard: 1 000

Minimum: 25

Höchstwert: 30 000

Beachten Sie beim Einrichten der Pufferung die folgenden Punkte:

  • Wenn einer der Eingabestreams geschlossen wird, leert Lambda die Protokolle. Dies kann beispielsweise passieren, wenn die Laufzeit abstürzt.

  • Jeder Subscriber kann in seiner Abonnementanfrage eine andere Pufferungskonfiguration angeben.

  • Rechnen Sie beim Bestimmen der Puffergröße für das Lesen der Daten mit eingehenden Nutzlasten in der Größenordnung von 2 * maxBytes + metadataBytes, wobei maxBytes ein Bestandteil Ihrer Pufferungskonfiguration ist. Anhand der folgenden Metadaten können Sie metadataBytes abschätzen. Lambda hängt jedem Datensatz ähnliche Metadaten an:

    { "time": "2022-08-20T12:31:32.123Z", "type": "function", "record": "Hello World" }
  • Wenn der Subscriber eingehende Telemetriedaten nicht schnell genug verarbeiten kann oder wenn Ihr Funktionscode ein sehr hohes Protokollvolumen erzeugt, löscht Lambda möglicherweise Datensätze, um die Speichernutzung zu begrenzen. In diesem Fall sendet Lambda ein platform.logsDropped-Ereignis.

Senden einer Abonnementanfrage an die Telemetrie-API

Lambda-Erweiterungen können den Empfang von Telemetriedaten abonnieren, indem sie eine Abonnementanfrage an die Telemetrie-API senden. Die Abonnementanfrage sollte Informationen über die Arten von Ereignissen enthalten, die die Erweiterung abonnieren soll. Darüber hinaus kann die Anfrage Informationen zum Lieferziel und eine Pufferkonfiguration enthalten.

Bevor Sie eine Abonnementanfrage senden, benötigen Sie eine Erweiterungs-ID (Lambda-Extension-Identifier). Wenn Sie Ihre Erweiterung in der Erweiterungs-API registrieren, erhalten Sie eine Erweiterungs-ID aus der API-Antwort.

Das Abonnement erfolgt während der Initialisierungsphase der Erweiterung. Das folgende Beispiel zeigt eine HTTP-Anfrage zum Abonnieren aller drei Telemetriestreams: Plattformtelemetrie, Funktionsprotokolle und Erweiterungsprotokolle.

PUT http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry HTTP/1.1 { "schemaVersion": "2022-12-13", "types": [ "platform", "function", "extension" ], "buffering": { "maxItems": 1000, "maxBytes": 256*1024, "timeoutMs": 100 }, "destination": { "protocol": "HTTP", "URI": "http://sandbox.localdomain:8080" } }

Ist die Anfrage erfolgreich, erhält der Subscriber eine HTTP 200-Erfolgsantwort.

HTTP/1.1 200 OK "OK"

Eingehende Telemetrie-API-Nachrichten

Nach dem Abonnieren mit der Telemetry API beginnt eine Erweiterung automatisch, Telemetriedaten von Lambda über POST-Anfragen zu empfangen. Jeder POST-Anforderungstext enthält ein Array von Event Objekten. Jedes Event hat das folgende Schema:

{ time: String, type: String, record: Object }
  • Die time-Eigenschaft definiert, wann die Lambda-Plattform das Ereignis generiert hat. Das ist nicht identisch mit dem Zeitpunkt, zu dem das Ereignis tatsächlich stattgefunden hat. Der Zeichenfolgenwert von time ist ein Zeitstempel im ISO 8601-Format.

  • Die type-Eigenschaft definiert den Ereignistyp. Die folgende Tabelle beschreibt alle möglichen Werte.

  • Die record-Eigenschaft definiert ein JSON-Objekt, das die Telemetriedaten enthält. Das Schema dieses JSON-Objekts hängt von dem type ab.

Die folgende Tabelle fasst alle Event-Objekttypen zusammen und enthält Links zur Event-Telemetrie-API-Schemareferenz für jeden Ereignistyp.

Telemetrie-API-Nachrichtentypen
Kategorie Ereignistyp Beschreibung Schema der Ereignisaufzeichnung

Plattform-Ereignis

platform.initStart

Die Funktionsinitialisierung wurde gestartet.

platform.initStart-Schema

Plattform-Ereignis

platform.initRuntimeDone

Die Funktionsinitialisierung ist abgeschlossen.

platform.initRuntimeDone-Schema

Plattform-Ereignis

platform.initReport

Ein Bericht über die Funktionsinitialisierung.

platform.initReport-Schema

Plattform-Ereignis

platform.start

Der Funktionsaufruf wurde gestartet.

platform.start-Schema

Plattform-Ereignis

platform.runtimeDone

Die Laufzeit hat die Verarbeitung eines Ereignisses erfolgreich oder mit einem Fehler abgeschlossen.

platform.runtimeDone-Schema

Plattform-Ereignis

platform.report

Ein Bericht über den Funktionsaufruf.

platform.report-Schema

Plattform-Ereignis

platform.restoreStart

Die Laufzeitwiederherstellung wurde gestartet.

platform.restoreStart-Schema

Plattform-Ereignis

platform.restoreRuntimeDone

Die Laufzeitwiederherstellung wurde abgeschlossen.

platform.restoreRuntimeDone-Schema

Plattform-Ereignis

platform.restoreReport

Bericht über die Laufzeitwiederherstellung.

platform.restoreReport-Schema

Plattform-Ereignis

platform.telemetrySubscription

Die Erweiterung hat die Telemetrie-API abonniert.

platform.telemetrySubscription-Schema

Plattform-Ereignis

platform.logsDropped

Lambda hat die Protokolleinträge gelöscht.

platform.logsDropped-Schema

Funktionsprotokolle

function

Eine Protokollzeile aus dem Funktionscode.

function-Schema

Erweiterungsprotokolle

extension

Eine Protokollzeile aus dem Erweiterungscode.

extension-Schema