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-Funktionen mit Lambda-Erweiterungen erweitern
Sie können Lambda-Erweiterungen verwenden, um Ihre Lambda-Funktionen zu erweitern. Verwenden Sie beispielsweise Lambda-Erweiterungen, um Funktionen in Ihre bevorzugten Überwachungs-, Beobachtbarkeits-, Sicherheits- und Governance-Tools zu integrieren. Sie können aus einer Vielzahl von Tools wählen, die von [AWS Lambda -Partnern](https://aws.amazon.com/lambda/partners/) bereitgestellt werden, oder Sie können [Ihre eigenen Lambda-Erweiterungen erstellen](runtimes-extensions-api.md).
Lambda unterstützt externe und interne Erweiterungen. Eine externe Erweiterung wird als unabhängiger Prozess in der Ausführungsumgebung ausgeführt und wird weiterhin ausgeführt, nachdem der Funktionsaufruf vollständig verarbeitet wurde. Da Erweiterungen als separate Prozesse ausgeführt werden, können Sie sie in einer anderen Sprache als die Funktion schreiben. Alle [Lambda-Laufzeiten](lambda-runtimes.md) unterstützen Erweiterungen.
Eine interne Erweiterung wird als Teil des Laufzeitprozesses ausgeführt. Ihre Funktion greift auf interne Erweiterungen zu, indem Sie Wrapper-Skripte oder In-Process-Mechanismen wie verwende `JAVA_TOOL_OPTIONS`. Weitere Informationen finden Sie unter [Ändern der Laufzeitumgebung](runtimes-modify.md).
Sie können einer Funktion Erweiterungen hinzufügen, indem Sie die Lambda-Konsole, die Dienste AWS Command Line Interface (AWS CLI) oder Infrastructure as Code (IaC) und Tools wie CloudFormation, AWS Serverless Application Model (AWS SAM) und Terraform verwenden.
Ihnen wird die Ausführungszeit berechnet, die von der Erweiterung verbraucht wird (in Schritten von 1 ms). Es fallen keine Kosten für die Installation eigener Erweiterungen an. Weitere Informationen zur Preisgestaltung für Erweiterungen finden Sie unter [AWS Lambda -Preise](https://aws.amazon.com/lambda/pricing/). Preisinformationen zu Partnererweiterungen finden Sie auf den Websites dieser Partner. Eine Liste der offiziellen Partnererweiterungen finden Sie unter [AWS Lambda-Partner für Erweiterungen](extensions-api-partners.md).
**Topics**
+ [
## Ausführungsumgebung
](#using-extensions-env)
+ [
## Auswirkungen auf Leistung und Ressourcen
](#using-extensions-reg)
+ [
## Berechtigungen
](#using-extensions-permissions)
+ [
# Konfigurieren von Lambda-Erweiterungen
](extensions-configuration.md)
+ [
# AWS Lambda-Partner für Erweiterungen
](extensions-api-partners.md)
+ [
# Verwendung der Lambda-Erweiterungs-API zur Erstellung von Erweiterungen
](runtimes-extensions-api.md)
+ [
# Zugriff auf Echtzeit-Telemetriedaten für Erweiterungen über die Telemetrie-API
](telemetry-api.md)
## Ausführungsumgebung
Lambda ruft Ihre Funktion in einer [Ausführungsumgebung](lambda-runtime-environment.md) auf, die eine sichere und isolierte Laufzeitumgebung bereitstellt. Die Ausführungsumgebung verwaltet die Ressourcen, die zum Ausführen Ihrer Funktion erforderlich sind, und bietet Lebenszyklusunterstützung für die Laufzeit und die Erweiterungen der Funktion.
Der Lebenszyklus der Ausführungsumgebung umfasst die folgenden Phasen:
+ `Init`: In dieser Phase erstellt oder hebt Lambda eine Ausführungsumgebung mit den konfigurierten Ressourcen auf, lädt den Code für die Funktion und alle Ebenen herunter, initialisiert alle Erweiterungen, initialisiert die Laufzeit und führt dann den Initialisierungscode der Funktion (der Code außerhalb des Haupthandlers) aus. Die Phase `Init` erfolgt entweder während des ersten Aufrufs oder vor Funktionsaufrufen, wenn Sie die [bereitgestellte Parallelität](provisioned-concurrency.md) aktiviert haben.
Die `Init`-Phase ist in drei Unterphasen unterteilt: `Extension init`, `Runtime init` und `Function init`. Diese Unterphasen stellen sicher, dass alle Erweiterungen und die Laufzeit ihre Einrichtungs-Aufgaben abschließen, bevor der Funktionscode ausgeführt wird.
Wenn [Lambda SnapStart](snapstart.md) aktiviert ist, findet die `Init`-Phase statt, wenn Sie eine Funktionsversion veröffentlichen. Lambda speichert einen Snapshot des Arbeitsspeichers und des Festplattenzustands der initialisierten Ausführungsumgebung, speichert den verschlüsselten Snapshot und speichert ihn im Cache für den Zugriff mit geringer Latenz. Wenn Sie einen [Laufzeit-Hook](snapstart-runtime-hooks.md) vor dem Prüfpunkt haben, wird der Code am Ende der `Init`-Phase ausgeführt.
+ `Restore`(SnapStart nur): Wenn Sie eine [SnapStart](snapstart.md)Funktion zum ersten Mal aufrufen und die Funktion skaliert wird, nimmt Lambda neue Ausführungsumgebungen aus dem persistenten Snapshot wieder auf, anstatt die Funktion von Grund auf neu zu initialisieren. Wenn Sie über einen [Laufzeit-Hook](snapstart-runtime-hooks.md) nach der Wiederherstellung verfügen, wird der Code am Ende der `Restore`-Phase ausgeführt. Die Dauer von Laufzeit-Hooks nach der Wiederherstellung wird Ihnen in Rechnung gestellt. Die Laufzeit muss geladen werden und Laufzeit-Hooks nach der Wiederherstellung müssen innerhalb des Timeout-Limits (10 Sekunden) abgeschlossen werden. Andernfalls erhalten Sie eine. SnapStartTimeoutException Wenn die `Restore`-Phase abgeschlossen ist, ruft Lambda den Funktionshandler ([Invoke-Phase](lambda-runtime-environment.md#runtimes-lifecycle-invoke)) auf.
+ `Invoke`: In dieser Phase ruft Lambda den Funktionshandler auf. Nachdem die Funktion vollständig ausgeführt wurde, bereitet sich Lambda auf die Verarbeitung eines weiteren Funktionsaufrufs vor.
+ `Shutdown`: Diese Phase wird ausgelöst, wenn die Lambda-Funktion für einen bestimmten Zeitraum keine Aufrufe empfängt. In dieser `Shutdown`-Phase fährt Lambda die Laufzeit herunter, warnt die Erweiterungen, damit sie sauber beendet werden können und entfernt dann die Umgebung. Lambda sendet ein `Shutdown`-Ereignis an jede Erweiterung, das der Erweiterung mitteilt, dass die Umgebung beendet wird.
Während der `Init`-Phase extrahiert Lambda Ebenen, die Erweiterungen enthalten, in das `/opt`-Verzeichnis in der Ausführungsumgebung. Lambda sucht im `/opt/extensions/`-Verzeichnis nach Erweiterungen, interpretiert jede Datei als ausführbaren Bootstrap zum Starten der Erweiterung und startet alle Erweiterungen parallel.
## Auswirkungen auf Leistung und Ressourcen
Die Größe der Erweiterungen Ihrer Funktion zählt für die Größenbeschränkung des Bereitstellungspakets. Bei einem ZIP-Dateiarchiv darf die entpackte Gesamtgröße der Funktion und sämtlicher Erweiterungen das Limit des entpackten Bereitstellungspakets von 250 MB nicht überschreiten.
Erweiterungen können sich auf die Leistung Ihrer Funktion auswirken, da sie Funktionsressourcen wie CPU, Arbeitsspeicher und Speicher gemeinsam nutzen. Wenn eine Erweiterung beispielsweise rechenintensive Operationen ausführt, kann die Ausführungsdauer Ihrer Funktion erhöht werden.
Jede Erweiterung muss ihre Initialisierung abschließen, bevor Lambda die Funktion aufruft. Daher kann eine Erweiterung, die erhebliche Initialisierungszeit verbraucht, die Latenz des Funktionsaufrufs erhöhen.
Um die zusätzliche Zeit zu messen, die die Erweiterung nach der Funktionsausführung benötigt, können Sie die [Funktionsmetrik](monitoring-metrics.md) `PostRuntimeExtensionsDuration` verwenden. Um die Zunahme des verwendeten Speichers zu messen, können Sie die `MaxMemoryUsed`-Metrik verwenden. Um die Auswirkungen einer bestimmten Erweiterung zu verstehen, können Sie verschiedene Versionen Ihrer Funktionen nebeneinander ausführen.
**Anmerkung**
`MaxMemoryUsed` ist eine der [Metriken, die von Lambda Insights erfasst werden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-metrics.html), und keine native Lambda-Metrik.
## Berechtigungen
Erweiterungen haben Zugriff auf die gleichen Ressourcen wie Funktionen. Da Erweiterungen in derselben Umgebung wie die Funktion ausgeführt werden, werden Berechtigungen von der Funktion und der Erweiterung gemeinsam genutzt.
Für ein ZIP-Dateiarchiv können Sie eine CloudFormation Vorlage erstellen, um das Anhängen derselben Erweiterungskonfiguration — einschließlich AWS Identity and Access Management (IAM-) Berechtigungen — an mehrere Funktionen zu vereinfachen.
# Konfigurieren von Lambda-Erweiterungen
## Konfigurieren von Erweiterungen (ZIP-Dateiarchiv)
Sie können Ihrer Funktion eine Erweiterung als [Lambda-Ebene](chapter-layers.md) hinzufügen. Mithilfe von Ebenen können Sie Erweiterungen in Ihrer Organisation oder in der gesamten Lambda-Entwicklercommunity freigeben. Sie können einer Ebene eine oder mehrere Erweiterungen hinzufügen. Sie können bis zu 10 Erweiterungen für eine Funktion registrieren.
Sie fügen die Erweiterung zu Ihrer Funktion hinzu, indem Sie dieselbe Methode verwenden wie für jede Ebene. Weitere Informationen finden Sie unter [Verwaltung von Lambda-Abhängigkeiten mit Ebenen](chapter-layers.md).
**Hinzufügen einer Erweiterung zu Ihrer Funktion (Konsole)**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie eine Funktion aus.
1. Wählen Sie die Registerkarte **Code** aus, falls sie noch nicht ausgewählt ist.
1. Wählen Sie unter **Ebenen** die Option **Bearbeiten** aus.
1. Geben Sie unter **Choose a layer (Ebene auswählen)** **Specify an ARN (Einen ARN angeben)**.
1. Geben Sie unter **Specify an ARN (Einen ARN angeben)**, den Amazon-Ressourcennamen (ARN) einer Erweiterungsebene ein.
1. Wählen Sie **Add** aus.
## Verwenden von Erweiterungen in Container-Images
Sie können Ihrem [Container-Image](images-create.md) Erweiterungen hinzufügen. Die Container-Image-Einstellung ENTRYPOINT gibt den Hauptprozess für die Funktion an. Konfigurieren Sie die Einstellung ENTRYPOINT im Dockerfile oder als Überschreibung in der Funktionskonfiguration.
Sie können mehrere Prozesse in einem Container ausführen. Lambda verwaltet den Lebenszyklus des Hauptprozesses und aller zusätzlichen Prozesse. Lambda verwendet die [Erweiterungs-API](runtimes-extensions-api.md), um den Erweiterungslebenszyklus zu verwalten.
### Beispiel: Hinzufügen einer externen Erweiterung
Eine externe Erweiterung wird in einem separaten Prozess von der Lambda-Funktion ausgeführt. Lambda startet einen Prozess für jede Erweiterung im `/opt/extensions/`-Verzeichnis. Lambda verwendet die Erweiterungs-API, um den Erweiterungslebenszyklus zu verwalten. Nachdem die Funktion bis zum Abschluss ausgeführt wurde, sendet Lambda ein `Shutdown`-Ereignis an jede externe Erweiterung.
**Example Hinzufügen einer externen Erweiterung zu einem Python-Basis-Image**
```
FROM public.ecr.aws/lambda/python:3.11
# Copy and install the app
COPY /app /app
WORKDIR /app
RUN pip install -r requirements.txt
# Add an extension from the local directory into /opt/extensions
ADD my-extension.zip /opt/extensions
CMD python ./my-function.py
```
## Nächste Schritte
Um mehr über Erweiterungen zu erfahren, empfehlen wir die folgenden Ressourcen:
+ Ein grundlegendes Arbeitsbeispiel finden Sie unter [Erweiterungen erstellen für AWS Lambda](https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/) im AWS-Compute-Blog.
+ Informationen zu Erweiterungen, die AWS Lambda-Partner bereitstellen, finden Sie unter [Einführung von AWS Lambda-Erweiterungen](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-extensions-in-preview/) im AWS Compute Blog.
+ Verfügbare Beispiel-Erweiterungen und Wrapper-Skripte finden Sie unter [AWS Lambda Erweiterungen](https://github.com/aws-samples/aws-lambda-extensions) im AWS Samples GitHub Repository.
# AWS Lambda-Partner für Erweiterungen
AWS Lambda hat sich mit mehreren Drittunternehmen zusammengetan, um Erweiterungen zur Integration in Ihre Lambda-Funktionen bereitzustellen. In der folgenden Liste werden Erweiterungen von Drittanbietern aufgeführt, die Sie jederzeit verwenden können.
+ [https://docs.appdynamics.com/display/PRO20X/Use+the+AppDynamics+AWS+Lambda+Extension+to+Instrument+Serverless+APM+at+Runtime](https://docs.appdynamics.com/display/PRO20X/Use+the+AppDynamics+AWS+Lambda+Extension+to+Instrument+Serverless+APM+at+Runtime) – Bietet die automatische Instrumentierung von Node.js- oder Python-Lambda-Funktionen und bietet Sichtbarkeit und Warnungen zur Funktionsleistung.
+ [https://axiom.co/docs/apps/lambda](https://axiom.co/docs/apps/lambda) – Bietet Dashboards zur Überwachung der Leistung von Lambda-Funktionen und aggregierte Metriken auf Systemebene.
+ [https://docs.datadoghq.com/serverless/datadog_lambda_library/extension/](https://docs.datadoghq.com/serverless/datadog_lambda_library/extension/) – Bietet umfassende Echtzeit-Transparenz für Ihre Serverless-Anwendungen durch die Verwendung von Metriken, Nachverfolgungen und Protokollen.
+ [https://www.dynatrace.com/support/help/technology-support/cloud-platforms/amazon-web-services/integrations/deploy-oneagent-as-lambda-extension/](https://www.dynatrace.com/support/help/technology-support/cloud-platforms/amazon-web-services/integrations/deploy-oneagent-as-lambda-extension/) – Bietet Einblick in Nachverfolgungen und Metriken und nutzt KI für die automatisierte Fehlererkennung und Ursachenanalyse über den gesamten Anwendungs-Stack.
+ [https://www.elastic.co/guide/en/apm/agent/nodejs/current/lambda.html](https://www.elastic.co/guide/en/apm/agent/nodejs/current/lambda.html) – Bietet Application Performance Monitoring (APM) zur Identifizierung und Behebung von Ursachenproblemen mithilfe korrelierter Traces, Metriken und Logs.
+ [https://docs.epsagon.com/docs/environment-monitoring/lambda/intro](https://docs.epsagon.com/docs/environment-monitoring/lambda/intro) – Hört sich Aufrufereignisse an, speichert Nachverfolgungen und sendet sie parallel an Lambda-Funktionsausführungen.
+ [https://docs.fastly.com/signalsciences/install-guides/paas/aws-lambda/](https://docs.fastly.com/signalsciences/install-guides/paas/aws-lambda/)– Schützt Ihre Lambda-Funktionen vor verdächtigen Aktivitäten wie Angriffen im Injektionsstil, Kontoübernahme durch Ausfüllen von Anmeldeinformationen, böswilligen Bots und API-Missbrauch.
+ [https://learn.hashicorp.com/tutorials/vault/aws-lambda](https://learn.hashicorp.com/tutorials/vault/aws-lambda) – Verwaltet Geheimnisse und stellt sie Entwicklern zur Verwendung im Funktionscode zur Verfügung, ohne Funktionen vaultbewusst zu machen.
+ [https://docs.honeycomb.io/getting-data-in/integrations/aws/aws-lambda/](https://docs.honeycomb.io/getting-data-in/integrations/aws/aws-lambda/) – Beobachtbarkeits-Tool zum Debuggen Ihres App-Stacks.
+ [https://docs.lumigo.io/docs/lambda-extensions](https://docs.lumigo.io/docs/lambda-extensions) – Profiliert Lambda-Funktionsaufrufe und sammelt Metriken zur Behebung von Problemen in Serverless- und Microservice-Umgebungen.
+ [https://docs.newrelic.com/docs/serverless-function-monitoring/aws-lambda-monitoring/get-started/monitoring-aws-lambda-serverless-monitoring](https://docs.newrelic.com/docs/serverless-function-monitoring/aws-lambda-monitoring/get-started/monitoring-aws-lambda-serverless-monitoring) – Läuft zusammen mit Lambda-Funktionen und sammelt, verbessert und transportiert Telemetriedaten automatisch zur einheitlichen Beobachtungsplattform von New Relic.
+ [https://docs.sedai.io/get-started/platform/optimization/aws/lambda](https://docs.sedai.io/get-started/platform/optimization/aws/lambda) – Eine autonome, auf KI/ML basierende Cloud-Management-Plattform, die eine kontinuierliche Optimierung für Cloud-Betriebsteams ermöglicht, um Cloud-Kosteneinsparungen, Leistung und Verfügbarkeit im großen Maßstab zu maximieren.
+ [https://docs.sentry.io/platforms/javascript/guides/aws-lambda/](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/) – Diagnostizieren, beheben und optimieren Sie die Leistung von Lambda-Funktionen.
+ [https://www.site24x7.com/help/aws/lambda-execution-logs.html](https://www.site24x7.com/help/aws/lambda-execution-logs.html) – Erreichen Sie Echtzeit-Beobachtbarkeit in Ihren Lambda-Umgebungen
+ [https://github.com/signalfx/splunk-otel-lambda](https://github.com/signalfx/splunk-otel-lambda) – Sammelt hochauflösende Metriken mit niedriger Latenz für eine effiziente und effektive Überwachung von Lambda-Funktionen.
+ [https://help.sumologic.com/03Send-Data/Collect-from-Other-Data-Sources/Collect_AWS_Lambda_Logs_using_an_Extension](https://help.sumologic.com/03Send-Data/Collect-from-Other-Data-Sources/Collect_AWS_Lambda_Logs_using_an_Extension) – Bietet Einblick in den Zustand und die Leistung von Serverless-Anwendungen.
+ [Salt Security](https://salt.security/press-releases/salt-security-becomes-the-first-and-only-api-security-vendor-to-join-aws-lambda-ready-program?) – Vereinfacht die API-Status-Governance und die API-Sicherheit für Lambda-Funktionen durch automatisiertes Setup und Support für verschiedene Laufzeiten.
## AWSVon verwaltete Erweiterungen
AWS stellt eigene verwaltete Erweiterungen bereit, einschließlich:
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions.html#appconfig-integration-lambda-extensions-enabling) – Verwenden Sie Feature-Flags und dynamische Daten, um Ihre Lambda-Funktionen zu aktualisieren. Sie können diese Erweiterung auch verwenden, um andere dynamische Konfigurationen wie Ops-Drosselung und Optimierung zu aktualisieren.
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/python-lambda-layers.html) – Verbessert die Anwendungsleistung und senkt den Preis, indem die teuerste Codezeile einer Anwendung lokalisiert wird und Empfehlungen zur Codeverbesserung erstellt werden.
+ [CloudWatch-Lambda-Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html) – Überwachen, beheben und optimieren Sie die Leistung Ihrer Lambda-Funktionen durch automatisierte Dashboards.
+ [AWS Distro für OpenTelemetry (ADOT)](https://aws.amazon.com/otel) – Aktiviert Funktionen zum Senden von Ablaufverfolgungsdaten an AWS-Überwachungsdienste wie AWS X-Ray und an Ziele, die OpenTelemetry unterstützen, wie Honeycomb und Lightstep.
+ [AWS-Parameter und -Geheimnisse](with-secrets-manager.md) – Sicheres Abrufen von Parametern aus AWS Systems Manager Parameter Store und Geheimnissen aus AWS Secrets Manager in Lambda-Funktionen.
Weitere Erweiterungs-Beispiele und Demo-Projekte finden Sie unter [Erweiterungen für AWS Lambda](https://github.com/aws-samples/aws-lambda-extensions).
# Verwendung der Lambda-Erweiterungs-API zur Erstellung von Erweiterungen
Lambda-Funktionsautoren verwenden Erweiterungen, um Lambda in ihre bevorzugten Tools zur Überwachung, Beobachtbarkeit, Sicherheit und Governance zu integrieren. Funktionsautoren können Erweiterungen von AWS, [AWS Partnern](extensions-api-partners.md) und Open-Source-Projekten verwenden. Weitere Informationen zur Verwendung von Erweiterungen finden Sie unter [Einführung in AWS Lambda Erweiterungen](https://aws.amazon.com/blogs/aws/getting-started-with-using-your-favorite-operational-tools-on-aws-lambda-extensions-are-now-generally-available/) im AWS Compute-Blog. In diesem Abschnitt wird beschrieben, wie Sie die Lambda-Erweiterungs-API, den Lebenszyklus der Lambda-Ausführungsumgebung und die Lambda-Erweiterungs-API-Referenz verwenden.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
Als Erweiterungsautor können Sie die Lambda-Erweiterungs-API verwenden, um sich tief in die Lambda-[Ausführungsumgebung](lambda-runtime-environment.md) zu integrieren. Ihre Erweiterung kann sich für Lebenszyklusereignisse für Funktions- und Ausführungsumgebung registrieren. Als Reaktion auf diese Ereignisse können Sie neue Prozesse starten, Logik ausführen und alle Phasen des Lambda-Lebenszyklus steuern und an ihnen teilnehmen: Initialisierung, Aufruf und Herunterfahren. Darüber hinaus können Sie die [Laufzeitprotokoll-API](runtimes-logs-api.md) verwenden, um einen Stream von Protokollen zu erhalten.
Eine Erweiterung wird als unabhängiger Prozess in der Ausführungsumgebung ausgeführt und kann weiterhin ausgeführt werden, nachdem der Funktionsaufruf vollständig verarbeitet wurde. Da Erweiterungen als Prozesse ausgeführt werden, können Sie diese in einer anderen Sprache als die Funktion schreiben. Es wird empfohlen, Erweiterungen mit einer kompilierten Sprache zu implementieren. In diesem Fall handelt es sich bei der Erweiterung um eine eigenständige Binärdatei, die mit unterstützten Laufzeiten kompatibel ist. Alle [Lambda-Laufzeiten](lambda-runtimes.md) unterstützen Erweiterungen. Wenn Sie eine nicht kompilierte Sprache verwenden, stellen Sie sicher, dass Sie eine kompatible Laufzeit in die Erweiterung aufnehmen.
Lambda unterstützt auch *interne Erweiterungen*. Eine interne Erweiterung wird als separater Thread im Laufzeitprozess ausgeführt. Die Laufzeit startet und stoppt die interne Erweiterung. Eine alternative Möglichkeit zur Integration in die Lambda-Umgebung ist die Verwendung sprachspezifischer [Umgebungsvariablen und Wrapper-Skripte](runtimes-modify.md). Sie können diese nutzen, um die Laufzeitumgebung zu konfigurieren und das Startup-Verhalten des Laufzeitprozesses zu verändern.
Sie können einer Funktion auf zwei Arten Erweiterungen hinzufügen. Bei einer Funktion, die als [.zip-Dateiarchiv](configuration-function-zip.md)bereitgestellt wird, stellen Sie Ihre Erweiterung als [Ebene](chapter-layers.md)bereit. Bei einer Funktion, die als Container-Image definiert ist, fügen Sie [die Erweiterungen](extensions-configuration.md#invocation-extensions-images) Ihrem Container-Image hinzu.
**Anmerkung**
Beispiele für Erweiterungen und Wrapper-Skripte finden Sie unter [AWS Lambda Erweiterungen](https://github.com/aws-samples/aws-lambda-extensions) im AWS GitHub Samples-Repository.
**Topics**
+ [
## Lebenszyklus der Lambda-Ausführungsumgebung
](#runtimes-extensions-api-lifecycle)
+ [
## Erweiterungs-API-Referenz
](#runtimes-extensions-registration-api)
## Lebenszyklus der Lambda-Ausführungsumgebung
Der Lebenszyklus der Ausführungsumgebung umfasst die folgenden Phasen:
+ `Init`: In dieser Phase erstellt oder hebt Lambda eine Ausführungsumgebung mit den konfigurierten Ressourcen auf, lädt den Code für die Funktion und alle Ebenen herunter, initialisiert alle Erweiterungen, initialisiert die Laufzeit und führt dann den Initialisierungscode der Funktion (der Code außerhalb des Haupthandlers) aus. Die Phase `Init` erfolgt entweder während des ersten Aufrufs oder vor Funktionsaufrufen, wenn Sie die [bereitgestellte Parallelität](provisioned-concurrency.md) aktiviert haben.
Die `Init`-Phase ist in drei Unterphasen unterteilt: `Extension init`, `Runtime init` und `Function init`. Diese Unterphasen stellen sicher, dass alle Erweiterungen und die Laufzeit ihre Einrichtungs-Aufgaben abschließen, bevor der Funktionscode ausgeführt wird.
+ `Invoke`: In dieser Phase ruft Lambda den Funktionshandler auf. Nachdem die Funktion vollständig ausgeführt wurde, bereitet sich Lambda auf die Verarbeitung eines weiteren Funktionsaufrufs vor.
+ `Shutdown`: Diese Phase wird ausgelöst, wenn die Lambda-Funktion für einen bestimmten Zeitraum keine Aufrufe empfängt. In dieser `Shutdown`-Phase fährt Lambda die Laufzeit herunter, warnt die Erweiterungen, damit sie sauber beendet werden können und entfernt dann die Umgebung. Lambda sendet ein `Shutdown`-Ereignis an jede Erweiterung, das der Erweiterung mitteilt, dass die Umgebung beendet wird.
Jede Phase beginnt mit einem Ereignis von Lambda zur Laufzeit und zu allen registrierten Erweiterungen. Die Laufzeit und jede Erweiterung zeigen den Abschluss durch Senden einer `Next`-API-Anfrage an. Lambda friert die Ausführungsumgebung ein, wenn jeder Prozess abgeschlossen ist und keine ausstehenden Ereignisse vorhanden sind.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/Overview-Full-Sequence.png)
**Topics**
+ [
### Init-Phase
](#runtimes-extensions-api-reg)
+ [
### Invoke-Phase
](#runtimes-lifecycle-extensions-invoke)
+ [
### Shutdown-Phase
](#runtimes-lifecycle-extensions-shutdown)
+ [
### Berechtigungen und Konfiguration
](#runtimes-extensions-registration-api-e)
+ [
### Fehlerbehandlung
](#runtimes-extensions-api-failure)
+ [
### Fehlerbehebung bei Erweiterungen
](#runtimes-extensions-api-trbl)
### Init-Phase
Während dieser `Extension init`-Phase muss sich jede Erweiterung bei Lambda registrieren, um Ereignisse zu empfangen. Lambda verwendet den vollständigen Dateinamen der Erweiterung, um zu überprüfen, ob die Erweiterung die Bootstrap-Sequenz abgeschlossen hat. Daher muss jeder `Register`-API-Aufruf den `Lambda-Extension-Name`-Header mit dem vollständigen Dateinamen der Erweiterung enthalten.
Sie können bis zu 10 Erweiterungen für eine Funktion registrieren. Dieses Limit wird durch den `Register`-API-Aufruf erzwungen.
Nachdem jede Erweiterung registriert ist, startet Lambda die `Runtime init`-Phase. Der Laufzeitprozess ruft `functionInit` auf, um die `Function init`-Phase zu starten.
Die `Init`-Phase wird nach der Laufzeit abgeschlossen und jede registrierte Erweiterung zeigt den Abschluss durch Senden einer `Next`-API-Anforderung an.
**Anmerkung**
Erweiterungen können ihre Initialisierung an jedem beliebigen Punkt in der `Init`-Phase abschließen.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/Init-Phase.png)
### Invoke-Phase
Wenn eine Lambda-Funktion als Antwort auf eine `Next`-API-Anforderung aufgerufen wird, sendet Lambda ein `Invoke`-Ereignis an die Laufzeitumgebung und an jede Erweiterung, die für das `Invoke`-Ereignis registriert ist.
**Anmerkung**
**Lambda Managed Instances:** Erweiterungen für Funktionen von Lambda Managed Instances können sich nicht für das `Invoke` Ereignis registrieren. Da Lambda Managed Instances gleichzeitige Aufrufe innerhalb einer einzigen Ausführungsumgebung unterstützt, wird das `Invoke` Ereignis nicht unterstützt. Erweiterungen können sich nur für das Ereignis registrieren. `Shutdown` Wenn Sie nachverfolgen möchten, wann Aufrufe beginnen und enden, verwenden Sie das `platform.report` Plattformereignis über die [Telemetrie-API](telemetry-api.md).
Während des Aufrufs werden externe Erweiterungen parallel zur Funktion ausgeführt. Sie werden auch weiter ausgeführt, nachdem die Funktion abgeschlossen ist. Auf diese Weise können Sie Diagnoseinformationen erfassen oder Protokolle, Metriken und Traces an einen Ort Ihrer Wahl senden.
Nachdem Erhalt der Funktionsantwort von der Laufzeitumgebung wird die Antwort von Lambda an den Client zurückgegeben, selbst wenn noch Erweiterungen ausgeführt werden.
Die `Invoke`-Phase endet nach der Laufzeit und alle Erweiterungen signalisieren durch Senden einer `Next`-API-Anforderung, dass sie ausgeführt wurden.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/Invoke-Phase.png)
**Ereignisnutzlast**: Das Ereignis, das an die Laufzeit (und die Lambda-Funktion) gesendet wird, trägt die gesamte Anforderung, Header (z. B. `RequestId`) und Nutzlast. Das an jede Erweiterung gesendete Ereignis enthält Metadaten, die den Ereignisinhalt beschreiben. Dieses Lebenszyklusereignis umfasst den Typ des Ereignisses, die Zeit, zu der das Timeout der Funktion (`deadlineMs`), das `requestId`, die aufgerufene Funktion, den Amazon Resource Name (ARN) der aufgerufenen Funktion und die Tracing-Header.
Erweiterungen, die auf den Funktionsereigniskörper zugreifen möchten, können ein In-Laufzeit-SDK verwenden, das mit der Erweiterung kommuniziert. Funktionsentwickler verwenden das In-Laufzeit-SDK, um die Nutzlast an die Erweiterung zu senden, wenn die Funktion aufgerufen wird.
Hier ist ein Beispiel für eine Nutzlast:
```
{
"eventType": "INVOKE",
"deadlineMs": 676051,
"requestId": "3da1f2dc-3222-475e-9205-e2e6c6318895",
"invokedFunctionArn": "arn:aws:lambda:us-east-1:123456789012:function:ExtensionTest",
"tracing": {
"type": "X-Amzn-Trace-Id",
"value": "Root=1-5f35ae12-0c0fec141ab77a00bc047aa2;Parent=2be948a625588e32;Sampled=1"
}
}
```
**Begrenzung der Dauer**: Die Timeout-Einstellung der Funktion begrenzt die Dauer der gesamten `Invoke`-Phase. Wenn Sie beispielsweise die Zeitüberschreitung für die Funktion auf 360 Sekunden festlegen, müssen die Funktion und alle Erweiterungen innerhalb von 360 Sekunden abgeschlossen werden. Beachten Sie, dass es keine unabhängige Post-Invoke-Phase gibt. Die Dauer ist die Gesamtzeit, die Ihre Laufzeit und alle Aufrufe Ihrer Erweiterungen benötigen und wird erst berechnet, wenn die Funktion und alle Erweiterungen abgeschlossen sind.
**Performance impact and extension overhead (Leistungsauswirkungen und Erweiterungsoverhead)**: Erweiterungen können sich auf die Funktionsleistung auswirken. Als Autor einer Erweiterung haben Sie die Kontrolle über die Auswirkungen Ihrer Erweiterung auf die Leistung. Ein Beispiel: Eine Erweiterung führt rechenintensive Operationen aus. In diesem Fall könnten Sie feststellen, dass die Dauer des Aufrufs Ihrer Funktion zunimmt, da Erweiterung und Funktion sich CPU-Ressourcen teilen. Wenn Ihre Erweiterung umfangreiche Operationen ausführt, nachdem der Funktionsaufruf abgeschlossen ist, verlängert sich die Dauer des Funktionsaufrufs, da die `Invoke`-Phase fortgesetzt wird, bis alle Erweiterungen signalisieren, dass sie abgeschlossen sind.
**Anmerkung**
Lambda weist CPU-Leistung im Verhältnis zur Speichereinstellung der Funktion zu. Bei niedrigeren Speichereinstellungen wird möglicherweise eine erhöhte Ausführungs- und Initialisierungsdauer angezeigt, da die Funktions- und Erweiterungsprozesse um die gleichen CPU-Ressourcen konkurrieren. Erhöhen Sie die Speichereinstellung, um die Ausführungs- und Initialisierungsdauer zu reduzieren.
Um die Leistungsbeeinträchtigung zu identifizieren, die durch Erweiterungen in der `Invoke`-Phase verursacht wird, gibt Lambda die `PostRuntimeExtensionsDuration`-Metrik aus. Diese Metrik misst die kumulative Zeit, die zwischen der `Next`-Laufzeit-API-Anforderung und der letzten `Next`-Erweiterungs-API-Anforderung vergeht. Verwenden Sie die `MaxMemoryUsed`-Metrik, um die Zunahme des verwendeten Speichers zu messen. Weitere Informationen zu Funktionsmetriken finden Sie unter [Verwendung von CloudWatch-Metriken mit Lambda](monitoring-metrics.md).
Funktionsentwickler können verschiedene Versionen ihrer Funktionen nebeneinander ausführen, um die Auswirkungen einer bestimmten Erweiterung zu verstehen. Wir empfehlen, dass Erweiterungsautoren den erwarteten Ressourcenverbrauch veröffentlichen, um Funktionsentwicklern die Auswahl einer geeigneten Erweiterung zu erleichtern.
### Shutdown-Phase
Wenn Lambda dabei ist, die Laufzeit zu beenden, sendet es ein `Shutdown` an die Laufzeitumgebung und dann an jede registrierte externe Erweiterung. Erweiterungen können diese Zeit für abschließende Bereinigungsaufgaben verwenden. Das `Shutdown`-Ereignis wird als Antwort auf eine `Next`-API-Anforderung gesendet.
**Duration Limit (Begrenzung der Dauer)**: Die maximale Dauer der `Shutdown`-Phase hängt von der Konfiguration der registrierten Erweiterungen ab:
+ 0 ms – Eine Funktion ohne registrierte Erweiterungen
+ 500 ms – Eine Funktion mit einer registrierten internen Erweiterung
+ 2.000 ms – Eine Funktion mit einer oder mehreren registrierten externen Erweiterungen
Wenn die Laufzeit oder eine Erweiterung nicht innerhalb des Limits auf das `Shutdown`-Ereignis reagiert, beendet Lambda den Prozess mit einem `SIGKILL`-Signal.
![\[\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/Shutdown-Phase.png)
**Event Payload (Ereignis-Nutzlast)**: Das `Shutdown`-Ereignis enthält den Grund für das Abschalten und die verbleibende Zeit in Millisekunden.
Das `shutdownReason` beinhaltet die folgenden Werte:
+ SPINDOWN – Normale Abschaltung
+ TIMEOUT – Zeitlimit abgelaufen
+ FAILURE – Fehlerzustand, etwa ein `out-of-memory`-Ereignis
```
{
"eventType": "SHUTDOWN",
"shutdownReason": "reason for shutdown",
"deadlineMs": "the time and date that the function times out in Unix time milliseconds"
}
```
### Berechtigungen und Konfiguration
Erweiterungen werden in derselben Ausführungsumgebung wie die Lambda-Funktion ausgeführt. Erweiterungen teilen auch Ressourcen mit der Funktion, wie CPU, Arbeitsspeicher und `/tmp`-Datenträgerspeicher. Darüber hinaus verwenden Erweiterungen dieselbe AWS Identity and Access Management (IAM-) Rolle und denselben Sicherheitskontext wie die Funktion.
**File system and network access permissions (Dateisystem- und Netzwerkzugriffsberechtigungen)**: Erweiterungen werden in demselben Dateisystem- und Netzwerk-Namespace wie die Funktionslaufzeit ausgeführt. Dies bedeutet, dass Erweiterungen mit dem zugehörigen Betriebssystem kompatibel sein müssen. Wenn für eine Erweiterung zusätzliche ausgehende Netzwerkverkehrsregeln erforderlich sind, müssen Sie diese Regeln auf die Funktionskonfiguration anwenden.
**Anmerkung**
Da das Funktionscode-Verzeichnis schreibgeschützt ist, können Erweiterungen den Funktionscode nicht ändern.
**Environment variables (Umgebungsvariablen)**: Erweiterungen können auf die [Umgebungsvariablen](configuration-envvars.md) der Funktion zugreifen, mit Ausnahme der folgenden Variablen, die für den Laufzeitprozess spezifisch sind:
+ `AWS_EXECUTION_ENV`
+ `AWS_LAMBDA_LOG_GROUP_NAME`
+ `AWS_LAMBDA_LOG_STREAM_NAME`
+ `AWS_XRAY_CONTEXT_MISSING`
+ `AWS_XRAY_DAEMON_ADDRESS`
+ `LAMBDA_RUNTIME_DIR`
+ `LAMBDA_TASK_ROOT`
+ `_AWS_XRAY_DAEMON_ADDRESS`
+ `_AWS_XRAY_DAEMON_PORT`
+ `_HANDLER`
**Anmerkung**
**Erkennung von Lambda Managed Instances:** Erweiterungen können anhand der `AWS_LAMBDA_INITIALIZATION_TYPE` Umgebungsvariablen überprüfen, ob sie auf Lambda Managed Instances oder auf Lambda-Funktionen (Standard) ausgeführt werden. Dies ist die empfohlene Methode für Erweiterungen, um ihr Verhalten an den Typ der Ausführungsumgebung anzupassen.
### Fehlerbehandlung
**Initialization failures (Initialisierungsfehler)**: Wenn eine Erweiterung fehlschlägt, startet Lambda die Ausführungsumgebung neu, um konsistentes Verhalten zu erzwingen und Fail Fast für Erweiterungen zu unterstützen. Für einige Kunden müssen die Erweiterungen auch geschäftskritische Anforderungen wie Protokollierung, Sicherheit, Governance und Telemetrieerfassung erfüllen.
**Invoke failures (Aufruffehler)** (z. B. kein Speicher mehr, Funktions-Timeout): Da Erweiterungen Ressourcen mit der Laufzeit gemeinsam nutzen, sind sie eventuell von Speichermangel betroffen. Wenn die Laufzeit ausfällt, nehmen alle Erweiterungen und die Laufzeit selbst an der `Shutdown`-Phase teil. Darüber hinaus wird die Laufzeitumgebung entweder automatisch als Teil des aktuellen Aufrufs oder über einen verzögerten Neuinitialisierungsmechanismus neu gestartet.
Wenn bei `Invoke` ein Fehler (z. B. eine Funktions-Zeitüberschreitung oder Laufzeitfehler) auftritt, führt der Lambda-Service einen Neustart durch. Der Reset verhält sich wie ein `Shutdown`-Ereignis. Zuerst beendet Lambda die Laufzeit und sendet dann ein `Shutdown`-Ereignis an jede registrierte externe Erweiterung. Das Ereignis enthält den Grund für das Abschalten. Wenn diese Umgebung für einen neuen Aufruf verwendet wird, werden die Erweiterung und die Laufzeit als Teil des nächsten Aufrufers neu initialisiert.
![\[Beispiel für eine Ausführungsumgebung: Init, Invoke, Invoke with Error, Invoke, Shutdown\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
Eine ausführlichere Erläuterung des vorherigen Diagramms finden Sie unter [Fehler während der Aufrufphase](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors).
**Erweiterungsprotokolle**: Lambda sendet die Protokollausgabe von Erweiterungen an CloudWatch Logs. Lambda generiert auch ein zusätzliches Protokollereignis für jede Erweiterung während `Init`. Das Protokollereignis zeichnet den Namen und die Registrierungseinstellung (Ereignis, Konfiguration) bei Erfolg oder die Fehlerursache bei einem Fehler auf.
### Fehlerbehebung bei Erweiterungen
+ Wenn eine `Register`-Anforderung fehlschlägt, stellen Sie sicher, dass der `Lambda-Extension-Name`-Header im `Register`-API-Aufruf den vollständigen Dateinamen der Erweiterung enthält.
+ Wenn die `Register`-Anforderung für eine interne Erweiterung fehlschlägt, stellen Sie sicher, dass sich die Anforderung nicht für das `Shutdown`-Ereignis registriert.
## Erweiterungs-API-Referenz
Die OpenAPI-Spezifikation für die Erweiterungs-API Version **2020-01-01** finden Sie hier: [extensions-api.zip](samples/extensions-api.zip)
Sie können den Wert des API-Endpunkts aus der `AWS_LAMBDA_RUNTIME_API`-Umgebungsvariablen abrufen. Um eine `Register`-Anforderung zu senden, verwenden Sie das Präfix `2020-01-01/` vor jedem API-Pfad. Zum Beispiel:
```
http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension/register
```
**Topics**
+ [
### Registrieren
](#extensions-registration-api-a)
+ [
### Next
](#extensions-api-next)
+ [
### Init-Fehler
](#runtimes-extensions-init-error)
+ [
### Exit-Fehler
](#runtimes-extensions-exit-error)
### Registrieren
Während `Extension init` müssen sich alle Erweiterungen bei Lambda registrieren, um Ereignisse zu empfangen. Lambda verwendet den vollständigen Dateinamen der Erweiterung, um zu überprüfen, ob die Erweiterung die Bootstrap-Sequenz abgeschlossen hat. Daher muss jeder `Register`-API-Aufruf den `Lambda-Extension-Name`-Header mit dem vollständigen Dateinamen der Erweiterung enthalten.
Interne Erweiterungen werden vom Laufzeitprozess gestartet und gestoppt, sodass sie sich nicht für das `Shutdown`-Ereignis registrieren können.
**Pfad** – `/extension/register`
**Methode** – **POST**
**Anfordern von Headern**
+ `Lambda-Extension-Name` – Der vollständige Dateiname der Erweiterung. Erforderlich: ja Typ: Zeichenkette
+ `Lambda-Extension-Accept-Feature` – Verwenden Sie dies, um optionale Erweiterungsfunktionen bei der Registrierung anzugeben. Erforderlich: Nein. Typ: durch Kommas getrennte Zeichenfolge. Funktionen, die mit dieser Einstellung angegeben werden können:
+ `accountId` – Falls angegeben, enthält die Registrierungsantwort der Erweiterung die Konto-ID, die der Lambda-Funktion zugeordnet ist, für die Sie die Erweiterung registrieren.
**Anfrage von Textparametern**
+ `events` – Array der Ereignisse, für die die Registrierung durchgeführt werden soll. Erforderlich: Nein Typ: Zeichenfolge-Array Gültige Zeichenfolgen: `INVOKE`, `SHUTDOWN`.
**Anmerkung**
**Lambda Managed Instances:** Erweiterungen für Funktionen von Lambda Managed Instances können sich nur für das `SHUTDOWN` Ereignis registrieren. Der Versuch, sich für das `INVOKE` Ereignis zu registrieren, führt zu einem Fehler. Dies liegt daran, dass Lambda Managed Instances gleichzeitige Aufrufe innerhalb einer einzigen Ausführungsumgebung unterstützt.
**Antwort-Header**
+ `Lambda-Extension-Identifier` – Generierte eindeutige Agent-ID (UUID-Zeichenfolge), die für alle nachfolgenden Anforderungen erforderlich ist.
**Antwortcodes**
+ 200 – Antworttext enthält den Funktionsnamen, die Funktionsversion und den Namen des Handlers.
+ 400 – Ungültige Anfrage
+ 403 – Verboten
+ 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Erweiterung sollte umgehend beendet werden.
**Example Beispielanfragetext**
```
{
'events': [ 'INVOKE', 'SHUTDOWN']
}
```
**Example Beispielantworttext**
```
{
"functionName": "helloWorld",
"functionVersion": "$LATEST",
"handler": "lambda_function.lambda_handler"
}
```
**Example Beispiel-Antworttext mit optionalem AccountID-Feature**
```
{
"functionName": "helloWorld",
"functionVersion": "$LATEST",
"handler": "lambda_function.lambda_handler",
"accountId": "123456789012"
}
```
### Next
Erweiterungen senden eine `Next`-API-Anforderung für den Empfang des nächsten Ereignisses, bei dem es sich um ein `Invoke`-Ereignis oder ein `Shutdown`-Ereignis handeln kann. Der Antworttext enthält die Nutzlast, bei der es sich um ein JSON-Dokument handelt, das Ereignisdaten enthält.
Die Erweiterung sendet eine `Next`-API-Anforderung, um zu signalisieren, dass sie bereit ist, neue Ereignisse zu empfangen. Das ist ein blockierender Aufruf.
Legen Sie für den GET-Aufruf kein Timeout fest, da die Erweiterung für einen bestimmten Zeitraum angehalten werden kann, bis ein Ereignis zurückgegeben werden soll.
**Pfad** – `/extension/event/next`
**Methode** – **GET**
**Anfordern von Headern**
+ `Lambda-Extension-Identifier` – Eindeutiger Bezeichner für die Erweiterung (UUID-Zeichenfolge). Erforderlich: ja Typ: UUID-Zeichenfolge
**Antwort-Header**
+ `Lambda-Extension-Event-Identifier` – Eindeutiger Bezeichner für das Ereignis (UUID-Zeichenfolge).
**Antwortcodes**
+ 200 – Die Antwort enthält Informationen über das nächste Ereignis (`EventInvoke` oder `EventShutdown`).
+ 403 – Verboten
+ 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Erweiterung sollte umgehend beendet werden.
### Init-Fehler
Die Erweiterung verwendet diese Methode, um einen Initialisierungsfehler an Lambda zu melden. Rufen Sie sie auf, wenn die Erweiterung nach der Registrierung nicht initialisiert werden kann. Nachdem der Fehler von Lambda empfangen wurde, sind keine weiteren API-Aufrufe erfolgreich. Die Erweiterung sollte beendet werden, nachdem sie die Antwort von Lambda erhalten hat.
**Pfad** – `/extension/init/error`
**Methode** – **POST**
**Anfordern von Headern**
+ `Lambda-Extension-Identifier` – Eindeutiger Bezeichner für die Erweiterung. Erforderlich: ja Typ: UUID-Zeichenfolge
+ `Lambda-Extension-Function-Error-Type` – Der Fehlertyp, auf den die Erweiterung gestoßen ist. Erforderlich: ja Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, aber wir empfehlen ein Format von . Beispiel:
+ Erweiterung. NoSuchHandler
+ Erweiterung. APIKeyNotFound
+ Erweiterung. ConfigInvalid
+ Erweiterung. UnknownReason
**Anfrage von Textparametern**
+ `ErrorRequest` – Informationen über den Fehler. Erforderlich: Nein
Dieses Feld ist ein JSON-Objekt mit der folgenden Struktur:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Beachten Sie, dass Lambda jeden Wert für `errorType` akzeptiert.
Das folgende Beispiel zeigt eine Lambda-Funktionsfehlermeldung, in der die Funktion die im Aufruf bereitgestellten Ereignisdaten nicht analysieren konnte.
**Example Funktionsfehler**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Antwortcodes**
+ 202 – Akzeptiert
+ 400 – Ungültige Anfrage
+ 403 – Verboten
+ 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Erweiterung sollte umgehend beendet werden.
### Exit-Fehler
Die Erweiterung verwendet diese Methode, um Lambda vor dem Beenden einen Fehler zu melden. Rufen Sie sie auf, wenn ein unerwarteter Fehler auftritt. Nachdem der Fehler von Lambda empfangen wurde, sind keine weiteren API-Aufrufe erfolgreich. Die Erweiterung sollte beendet werden, nachdem sie die Antwort von Lambda erhalten hat.
**Pfad** – `/extension/exit/error`
**Methode** – **POST**
**Anfordern von Headern**
+ `Lambda-Extension-Identifier` – Eindeutiger Bezeichner für die Erweiterung. Erforderlich: ja Typ: UUID-Zeichenfolge
+ `Lambda-Extension-Function-Error-Type` – Der Fehlertyp, auf den die Erweiterung gestoßen ist. Erforderlich: ja Dieser Header besteht aus einem Zeichenfolgen-Wert. Lambda akzeptiert jede Zeichenfolge, aber wir empfehlen ein Format von . Beispiel:
+ Erweiterung. NoSuchHandler
+ Erweiterung. APIKeyNotFound
+ Erweiterung. ConfigInvalid
+ Erweiterung. UnknownReason
**Anfrage von Textparametern**
+ `ErrorRequest` – Informationen über den Fehler. Erforderlich: Nein
Dieses Feld ist ein JSON-Objekt mit der folgenden Struktur:
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Beachten Sie, dass Lambda jeden Wert für `errorType` akzeptiert.
Das folgende Beispiel zeigt eine Lambda-Funktionsfehlermeldung, in der die Funktion die im Aufruf bereitgestellten Ereignisdaten nicht analysieren konnte.
**Example Funktionsfehler**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Antwortcodes**
+ 202 – Akzeptiert
+ 400 – Ungültige Anfrage
+ 403 – Verboten
+ 500 – Container-Fehler. Nicht wiederherstellbarer Zustand. Die Erweiterung sollte umgehend beendet werden.
# 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"
}
}
```