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.
# Zugriff auf Echtzeit-Telemetriedaten für Erweiterungen über die 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.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
**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 mit einer dieser APIs wird bei jedem Versuch APIs, ein Abonnement über die andere API abzuschließen, ein Fehler zurückgegeben.
**Anforderung an die Schemaversion von Lambda Managed Instances**
Lambda Managed Instances unterstützen nur die `2025-01-29` Schemaversion der Telemetrie-API. Wenn Sie Telemetriestreams für Funktionen der verwalteten Instanz abonnieren, **müssen** Sie dies `"schemaVersion": "2025-01-29"` in Ihrer Abonnementanfrage verwenden. Die Verwendung früherer Schemaversionen führt dazu, dass Ereignisse von Lambda zurückgewiesen werden.
Die `2025-01-29` Schemaversion ist abwärtskompatibel und kann sowohl mit Lambda Managed Instances als auch mit Lambda-Funktionen (Standard) verwendet werden. Wir empfehlen, diese Version für alle neuen Erweiterungen zu verwenden, um die Kompatibilität zwischen beiden Bereitstellungsmodellen sicherzustellen.
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 Logs und Metriken an CloudWatch X-Ray und Traces an X-Ray (sofern Sie Tracing aktiviert haben), auch wenn eine Erweiterung Telemetriestreams abonniert.
**Topics**
+ [Erstellen von Erweiterungen mithilfe der Telemetrie-API](#telemetry-api-creating-extensions)
+ [Registrieren Ihrer Erweiterung](#telemetry-api-registration)
+ [Erstellen eines Telemetrie-Listeners](#telemetry-api-listener)
+ [Festlegen eines Zielprotokolls](#telemetry-api-destination)
+ [Konfiguration der Speichernutzung und Pufferung](#telemetry-api-buffering)
+ [Senden einer Abonnementanfrage an die Telemetrie-API](#telemetry-api-subscription)
+ [Eingehende Telemetrie-API-Nachrichten](#telemetry-api-messages)
+ [Referenz zur Lambda-Telemetrie-API](telemetry-api-reference.md)
+ [Referenz zum `Event`-Schema der Lambda-Telemetrie-API](telemetry-schema-reference.md)
+ [`Event`Lambda-Telemetrie-API-Objekte in Spans konvertieren OpenTelemetry](telemetry-otel-spans.md)
+ [Verwendung der Lambda-Protokoll-API](runtimes-logs-api.md)
## 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.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/telemetry-api-creation-steps.png)
Hier sind die einzelnen Schritte im Detail:
1. Registrieren Sie Ihre Erweiterung mithilfe von [Verwendung der Lambda-Erweiterungs-API zur Erstellung von Erweiterungen](runtimes-extensions-api.md). 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](#telemetry-api-registration).
1. 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](#telemetry-api-listener).
1. 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](#telemetry-api-subscription).
1. 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](runtimes-extensions-api.md#runtimes-extensions-api-lifecycle) 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](runtimes-extensions-api.md#runtimes-extensions-api-reg). 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](runtimes-extensions-api.md#runtimes-extensions-registration-api).
## 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](https://github.com/ndjson/ndjson-spec).
**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
}
}
```
| Parameter | Description | 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](#telemetry-api-destination) und eine [Pufferkonfiguration](#telemetry-api-buffering) enthalten.
Bevor Sie eine Abonnementanfrage senden, benötigen Sie eine Erweiterungs-ID (`Lambda-Extension-Identifier`). Wenn Sie [Ihre Erweiterung in der Erweiterungs-API registrieren](#telemetry-api-registration), erhalten Sie eine Erweiterungs-ID aus der API-Antwort.
Das Abonnement erfolgt während der [Initialisierungsphase der Erweiterung](runtimes-extensions-api.md#runtimes-extensions-api-reg). 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": "2025-01-29",
"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.
**Bestellung von Ereignissen mit gleichzeitigen Aufrufen**
Bei [Lambda Managed Instances](lambda-managed-instances.md) können mehrere Funktionsaufrufen gleichzeitig in derselben Ausführungsumgebung ausgeführt werden. In diesem Fall ist die Reihenfolge der `platform.report` Ereignisse `platform.start` und zwischen verschiedenen gleichzeitigen Aufrufen nicht garantiert. Erweiterungen müssen Ereignisse aus mehreren Aufrufen verarbeiten, die parallel ausgeführt werden, und sollten keine sequentielle Reihenfolge annehmen.
Um Ereignisse bestimmten Aufrufen korrekt zuzuordnen, sollten Erweiterungen das `requestId` Feld verwenden, das in diesen Plattformereignissen vorhanden ist. Jeder Aufruf hat eine eindeutige Anforderungs-ID, die für alle Ereignisse dieses Aufrufs einheitlich bleibt, sodass Erweiterungen Ereignisse auch dann korrekt korrelieren können, wenn sie nicht in der richtigen Reihenfolge ankommen.
Die folgende Tabelle fasst alle `Event`-Objekttypen zusammen und enthält Links zur [`Event`-Telemetrie-API-Schemareferenz](telemetry-schema-reference.md) für jeden Ereignistyp.
| Kategorie | Ereignistyp | Description | Schema der Ereignisaufzeichnung |
| --- | --- | --- | --- |
| Plattform-Ereignis | `platform.initStart` | Die Funktionsinitialisierung wurde gestartet. | [`platform.initStart`](telemetry-schema-reference.md#platform-initStart)-Schema |
| Plattform-Ereignis | `platform.initRuntimeDone` | Die Funktionsinitialisierung ist abgeschlossen. | [`platform.initRuntimeDone`](telemetry-schema-reference.md#platform-initRuntimeDone)-Schema |
| Plattform-Ereignis | `platform.initReport` | Ein Bericht über die Funktionsinitialisierung. | [`platform.initReport`](telemetry-schema-reference.md#platform-initReport)-Schema |
| Plattform-Ereignis | `platform.start` | Der Funktionsaufruf wurde gestartet. | [`platform.start`](telemetry-schema-reference.md#platform-start)-Schema |
| Plattform-Ereignis | `platform.runtimeDone` | Die Laufzeit hat die Verarbeitung eines Ereignisses erfolgreich oder mit einem Fehler abgeschlossen. | [`platform.runtimeDone`](telemetry-schema-reference.md#platform-runtimeDone)-Schema |
| Plattform-Ereignis | `platform.report` | Ein Bericht über den Funktionsaufruf. | [`platform.report`](telemetry-schema-reference.md#platform-report)-Schema |
| Plattform-Ereignis | `platform.restoreStart` | Die Laufzeitwiederherstellung wurde gestartet. | [`platform.restoreStart`](telemetry-schema-reference.md#platform-restoreStart)-Schema |
| Plattform-Ereignis | `platform.restoreRuntimeDone` | Die Laufzeitwiederherstellung wurde abgeschlossen. | [`platform.restoreRuntimeDone`](telemetry-schema-reference.md#platform-restoreRuntimeDone)-Schema |
| Plattform-Ereignis | `platform.restoreReport` | Bericht über die Laufzeitwiederherstellung. | [`platform.restoreReport`](telemetry-schema-reference.md#platform-restoreReport)-Schema |
| Plattform-Ereignis | `platform.telemetrySubscription` | Die Erweiterung hat die Telemetrie-API abonniert. | [`platform.telemetrySubscription`](telemetry-schema-reference.md#platform-telemetrySubscription)-Schema |
| Plattform-Ereignis | `platform.logsDropped` | Lambda hat die Protokolleinträge gelöscht. | [`platform.logsDropped`](telemetry-schema-reference.md#platform-logsDropped)-Schema |
| Funktionsprotokolle | `function` | Eine Protokollzeile aus dem Funktionscode. | [`function`](telemetry-schema-reference.md#telemetry-api-function)-Schema |
| Erweiterungsprotokolle | `extension` | Eine Protokollzeile aus dem Erweiterungscode. | [`extension`](telemetry-schema-reference.md#telemetry-api-extension)-Schema |
# Referenz zur Lambda-Telemetrie-API
Verwenden Sie den Lambda-Telemetrie-API-Endpunkt, um Erweiterungen für Telemetrie-Streams zu abonnieren. Sie können den Telemtrie-API-Endpunkts aus der `AWS_LAMBDA_RUNTIME_API`-Umgebungsvariable abrufen. Um eine API-Anfrage zu senden, fügen Sie die API-Version (`2022-07-01/`) und `telemetry/` an. Beispiel:
```
http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry/
```
Die Definition der OpenAPI-Spezifikation (OAS) der Abonnementantwortversion `2025-01-29` finden Sie unter:
+ **HTTP** — [telemetry-api-http-schema.zip](samples/events_http_schema_v2025_01_29.zip)
+ **[TCP — .zip telemetry-api-tcp-schema](samples/events_tcp_schema_v2025_01_29.zip)**
**Topics**
+ [Abonnieren](#telemetry-subscribe-api)
## Abonnieren
Um einen Telemetrie-Stream zu abonnieren, kann eine Lambda-Erweiterung eine Abonnement-API-Anfrage senden.
+ **Pfad** – `/telemetry`
+ **Methode** – `PUT`
+ **Header**
+ `Content-Type`: `application/json`
+ **Anfrage von Textparametern**
+ **schemaVersion**
+ Erforderlich: Ja
+ Typ: Zeichenfolge
+ Gültige Werte: `"2025-01-29"`, `"2022-12-13"` oder `"2022-07-01"`
+ **Hinweis:** Für Lambda Managed Instances ist Folgendes erforderlich`"2025-01-29"`. Diese Version ist abwärtskompatibel mit Lambda-Funktionen (Standard).
+ **Ziel** – Die Konfigurationseinstellungen, die das Ziel des Telemetrieereignisses und das Protokoll für die Ereignisübermittlung definieren.
+ Erforderlich: Ja
+ Typ: Objekt
```
{
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080"
}
```
+ **Protokoll** – Das Protokoll, das Lambda zum Senden von Telemetriedaten verwendet.
+ Erforderlich: Ja
+ Typ: Zeichenfolge
+ Gültige Werte: `"HTTP"`\$1`"TCP"`
+ **URI** – Der URI, an den Telemetriedaten gesendet werden sollen.
+ Erforderlich: Ja
+ Typ: Zeichenfolge
+ Weitere Informationen finden Sie unter [Festlegen eines Zielprotokolls](telemetry-api.md#telemetry-api-destination).
+ **Typen** – Die Telemetrietypen, die die Erweiterung abonnieren soll.
+ Erforderlich: Ja
+ Typ: Zeichenfolgen-Array
+ Zulässige Werte: `"platform"`\$1`"function"`\$1`"extension"`
+ **Pufferung** – Die Konfigurationseinstellungen für die Ereignispufferung.
+ Erforderlich: Nein
+ Typ: Objekt
```
{
"buffering": {
"maxItems": 1000,
"maxBytes": 256*1024,
"timeoutMs": 100
}
}
```
+ **maxItems** – Die maximale Anzahl der Ereignisse im Speicher, die gepuffert werden sollen.
+ Erforderlich: Nein
+ Typ: Ganzzahl
+ Standard: 1 000
+ Mindestwert 1 000
+ Höchstwert: 10 000.
+ **maxBytes** – Das maximale Telemetrievolumen (in Bytes), das im Speicher gepuffert werden soll.
+ Erforderlich: Nein
+ Typ: Ganzzahl
+ Standard: 262 144
+ Mindestwert: 262 144
+ Höchstwert: 1 048 576
+ **timeoutMs** – Die maximale Zeit (in Millisekunden) zum Puffern eines Batches.
+ Erforderlich: Nein
+ Typ: Ganzzahl
+ Standard: 1 000
+ Minimum: 25
+ Höchstwert: 30 000
+ Weitere Informationen finden Sie unter [Konfiguration der Speichernutzung und Pufferung](telemetry-api.md#telemetry-api-buffering).
### Beispiel für eine Abonnement-API-Anfrage
```
PUT http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry HTTP/1.1
{
"schemaVersion": "2025-01-29",
"types": [
"platform",
"function",
"extension"
],
"buffering": {
"maxItems": 1000,
"maxBytes": 256*1024,
"timeoutMs": 100
},
"destination": {
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080"
}
}
```
Wenn die Abonnement-Anfrage erfolgreich war, erhält die Erweiterung eine Erfolgsbestätigung (HTTP 200):
```
HTTP/1.1 200 OK
"OK"
```
Wenn die Abonnement-Anfrage fehlschlägt, erhält die Erweiterung eine Fehlerantwort. Beispiel:
```
HTTP/1.1 400 OK
{
"errorType": "ValidationError",
"errorMessage": "URI port is not provided; types should not be empty"
}
```
Hier sind einige zusätzliche Antwortcodes, die die Erweiterung empfangen kann:
+ 200 – Anfrage erfolgreich abgeschlossen
+ 202 – Anfrage wurde akzeptiert. Antwort auf die Abonnement-Anfrage in einer lokalen Testumgebung
+ 400 – Ungültige Anfrage
+ 500 – Servicefehler
# Referenz zum `Event`-Schema der Lambda-Telemetrie-API
Verwenden Sie den Lambda-Telemetrie-API-Endpunkt, um Erweiterungen für Telemetrie-Streams zu abonnieren. Sie können den Telemtrie-API-Endpunkts aus der `AWS_LAMBDA_RUNTIME_API`-Umgebungsvariable abrufen. Um eine API-Anfrage zu senden, fügen Sie die API-Version (`2022-07-01/`) und `telemetry/` an. Beispiel:
```
http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry/
```
Die Definition der OpenAPI-Spezifikation (OAS) der Abonnementantwortversion `2025-01-29` finden Sie unter:
+ **HTTP** — [telemetry-api-http-schema.zip](samples/events_http_schema_v2025_01_29.zip)
+ **[TCP — .zip telemetry-api-tcp-schema](samples/events_tcp_schema_v2025_01_29.zip)**
Die folgende Tabelle enthält eine Zusammenfassung aller `Event`-Objekttypen, die die Telemetrie-API unterstützt.
| Kategorie | Ereignistyp | Description | Schema der Ereignisaufzeichnung |
| --- | --- | --- | --- |
| Plattform-Ereignis | `platform.initStart` | Die Funktionsinitialisierung wurde gestartet. | [`platform.initStart`](#platform-initStart)-Schema |
| Plattform-Ereignis | `platform.initRuntimeDone` | Die Funktionsinitialisierung ist abgeschlossen. | [`platform.initRuntimeDone`](#platform-initRuntimeDone)-Schema |
| Plattform-Ereignis | `platform.initReport` | Ein Bericht über die Funktionsinitialisierung. | [`platform.initReport`](#platform-initReport)-Schema |
| Plattform-Ereignis | `platform.start` | Der Funktionsaufruf wurde gestartet. | [`platform.start`](#platform-start)-Schema |
| Plattform-Ereignis | `platform.runtimeDone` | Die Laufzeit hat die Verarbeitung eines Ereignisses erfolgreich oder mit einem Fehler abgeschlossen. | [`platform.runtimeDone`](#platform-runtimeDone)-Schema |
| Plattform-Ereignis | `platform.report` | Ein Bericht über den Funktionsaufruf. | [`platform.report`](#platform-report)-Schema |
| Plattform-Ereignis | `platform.restoreStart` | Die Laufzeitwiederherstellung wurde gestartet. | [`platform.restoreStart`](#platform-restoreStart)-Schema |
| Plattform-Ereignis | `platform.restoreRuntimeDone` | Die Laufzeitwiederherstellung wurde abgeschlossen. | [`platform.restoreRuntimeDone`](#platform-restoreRuntimeDone)-Schema |
| Plattform-Ereignis | `platform.restoreReport` | Bericht über die Laufzeitwiederherstellung. | [`platform.restoreReport`](#platform-restoreReport)-Schema |
| Plattform-Ereignis | `platform.telemetrySubscription` | Die Erweiterung hat die Telemetrie-API abonniert. | [`platform.telemetrySubscription`](#platform-telemetrySubscription)-Schema |
| Plattform-Ereignis | `platform.logsDropped` | Lambda hat die Protokolleinträge gelöscht. | [`platform.logsDropped`](#platform-logsDropped)-Schema |
| Funktionsprotokolle | `function` | Eine Protokollzeile aus dem Funktionscode. | [`function`](#telemetry-api-function)-Schema |
| Erweiterungsprotokolle | `extension` | Eine Protokollzeile aus dem Erweiterungscode. | [`extension`](#telemetry-api-extension)-Schema |
**Contents**
+ [Telemetrie-API `Event`-Objekttypen](#telemetry-api-events)
+ [`platform.initStart`](#platform-initStart)
+ [`platform.initRuntimeDone`](#platform-initRuntimeDone)
+ [`platform.initReport`](#platform-initReport)
+ [`platform.start`](#platform-start)
+ [`platform.runtimeDone`](#platform-runtimeDone)
+ [`platform.report`](#platform-report)
+ [`platform.restoreStart`](#platform-restoreStart)
+ [`platform.restoreRuntimeDone`](#platform-restoreRuntimeDone)
+ [`platform.restoreReport`](#platform-restoreReport)
+ [`platform.extension`](#platform-extension)
+ [`platform.telemetrySubscription`](#platform-telemetrySubscription)
+ [`platform.logsDropped`](#platform-logsDropped)
+ [`function`](#telemetry-api-function)
+ [`extension`](#telemetry-api-extension)
+ [Freigegebene Objekttypen](#telemetry-api-objects)
+ [`InitPhase`](#InitPhase)
+ [`InitReportMetrics`](#InitReportMetrics)
+ [`InitType`](#InitType)
+ [`ReportMetrics`](#ReportMetrics)
+ [`RestoreReportMetrics`](#RestoreReportMetrics)
+ [`RuntimeDoneMetrics`](#RuntimeDoneMetrics)
+ [`Span`](#Span)
+ [`Status`](#Status)
+ [`TraceContext`](#TraceContext)
+ [`TracingType`](#TracingType)
## Telemetrie-API `Event`-Objekttypen
Dieser Abschnitt beschreibt die Arten der `Event`-Objekte, die die Lambda-Telemetrie-API unterstützt. In den Ereignisbeschreibungen weist ein Fragezeichen (`?`) darauf hin, dass das Attribut möglicherweise nicht in diesem Objekt vorhanden ist.
### `platform.initStart`
Ein `platform.initStart`-Ereignis zeigt an, dass die Initialisierungsphase der Funktion begonnen hat. Ein `platform.initStart` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.initStart
- record: PlatformInitStart
```
Dieses `PlatformInitStart`-Objekt hat die folgenden Attribute:
+ **functionName** – `String`
+ **functionVersion** – `String`
+ **initializationType** – ``InitType``-Objekt
+ **instanceId?** – `String`
+ **instanceMaxMemory?** – `Integer`
+ **phase** – ``InitPhase``-Objekt
+ **runtimeVersion?** – `String`
+ **runtimeVersionArn?** – `String`
Es folgt ein Beispiel für `Event` des Typs `platform.initStart`:
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "nodejs-14.v3",
"runtimeVersionArn": "arn",
"functionName": "myFunction",
"functionVersion": "$LATEST",
"instanceId": "82561ce0-53dd-47d1-90e0-c8f5e063e62e",
"instanceMaxMemory": 256
}
}
```
### `platform.initRuntimeDone`
Ein `platform.initRuntimeDone`-Ereignis zeigt an, dass die Initialisierungsphase der Funktion abgeschlossen wurde. Ein `platform.initRuntimeDone` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.initRuntimeDone
- record: PlatformInitRuntimeDone
```
Dieses `PlatformInitRuntimeDone`-Objekt hat die folgenden Attribute:
+ **initializationType** – ``InitType``-Objekt
+ **phase** – ``InitPhase``-Objekt
+ **status** – ``Status``-Objekt
+ **spans?** – Liste von ``Span``-Objekten
Es folgt ein Beispiel für `Event` des Typs `platform.initRuntimeDone`:
```
{
"time": "2022-10-12T00:01:15.000Z",
"type": "platform.initRuntimeDone",
"record": {
"initializationType": "on-demand"
"status": "success",
"spans": [
{
"name": "someTimeSpan",
"start": "2022-06-02T12:02:33.913Z",
"durationMs": 70.5
}
]
}
}
```
### `platform.initReport`
Ein `platform.initReport`-Ereignis enthält einen Gesamtbericht über die Initialisierungsphase der Funktion. Ein `platform.initReport` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.initReport
- record: PlatformInitReport
```
Dieses `PlatformInitReport`-Objekt hat die folgenden Attribute:
+ **errorType?** – Zeichenfolge
+ **initializationType** – ``InitType``-Objekt
+ **phase** – ``InitPhase``-Objekt
+ **metrics** – ``InitReportMetrics``-Objekt
+ **spans?** – Liste von ``Span``-Objekten
+ **status** – ``Status``-Objekt
Es folgt ein Beispiel für `Event` des Typs `platform.initReport`:
```
{
"time": "2022-10-12T00:01:15.000Z",
"type": "platform.initReport",
"record": {
"initializationType": "on-demand",
"status": "success",
"phase": "init",
"metrics": {
"durationMs": 125.33
},
"spans": [
{
"name": "someTimeSpan",
"start": "2022-06-02T12:02:33.913Z",
"durationMs": 90.1
}
]
}
}
```
### `platform.start`
Ein `platform.start`-Ereignis zeigt an, dass die Funktionsaufrufphase begonnen hat. Ein `platform.start` `Event` Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.start
- record: PlatformStart
```
Dieses `PlatformStart`-Objekt hat die folgenden Attribute:
+ **requestId** – `String`
+ **version?** – `String`
+ **tracing?** – ``TraceContext``
Es folgt ein Beispiel für `Event` des Typs `platform.start`:
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.start",
"record": {
"requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
"version": "$LATEST",
"tracing": {
"spanId": "54565fb41ac79632",
"type": "X-Amzn-Trace-Id",
"value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
}
}
}
```
### `platform.runtimeDone`
Ein `platform.runtimeDone`-Ereignis zeigt an, dass die Funktionsaufrufphase abgeschlossen ist. Ein `platform.runtimeDone` `Event`-Objekt hat die folgende Form:
**Von Lambda verwaltete Instanzen**
Das `platform.runtimeDone` Ereignis wird für Lambda Managed Instances nicht unterstützt. Erweiterungen, die auf verwalteten Instanzen ausgeführt werden, erhalten dieses Ereignis nicht, da Erweiterungen das `INVOKE` Ereignis auf verwalteten Instanzen nicht abonnieren können. Aufgrund des Modells der gleichzeitigen Ausführung, bei dem mehrere Aufrufe gleichzeitig verarbeitet werden können, können Erweiterungen keine Verarbeitung nach dem Aufrufen für einzelne Aufrufe durchführen, wie dies üblicherweise bei Lambda-Funktionen (Standard) der Fall ist.
Bei verwalteten Instanzen sind die Bereiche `responseLatency` und, die normalerweise `responseDuration` enthalten sind, stattdessen im Ereignis verfügbar. `platform.runtimeDone` `platform.report` Details dazu finden Sie unter [`platform.report`](#platform-report).
```
Event: Object
- time: String
- type: String = platform.runtimeDone
- record: PlatformRuntimeDone
```
Dieses `PlatformRuntimeDone`-Objekt hat die folgenden Attribute:
+ **errorType? ** – `String`
+ **metrics?** – ``RuntimeDoneMetrics`` Objekt
+ **requestId** – `String`
+ **status** – ``Status``-Objekt
+ **spans?** – Liste von ``Span``-Objekten
+ **tracing?** – ``TraceContext``-Objekt
Es folgt ein Beispiel für `Event` des Typs `platform.runtimeDone`:
```
{
"time": "2022-10-12T00:01:15.000Z",
"type": "platform.runtimeDone",
"record": {
"requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
"status": "success",
"tracing": {
"spanId": "54565fb41ac79632",
"type": "X-Amzn-Trace-Id",
"value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
},
"spans": [
{
"name": "someTimeSpan",
"start": "2022-08-02T12:01:23:521Z",
"durationMs": 80.0
}
],
"metrics": {
"durationMs": 140.0,
"producedBytes": 16
}
}
}
```
### `platform.report`
Ein `platform.report`-Ereignis enthält einen Gesamtbericht über die Phase des Funktionsaufrufs. Ein `platform.report` `Event`-Objekt hat die folgende Form:
**Von Lambda verwaltete Instanzen**
Das `platform.report` Ereignis für Lambda Managed Instances hat im Vergleich zu Lambda-Funktionen (Standard) andere Metriken und Spannweiten. Für verwaltete Instanzen:
**Spans**: Enthält `responseLatency` und `responseDuration` statt. `extensionOverhead` Die `extensionOverhead` Spanne ist nicht verfügbar, da Erweiterungen das `INVOKE` Ereignis auf verwalteten Instanzen aufgrund des parallelen Ausführungsmodells nicht abonnieren können.
**Metriken**: Beinhaltet `durationMs` nur. Die folgenden Metriken sind nicht enthalten: `billedDurationMs``initDurationMs`,`maxMemoryUsedMB`, und`memorySizeMB`. Diese Metriken pro Aufruf sind in der Umgebung für die gleichzeitige Ausführung nicht anwendbar. Verwenden [Überwachung von Lambda-verwalteten Instanzen](lambda-managed-instances-monitoring.md) Sie [Lambda Insights](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-insights.html) für Kennzahlen zur Ressourcennutzung.
```
Event: Object
- time: String
- type: String = platform.report
- record: PlatformReport
```
Dieses `PlatformReport`-Objekt hat die folgenden Attribute:
+ **metrics** – ``ReportMetrics``-Objekt
+ **requestId** – `String`
+ **spans?** – Liste von ``Span``-Objekten
+ **Status** – ``Status``-Objekt
+ **Nachverfolgung? ** – ``TraceContext``-Objekt
Es folgt ein Beispiel für `Event` des Typs `platform.report`:
```
{
"time": "2022-10-12T00:01:15.000Z",
"type": "platform.report",
"record": {
"metrics": {
"billedDurationMs": 694,
"durationMs": 693.92,
"initDurationMs": 397.68,
"maxMemoryUsedMB": 84,
"memorySizeMB": 128
},
"requestId": "6d68ca91-49c9-448d-89b8-7ca3e6dc66aa",
}
}
```
### `platform.restoreStart`
Ein `platform.restoreStart`-Ereignis zeigt an, dass ein Ereignis zur Wiederherstellung der Funktionsumgebung gestartet wurde. Bei einem Wiederherstellungsereignis einer Umgebung erstellt Lambda die Umgebung aus einem im Cache gespeicherten Snapshot, anstatt diese von Grund auf neu zu initialisieren. Weitere Informationen finden Sie unter [Lambda SnapStart](snapstart.md). Ein `platform.restoreStart` `Event` Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.restoreStart
- record: PlatformRestoreStart
```
Dieses `PlatformRestoreStart`-Objekt hat die folgenden Attribute:
+ **functionName** – `String`
+ **functionVersion** – `String`
+ **instanceId?** – `String`
+ **instanceMaxMemory?** – `String`
+ **runtimeVersion?** – `String`
+ **runtimeVersionArn?** – `String`
Es folgt ein Beispiel für `Event` des Typs `platform.restoreStart`:
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.restoreStart",
"record": {
"runtimeVersion": "nodejs-14.v3",
"runtimeVersionArn": "arn",
"functionName": "myFunction",
"functionVersion": "$LATEST",
"instanceId": "82561ce0-53dd-47d1-90e0-c8f5e063e62e",
"instanceMaxMemory": 256
}
}
```
### `platform.restoreRuntimeDone`
Ein `platform.restoreRuntimeDone`-Ereignis weist darauf hin, dass ein Wiederherstellungsereignis der Funktionsumgebung abgeschlossen wurde. Bei einem Wiederherstellungsereignis einer Umgebung erstellt Lambda die Umgebung aus einem im Cache gespeicherten Snapshot, anstatt diese von Grund auf neu zu initialisieren. Weitere Informationen finden Sie unter [Lambda SnapStart](snapstart.md). Ein `platform.restoreRuntimeDone` `Event` Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.restoreRuntimeDone
- record: PlatformRestoreRuntimeDone
```
Dieses `PlatformRestoreRuntimeDone`-Objekt hat die folgenden Attribute:
+ **errorType? ** – `String`
+ **spans?** – Liste von ``Span``-Objekten
+ **status** – ``Status``-Objekt
Es folgt ein Beispiel für `Event` des Typs `platform.restoreRuntimeDone`:
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.restoreRuntimeDone",
"record": {
"status": "success",
"spans": [
{
"name": "someTimeSpan",
"start": "2022-08-02T12:01:23:521Z",
"durationMs": 80.0
}
]
}
}
```
### `platform.restoreReport`
Ein `platform.restoreReport`-Ereignis enthält einen Gesamtbericht über ein Ereignis zur Funktionswiederherstellung. Ein `platform.restoreReport` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.restoreReport
- record: PlatformRestoreReport
```
Dieses `PlatformRestoreReport`-Objekt hat die folgenden Attribute:
+ **errorType?** – Zeichenfolge
+ **metrics?** – ``RestoreReportMetrics`` Objekt
+ **spans?** – Liste von ``Span``-Objekten
+ **status** – ``Status``-Objekt
Es folgt ein Beispiel für `Event` des Typs `platform.restoreReport`:
```
{
"time": "2022-10-12T00:00:15.064Z",
"type": "platform.restoreReport",
"record": {
"status": "success",
"metrics": {
"durationMs": 15.19
},
"spans": [
{
"name": "someTimeSpan",
"start": "2022-08-02T12:01:23:521Z",
"durationMs": 30.0
}
]
}
}
```
### `platform.extension`
Ein `extension`-Ereignis enthält Protokolle aus dem Erweiterungscode. Ein `extension` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = extension
- record: {}
```
Dieses `PlatformExtension`-Objekt hat die folgenden Attribute:
+ **events** – Liste von `String`
+ **name** – `String`
+ **status** – `String`
Es folgt ein Beispiel für `Event` des Typs `platform.extension`:
```
{
"time": "2022-10-12T00:02:15.000Z",
"type": "platform.extension",
"record": {
"events": [ "INVOKE", "SHUTDOWN" ],
"name": "my-telemetry-extension",
"state": "Ready"
}
}
```
### `platform.telemetrySubscription`
Ein `platform.telemetrySubscription`-Ereignis enthält Informationen zu einem Erweiterungsabonnement. Ein `platform.telemetrySubscription` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.telemetrySubscription
- record: PlatformTelemetrySubscription
```
Dieses `PlatformTelemetrySubscription`-Objekt hat die folgenden Attribute:
+ **name** – `String`
+ **status** – `String`
+ **types** – Liste von `String`
Es folgt ein Beispiel für `Event` des Typs `platform.telemetrySubscription`:
```
{
"time": "2022-10-12T00:02:35.000Z",
"type": "platform.telemetrySubscription",
"record": {
"name": "my-telemetry-extension",
"state": "Subscribed",
"types": [ "platform", "function" ]
}
}
```
### `platform.logsDropped`
Ein `platform.logsDropped`-Ereignis enthält Informationen über gelöschte Ereignisse. Lambda gibt das `platform.logsDropped`-Ereignis aus, wenn eine Funktion Protokolle schneller ausgibt, als Lambda sie verarbeiten kann. Wenn Lambda Protokolle nicht mit der Geschwindigkeit an CloudWatch oder an die Erweiterung senden kann, die die Telemetrie-API abonniert hat, werden Protokolle gelöscht, um zu verhindern, dass die Ausführung der Funktion verlangsamt wird. Ein `platform.logsDropped` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = platform.logsDropped
- record: PlatformLogsDropped
```
Dieses `PlatformLogsDropped`-Objekt hat die folgenden Attribute:
+ **droppedBytes** – `Integer`
+ **droppedRecords** – `Integer`
+ **reason** – `String`
Es folgt ein Beispiel für `Event` des Typs `platform.logsDropped`:
```
{
"time": "2022-10-12T00:02:35.000Z",
"type": "platform.logsDropped",
"record": {
"droppedBytes": 12345,
"droppedRecords": 123,
"reason": "Some logs were dropped because the downstream consumer is slower than the logs production rate"
}
}
```
### `function`
Ein `function`-Ereignis enthält Protokolle aus dem Funktionscode. Ein `function` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = function
- record: {}
```
Das Format des Felds `record` hängt davon ab, ob die Protokolle Ihrer Funktion im Klartext- oder JSON-Format formatiert sind. Weitere Informationen zu den Konfigurationsoptionen für das Protokollformat finden Sie unter [Konfiguration der JSON- und Klartext-Protokollformate](monitoring-cloudwatchlogs-logformat.md).
Im Folgenden finden Sie ein Beispiel für `Event` vom Typ `function`, bei dem das Protokollformat Klartext ist:
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "function",
"record": "[INFO] Hello world, I am a function!"
}
```
Im Folgenden finden Sie ein Beispiel für `Event` vom Typ `function`, bei dem das Protokollformat JSON ist:
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "function",
"record": {
"timestamp": "2022-10-12T00:03:50.000Z",
"level": "INFO",
"requestId": "79b4f56e-95b1-4643-9700-2807f4e68189",
"message": "Hello world, I am a function!"
}
}
```
**Anmerkung**
Wenn die von Ihnen verwendete Schemaversion älter als die `2022-12-13`-Version ist, wird `"record"` immer als Zeichenfolge gerendert, auch wenn das Protokollierungsformat Ihrer Funktion als JSON konfiguriert ist. Für Lambda Managed Instances müssen Sie die Schemaversion `2025-01-29` verwenden.
### `extension`
Ein `extension`-Ereignis enthält Protokolle aus dem Erweiterungscode. Ein `extension` `Event`-Objekt hat die folgende Form:
```
Event: Object
- time: String
- type: String = extension
- record: {}
```
Das Format des Felds `record` hängt davon ab, ob die Protokolle Ihrer Funktion im Klartext- oder JSON-Format formatiert sind. Weitere Informationen zu den Konfigurationsoptionen für das Protokollformat finden Sie unter [Konfiguration der JSON- und Klartext-Protokollformate](monitoring-cloudwatchlogs-logformat.md).
Im Folgenden finden Sie ein Beispiel für `Event` vom Typ `extension`, bei dem das Protokollformat Klartext ist:
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "extension",
"record": "[INFO] Hello world, I am an extension!"
}
```
Im Folgenden finden Sie ein Beispiel für `Event` vom Typ `extension`, bei dem das Protokollformat JSON ist:
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "extension",
"record": {
"timestamp": "2022-10-12T00:03:50.000Z",
"level": "INFO",
"requestId": "79b4f56e-95b1-4643-9700-2807f4e68189",
"message": "Hello world, I am an extension!"
}
}
```
**Anmerkung**
Wenn die von Ihnen verwendete Schemaversion älter als die `2022-12-13`-Version ist, wird `"record"` immer als Zeichenfolge gerendert, auch wenn das Protokollierungsformat Ihrer Funktion als JSON konfiguriert ist. Für Lambda Managed Instances müssen Sie die Schemaversion `2025-01-29` verwenden.
## Freigegebene Objekttypen
Dieser Abschnitt beschreibt die Arten von freigegebenen Objekten, die die Lambda-Telemetrie-API unterstützt.
### `InitPhase`
Eine Zeichenfolgenaufzählung, die die Phase beschreibt, in der der Initialisierungsschritt auftritt. In den meisten Fällen führt Lambda den Funktionsinitialisierungscode während der `init`-Phase aus. In einigen Fehlerfällen kann Lambda jedoch den Funktionsinitialisierungscode während der `invoke`-Phase erneut ausführen. (Dies wird als *suppressed init* bezeichnet.)
+ **Typ:** – `String`
+ **Gültige Werte** – `init`\$1`invoke`\$1`snap-start`
### `InitReportMetrics`
Ein Objekt, das Metriken zu einer Initialisierungsphase enthält.
+ **Typ:** – `Object`
Ein `InitReportMetrics`-Objekt hat die folgende Form:
```
InitReportMetrics: Object
- durationMs: Double
```
Es folgt ein Beispiel für ein `InitReportMetrics`-Objekt:
```
{
"durationMs": 247.88
}
```
### `InitType`
Eine Zeichenfolgenaufzählung, die beschreibt, wie Lambda die Umgebung initialisiert hat.
+ **Typ:** – `String`
+ **Gültige Werte** – `on-demand`\$1`provisioned-concurrency`
### `ReportMetrics`
Ein Objekt, das Details zu einer abgeschlossenen Phase enthält.
+ **Typ:** – `Object`
Ein `ReportMetrics`-Objekt hat die folgende Form:
```
ReportMetrics: Object
- billedDurationMs: Integer
- durationMs: Double
- initDurationMs?: Double
- maxMemoryUsedMB: Integer
- memorySizeMB: Integer
- restoreDurationMs?: Double
```
Es folgt ein Beispiel für ein `ReportMetrics`-Objekt:
```
{
"billedDurationMs": 694,
"durationMs": 693.92,
"initDurationMs": 397.68,
"maxMemoryUsedMB": 84,
"memorySizeMB": 128
}
```
### `RestoreReportMetrics`
Ein Objekt, das Metriken über eine abgeschlossene Wiederherstellungsphase enthält.
+ **Typ:** – `Object`
Ein `RestoreReportMetrics`-Objekt hat die folgende Form:
```
RestoreReportMetrics: Object
- durationMs: Double
```
Es folgt ein Beispiel für ein `RestoreReportMetrics`-Objekt:
```
{
"durationMs": 15.19
}
```
### `RuntimeDoneMetrics`
Ein Objekt, das Metriken über eine Aufrufphase enthält.
+ **Typ:** – `Object`
Ein `RuntimeDoneMetrics`-Objekt hat die folgende Form:
```
RuntimeDoneMetrics: Object
- durationMs: Double
- producedBytes?: Integer
```
Es folgt ein Beispiel für ein `RuntimeDoneMetrics`-Objekt:
```
{
"durationMs": 200.0,
"producedBytes": 15
}
```
### `Span`
Ein Objekt, das Details einem Span enthält. Ein Span stellt eine Arbeitseinheit oder einen Vorgang in einer Ablaufverfolgung dar. Weitere Informationen zu Spans finden Sie unter [Span](https://opentelemetry.io/docs/reference/specification/trace/api/#span) auf der **Tracing-API-Seite der OpenTelemetry Docs-Website**.
Lambda unterstützt die folgenden zwei Bereiche für das `platform.RuntimeDone`-Ereignis:
+ Der `responseLatency`-Span beschreibt, wie lange es gedauert hat, bis Ihre Lambda-Funktion mit dem Senden der Antwort begonnen hat.
+ Der `responseDuration`-Spanbeschreibt, wie lange es gedauert hat, bis Ihre Lambda-Funktion das Senden der Antwort abgeschlossen hat.
+ Die `runtimeOverhead`-Spanne beschreibt, wie lange es gedauert hat, bis die Lambda-Laufzeit signalisiert hat, dass sie für die Verarbeitung des nächsten Funktionsaufrufs bereit ist. Dies ist die Zeit, die die Laufzeit benötigt hat, um die [nächste Aufruf](runtimes-api.md#runtimes-api-next)-API aufzurufen, um das nächste Ereignis nach der Rückgabe Ihrer Funktionsantwort zu erhalten.
Es folgt ein Beispiel für ein Objekt des `responseLatency`-Spans:
```
{
"name": "responseLatency",
"start": "2022-08-02T12:01:23.521Z",
"durationMs": 23.02
}
```
### `Status`
Ein Objekt, das den Status einer Initialisierungs- oder Aufrufphase beschreibt. Wenn der Status entweder `failure` oder `error` ist, dann enthält das `Status`-Objekt auch ein `errorType`-Feld, das den Fehler beschreibt.
+ **Typ:** – `Object`
+ **Gültige Statuswerte** – `success`\$1`failure`\$1`error`\$1`timeout`
### `TraceContext`
Ein Objekt, das die Eigenschaften einer Ablaufverfolgung beschreibt.
+ **Typ:** – `Object`
Ein `TraceContext`-Objekt hat die folgende Form:
```
TraceContext: Object
- spanId?: String
- type: TracingType enum
- value: String
```
Es folgt ein Beispiel für ein `TraceContext`-Objekt:
```
{
"spanId": "073a49012f3c312e",
"type": "X-Amzn-Trace-Id",
"value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
}
```
### `TracingType`
Eine Zeichenfolgenaufzählung, die den Ablaufverfolgungstyp in einem ``TraceContext``-Objekt beschreibt.
+ **Typ:** – `String`
+ **Gültige Werte** – `X-Amzn-Trace-Id`
# `Event`Lambda-Telemetrie-API-Objekte in Spans konvertieren OpenTelemetry
Das AWS Lambda Telemetrie-API-Schema ist semantisch kompatibel mit (). OpenTelemetry OTel Das bedeutet, dass Sie Ihre AWS Lambda `Event` Telemetrie-API-Objekte in OpenTelemetry () OTel -Spans konvertieren können. Bei der Konvertierung sollten Sie kein einzelnes `Event` Objekt einem einzelnen Span zuordnen. OTel Stattdessen sollten Sie alle drei Ereignisse, die sich auf eine Lebenszyklusphase beziehen, in einem einzigen OTel Span darstellen. Die `start`, `runtimeDone`, und `runtimeReport`-Ereignisse repräsentieren beispielsweise einen einzelnen Funktionsaufruf. Präsentieren Sie alle drei Ereignisse als einen einzigen OTel Span.
Sie können Ihre Ereignisse mithilfe von Span-Ereignissen oder untergeordneten (verschachtelten) Spans konvertieren. In den Tabellen auf dieser Seite werden die Zuordnungen zwischen den Eigenschaften des Telemetrie-API-Schemas und den OTel Span-Eigenschaften für beide Ansätze beschrieben. Weitere Informationen zu OTel Spans finden Sie unter [Span](https://opentelemetry.io/docs/reference/specification/trace/api/#span) auf der **Tracing-API-Seite** der Docs-Website. OpenTelemetry
**Topics**
+ [Ordnen Sie OTel Spans mit Span-Ereignissen zu](#telemetry-otel-span-events)
+ [Ordnen Sie OTel Spans mit untergeordneten Spans zu](#telemetry-otel-child-spans)
## Ordnen Sie OTel Spans mit Span-Ereignissen zu
In den folgenden Tabellen stellt `e` das Ereignis dar, das von der Telemetrie-Quelle stammt.
**Zuordnung der \$1Start-Ereignisse**
| OpenTelemetry | Schema der Lambda-Telemetrie-API |
| --- | --- |
| `Span.Name` | Ihre Erweiterung generiert diesen Wert basierend auf dem `type`-Feld. |
| `Span.StartTime` | Verwenden Sie `e.time`. |
| `Span.EndTime` | Nicht zutreffend, da das Ereignis noch nicht abgeschlossen ist. |
| `Span.Kind` | Setzen Sie diesen Wert auf `Server`. |
| `Span.Status` | Setzen Sie diesen Wert auf `Unset`. |
| `Span.TraceId` | Analysieren Sie den in gefundenen AWS X-Ray Header `e.tracing.value` und verwenden Sie dann den `TraceId` Wert. |
| `Span.ParentId` | Analysieren Sie den X-Ray-Header, der in `e.tracing.value` gefunden wurde, und verwenden Sie dann den `Parent`-Wert. |
| `Span.SpanId` | Verwenden Sie `e.tracing.spanId`, falls verfügbar. Generieren Sie andernfalls eine neue `SpanId`. |
| `Span.SpanContext.TraceState` | Nicht zutreffend für einen X-Ray-Ablaufverfolgungskontext. |
| `Span.SpanContext.TraceFlags` | Analysieren Sie den X-Ray-Header, der in `e.tracing.value` gefunden wurde, und verwenden Sie dann den `Sampled`-Wert. |
| `Span.Attributes` | Ihre Erweiterung kann hier beliebige benutzerdefinierte Werte hinzufügen. |
**Zuordnen der RuntimeDone \$1-Ereignisse**
| OpenTelemetry | Schema der Lambda-Telemetrie-API |
| --- | --- |
| `Span.Name` | Ihre Erweiterung generiert den Wert basierend auf dem `type`-Feld. |
| `Span.StartTime` | Verwenden Sie `e.time` aus dem übereinstimmenden `*Start`-Ereignis. Als alternative Vorgehensweise verwenden Sie `e.time - e.metrics.durationMs`. |
| `Span.EndTime` | Nicht zutreffend, da das Ereignis noch nicht abgeschlossen ist. |
| `Span.Kind` | Setzen Sie diesen Wert auf `Server`. |
| `Span.Status` | Wenn `e.status` nicht gleich `success` ist, dann Wert auf `Error` festlegen. Ansonsten auf `Ok` festlegen. |
| `Span.Events[]` | Verwenden Sie `e.spans[]`. |
| `Span.Events[i].Name` | Verwenden Sie `e.spans[i].name`. |
| `Span.Events[i].Time` | Verwenden Sie `e.spans[i].start`. |
| `Span.TraceId` | Analysieren Sie den in gefundenen AWS X-Ray Header `e.tracing.value` und verwenden Sie dann den `TraceId` Wert. |
| `Span.ParentId` | Analysieren Sie den X-Ray-Header, der in `e.tracing.value` gefunden wurde, und verwenden Sie dann den `Parent`-Wert. |
| `Span.SpanId` | Verwenden Sie dieselbe `SpanId` aus dem `*Start`-Ereignis. Falls nicht verfügbar, verwenden Sie `e.tracing.spanId` oder generieren Sie eine neue `SpanId`. |
| `Span.SpanContext.TraceState` | Nicht zutreffend für einen X-Ray-Ablaufverfolgungskontext. |
| `Span.SpanContext.TraceFlags` | Analysieren Sie den X-Ray-Header, der in `e.tracing.value` gefunden wurde, und verwenden Sie dann den `Sampled`-Wert. |
| `Span.Attributes` | Ihre Erweiterung kann hier beliebige benutzerdefinierte Werte hinzufügen. |
**Zuordnung der \$1Report-Ereignisse**
| OpenTelemetry | Schema der Lambda-Telemetrie-API |
| --- | --- |
| `Span.Name` | Ihre Erweiterung generiert den Wert basierend auf dem `type`-Feld. |
| `Span.StartTime` | Verwenden Sie `e.time` aus dem übereinstimmenden `*Start`-Ereignis. Als alternative Vorgehensweise verwenden Sie `e.time - e.metrics.durationMs`. |
| `Span.EndTime` | Verwenden Sie `e.time`. |
| `Span.Kind` | Setzen Sie diesen Wert auf `Server`. |
| `Span.Status` | Verwenden Sie den gleichen Wert wie das `*RuntimeDone`-Ereignis. |
| `Span.TraceId` | Analysieren Sie den AWS X-Ray Header, der in gefunden wurde`e.tracing.value`, und verwenden Sie dann den `TraceId` Wert. |
| `Span.ParentId` | Analysieren Sie den X-Ray-Header, der in `e.tracing.value` gefunden wurde, und verwenden Sie dann den `Parent`-Wert. |
| `Span.SpanId` | Verwenden Sie dieselbe `SpanId` aus dem `*Start`-Ereignis. Falls nicht verfügbar, verwenden Sie `e.tracing.spanId` oder generieren Sie eine neue `SpanId`. |
| `Span.SpanContext.TraceState` | Nicht zutreffend für einen X-Ray-Ablaufverfolgungskontext. |
| `Span.SpanContext.TraceFlags` | Analysieren Sie den X-Ray-Header, der in `e.tracing.value` gefunden wurde, und verwenden Sie dann den `Sampled`-Wert. |
| `Span.Attributes` | Ihre Erweiterung kann hier beliebige benutzerdefinierte Werte hinzufügen. |
## Ordnen Sie OTel Spans mit untergeordneten Spans zu
In der folgenden Tabelle wird beschrieben, wie Lambda-Telemetrie-API-Ereignisse in OTel Spans mit untergeordneten (verschachtelten) Spans for Spans konvertiert werden. `*RuntimeDone` Informationen zu `*Start`- und `*Report`-Zuordnungen finden Sie in den Tabellen in [Ordnen Sie OTel Spans mit Span-Ereignissen zu](#telemetry-otel-span-events), da diese für untergeordnete Spans identisch sind. In dieser Tabelle stellt `e` das Ereignis dar, das von der Telemetrie-Quelle stammt.
**RuntimeDone Zuordnung der \$1-Ereignisse**
| OpenTelemetry | Schema der Lambda-Telemetrie-API |
| --- | --- |
| `Span.Name` | Ihre Erweiterung generiert den Wert basierend auf dem `type`-Feld. |
| `Span.StartTime` | Verwenden Sie `e.time` aus dem übereinstimmenden `*Start`-Ereignis. Als alternative Vorgehensweise verwenden Sie `e.time - e.metrics.durationMs`. |
| `Span.EndTime` | Nicht zutreffend, da das Ereignis noch nicht abgeschlossen ist. |
| `Span.Kind` | Setzen Sie diesen Wert auf `Server`. |
| `Span.Status` | Wenn `e.status` nicht gleich `success` ist, dann Wert auf `Error` festlegen. Ansonsten auf `Ok` festlegen. |
| `Span.TraceId` | Analysieren Sie den in gefundenen AWS X-Ray Header `e.tracing.value` und verwenden Sie dann den `TraceId` Wert. |
| `Span.ParentId` | Analysieren Sie den X-Ray-Header, der in `e.tracing.value` gefunden wurde, und verwenden Sie dann den `Parent`-Wert. |
| `Span.SpanId` | Verwenden Sie dieselbe `SpanId` aus dem `*Start`-Ereignis. Falls nicht verfügbar, verwenden Sie `e.tracing.spanId` oder generieren Sie eine neue `SpanId`. |
| `Span.SpanContext.TraceState` | Nicht zutreffend für einen X-Ray-Ablaufverfolgungskontext. |
| `Span.SpanContext.TraceFlags` | Analysieren Sie den X-Ray-Header, der in `e.tracing.value` gefunden wurde, und verwenden Sie dann den `Sampled`-Wert. |
| `Span.Attributes` | Ihre Erweiterung kann hier beliebige benutzerdefinierte Werte hinzufügen. |
| `ChildSpan[i].Name` | Verwenden Sie `e.spans[i].name`. |
| `ChildSpan[i].StartTime` | Verwenden Sie `e.spans[i].start`. |
| `ChildSpan[i].EndTime` | Verwenden Sie `e.spans[i].start + e.spans[i].durations`. |
| `ChildSpan[i].Kind` | Wie bei übergeordnetem `Span.Kind`. |
| `ChildSpan[i].Status` | Wie bei übergeordnetem `Span.Status`. |
| `ChildSpan[i].TraceId` | Wie bei übergeordnetem `Span.TraceId`. |
| `ChildSpan[i].ParentId` | Verwenden Sie die übergeordnete `Span.SpanId`. |
| `ChildSpan[i].SpanId` | Generieren Sie eine neue `SpanId`. |
| `ChildSpan[i].SpanContext.TraceState` | Nicht zutreffend für einen X-Ray-Ablaufverfolgungskontext. |
| `ChildSpan[i].SpanContext.TraceFlags` | Wie bei übergeordnetem `Span.SpanContext.TraceFlags`. |
# Verwendung der Lambda-Protokoll-API
**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 mit einer dieser APIs wird bei jedem Versuch APIs, ein Abonnement über die andere API abzuschließen, ein Fehler zurückgegeben.
**Lambda Managed Instances unterstützen die Logs-API nicht**
Lambda Managed Instances unterstützen die Logs-API nicht. Wenn Sie Funktionen für verwaltete Instanzen verwenden, verwenden Sie stattdessen die [Telemetrie-API](telemetry-api.md). Die Telemetrie-API bietet erweiterte Funktionen für die Erfassung und Verarbeitung von Telemetriedaten aus Ihren Lambda-Funktionen.
Lambda erfasst automatisch Laufzeitprotokolle und streamt sie an Amazon CloudWatch. Dieser Protokolldatenstream enthält die Protokolle, die Ihr Funktionscode und Ihre Erweiterungen generieren, sowie die Protokolle, die Lambda im Rahmen des Funktionsaufrufens generiert.
[Lambda-Erweiterungen](runtimes-extensions-api.md) können die Lambda-Laufzeitprotokoll-API verwenden, um Protokollstreams direkt aus der Lambda-[Ausführungsumgebung](lambda-runtime-environment.md) zu abonnieren. Lambda streamt die Protokolle zur Erweiterung und die Erweiterung kann die Protokolle dann an ein beliebiges bevorzugtes Ziel verarbeiten, filtern und senden.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/logs-api-concept-diagram.png)
Die Logs API ermöglicht es Erweiterungen, drei verschiedene Protokollstreams zu abonnieren:
+ Funktionsprotokolle, die die Lambda-Funktion generiert und in `stdout` oder `stderr` schreibt.
+ Erweiterungsprotokolle, die der Erweiterungscode generiert.
+ Lambda-Plattformprotokolle, die Ereignisse und Fehler im Zusammenhang mit Aufrufen und Erweiterungen aufzeichnen.
**Anmerkung**
Lambda sendet alle Protokolle an CloudWatch, auch wenn eine Erweiterung einen oder mehrere der Protokollstreams abonniert.
**Topics**
+ [Abonnieren des Empfangs von Protokollen](#runtimes-logs-api-subscribing)
+ [Speicherauslastung](#runtimes-logs-api-memory)
+ [Ziel-Protokolle](#runtimes-logs-api-dest)
+ [Pufferung der Konfiguration](#runtimes-logs-api-buffering)
+ [Beispielabonnement](#runtimes-logs-api-subs-example)
+ [Beispielcode für Logs API](#runtimes-logs-api-samples)
+ [Logs API-Referenz](#runtimes-logs-api-ref)
+ [Protokollmeldungen](#runtimes-logs-api-msg)
## Abonnieren des Empfangs von Protokollen
Eine Lambda-Erweiterung kann den Empfang von Protokollen abonnieren, indem sie eine Abonnementanfrage an die Protokoll-API sendet.
Um den Empfang von Protokollen zu abonnieren, benötigen Sie die Erweiterungskennung (`Lambda-Extension-Identifier`). [Registrieren Sie zunächst die Erweiterung](runtimes-extensions-api.md#extensions-registration-api-a) , um die Erweiterungskennung zu erhalten. Abonnieren Sie dann während der [Initialisierung](lambda-runtime-environment.md#runtimes-lifecycle-ib) die Logs API. Lambda verarbeitet nach Abschluss der Initialisierungsphase keine Abonnementanfragen.
**Anmerkung**
Das Logs API-Abonnement ist idempotent. Doppelte Abonnementanfragen führen nicht zu doppelten Abonnements.
## Speicherauslastung
Die Speichernutzung steigt linear, wenn die Anzahl der Abonnenten zunimmt. Abonnements verbrauchen Speicherressourcen, da jedes Abonnement einen neuen Speicherpuffer zum Speichern der Protokolle öffnet. Um die Speicherauslastung zu optimieren, können Sie die [Pufferungskonfiguration](#runtimes-logs-api-buffering)anpassen. Die Pufferspeichernutzung wird zum Gesamtspeicherverbrauch in der Ausführungsumgebung gezählt.
## Ziel-Protokolle
Sie können eines der folgenden Protokolle auswählen, um die Logs zu erhalten:
1. **HTTP** (empfohlen) – Lambda stellt Protokolle als Array von Datensätzen im JSON-Format an einen lokalen HTTP-Endpunkt (`http://sandbox.localdomain:${PORT}/${PATH}`) bereit. Der Parameter `$PATH` ist optional. Beachten Sie, dass nur HTTP unterstützt wird, nicht HTTPS. Sie können wählen, ob Sie Logs über PUT oder POST erhalten möchten.
1. **TCP** – Lambda stellt Protokolle an einen TCP-Port im [Newline-delimited-JSON-(NDJSON)-Format](https://github.com/ndjson/ndjson-spec) bereit.
Wir empfehlen, HTTP statt TCP zu verwenden. Mit TCP kann die Lambda-Plattform nicht bestätigen, wenn es Protokolle an die Anwendungsebene übermittelt. Daher können Sie Protokolle verlieren, wenn Ihre Erweiterung abstürzt. Bei HTTP gilt diese Einschränkung nicht.
Wir empfehlen außerdem, den lokalen HTTP-Listener oder den TCP-Port einzurichten, bevor Sie sich für den Empfang von Protokollen anmelden. Beachten Sie bei der Einrichtung Folgendes:
+ Lambda sendet Protokolle nur an Ziele, die sich innerhalb der Ausführungsumgebung befinden.
+ Lambda wiederholt den Versuch, die Protokolle (mit Backoff) zu senden, wenn es keinen Listener gibt oder wenn die POST- oder PUT-Anfrage zu einem Fehler führt. Wenn der Protokoll-Subscriber abstürzt, erhält er nach dem Neustart der Ausführungsumgebung durch Lambda weiterhin Protokolle.
+ Lambda reserviert Port 9001. Es gibt keine weiteren Einschränkungen oder Empfehlungen für Portnummern.
## Pufferung der Konfiguration
Lambda kann Protokolle puffern und an den Subscriber liefern. Sie können dieses Verhalten in der Abonnementanfrage konfigurieren, indem Sie die folgenden optionalen Felder angeben. Beachten Sie, dass Lambda den Standardwert für jedes Feld verwenden wird, das Sie nicht angeben.
+ **timeoutMs** – Die maximale Zeit (in Millisekunden) zum Puffern eines Batches. Standard: 1 000. Minimum: 25. Höchstwert: 30 000.
+ **maxBytes** – Die maximale Größe (in Byte) der Protokolle, die im Speicher gepuffert werden sollen. Standard: 262 144. Mindestwert: 262 144. Höchstwert: 1 048 576.
+ **maxItems** – Die maximale Anzahl der Ereignisse im Speicher, die gepuffert werden sollen. Standard: 10 000. Mindestwert 1 000. Höchstwert: 10 000.
Beachten Sie bei der Pufferung die folgenden Punkte:
+ Lambda bereinigt die Protokolle, wenn einer der Eingabestreams geschlossen wird, z. B. wenn die Laufzeit abstürzt.
+ Jeder Subscriber kann in seiner Abonnementanfrage eine andere Pufferungskonfiguration angeben.
+ Berücksichtigen Sie die Puffergröße, die Sie zum Lesen der Daten benötigen. Gehen Sie davon aus, dass die Nutzlasten so groß wie `2*maxBytes+metadata` sein werden, wo `maxBytes` in der Abonnementanfrage konfiguriert ist. Lambda fügt beispielsweise jedem Datensatz die folgenden Metadaten-Bytes hinzu:
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "function",
"record": "Hello World"
}
```
+ Wenn der Subscriber eingehende Protokolle nicht schnell genug verarbeiten kann, wird Lambda Protokolle möglicherweise löschen, um die Speicherauslastung begrenzt zu halten. Um die Anzahl der gelöschten Datensätze anzugeben, schickt Lambda ein `platform.logsDropped`-Protokoll. Weitere Informationen finden Sie unter [Lambda: Nicht alle Protokolle meiner Funktion werden angezeigt](troubleshooting-execution.md#troubleshooting-execution-missinglogs).
## Beispielabonnement
Das folgende Beispiel zeigt eine Anfrage zum Abonnieren der Plattform- und Funktionsprotokolle.
```
PUT http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs HTTP/1.1
{ "schemaVersion": "2020-08-15",
"types": [
"platform",
"function"
],
"buffering": {
"maxItems": 1000,
"maxBytes": 262144,
"timeoutMs": 100
},
"destination": {
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080/lambda_logs"
}
}
```
Wenn die Anfrage erfolgreich ist, erhält der Subscriber eine Erfolgsantwort von HTTP 200.
```
HTTP/1.1 200 OK
"OK"
```
## Beispielcode für Logs API
Einen Beispielcode, der zeigt, wie Logs an ein benutzerdefiniertes Ziel gesendet werden, finden Sie im [AWS LambdaAWS Compute-Blog unter Verwenden von Erweiterungen zum Senden von Logs an benutzerdefinierte Ziele](https://aws.amazon.com/blogs/compute/using-aws-lambda-extensions-to-send-logs-to-custom-destinations/).
Codebeispiele für Python und Go, die zeigen, wie Sie eine grundlegende Lambda-Erweiterung entwickeln und die Logs-API abonnieren, finden Sie unter [AWS Lambda Erweiterungen](https://github.com/aws-samples/aws-lambda-extensions) im AWS GitHub Samples-Repository. Für weitere Informationen zum Erstellen einer Lambda-Erweiterung siehe [Verwendung der Lambda-Erweiterungs-API zur Erstellung von Erweiterungen](runtimes-extensions-api.md).
## Logs API-Referenz
Sie können den Wert des API-Endpunkts aus der `AWS_LAMBDA_RUNTIME_API`-Umgebungsvariablen abrufen. Um eine API-Anfrage zu senden, verwenden Sie das Präfix `2020-08-15/` vor dem API-Pfad. Beispiel:
```
http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs
```
[Die OpenAPI-Spezifikation für die Logs-API-Version **2020-08-15** ist hier verfügbar: .zip logs-api-request](samples/logs-api-request.zip)
### Abonnieren
Um einen oder mehrere der in der Lambda-Ausführungsumgebung verfügbaren Protokollstreams zu abonnieren, senden Erweiterungen eine Abonnement-API-Anforderung.
**Pfad** – `/logs`
**Methode** – **PUT**
**Body-Parameter**
`destination` – Siehe [Ziel-Protokolle](#runtimes-logs-api-dest). Erforderlich: ja Typ: Strings.
`buffering` – Siehe [Pufferung der Konfiguration](#runtimes-logs-api-buffering). Erforderlich: Nein Typ: Strings.
`types` – Ein Array der zu empfangenden Protokollentypen. Erforderlich: ja Typ: Zeichenfolge-Array Gültige Werte: „platform“, „function“, „extension“.
`schemaVersion` – Erforderlich: Nein. Standardwert: „2020-08-15“. Stellen Sie „2021-03-18“ ein, damit die Erweiterung [`platform.runtimeDone`](#runtimes-logs-api-ref-done)-Meldungen empfangen kann.
****Antwortparameter****
Die OpenAPI-Spezifikationen für die Abonnementantworten, Version **2020-08-15**, stehen für HTTP- und TCP-Protokolle zur Verfügung:
+ [logs-api-http-responseHTTP](samples/logs-api-http-response.zip): .zip
+ [TCP: .zip logs-api-tcp-response](samples/logs-api-tcp-response.zip)
****Antwortcodes****
+ 200 – Anfrage erfolgreich abgeschlossen
+ 202 – Anfrage wurde akzeptiert. Antwort auf eine Abonnementanfrage während lokaler Tests.
+ 4XX – Ungültige Anfrage
+ 500 – Servicefehler
Wenn die Anfrage erfolgreich ist, erhält der Subscriber eine Erfolgsantwort von HTTP 200.
```
HTTP/1.1 200 OK
"OK"
```
Schlägt die Anfrage fehl, erhält der Subscriber eine Fehlerantwort. Zum Beispiel:
```
HTTP/1.1 400 OK
{
"errorType": "Logs.ValidationError",
"errorMessage": URI port is not provided; types should not be empty"
}
```
## Protokollmeldungen
Die Logs API ermöglicht es Erweiterungen, drei verschiedene Protokollstreams zu abonnieren:
+ Funktion – Protokolle, die die Lambda-Funktion generiert und in `stdout` oder `stderr` schreibt.
+ Erweiterung – Protokolle, die der Erweiterungscode generiert.
+ Plattform – Protokolle, die von der Laufzeitplattform generiert werden und die Ereignisse und Fehler im Zusammenhang mit Aufrufen und Erweiterungen aufzeichnen.
**Topics**
+ [Funktionsprotokolle](#runtimes-logs-api-msg-function)
+ [Erweiterungsprotokolle](#runtimes-logs-api-msg-extension)
+ [Plattformprotokolle](#runtimes-logs-api-msg-platform)
### Funktionsprotokolle
Die Lambda-Funktion und interne Erweiterungen generieren Funktionsprotokolle und schreiben sie in `stdout` oder `stderr`.
Das folgende Beispiel zeigt das Format einer Funktionsprotokollmeldung. \$1„time“: „2020-08-20T12:31:32.123Z“, „type“: „function“, „record“: „ERROR encountered. Stack trace:\$1n\$1my-function (line 10)\$1n" \$1
### Erweiterungsprotokolle
Erweiterungen können Erweiterungsprotokolle generieren. Das Protokollformat ist das gleiche wie bei einem Funktionsprotokoll.
### Plattformprotokolle
Lambda generiert Protokollmeldungen für Plattformereignisse wie `platform.start`, `platform.end` und `platform.fault`.
Optional können Sie die Version **2021-03-18** des Logs API-Schemas abonnieren, welche die `platform.runtimeDone`-Protokollmeldungen enthält.
#### Beispiel für Plattformprotokollmeldungen
Das folgende Beispiel zeigt die Plattformstart- und Plattformendprotokolle. Diese Protokolle zeigen die Startzeit des Aufrufs und die Endzeit des Aufrufs für den Aufruf an, den die RequestID angibt.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.start",
"record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56"}
}
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.end",
"record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56"}
}
```
Die **Plattform. initRuntimeDone**Die Protokollnachricht zeigt den Status der `Runtime init` Unterphase an, die Teil der [Init-Lebenszyklusphase](lambda-runtime-environment.md#runtimes-lifecycle-ib) ist. Wenn `Runtime init` erfolgreich ist, sendet die Laufzeit eine `/next`-Laufzeit-API-Anfrage (für die `on-demand`- und `provisioned-concurrency`-Initialisierungstypen) oder `restore/next` (für den `snap-start`-Initialisierungstyp). **Das folgende Beispiel zeigt eine erfolgreiche Plattform. initRuntimeDone**Protokollnachricht für den `snap-start` Initialisierungstyp.
```
{
"time":"2022-07-17T18:41:57.083Z",
"type":"platform.initRuntimeDone",
"record":{
"initializationType":"snap-start",
"status":"success"
}
}
```
Die **platform.initReport**-Protokollnachricht zeigt, wie lange die `Init`-Phase gedauert hat und wie viele Millisekunden Ihnen während dieser Phase in Rechnung gestellt wurden. Wenn der Initialisierungstyp `provisioned-concurrency` lautet, sendet Lambda diese Nachricht während des Aufrufs. Wenn der Initialisierungstyp `snap-start` lautet, sendet Lambda diese Nachricht nach der Wiederherstellung des Snapshots. Das folgende Beispiel zeigt eine **platform.initReport**-Protokollnachricht für den `snap-start`-Initialisierungstyp.
```
{
"time":"2022-07-17T18:41:57.083Z",
"type":"platform.initReport",
"record":{
"initializationType":"snap-start",
"metrics":{
"durationMs":731.79,
"billedDurationMs":732
}
}
}
```
Das Berichtsprotokoll der Plattform enthält Metriken über den Aufruf, den die RequestID angibt. Das `initDurationMs`-Feld ist nur dann im Protokoll enthalten, wenn der Aufruf einen Kaltstart enthielt. Wenn die AWS X-Ray -Ablaufverfolgung aktiv ist, enthält das Protokoll X-Ray-Metadaten. Das folgende Beispiel zeigt ein Plattformberichtsprotokoll für einen Aufruf, der einen Kaltstart enthielt.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.report",
"record": {"requestId": "6f7f0961f83442118a7af6fe80b88d56",
"metrics": {"durationMs": 101.51,
"billedDurationMs": 300,
"memorySizeMB": 512,
"maxMemoryUsedMB": 33,
"initDurationMs": 116.67
}
}
}
```
Das Plattformfehlerprotokoll erfasst Fehler bei der Laufzeit oder der Ausführungsumgebung. Das folgende Beispiel zeigt eine Fehlerprotokollmeldung der Plattform.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.fault",
"record": "RequestId: d783b35e-a91d-4251-af17-035953428a2c Process exited before completing request"
}
```
**Anmerkung**
AWS implementiert derzeit Änderungen am Lambda-Service. Aufgrund dieser Änderungen können geringfügige Unterschiede in Struktur und Inhalt der Systemprotokollmeldungen und Trace-Segmente auftreten, die von verschiedenen Lambda-Funktionen in Ihrem AWS-Konto.
Eine der von dieser Änderung betroffenen Protokollausgaben ist das Feld `"record"` des Plattformfehlerprotokolls. Die folgenden Beispiele zeigen illustrative `"record"`-Felder im alten und neuen Format. Der neue Stil des Fehlerprotokolls enthält eine prägnantere Meldung
Diese Änderungen werden in den kommenden Wochen umgesetzt, und alle Funktionen AWS-Regionen außer China und den GovCloud Regionen werden auf die Verwendung der Protokollnachrichten und Trace-Segmente im neuen Format umgestellt.
**Example Aufzeichnung des Plattformfehlerprotokolls (alter Stil)**
```
"record":"RequestId: ...\tError: Runtime exited with error: exit status 255\nRuntime.ExitError"
```
**Example Aufzeichnung des Plattformfehlerprotokolls (neuer Stil)**
```
"record":"RequestId: ... Status: error\tErrorType: Runtime.ExitError"
```
Lambda generiert ein Plattformerweiterungsprotokoll, wenn sich eine Erweiterung bei der Erweiterungs-API registriert. Das folgende Beispiel zeigt eine Plattformerweiterungsmeldung.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.extension",
"record": {"name": "Foo.bar",
"state": "Ready",
"events": ["INVOKE", "SHUTDOWN"]
}
}
```
Lambda generiert ein Plattformprotokoll-Abonnementprotokoll, wenn eine Erweiterung die Protokoll-API abonniert. Das folgende Beispiel zeigt eine Protokoll-Abonnementmeldung.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.logsSubscription",
"record": {"name": "Foo.bar",
"state": "Subscribed",
"types": ["function", "platform"],
}
}
```
Lambda generiert ein vom Plattformprotokoll abgelegtes Protokoll, wenn eine Erweiterung nicht in der Lage ist, die Anzahl der Protokolle zu verarbeiten, die sie empfängt. Das folgende Beispiel zeigt eine `platform.logsDropped`-Protokollmeldung.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.logsDropped",
"record": {"reason": "Consumer seems to have fallen behind as it has not acknowledged receipt of logs.",
"droppedRecords": 123,
"droppedBytes" 12345
}
}
```
Die **platform.restoreStart**-Protokollnachricht zeigt den Zeitpunkt an, zu dem die `Restore`-Phase begonnen hat (nur `snap-start`-Initialisierungstyp). Beispiel:
```
{
"time":"2022-07-17T18:43:44.782Z",
"type":"platform.restoreStart",
"record":{}
}
```
Die **platform.restoreReport**-Protokollnachricht zeigt, wie lange die `Restore`-Phase gedauert hat und wie viele Millisekunden Ihnen während dieser Phase in Rechnung gestellt wurden (nur `snap-start`-Initialisierungstyp). Beispiel:
```
{
"time":"2022-07-17T18:43:45.936Z",
"type":"platform.restoreReport",
"record":{
"metrics":{
"durationMs":70.87,
"billedDurationMs":13
}
}
}
```
#### Plattform `runtimeDone`-Meldungen
Wenn Sie die Schemaversion in der Abonnementanforderung auf „2021-03-18“ setzen, schickt Lambda eine `platform.runtimeDone`-Meldung, nachdem der Funktionsaufruf entweder erfolgreich oder mit einem Fehler abgeschlossen wurde. Die Erweiterung kann diese Meldung verwenden, um die gesamte Telemetrie-Sammlung für diesen Funktionsaufruf anzuhalten.
Die OpenAPI-Spezifikation für den Protokollereignistyp in der Schemaversion **2021-03-18** ist hier verfügbar: [schema-2021-03-18.zip](samples/schema-2021-03-18.zip)
Lambda generiert die `platform.runtimeDone`-Protokollmeldung, wenn die Laufzeitumgebung eine `Next`- oder `Error`-Laufzeit-API-Anforderung sendet. Das `platform.runtimeDone`-Protokoll informiert die Verbraucher über die Protokoll-API, dass der Funktionsaufruf abgeschlossen ist. Erweiterungen können diese Informationen verwenden, um zu entscheiden, wann die gesamte während dieses Aufrufs gesammelte Telemetrie gesendet werden soll.
##### Beispiele
Lambda sendet die `platform.runtimeDone`-Meldung, nachdem die Laufzeit die NEXT-Anfrage sendet, wenn der Funktionsaufruf abgeschlossen wird. Die folgenden Beispiele zeigen Meldungen für jeden der Statuswerte: Erfolg, Misserfolg und Timeout.
**Example Beispiel Erfolgsmeldung**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "success"
}
}
```
**Example Beispiel Misserfolgsmeldung**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "failure"
}
}
```
**Example Beispiel Timeout-Meldung**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "timeout"
}
}
```
**Example Beispiel für eine Plattform. restoreRuntimeDone Nachricht (nur `snap-start` Initialisierungstyp)**
Die **Plattform. restoreRuntimeDone**Die Protokollnachricht zeigt, ob die `Restore` Phase erfolgreich war oder nicht. Lambda sendet diese Nachricht, wenn die Laufzeit eine `restore/next`-Laufzeit-API-Anfrage sendet. Es gibt drei mögliche Status: erfolgreich, fehlgeschlagen und Timeout. Das folgende Beispiel zeigt eine erfolgreiche **Plattform. restoreRuntimeDone**Nachricht protokollieren.
```
{
"time":"2022-07-17T18:43:45.936Z",
"type":"platform.restoreRuntimeDone",
"record":{
"status":"success"
}
}
```