Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Utilisation des extensions Lambda pour augmenter vos fonctions Lambda
Vous pouvez utiliser des extensions Lambda pour augmenter vos fonctions Lambda. Par exemple, utilisez des extensions Lambda pour intégrer des fonctions à vos outils de surveillance, d’observabilité, de sécurité et de gouvernance préférés. Vous pouvez choisir parmi un vaste éventail d’outils fournis par des [partenaires AWS Lambda](https://aws.amazon.com/lambda/partners/), ou [créer vos propres extensions Lambda](runtimes-extensions-api.md).
Lambda prend en charge les extensions externes et internes. Une extension externe s’exécute en tant que processus indépendant dans l’environnement d’exécution et continue à s’exécuter une fois l’invocation de fonction entièrement traité. Étant donné que les extensions s’exécutent sous forme de processus distincts, vous pouvez les écrire dans un langage différent de la fonction. Tous les [Environnements d’exécution (runtimes) Lambda](lambda-runtimes.md) prennent en charge des extensions.
Une extension interne s’exécute dans le cadre du processus de runtime. Votre fonction accède aux extensions internes via des scripts encapsuleurs ou des mécanismes internes tels que `JAVA_TOOL_OPTIONS`. Pour de plus amples informations, veuillez consulter [Modification de l’environnement d’exécution](runtimes-modify.md).
Vous pouvez ajouter des extensions à une fonction à l'aide de la console Lambda, du AWS Command Line Interface (AWS CLI) ou des services et outils d'infrastructure en tant que code (IaC) tels que CloudFormation, AWS Serverless Application Model (AWS SAM) et Terraform.
Vous êtes facturé pour le temps d’exécution que l’extension consomme (par incréments de 1 ms). Aucun coût n’est facturé pour l’installation de vos propres extensions. Pour obtenir des informations sur la tarification des extensions, consultez [Tarification AWS Lambda](https://aws.amazon.com/lambda/pricing/). Pour obtenir des informations sur la tarification des extensions de partenaires, consultez les sites web de ces partenaires. Consultez [Partenaires des extensions AWS Lambda](extensions-api-partners.md) pour obtenir la liste des extensions partenaires officielles.
**Topics**
+ [
## Environnement d’exécution
](#using-extensions-env)
+ [
## Impact sur les performances et les ressources
](#using-extensions-reg)
+ [
## Permissions
](#using-extensions-permissions)
+ [
# Configuration des extensions Lambda
](extensions-configuration.md)
+ [
# Partenaires des extensions AWS Lambda
](extensions-api-partners.md)
+ [
# Utilisation de l’API d’extensions Lambda pour créer des extensions
](runtimes-extensions-api.md)
+ [
# Accès aux données de télémétrie en temps réel pour les extensions à l’aide de l’API de télémétrie
](telemetry-api.md)
## Environnement d’exécution
Lambda invoque votre fonction dans un [environnement d’exécution](lambda-runtime-environment.md) qui fournit un environnement d’exécution sécurisé et isolé. L’environnement d’exécution gère les ressources requises pour exécuter votre fonction et prend en charge le cycle de vie pour l’exécution de la fonction et les extensions associées à votre fonction.
Le cycle de vie de l’environnement d’exécution comprend les phases suivantes :
+ `Init` : au cours de cette phase, Lambda crée ou libère un environnement d’exécution avec les ressources configurées, télécharge le code pour la fonction et toutes les couches, initialise les extensions, initialise l’exécution et exécute le code d’initialisation de la fonction (code en dehors du gestionnaire principal). La phase `Init` se produit soit lors de la première invocation, soit avant invocations de fonctions si vous avez activé la [simultanéité approvisionnée](provisioned-concurrency.md).
La phase `Init` est fractionnée en trois sous-phases : `Extension init`, `Runtime init` et `Function init`. Ces sous-phases garantissent que toutes les extensions et l’exécution accomplissent leurs tâches de configuration avant l’exécution du code de la fonction.
Lorsque [Lambda SnapStart](snapstart.md) est activé, la phase `Init` se produit lorsque vous publiez une version de la fonction. Lambda enregistre un instantané de l’état de la mémoire et du disque de l’environnement d’exécution initialisé, fait persister l’instantané chiffré et le met en cache pour un accès à faible latence. Si vous avez un [hook d’environnement d’exécution](snapstart-runtime-hooks.md) avant le point de contrôle, le code s’exécute alors à la fin de la phase `Init`.
+ `Restore`(SnapStart uniquement) : Lorsque vous appelez une [SnapStart](snapstart.md)fonction pour la première fois et que celle-ci prend de l'ampleur, Lambda reprend les nouveaux environnements d'exécution à partir de l'instantané persistant au lieu d'initialiser la fonction à partir de zéro. Si vous avez un [hook d’exécution](snapstart-runtime-hooks.md) après restauration, le code s’exécute à la fin de la phase `Restore`. Vous êtes facturé pour la durée des hooks d’exécution après restauration. L’exécution doit se charger et les hooks d’exécution après restauration doivent se terminer dans le délai imparti (10 secondes). Sinon, vous obtiendrez un SnapStartTimeoutException. Lorsque la phase `Restore` se termine, Lambda invoque le gestionnaire de fonction ([Phase d’invocation](lambda-runtime-environment.md#runtimes-lifecycle-invoke)).
+ `Invoke` : au cours de cette phase, Lambda invoque le gestionnaire de la fonction. Une fois l’exécution de la fonction terminée, Lambda se prépare à gérer une autre invocation de fonction.
+ `Shutdown`: cette phase se déclenche si la fonction Lambda ne reçoit aucune invocation pendant un certain temps. Au cours de la phase `Shutdown`, Lambda arrête l’exécution, alerte les extensions pour les laisser s’arrêter proprement, puis supprime l’environnement. Lambda envoie à chaque extension un événement `Shutdown` indiquant que l’environnement est sur le point d’être arrêté.
Au cours de la phase `Init`, Lambda extrait des couches contenant des extensions dans le répertoire `/opt` dans l’environnement d’exécution. Lambda recherche des extensions dans le répertoire `/opt/extensions/`, interprète chaque fichier comme un fichier d’amorçage exécutable pour le lancement de l’extension, puis démarre toutes les extensions en parallèle.
## Impact sur les performances et les ressources
La taille des extensions de votre fonction compte dans la limite de taille du package de déploiement. Pour une archive de fichiers .zip, la taille totale après décompression de la fonction et de toutes les extensions ne peut pas dépasser la limite de taille du package de déploiement fixée à 250 Mo.
Les extensions peuvent avoir un impact sur les performances de votre fonction car elles partagent des ressources telles que le processeur, la mémoire et le stockage. Par exemple, si une extension effectue des opérations intensives de calcul, il se peut que vous observiez une augmentation de la durée d’exécution de la fonction.
Chaque extension doit terminer son initialisation avant que Lambda invoque la fonction. Par conséquent, une extension qui consomme un temps d’initialisation important peut augmenter la latence de l’invocation de la fonction.
Pour mesurer le temps supplémentaire que prend l’extension après l’exécution de la fonction, vous pouvez utiliser la [métrique de fonction `PostRuntimeExtensionsDuration`](monitoring-metrics.md). Pour mesurer l’augmentation de la mémoire utilisée, vous pouvez utiliser la métrique `MaxMemoryUsed`. Pour comprendre l’impact d’une extension spécifique, vous pouvez exécuter différentes versions de vos fonctions côte à côte.
**Note**
La métrique `MaxMemoryUsed` est l’une des [métriques collectées par Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-metrics.html) et non une métrique native Lambda.
## Permissions
Les extensions ont accès aux mêmes ressources que les fonctions. Étant donné que les extensions sont exécutées dans le même environnement que la fonction, les autorisations sont partagées entre la fonction et l’extension.
Pour une archive de fichier .zip, vous pouvez créer un CloudFormation modèle afin de simplifier la tâche consistant à associer la même configuration d'extension, y compris les autorisations Gestion des identités et des accès AWS (IAM), à plusieurs fonctions.
# Configuration des extensions Lambda
## Configuration des extensions (archive de fichiers .zip)
Vous pouvez ajouter une extension à votre fonction en tant que [couche Lambda](chapter-layers.md). L'utilisation de couches vous permet de partager des extensions au sein de votre organisation ou avec l'ensemble de la communauté des développeurs Lambda. Vous pouvez ajouter une ou plusieurs extensions à une couche. Vous pouvez enregistrer jusqu'à 10 extensions pour une fonction.
Ajoutez l'extension à votre fonction en utilisant la même méthode que pour n'importe quelle couche. Pour de plus amples informations, consultez [Gestion des dépendances Lambda à l’aide de couches](chapter-layers.md).
**Ajout d'une extension à votre fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Sélectionnez l'onglet **Code** s'il n'est pas déjà sélectionné.
1. Sous **Layers (Couches)**, sélectionnez **Edit (Modifier)**.
1. Pour **Choose a layer (Choisir une couche)**, sélectionnez **Specify an ARN (Spécifier un nom ARN)**.
1. Pour **Specify an ARN** (Spécifier un ARN), entrez l’Amazon Resource Name (ARN) d'une couche d'extension.
1. Choisissez **Ajouter**.
## Utilisation des extensions dans les images de conteneur
Vous pouvez ajouter des extensions à votre [image de conteneur](images-create.md). Le paramètre d'image de conteneur ENTRYPOINT détermine le processus principal de la fonction. Configurez le paramètre ENTRYPOINT dans le Dockerfile ou en tant que remplacement dans la configuration de la fonction.
Vous pouvez exécuter plusieurs traitements au sein d'un conteneur. Lambda gère le cycle de vie du traitement principal et tous les traitements supplémentaires. Lambda utilise l'[API des extensions](runtimes-extensions-api.md) pour gérer le cycle de vie des extensions.
### Exemple : ajout d'une extension externe
Une extension externe s'exécute dans un processus distinct de la fonction Lambda. Lambda démarre un traitement pour chaque extension dans le répertoire `/opt/extensions/`. Lambda utilise l'API d'extensions pour gérer le cycle de vie des extensions. Une fois l'exécution de la fonction terminée, Lambda envoie un événement `Shutdown` à chaque extension externe.
**Example d'ajouter une extension externe à une image de base Python**
```
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
```
## Étapes suivantes
Pour de plus amples informations sur les extensions, nous vous recommandons les ressources suivantes :
+ Pour consulter un exemple pratique de base, consultez [Building Extensions for AWS Lambda](https://aws.amazon.com/blogs/compute/building-extensions-for-aws-lambda-in-preview/) sur le blog AWS Compute.
+ Pour plus d'informations sur les extensions fournies par les partenaires AWS Lambda, consultez [Introducing AWS Lambda Extensions](https://aws.amazon.com/blogs/compute/introducing-aws-lambda-extensions-in-preview/) sur le blog AWS Compute.
+ Pour consulter les exemples d'extensions disponibles et scripts encapsuleurs, reportez-vous à [Extensions AWS Lambda](https://github.com/aws-samples/aws-lambda-extensions) sur le référentiel d'exemples AWS GitHub.
# Partenaires des extensions AWS Lambda
AWS Lambda s’est associé à plusieurs entités tierces pour fournir des extensions à intégrer à vos fonctions Lambda. La liste suivante détaille les extensions tierces qui sont prêtes à être utilisées à tout moment.
+ [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) : fournit une instrumentation automatique des fonctions Node.js ou Python Lambda, offrant une visibilité et des alertes sur les performances des fonctions.
+ [https://axiom.co/docs/apps/lambda](https://axiom.co/docs/apps/lambda) : fournit des tableaux de bord pour surveiller les performances de la fonction Lambda et les métriques agrégées au niveau du système.
+ [https://docs.datadoghq.com/serverless/datadog_lambda_library/extension/](https://docs.datadoghq.com/serverless/datadog_lambda_library/extension/) : offre une visibilité complète en temps réel pour vos applications sans serveur grâce à l'utilisation de métriques, de traces et de journaux.
+ [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/) : offre une visibilité sur les traces et les métriques, et exploite l'IA pour la détection automatisée des erreurs et l'analyse des causes profondes sur l'ensemble de la pile d'applications.
+ [https://www.elastic.co/guide/en/apm/agent/nodejs/current/lambda.html](https://www.elastic.co/guide/en/apm/agent/nodejs/current/lambda.html) : offre une surveillance de la performance des applications (APM) pour identifier et résoudre la cause profonde des problèmes à l'aide de traces, de métriques et de journaux corrélés.
+ [https://docs.epsagon.com/docs/environment-monitoring/lambda/intro](https://docs.epsagon.com/docs/environment-monitoring/lambda/intro) – écoute les événements d’invocation, stocke les traces et les envoie en parallèle aux exécutions de fonctions Lambda.
+ [https://docs.fastly.com/signalsciences/install-guides/paas/aws-lambda/](https://docs.fastly.com/signalsciences/install-guides/paas/aws-lambda/)– protège vos fonctions Lambda contre les activités suspectes, telles que les attaques de type injection, l'usurpation de compte par surcharge d'informations d'identification, les robots malveillants et les extorsions d'API.
+ [https://learn.hashicorp.com/tutorials/vault/aws-lambda](https://learn.hashicorp.com/tutorials/vault/aws-lambda) – gère les secrets et les met à la disposition des développeurs pour qu'ils les utilisent dans le code de fonction, sans rendre compte aux fonctions Vault.
+ [https://docs.honeycomb.io/getting-data-in/integrations/aws/aws-lambda/](https://docs.honeycomb.io/getting-data-in/integrations/aws/aws-lambda/) – outil d'observabilité pour déboguer votre pile d'applications.
+ [https://docs.lumigo.io/docs/lambda-extensions](https://docs.lumigo.io/docs/lambda-extensions) – profile les appels de fonctions Lambda et collecte des métriques pour résoudre les problèmes dans les environnements sans serveur et de microservice.
+ [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) – exécutée avec les fonctions Lambda, collecte, améliore et transporte automatiquement la télémétrie vers la plateforme d'observabilité unifiée de New Relic.
+ [https://docs.sedai.io/get-started/platform/optimization/aws/lambda](https://docs.sedai.io/get-started/platform/optimization/aws/lambda) – une plateforme autonome de gestion du cloud, alimentée par l'IA/ML, qui offre une optimisation continue aux équipes d'exploitation du cloud afin de maximiser les économies, les performances et la disponibilité du cloud à grande échelle.
+ [https://docs.sentry.io/platforms/javascript/guides/aws-lambda/](https://docs.sentry.io/platforms/javascript/guides/aws-lambda/) – diagnostique, corrige et optimise les performances des fonctions Lambda.
+ [https://www.site24x7.com/help/aws/lambda-execution-logs.html](https://www.site24x7.com/help/aws/lambda-execution-logs.html) – permet une observabilité en temps réel dans vos environnements Lambda.
+ [https://github.com/signalfx/splunk-otel-lambda](https://github.com/signalfx/splunk-otel-lambda) – collecte des métriques haute résolution à faible latence pour une surveillance efficiente et efficace des fonctions Lambda.
+ [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) – offre une visibilité sur l'état et les performances des applications sans serveur.
+ [Salt Security](https://salt.security/press-releases/salt-security-becomes-the-first-and-only-api-security-vendor-to-join-aws-lambda-ready-program?) : simplifie la gouvernance de la posture des API et la sécurité des API pour les fonctions Lambda grâce à une configuration automatisée et à une prise en charge de divers environnements d’exécution.
## AWSExtensions gérées
AWS fournit ses propres extensions gérées, notamment :
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions.html#appconfig-integration-lambda-extensions-enabling) : utilise des indicateurs de fonction et des données dynamiques pour mettre à jour vos fonctions Lambda. Vous pouvez également utiliser cette extension pour mettre à jour d’autres configurations dynamiques, telles que la limitation et le réglage des opérations.
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/python-lambda-layers.html) : améliore les performances des applications et réduit les coûts en identifiant la ligne de code la plus coûteuse d’une application et en fournissant des recommandations pour améliorer le code.
+ [CloudWatch Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights.html) : surveille, dépanne et optimise les performances de vos fonctions Lambda grâce aux tableaux de bord automatisés.
+ [AWS Distro for Open Telemetry (ADOT)](https://aws.amazon.com/otel) – Permet aux fonctions d'envoyer des données de traçage aux services de surveillance AWS tels que AWS X-Ray et vers des destinations prenant en charge OpenTelemetry, telles que Honeycomb et Lightstep.
+ [Paramètres et secrets AWS](with-secrets-manager.md) : récupère en toute sécurité les paramètres de AWS Systems Manager Parameter Store et les secrets de AWS Secrets Manager dans les fonctions Lambda.
Pour plus d’exemples d’extensions supplémentaires et de projets de démonstration, voir [Extensions AWS Lambda](https://github.com/aws-samples/aws-lambda-extensions).
# Utilisation de l’API d’extensions Lambda pour créer des extensions
Les auteurs de fonctions Lambda utilisent des extensions pour intégrer Lambda avec leurs outils de prédilection en matière de surveillance, d’observabilité, de sécurité et de gouvernance. Les auteurs de fonctions peuvent utiliser des extensions issues de AWS projets open source, de [AWS partenaires](extensions-api-partners.md) et de projets open source. Pour plus d'informations sur l'utilisation des extensions, consultez la section [Présentation des AWS Lambda extensions](https://aws.amazon.com/blogs/aws/getting-started-with-using-your-favorite-operational-tools-on-aws-lambda-extensions-are-now-generally-available/) sur le blog AWS Compute. Cette section décrit comment utiliser l’API Extensions Lambda, le cycle de vie de l’environnement d’exécution Lambda et la référence de l’API Extensions Lambda.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
En tant qu’auteur d’extension, vous pouvez utiliser l’API d’extensions Lambda pour opérer une intégration profonde à [l’environnement d’exécution](lambda-runtime-environment.md) Lambda. Votre extension peut enregistrer les événements du cycle de vie de la fonction et de l’environnement d’exécution. En réponse à ces événements, vous pouvez démarrer de nouveaux processus, exécuter une logique, ainsi que contrôler et orienter toutes les phases du cycle de vie Lambda : initialisation, appel et arrêt. En outre, vous pouvez utiliser l’[API Runtime Logs](runtimes-logs-api.md) pour recevoir un flux de journaux.
Une extension s’exécute en tant que processus indépendant dans l’environnement d’exécution et peut continuer de s’exécuter une fois l’appel de fonction entièrement traité. Étant donné que les extensions s’exécutent en tant que processus, vous pouvez les écrire dans un langage différent de celui de la fonction. Nous vous recommandons d’implémenter des extensions à l’aide d’un langage compilé. Dans ce cas, l’extension est un fichier binaire autonome compatible avec les environnements d’exécution pris en charge. Tous les [Environnements d’exécution (runtimes) Lambda](lambda-runtimes.md) prennent en charge des extensions. Si vous utilisez un langage non compilé, assurez-vous d’inclure un environnement d’exécution compatible dans l’extension.
Lambda prend également en charge les *extensions internes*. Une extension interne s’exécute comme un thread séparé dans le processus d’exécution. L’exécution démarre et arrête l’extension interne. Un autre mode d’intégration à l’environnement Lambda consiste à utiliser des [variables d’environnement spécifiques au langage et des scripts encapsuleurs](runtimes-modify.md). Vous pouvez utiliser ces paramètres pour configurer l’environnement d’exécution et modifier le comportement de démarrage du processus d’exécution.
Vous pouvez ajouter des extensions à une fonction de deux manières. Pour une fonction déployée en tant qu’[archive de fichier .zip](configuration-function-zip.md), vous déployez votre extension en tant que [couche](chapter-layers.md). Pour une fonction définie comme une image de conteneur, vous ajoutez [les extensions](extensions-configuration.md#invocation-extensions-images) à cette dernière.
**Note**
Pour des exemples d'extensions et de scripts wrapper, voir [AWS Lambda Extensions](https://github.com/aws-samples/aws-lambda-extensions) dans le GitHub référentiel AWS Samples.
**Topics**
+ [
## Cycle de vie d’un environnement d’exécution Lambda
](#runtimes-extensions-api-lifecycle)
+ [
## Référence d’API d’extensions
](#runtimes-extensions-registration-api)
## Cycle de vie d’un environnement d’exécution Lambda
Le cycle de vie de l’environnement d’exécution comprend les phases suivantes :
+ `Init` : au cours de cette phase, Lambda crée ou libère un environnement d’exécution avec les ressources configurées, télécharge le code pour la fonction et toutes les couches, initialise les extensions, initialise l’exécution et exécute le code d’initialisation de la fonction (code en dehors du gestionnaire principal). La phase `Init` se produit soit lors de la première invocation, soit avant invocations de fonctions si vous avez activé la [simultanéité approvisionnée](provisioned-concurrency.md).
La phase `Init` est fractionnée en trois sous-phases : `Extension init`, `Runtime init` et `Function init`. Ces sous-phases garantissent que toutes les extensions et l’exécution accomplissent leurs tâches de configuration avant l’exécution du code de la fonction.
+ `Invoke` : au cours de cette phase, Lambda appelle le gestionnaire de la fonction. Une fois l’exécution de la fonction terminée, Lambda se prépare à gérer une autre invocation de fonction.
+ `Shutdown`: cette phase se déclenche si la fonction Lambda ne reçoit aucune invocation pendant un certain temps. Au cours de la phase `Shutdown`, Lambda arrête l’exécution, alerte les extensions pour les laisser s’arrêter proprement, puis supprime l’environnement. Lambda envoie à chaque extension un événement `Shutdown` indiquant que l’environnement est sur le point d’être arrêté.
Chaque phase commence par un événement que Lambda envoie au runtime et à toutes les extensions enregistrées. L’exécution et chaque extension signalent la fin de l’opération en envoyant une requête d’API `Next`. Lambda bloque l’environnement d’exécution lorsque l’exécution de chaque processus est terminée, et qu’il n’y a pas d’événement en attente.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/Overview-Full-Sequence.png)
**Topics**
+ [
### Phase d’initialisation
](#runtimes-extensions-api-reg)
+ [
### Phase d’appel
](#runtimes-lifecycle-extensions-invoke)
+ [
### Phase d’arrêt
](#runtimes-lifecycle-extensions-shutdown)
+ [
### Autorisations et configuration
](#runtimes-extensions-registration-api-e)
+ [
### Gestion des défaillances
](#runtimes-extensions-api-failure)
+ [
### Dépannage des extensions
](#runtimes-extensions-api-trbl)
### Phase d’initialisation
Au cours de la phase `Extension init`, chaque extension doit s’enregistrer auprès de Lambda pour recevoir des événements. Lambda utilise le nom de fichier complet de l’extension pour vérifier que la séquence d’amorçage de celle-ci est terminée. Par conséquent, chaque appel d’API `Register` doit inclure l’en-tête `Lambda-Extension-Name` avec le nom de fichier complet de l’extension.
Vous pouvez enregistrer jusqu’à 10 extensions pour une fonction. Cette limite est appliquée via l’appel d’API `Register`.
Après l’enregistrement de chaque extension, Lambda démarre la phase `Runtime init`. Le processus d’exécution appelle `functionInit` pour démarrer la phase `Function init`.
La phase `Init` se termine lorsque l’environnement d’exécution et chaque extension enregistrée indiquent la fin de l’opération en envoyant une demande d’API `Next`.
**Note**
Les extensions peuvent terminer leur initialisation à n’importe quel moment de la phase `Init`.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/Init-Phase.png)
### Phase d’appel
Lorsqu’une fonction Lambda est appelée en réponse à une requête d’API `Next`, Lambda envoie un événement `Invoke` à l’environnement d’exécution et à chaque extension enregistrée pour l’événement `Invoke`.
**Note**
**Instances gérées Lambda : les extensions pour les fonctions des instances** gérées Lambda ne peuvent pas être enregistrées pour l'événement. `Invoke` Comme les instances gérées Lambda prennent en charge les appels simultanés au sein d'un même environnement d'exécution, l'`Invoke`événement n'est pas pris en charge. Les extensions ne peuvent être enregistrées que pour l'`Shutdown`événement. Si vous devez suivre le début et la fin des invocations, utilisez l'événement de `platform.report` plateforme via l'API de [télémétrie](telemetry-api.md).
Pendant l’appel, les extensions externes s’exécutent en parallèle avec la fonction. Elles continuent également à s’exécuter après la fin de la fonction. Cela vous permet de capturer des informations de diagnostic ou d’envoyer des journaux, des métriques et des suivis à l’emplacement de votre choix.
Après réception de la réponse de fonction de l’environnement d’exécution, Lambda renvoie celle-ci au client, même si les extensions sont toujours en cours d’exécution.
La phase `Invoke` prend fin lorsque l’environnement d’exécution et toutes les extensions signalent qu’ils ont terminé en envoyant une demande d’API `Next`.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/Invoke-Phase.png)
**Charge utile de l’événement** : l’événement envoyé à l’environnement d’exécution (et à la fonction Lambda) transporte la totalité de la requête, les en-têtes (tels que `RequestId`) et la charge utile. L’événement envoyé à chaque extension contient des métadonnées décrivant le contenu de l’événement. Cet événement de cycle de vie inclut le type de l’événement, l’heure à laquelle la fonction expire (`deadlineMs`), la `requestId`, l’Amazon Resource Name (ARN) de la fonction appelée et les en-têtes de suivi.
Les extensions qui souhaitent accéder au corps de l’événement de la fonction peuvent utiliser un kit SDK interne à l’environnement d’exécution qui communique avec l’extension. Les développeurs de fonctions utilisent le kit SDK interne à l’environnement d’exécution pour envoyer la charge utile à l’extension lorsque la fonction est appelée.
Voici un exemple de charge utile :
```
{
"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"
}
}
```
**Limite de durée** : le paramètre d’expiration de la fonction limite la durée de la phase `Invoke` entière. Par exemple, si vous définissez le délai d’expiration de la fonction sur 360 secondes, la fonction et toutes les extensions doivent être terminées dans un délai de 360 secondes. Notez qu’il n’y a pas de phase post-invocation indépendante. La durée correspond à la durée totale nécessaire pour que votre environnement d’exécution et toutes vos invocations d’extensions se terminent. Elle n’est calculée que lorsque l’exécution de la fonction et de toutes les extensions est terminée.
**Impact sur les performances et surcharge d’extension** : les extensions peuvent avoir un impact sur les performances des fonctions. En tant qu’auteur d’extension, vous contrôlez l’impact de votre extension sur les performances. Par exemple, si votre extension effectue des opérations intensives de calcul, la durée de la fonction augmente, car le code de l’extension et de votre fonction partage les mêmes ressources d’UC. En outre, si votre extension effectue des opérations importantes après la fin de l’appel de fonction, la durée de la fonction augmente, car la phase `Invoke` continue jusqu’à ce que toutes les extensions signalent qu’elles sont terminées.
**Note**
Lambda alloue une puissance de processeur proportionnelle au paramètre de mémoire de la fonction. La durée d’exécution et d’initialisation peut augmenter avec des paramètres de mémoire inférieurs, car les processus de fonction et d’extensions sont en concurrence pour les mêmes ressources de processeur. Pour réduire la durée d’exécution et d’initialisation, essayez d’augmenter le paramètre de mémoire.
Pour vous aider à déterminer l’impact sur les performances des extensions dans la phase `Invoke`, Lambda génère la métrique `PostRuntimeExtensionsDuration`. Cette métrique mesure le temps cumulé qui s’écoule entre la demande d’API `Next` de l’environnement d’exécution et la dernière demande d’API `Next` d’une extension. La métrique `MaxMemoryUsed` permet de mesurer l’augmentation de la mémoire utilisée. Pour de plus amples informations sur les métriques de fonction, veuillez consulter [Utilisation des métriques CloudWatch avec Lambda](monitoring-metrics.md).
Les développeurs de fonctions peuvent exécuter différentes versions de leurs fonctions côte à côte pour comprendre l’impact d’une extension spécifique. Nous recommandons aux auteurs d’extension de publier la consommation de ressources prévue de manière à aider les développeurs de fonction dans leur choix de l’extension appropriée.
### Phase d’arrêt
Quand Lambda est sur le point d’arrêter l’exécution, il envoie un `Shutdown` à chaque extension externe enregistrée. Les extensions peuvent utiliser ce temps pour les tâches de nettoyage final. L’événement `Shutdown` est envoyé en réponse à une demande d’API `Next`.
**Limite de durée** : la durée maximale de la phase `Shutdown` dépend de la configuration des extensions enregistrées :
+ 0 ms : fonction sans extension enregistrée
+ 500 ms : fonction avec une extension interne enregistrée.
+ 2 000 ms : fonction avec une ou plusieurs extensions externes enregistrées.
Si l’environnement d’exécution ou une extension ne répondent pas à l’événement `Shutdown` dans cette limite de temps, Lambda met fin au processus à l’aide d’un signal `SIGKILL`.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/Shutdown-Phase.png)
**Charge utile d’événement** : l’événement `Shutdown` contient la raison de l’arrêt et le temps restant en millisecondes.
`shutdownReason` contient les éléments suivants :
+ SPINDOWN – Arrêt normal
+ TIMEOUT – Limite de durée dépassée
+ ÉCHEC : condition d’erreur, telle qu’un événement `out-of-memory`
```
{
"eventType": "SHUTDOWN",
"shutdownReason": "reason for shutdown",
"deadlineMs": "the time and date that the function times out in Unix time milliseconds"
}
```
### Autorisations et configuration
Les extensions s’exécutent dans le même environnement d’exécution que la fonction Lambda. Les extensions partagent également des ressources avec la fonction, telles que le processeur, la mémoire et le disque de stockage `/tmp`. En outre, les extensions utilisent le même rôle Gestion des identités et des accès AWS (IAM) et le même contexte de sécurité que la fonction.
**Autorisations d’accès au système de fichiers et au réseau** : les extensions s’exécutent dans le même espace de noms de système de fichiers et de nom de réseau que l’environnement d’exécution de la fonction. Cela signifie que les extensions doivent être compatibles avec le système d’exploitation associé. Si une extension nécessite des règles supplémentaires de trafic réseau sortant, vous devez appliquer celles-ci à la configuration de la fonction.
**Note**
Étant donné que le répertoire du code de la fonction est en lecture seule, les extensions ne peuvent pas modifier le code de la fonction.
**Variables d’environnement** : les extensions peuvent accéder aux [variables d’environnement](configuration-envvars.md) de la fonction, à l’exception des variables suivantes spécifiques au processus d’environnement d’exécution :
+ `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`
**Note**
**Détection des instances gérées Lambda : les** extensions peuvent vérifier la variable d'`AWS_LAMBDA_INITIALIZATION_TYPE`environnement pour déterminer si elles s'exécutent sur des instances gérées Lambda plutôt que sur des fonctions Lambda (par défaut). Il s'agit de la méthode recommandée pour que les extensions adaptent leur comportement en fonction du type d'environnement d'exécution.
### Gestion des défaillances
**Échecs d’initialisation** : si une extension échoue, Lambda redémarre l’environnement d’exécution pour assurer un comportement cohérent et encourager un échec rapide des extensions. En outre, pour certains clients, les extensions doivent répondre à des besoins stratégiques tels que la journalisation, la sécurité, la gouvernance et la collecte de télémétrie.
**Échecs d’appel** (par exemple, manque de mémoire, expiration de fonction) : les extensions partageant des ressources avec l’environnement d’exécution, elles sont affectées par l’épuisement de la mémoire. Lorsque l’environnement d’exécution échoue, toutes les extensions et l’environnement d’exécution lui-même participent à la phase `Shutdown`. En outre, l’environnement d’exécution est redémarré soit automatiquement dans le cadre de l’appel actuel, soit via un mécanisme de réinitialisation différée.
En cas d’échec (par exemple, dépassement de délai d’attente de fonction ou erreur d’exécution) pendant la phase `Invoke`, le service Lambda effectue une réinitialisation. La réinitialisation se comporte comme un événement `Shutdown`. Lambda commence par arrêter l’environnement d’exécution, puis envoie un événement `Shutdown` à chaque extension externe enregistrée. L’événement comprend le motif de l’arrêt. Si cet environnement est utilisé pour un nouvel appel, l’extension et l’environnement d’exécution sont réinitialisés dans le cadre de l’appel suivant.
![\[Exemple d’environnement d’exécution : Init, Invoke, Invoke with Error, Invoke, Shutdown\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
Pour une explication plus détaillée du diagramme précédent, consultez [Échecs pendant la phase d’invocation](lambda-runtime-environment.md#runtimes-lifecycle-invoke-with-errors).
**Journaux des extensions** : Lambda envoie le résultat du journal des extensions à CloudWatch Logs. Lambda génère également un événement de journal supplémentaire pour chaque extension pendant la phase `Init`. L’événement de journal enregistre le nom et la préférence d’enregistrement (événement, configuration) en cas de succès, ou la raison de l’échec le cas échéant.
### Dépannage des extensions
+ Si une demande `Register` échoue, assurez-vous que l’en-tête `Lambda-Extension-Name` de l’appel d’API `Register` contient le nom de fichier complet de l’extension.
+ Si la demande `Register` échoue pour une extension interne, assurez-vous que la demande n’est pas enregistrée pour l’événement `Shutdown`.
## Référence d’API d’extensions
La spécification OpenAPI pour l’API d’extensions version **2020-01-01** est disponible ici : [extensions-api.zip](samples/extensions-api.zip)
Vous pouvez extraire la valeur du point de terminaison d’API à partir de la variable d’environnement `AWS_LAMBDA_RUNTIME_API`. Pour envoyer une demande `Register`, utilisez le préfixe `2020-01-01/` avant chaque chemin d’API. Exemples :
```
http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension/register
```
**Topics**
+ [
### Enregistrement
](#extensions-registration-api-a)
+ [
### Suivant
](#extensions-api-next)
+ [
### Erreur d’initiation
](#runtimes-extensions-init-error)
+ [
### Erreur de sortie
](#runtimes-extensions-exit-error)
### Enregistrement
Au cours de la phase `Extension init`, chaque extension doit s’enregistrer auprès de Lambda pour recevoir les événements. Lambda utilise le nom de fichier complet de l’extension pour vérifier que la séquence d’amorçage de celle-ci est terminée. Par conséquent, chaque appel d’API `Register` doit inclure l’en-tête `Lambda-Extension-Name` avec le nom de fichier complet de l’extension.
Les extensions internes sont lancées et arrêtées par le processus d’environnement d’exécution, de sorte qu’elles ne peuvent pas être enregistrées pour l’événement `Shutdown`.
**Chemin** – `/extension/register`
**Méthode** – **POST**
**En-têtes de demandes**
+ `Lambda-Extension-Name` : nom de fichier complet de l’extension. Obligatoire : oui. Type : chaîne.
+ `Lambda-Extension-Accept-Feature` – Utilisez ceci pour spécifier les fonctionnalités optionnelles d’Extensions pendant l’enregistrement. Requis : non. Type : chaîne séparée par des virgules. Fonctions disponibles pour spécifier en utilisant ce paramètre :
+ `accountId` – Si elle est spécifiée, la réponse d’enregistrement de l’extension contiendra l’ID du compte associé à la fonction Lambda pour laquelle vous enregistrez l’extension.
**Paramètres du corps de la demande**
+ `events` : tableau des événements pour lesquels s’enregistrer. Requis : non. Type : tableau de chaînes. Chaînes valides : `INVOKE`, `SHUTDOWN`.
**Note**
**Instances gérées Lambda : les extensions pour les fonctions des instances** gérées Lambda ne peuvent être enregistrées que pour l'événement. `SHUTDOWN` Toute tentative d'inscription à l'`INVOKE`événement provoquera une erreur. Cela est dû au fait que les instances gérées Lambda prennent en charge les appels simultanés au sein d'un environnement d'exécution unique.
**En-têtes de réponse**
+ `Lambda-Extension-Identifier` : identifiant d’agent unique généré (chaîne UUID) requis pour toutes les requêtes subséquentes.
**Codes de réponse**
+ 200 – Corps de la réponse contenant le nom de la fonction, la version de la fonction et le nom du gestionnaire.
+ 400 – Demande erronée.
+ 403 – Interdit
+ 500 – Erreur de conteneur. État non récupérable. L’extension doit se fermer rapidement.
**Example Exemple de corps de la demande**
```
{
'events': [ 'INVOKE', 'SHUTDOWN']
}
```
**Example Exemple de corps de la réponse**
```
{
"functionName": "helloWorld",
"functionVersion": "$LATEST",
"handler": "lambda_function.lambda_handler"
}
```
**Example Exemple de corps de réponse avec la fonction optionnelle accountId**
```
{
"functionName": "helloWorld",
"functionVersion": "$LATEST",
"handler": "lambda_function.lambda_handler",
"accountId": "123456789012"
}
```
### Suivant
Les extensions envoient une demande d’API `Next` pour recevoir l’événement suivant, qui peut être un événement `Invoke` ou un événement `Shutdown`. Le corps de la réponse contient la charge utile, sous la forme d’un document JSON contenant des données d’événement.
L’extension envoie une demande d’API `Next` pour signaler qu’elle est prête à recevoir de nouveaux événements. Il s’agit d’un appel bloquant.
Ne définissez pas de délai d’expiration sur l’appel GET, car l’extension peut être suspendue pendant un certain temps jusqu’à ce qu’il y ait un événement à retourner.
**Chemin** – `/extension/event/next`
**Méthode** – **GET**
**En-têtes de demandes**
+ `Lambda-Extension-Identifier` : identifiant unique pour l’extension (chaîne UUID). Obligatoire : oui. Type : chaîne UUID.
**En-têtes de réponse**
+ `Lambda-Extension-Event-Identifier` : identifiant unique pour l’événement (chaîne UUID).
**Codes de réponse**
+ 200 : réponse contenant des informations sur l’événement suivant (`EventInvoke` ou `EventShutdown`).
+ 403 – Interdit.
+ 500 – Erreur de conteneur. État non récupérable. L’extension doit se fermer rapidement.
### Erreur d’initiation
L’extension utilise cette méthode pour signaler une erreur d’initialisation à Lambda. Appelez-la lorsque l’extension ne parvient pas à s’initialiser après son enregistrement. Après que Lambda a reçu l’erreur, aucun autre appel d’API n’aboutit. L’extension doit quitter après avoir reçu la réponse de Lambda.
**Chemin** – `/extension/init/error`
**Méthode** – **POST**
**En-têtes de demandes**
+ `Lambda-Extension-Identifier` : identifiant unique pour l’extension. Obligatoire : oui. Type : chaîne UUID.
+ `Lambda-Extension-Function-Error-Type` – Type d’erreur rencontré par l’extension. Obligatoire : oui. Cet en-tête se compose d’une valeur de chaîne. Lambda accepte n’importe quelle chaîne, mais nous recommandons le format . Par exemple :
+ Prolongation. NoSuchHandler
+ Prolongation. APIKeyNotFound
+ Prolongation. ConfigInvalid
+ Prolongation. UnknownReason
**Paramètres du corps de la demande**
+ `ErrorRequest` : informations sur l’erreur. Requis : non.
Ce champ est un objet JSON avec la structure suivante :
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Notez que Lambda accepte n’importe quelle valeur pour `errorType`.
L’exemple suivant montre un message d’erreur de fonction Lambda indiquant que la fonction n’a pas pu analyser les données d’événement fournies dans l’invocation.
**Example Erreur de fonction**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Codes de réponse**
+ 202 – Accepté
+ 400 – Demande erronée.
+ 403 – Interdit
+ 500 – Erreur de conteneur. État non récupérable. L’extension doit se fermer rapidement.
### Erreur de sortie
L’extension utilise cette méthode pour signaler une erreur à Lambda avant de quitter. Appelez-la lorsque vous rencontrez une défaillance inattendue. Après que Lambda a reçu l’erreur, aucun autre appel d’API n’aboutit. L’extension doit quitter après avoir reçu la réponse de Lambda.
**Chemin** – `/extension/exit/error`
**Méthode** – **POST**
**En-têtes de demandes**
+ `Lambda-Extension-Identifier` : identifiant unique pour l’extension. Obligatoire : oui. Type : chaîne UUID.
+ `Lambda-Extension-Function-Error-Type` – Type d’erreur rencontré par l’extension. Obligatoire : oui. Cet en-tête se compose d’une valeur de chaîne. Lambda accepte n’importe quelle chaîne, mais nous recommandons le format . Par exemple :
+ Prolongation. NoSuchHandler
+ Prolongation. APIKeyNotFound
+ Prolongation. ConfigInvalid
+ Prolongation. UnknownReason
**Paramètres du corps de la demande**
+ `ErrorRequest` : informations sur l’erreur. Requis : non.
Ce champ est un objet JSON avec la structure suivante :
```
{
errorMessage: string (text description of the error),
errorType: string,
stackTrace: array of strings
}
```
Notez que Lambda accepte n’importe quelle valeur pour `errorType`.
L’exemple suivant montre un message d’erreur de fonction Lambda indiquant que la fonction n’a pas pu analyser les données d’événement fournies dans l’invocation.
**Example Erreur de fonction**
```
{
"errorMessage" : "Error parsing event data.",
"errorType" : "InvalidEventDataException",
"stackTrace": [ ]
}
```
**Codes de réponse**
+ 202 – Accepté
+ 400 – Demande erronée.
+ 403 – Interdit
+ 500 – Erreur de conteneur. État non récupérable. L’extension doit se fermer rapidement.
# Accès aux données de télémétrie en temps réel pour les extensions à l’aide de l’API de télémétrie
L’API de télémétrie active vos extensions pour recevoir directement des données de télémétrie de Lambda. Pendant l’initialisation et l’invocation des fonctions, Lambda capture automatiquement la télémétrie, notamment les journaux, les métriques de la plateforme et les traces de la plateforme. L’API de télémétrie active des extensions pour accéder à ces données de télémétrie directement depuis Lambda en temps quasi réel.
Dans l’environnement d’exécution Lambda, vous pouvez abonner vos extensions Lambda à des flux de télémétrie. Après la souscription, Lambda envoie automatiquement toutes les données de télémétrie à vos extensions. Vous pouvez ensuite traiter, filtrer et distribuer les données à votre destination préférée, telle qu’un compartiment Amazon Simple Storage Service (Amazon S3) ou un fournisseur d’outils d’observabilité tiers.
Le schéma suivant montre comment l’API d’extensions et l’API de télémétrie lient les extensions à Lambda depuis l’environnement d’exécution. De plus, l’API d’exécution connecte votre environnement d’exécution et votre fonction à Lambda.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
**Important**
L’API de télémétrie Lambda remplace l’API de journaux Lambda. **Bien que l’API de journaux reste entièrement fonctionnelle, nous vous recommandons d’utiliser uniquement l’API de télémétrie à l’avenir.** Vous pouvez abonner votre extension à un flux de télémétrie en utilisant l’API de télémétrie ou l’API de journaux. Après vous être abonné à l'aide de l'une de ces API APIs, toute tentative de souscription à l'aide de l'autre API renvoie une erreur.
**Exigence de version du schéma des instances gérées Lambda**
Les instances gérées Lambda ne prennent en charge que la version du `2025-01-29` schéma de l'API de télémétrie. Lorsque vous vous abonnez à des flux de télémétrie pour les fonctions des instances gérées, vous **devez** les utiliser `"schemaVersion": "2025-01-29"` dans votre demande d'abonnement. L'utilisation de versions de schéma précédentes entraînera le rejet d'événements par Lambda.
La version du `2025-01-29` schéma est rétrocompatible et peut être utilisée à la fois avec les instances gérées Lambda et les fonctions Lambda (par défaut). Nous recommandons d'utiliser cette version pour toutes les nouvelles extensions afin de garantir la compatibilité entre les deux modèles de déploiement.
Les extensions peuvent utiliser l’API de télémétrie pour s’abonner à trois flux de télémétrie différents :
+ **Télémétrie de plateforme** – Journaux, métriques et traces, qui décrivent les événements et les erreurs liés au cycle de vie de l’environnement d’exécution, au cycle de vie des extensions et aux appels de fonctions
+ **Journaux de fonction** – Journaux personnalisés que le code de la fonction Lambda génère.
+ **Journaux d’extension** – Journaux personnalisés générés par le code d’extension Lambda.
**Note**
Lambda envoie des journaux CloudWatch, des métriques et des traces à X-Ray (si vous avez activé le suivi), même si une extension s'abonne à des flux de télémétrie.
**Topics**
+ [
## Création d’extensions à l’aide de l’API de télémétrie
](#telemetry-api-creating-extensions)
+ [
## Enregistrement de votre extension
](#telemetry-api-registration)
+ [
## Création d’un écouteur de télémétrie
](#telemetry-api-listener)
+ [
## Spécification d’un protocole de destination
](#telemetry-api-destination)
+ [
## Configuration de l’utilisation de la mémoire et de la mise en mémoire tampon
](#telemetry-api-buffering)
+ [
## Envoi d’une demande d’abonnement à l’API de télémétrie
](#telemetry-api-subscription)
+ [
## Messages entrants de l’API de télémétrie
](#telemetry-api-messages)
+ [
# Référence de l’API de télémétrie Lambda
](telemetry-api-reference.md)
+ [
# Référence du schéma `Event` de l’API de télémétrie Lambda
](telemetry-schema-reference.md)
+ [
# Conversion d'objets de l'API de télémétrie Lambda en Spans `Event` OpenTelemetry
](telemetry-otel-spans.md)
+ [
# Utilisation de l’API Logs Lambda
](runtimes-logs-api.md)
## Création d’extensions à l’aide de l’API de télémétrie
Les extensions Lambda s’exécutent comme des processus indépendants dans l’environnement d’exécution. Les extensions peuvent continuer à s’exécuter une fois l’invocation des fonctions terminée. Comme les extensions sont des processus séparés, vous pouvez les écrire dans un langage différent du code de la fonction. Nous recommandons d’écrire les extensions en utilisant un langage compilé tel que Golang ou Rust. De cette façon, l’extension est un binaire autonome qui peut être compatible avec tout environnement d’exécution pris en charge.
Le schéma suivant illustre un processus en quatre étapes pour créer une extension qui reçoit et traite des données de télémétrie à l’aide de l’API de télémétrie.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/telemetry-api-creation-steps.png)
Voici chaque étape plus en détail :
1. Enregistrez votre extension à l’aide du [Utilisation de l’API d’extensions Lambda pour créer des extensions](runtimes-extensions-api.md). Cela vous fournit un `Lambda-Extension-Identifier`, dont vous aurez besoin dans les étapes suivantes. Pour plus d’informations sur la façon d’enregistrer votre extension, consultez [Enregistrement de votre extension](#telemetry-api-registration).
1. Créez un écouteur de télémétrie. Il peut s’agir d’un serveur HTTP ou TCP de base. Lambda utilise l’URI de l’écouteur de télémétrie pour envoyer des données de télémétrie à votre extension. Pour de plus amples informations, veuillez consulter [Création d’un écouteur de télémétrie](#telemetry-api-listener).
1. À l’aide de l’API d’abonnement de l’API de télémétrie, abonnez votre extension aux flux de télémétrie souhaités. Vous aurez besoin de l’URI de votre écouteur de télémétrie pour cette étape. Pour de plus amples informations, veuillez consulter [Envoi d’une demande d’abonnement à l’API de télémétrie](#telemetry-api-subscription).
1. Obtenez les données de télémétrie de Lambda via l’écouteur de télémétrie. Vous pouvez effectuer tout traitement personnalisé de ces données, par exemple en les envoyant vers Amazon S3 ou vers un service d’observabilité externe.
**Note**
L’environnement d’exécution d’une fonction Lambda peut démarrer et s’arrêter plusieurs fois dans le cadre de son [cycle de vie](runtimes-extensions-api.md#runtimes-extensions-api-lifecycle). En général, votre code d’extension s’exécute pendant les appels de la fonction, et aussi jusqu’à 2 secondes pendant la phase d’arrêt. Nous vous recommandons de regrouper la télémétrie au fur et à mesure qu’elle parvient à votre écouteur. Utilisez ensuite les événements du cycle de vie `Invoke` et `Shutdown` pour envoyer chaque lot vers les destinations souhaitées.
## Enregistrement de votre extension
Avant de pouvoir vous abonner aux données de télémétrie, vous devez enregistrer votre extension Lambda. L’enregistrement a lieu pendant la [phase d’initialisation de l’extension](runtimes-extensions-api.md#runtimes-extensions-api-reg). L’exemple suivant montre une demande HTTP pour enregistrer une extension.
```
POST http://${AWS_LAMBDA_RUNTIME_API}/2020-01-01/extension/register
Lambda-Extension-Name: lambda_extension_name
{
'events': [ 'INVOKE', 'SHUTDOWN']
}
```
Si la demande réussit, l’abonné reçoit une réponse de succès HTTP 200. L’en-tête de réponse contient le `Lambda-Extension-Identifier`. Le corps de la réponse contient d’autres propriétés de la fonction.
```
HTTP/1.1 200 OK
Lambda-Extension-Identifier: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111
{
"functionName": "lambda_function",
"functionVersion": "$LATEST",
"handler": "lambda_handler",
"accountId": "123456789012"
}
```
Pour plus d’informations, consultez le [Référence d’API d’extensions](runtimes-extensions-api.md#runtimes-extensions-registration-api).
## Création d’un écouteur de télémétrie
Votre extension Lambda doit avoir un écouteur qui traite les demandes entrantes de l’API de télémétrie. Le code suivant présente un exemple de mise en œuvre d’un écouteur de télémétrie en 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
}
```
## Spécification d’un protocole de destination
Lorsque vous vous abonnez pour recevoir de la télémétrie à l’aide de l’API de télémétrie, vous pouvez spécifier un protocole de destination en plus de l’URI de destination :
```
{
"destination": {
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080"
}
}
```
Lambda accepte deux protocoles pour recevoir des télémétries :
+ **HTTP (recommandé)** – Lambda envoie la télémétrie à un point de terminaison HTTP local (`http://sandbox.localdomain:${PORT}/${PATH}`) sous la forme d’un tableau d’enregistrements au format JSON. Le paramètre `$PATH` est facultatif. Lambda ne prend en charge que HTTP, pas HTTPS. Lambda fournit des données de télémétrie via des demandes POST.
+ **TCP** – Lambda envoie la télémétrie à un port TCP au [format NDJSON (Newline delimited JSON)](https://github.com/ndjson/ndjson-spec).
**Note**
Nous vous recommandons vivement d’utiliser HTTP plutôt que TCP. Avec TCP, la plateforme Lambda ne peut pas confirmer la livraison de la télémétrie à la couche d’application. Par conséquent, si votre extension se bloque, vous risquez de perdre la télémétrie. HTTP ne présente pas cette limitation.
Avant de vous abonner pour recevoir la télémétrie, établissez l’écouteur HTTP local ou le port TCP. Au cours de l’installation, notez ce qui suit :
+ Lambda n’envoie la télémétrie qu’à des destinations au sein de l’environnement d’exécution.
+ Lambda réessaie d’envoyer la télémétrie (avec interruption) en l’absence d’écouteur, ou si la demande POST rencontre une erreur. Si l’écouteur de télémétrie se bloque, il reprend la réception de la télémétrie après que Lambda a redémarré l’environnement d’exécution.
+ Lambda réserve le port 9001. Il n’y a pas d’autres restrictions ou recommandations relatives au numéro de port.
## Configuration de l’utilisation de la mémoire et de la mise en mémoire tampon
L’utilisation de la mémoire dans un environnement d’exécution augmente de façon linéaire avec le nombre d’abonnés. Les abonnements consomment des ressources de mémoire, car chacun d’eux ouvre un nouveau tampon mémoire pour stocker les données de télémétrie. L’utilisation de la mémoire tampon contribue à la consommation globale de mémoire dans l’environnement d’exécution.
Lorsque vous vous abonnez pour recevoir des données télémétriques via l’API de télémétrie, vous pouvez mettre en mémoire tampon les données télémétriques et les transmettre aux abonnés par lots. Pour optimiser l’utilisation de la mémoire, vous pouvez spécifier une configuration de mise en mémoire tampon :
```
{
"buffering": {
"maxBytes": 256*1024,
"maxItems": 1000,
"timeoutMs": 100
}
}
```
| Paramètre | Description | Valeurs par défaut et limites |
| --- | --- | --- |
| `maxBytes` | Le volume maximal de télémétrie (en octets) à mettre en mémoire tampon. | Par défaut : 262 144 Minimum : 262 144 Maximum : 1 048 576 |
| `maxItems` | Le nombre maximal d’événements à mettre en mémoire tampon. | Par défaut : 10 000 Minimum : 1 000 Maximum : 10 000. |
| `timeoutMs` | La durée maximale (en millisecondes) pour la mise en mémoire tampon d’un lot. | Par défaut : 1 000 Minimum : 25 Maximum : 30 000 |
Lorsque vous configurez la mise en mémoire tampon, tenez compte des points suivants :
+ Si l’un des flux d’entrée est fermé, Lambda vide les journaux. Cela peut se produire si, par exemple, l’environnement d’exécution se bloque.
+ Chaque abonné peut spécifier une configuration de mise en mémoire tampon différente dans sa demande d’abonnement.
+ Lorsque vous déterminez la taille de la mémoire tampon pour la lecture des données, attendez-vous à recevoir des charges utiles aussi importantes que `2 * maxBytes + metadataBytes`, `maxBytes` étant un composant de votre configuration de mise en mémoire tampon. Pour évaluer la quantité de `metadataBytes` à prendre en compte, consultez les métadonnées suivantes. Lambda adjoint des métadonnées similaires à celles-ci à chaque enregistrement :
```
{
"time": "2022-08-20T12:31:32.123Z",
"type": "function",
"record": "Hello World"
}
```
+ Si l’abonné ne peut pas traiter la télémétrie entrante assez rapidement, ou si votre code de fonction génère un volume de journal très élevé, Lambda peut abandonner des enregistrements pour limiter l’utilisation de la mémoire. Lorsque cela se produit, Lambda envoie un événement `platform.logsDropped`.
## Envoi d’une demande d’abonnement à l’API de télémétrie
Les extensions Lambda peuvent s’abonner pour recevoir des données de télémétrie en envoyant une demande d’abonnement à l’API de télémétrie. La demande d’abonnement doit contenir des informations sur les types d’événements auxquels vous voulez que l’extension s’abonne. En outre, la demande peut contenir des [informations sur la destination de la livraison](#telemetry-api-destination) et une [configuration de mise en mémoire tampon](#telemetry-api-buffering).
Avant d’envoyer une demande d’abonnement, vous devez disposer d’un ID d’extension (`Lambda-Extension-Identifier`). Lorsque vous [enregistrez votre extension avec l’API d’extensions](#telemetry-api-registration), vous obtenez un ID d’extension à partir de la réponse API.
L’abonnement a lieu pendant la [phase d’initialisation de l’extension](runtimes-extensions-api.md#runtimes-extensions-api-reg). L’exemple suivant montre une demande HTTP pour s’abonner aux trois flux de télémétrie : télémétrie de la plateforme, journaux des fonctions et journaux des extensions.
```
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"
}
}
```
Si la demande réussit, l’abonné reçoit une réponse de succès HTTP 200.
```
HTTP/1.1 200 OK
"OK"
```
## Messages entrants de l’API de télémétrie
Après s’être abonnée à l’API de télémétrie, une extension commence automatiquement à recevoir la télémétrie de Lambda via des demandes POST. Chaque corps de requête POST contient un tableau d’objets `Event`. Chaque `Event` est structuré selon le schéma suivant :
```
{
time: String,
type: String,
record: Object
}
```
+ La propriété `time` définit le moment où la plateforme Lambda a généré l’événement. Cela est différent du moment où l’événement s’est réellement produit. La valeur de la chaîne `time` est un horodatage au format ISO 8601.
+ La propriété `type` définit le type d’événement. Le tableau suivant décrit toutes les valeurs possibles.
+ La propriété `record` définit un objet JSON qui contient les données de télémétrie. Le schéma de cet objet JSON dépend de la propriété `type`.
**Commande d'événements avec invocations simultanées**
Pour les [instances gérées Lambda](lambda-managed-instances.md), plusieurs invocations de fonctions peuvent s'exécuter simultanément dans le même environnement d'exécution. Dans ce cas, l'ordre `platform.start` et les `platform.report` événements ne sont pas garantis entre les différentes invocations simultanées. Les extensions doivent gérer les événements issus de plusieurs invocations exécutées en parallèle et ne doivent pas adopter un ordre séquentiel.
Pour attribuer correctement des événements à des invocations spécifiques, les extensions doivent utiliser le `requestId` champ présent dans ces événements de plateforme. Chaque appel possède un identifiant de demande unique qui reste le même pour tous les événements associés à cet appel, ce qui permet aux extensions de corréler correctement les événements même lorsqu'ils arrivent dans le désordre.
Le tableau suivant résume tous les types d’objets `Event` et renvoie à la [référence du schéma `Event` de l’API de télémétrie](telemetry-schema-reference.md) pour chaque type d’événement.
| Catégorie | Type d’événement | Description | Schéma d’enregistrement des événements |
| --- | --- | --- | --- |
| Événement de plateforme | `platform.initStart` | L’initialisation de la fonction a commencé. | Schéma [`platform.initStart`](telemetry-schema-reference.md#platform-initStart) |
| Événement de plateforme | `platform.initRuntimeDone` | L’initialisation de la fonction est terminée. | Schéma [`platform.initRuntimeDone`](telemetry-schema-reference.md#platform-initRuntimeDone) |
| Événement de plateforme | `platform.initReport` | Un rapport d’initialisation de la fonction. | Schéma [`platform.initReport`](telemetry-schema-reference.md#platform-initReport) |
| Événement de plateforme | `platform.start` | L’invocation de la fonction a commencé. | Schéma [`platform.start`](telemetry-schema-reference.md#platform-start) |
| Événement de plateforme | `platform.runtimeDone` | L’environnement d’exécution a fini de traiter un événement avec succès ou échec. | Schéma [`platform.runtimeDone`](telemetry-schema-reference.md#platform-runtimeDone) |
| Événement de plateforme | `platform.report` | Un rapport sur l’invocation de la fonction. | Schéma [`platform.report`](telemetry-schema-reference.md#platform-report) |
| Événement de plateforme | `platform.restoreStart` | La restauration de l’exécution a commencé. | Schéma [`platform.restoreStart`](telemetry-schema-reference.md#platform-restoreStart) |
| Événement de plateforme | `platform.restoreRuntimeDone` | La restauration de l’exécution est terminée. | Schéma [`platform.restoreRuntimeDone`](telemetry-schema-reference.md#platform-restoreRuntimeDone) |
| Événement de plateforme | `platform.restoreReport` | Le rapport de restauration de d’exécution. | Schéma [`platform.restoreReport`](telemetry-schema-reference.md#platform-restoreReport) |
| Événement de plateforme | `platform.telemetrySubscription` | L’extension s’est abonnée à l’API de télémétrie. | Schéma [`platform.telemetrySubscription`](telemetry-schema-reference.md#platform-telemetrySubscription) |
| Événement de plateforme | `platform.logsDropped` | Les entrées de journal abandonnées par Lambda. | Schéma [`platform.logsDropped`](telemetry-schema-reference.md#platform-logsDropped) |
| Journaux de fonctions | `function` | Une ligne de journal du code de la fonction. | Schéma [`function`](telemetry-schema-reference.md#telemetry-api-function) |
| Journaux d’extension | `extension` | Une ligne de journal du code de l’extension. | Schéma [`extension`](telemetry-schema-reference.md#telemetry-api-extension) |
# Référence de l’API de télémétrie Lambda
Utilisez le point de terminaison de l’API de télémétrie Lambda pour abonner des extensions aux flux de télémétrie. Vous pouvez extraire le point de terminaison d’API de télémétrie à partir de la variable d’environnement `AWS_LAMBDA_RUNTIME_API`. Pour envoyer une demande d’API, ajoutez la version de l’API (`2022-07-01/`) et `telemetry/`. Par exemple :
```
http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry/
```
Pour la définition de la spécification OpenAPI (OAS) de la version des réponses d’abonnement `2025-01-29`, voir ce qui suit :
+ **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**
+ [
## S’abonner
](#telemetry-subscribe-api)
## S’abonner
Pour s’abonner à un flux de télémétrie, une extension Lambda peut envoyer une demande d’API d’abonnement.
+ **Chemin** – `/telemetry`
+ **Méthode** – `PUT`
+ **En-têtes**
+ `Content-Type`: `application/json`
+ **Paramètres du corps de la demande**
+ **schemaVersion **
+ Obligatoire : oui
+ Type : String
+ Valeurs valides : `"2025-01-29"`, `"2022-12-13"` ou `"2022-07-01"`
+ **Remarque :** les instances gérées Lambda nécessitent. `"2025-01-29"` Cette version est rétrocompatible avec les fonctions Lambda (par défaut).
+ **destination** – Les paramètres de configuration qui définissent la destination de l’événement de télémétrie et le protocole de livraison de l’événement.
+ Obligatoire : oui
+ Type : objet
```
{
"protocol": "HTTP",
"URI": "http://sandbox.localdomain:8080"
}
```
+ **protocol** – Le protocole que Lambda utilise pour envoyer les données de télémétrie.
+ Obligatoire : oui
+ Type : String
+ Valeurs valides : `"HTTP"`\$1`"TCP"`
+ **URI** – L’URI auquel envoyer les données de télémétrie.
+ Obligatoire : oui
+ Type : String
+ Pour de plus amples informations, veuillez consulter [Spécification d’un protocole de destination](telemetry-api.md#telemetry-api-destination).
+ **types** – Les types de télémétrie auxquels vous voulez que l’extension s’abonne.
+ Obligatoire : oui
+ Type : tableau de chaînes
+ Valeurs valides : `"platform"`\$1`"function"`\$1`"extension"`
+ **buffering** – Les paramètres de configuration de la mise en mémoire tampon des événements.
+ Obligatoire : non
+ Type : objet
```
{
"buffering": {
"maxItems": 1000,
"maxBytes": 256*1024,
"timeoutMs": 100
}
}
```
+ **maxItems** – Nombre maximum d’événements à mettre en mémoire tampon.
+ Obligatoire : non
+ Type : Integer
+ Par défaut : 1 000
+ Minimum : 1 000
+ Maximum : 10 000.
+ **maxBytes** – Le volume maximal de télémétrie (en octets) à mettre en mémoire tampon.
+ Obligatoire : non
+ Type : Integer
+ Par défaut : 262 144
+ Minimum : 262 144
+ Maximum : 1 048 576
+ **timeoutMs** – Durée maximum (en millisecondes) de mise en mémoire tampon d’un lot.
+ Obligatoire : non
+ Type : Integer
+ Par défaut : 1 000
+ Minimum : 25
+ Maximum : 30 000
+ Pour de plus amples informations, veuillez consulter [Configuration de l’utilisation de la mémoire et de la mise en mémoire tampon](telemetry-api.md#telemetry-api-buffering).
### Exemple de demande d’API d’abonnement
```
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"
}
}
```
Si la demande d’abonnement aboutit, l’extension reçoit une réponse HTTP 200 :
```
HTTP/1.1 200 OK
"OK"
```
Si la demande d’abonnement échoue, l’extension reçoit une réponse d’erreur. Par exemple :
```
HTTP/1.1 400 OK
{
"errorType": "ValidationError",
"errorMessage": "URI port is not provided; types should not be empty"
}
```
Voici quelques codes de réponse supplémentaires que l’extension peut recevoir :
+ 200 – Demande effectuée avec succès.
+ 202 – Demande acceptée. Réponse à une demande d’abonnement dans un environnement de test local
+ 400 – Demande erronée
+ 500 – Erreur de service.
# Référence du schéma `Event` de l’API de télémétrie Lambda
Utilisez le point de terminaison de l’API de télémétrie Lambda pour abonner des extensions aux flux de télémétrie. Vous pouvez extraire le point de terminaison d’API de télémétrie à partir de la variable d’environnement `AWS_LAMBDA_RUNTIME_API`. Pour envoyer une demande d’API, ajoutez la version de l’API (`2022-07-01/`) et `telemetry/`. Par exemple :
```
http://${AWS_LAMBDA_RUNTIME_API}/2022-07-01/telemetry/
```
Pour la définition de la spécification OpenAPI (OAS) de la version des réponses d’abonnement `2025-01-29`, voir ce qui suit :
+ **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)**
Le tableau suivant est un résumé de tous les types d’objets `Event` que l’API de télémétrie prend en charge.
| Catégorie | Type d’événement | Description | Schéma d’enregistrement des événements |
| --- | --- | --- | --- |
| Événement de plateforme | `platform.initStart` | L’initialisation de la fonction a commencé. | Schéma [`platform.initStart`](#platform-initStart) |
| Événement de plateforme | `platform.initRuntimeDone` | L’initialisation de la fonction est terminée. | Schéma [`platform.initRuntimeDone`](#platform-initRuntimeDone) |
| Événement de plateforme | `platform.initReport` | Un rapport d’initialisation de la fonction. | Schéma [`platform.initReport`](#platform-initReport) |
| Événement de plateforme | `platform.start` | L’invocation de la fonction a commencé. | Schéma [`platform.start`](#platform-start) |
| Événement de plateforme | `platform.runtimeDone` | L’environnement d’exécution a fini de traiter un événement avec succès ou échec. | Schéma [`platform.runtimeDone`](#platform-runtimeDone) |
| Événement de plateforme | `platform.report` | Un rapport sur l’invocation de la fonction. | Schéma [`platform.report`](#platform-report) |
| Événement de plateforme | `platform.restoreStart` | La restauration de l’exécution a commencé. | Schéma [`platform.restoreStart`](#platform-restoreStart) |
| Événement de plateforme | `platform.restoreRuntimeDone` | La restauration de l’exécution est terminée. | Schéma [`platform.restoreRuntimeDone`](#platform-restoreRuntimeDone) |
| Événement de plateforme | `platform.restoreReport` | Le rapport de restauration de d’exécution. | Schéma [`platform.restoreReport`](#platform-restoreReport) |
| Événement de plateforme | `platform.telemetrySubscription` | L’extension s’est abonnée à l’API de télémétrie. | Schéma [`platform.telemetrySubscription`](#platform-telemetrySubscription) |
| Événement de plateforme | `platform.logsDropped` | Les entrées de journal abandonnées par Lambda. | Schéma [`platform.logsDropped`](#platform-logsDropped) |
| Journaux de fonctions | `function` | Une ligne de journal du code de la fonction. | Schéma [`function`](#telemetry-api-function) |
| Journaux d’extension | `extension` | Une ligne de journal du code de l’extension. | Schéma [`extension`](#telemetry-api-extension) |
**Contents**
+ [
## Types d’objets `Event` de l’API de télémétrie
](#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)
+ [
## Types d’objets partagés
](#telemetry-api-objects)
+ [
### `InitPhase`
](#InitPhase)
+ [
### `InitReportMetrics`
](#InitReportMetrics)
+ [
### `InitType`
](#InitType)
+ [
### `ReportMetrics`
](#ReportMetrics)
+ [
### `RestoreReportMetrics`
](#RestoreReportMetrics)
+ [
### `RuntimeDoneMetrics`
](#RuntimeDoneMetrics)
+ [
### `Span`
](#Span)
+ [
### `Status`
](#Status)
+ [
### `TraceContext`
](#TraceContext)
+ [
### `TracingType`
](#TracingType)
## Types d’objets `Event` de l’API de télémétrie
Cette section détaille les types d’objets `Event` que l’API de télémétrie Lambda prend en charge. Dans les descriptions d’événements, un point d’interrogation (`?`) indique que l’attribut peut ne pas être présent dans l’objet.
### `platform.initStart`
Un événement `platform.initStart` indique que la phase d’initialisation de la fonction a commencé. Un objet `Event` `platform.initStart` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.initStart
- record: PlatformInitStart
```
L’objet `PlatformInitStart` possède les attributs suivants :
+ **functionName** – `String`
+ **functionVersion** – `String`
+ **InitializationType** – Objet ``InitType``
+ **instanceId?** – `String`
+ **instanceMaxMemory?** – `Integer`
+ **phase** – Objet ``InitPhase``
+ **runtimeVersion?** – `String`
+ **runtimeVersionArn?** – `String`
Voici un exemple de `Event` de type `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`
Un événement `platform.initRuntimeDone` indique que la phase d’initialisation de la fonction est terminée. Un objet `Event` `platform.initRuntimeDone` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.initRuntimeDone
- record: PlatformInitRuntimeDone
```
L’objet `PlatformInitRuntimeDone` possède les attributs suivants :
+ **InitializationType** – Objet ``InitType``
+ **phase** – Objet ``InitPhase``
+ **status** – Objet ``Status``
+ **spans?** – Liste d’objets ``Span``
Voici un exemple de `Event` de type `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`
Un événement `platform.initReport` contient un rapport global de la phase d’initialisation de la fonction. Un objet `Event` `platform.initReport` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.initReport
- record: PlatformInitReport
```
L’objet `PlatformInitReport` possède les attributs suivants :
+ **errorType?** – chaîne
+ **InitializationType** – Objet ``InitType``
+ **phase** – Objet ``InitPhase``
+ **metrics** – Objet ``InitReportMetrics``
+ **spans?** – Liste d’objets ``Span``
+ **status** – Objet ``Status``
Voici un exemple de `Event` de type `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`
Un événement `platform.start` indique que la phase d’invocation de la fonction a commencé. Un objet `Event` `platform.start` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.start
- record: PlatformStart
```
L’objet `PlatformStart` possède les attributs suivants :
+ **requestId** – `String`
+ **version?** – `String`
+ **tracing?** – ``TraceContext``
Voici un exemple de `Event` de type `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`
Un événement `platform.runtimeDone` indique que la phase d’invocation de la fonction est terminée. Un objet `Event` `platform.runtimeDone` a la forme suivante :
**Instances gérées Lambda**
L'`platform.runtimeDone`événement n'est pas pris en charge pour les instances gérées Lambda. Les extensions exécutées sur les instances gérées ne recevront pas cet événement car les extensions ne peuvent pas s'abonner à l'`INVOKE`événement sur les instances gérées. En raison du modèle d'exécution simultanée dans lequel plusieurs invocations peuvent être traitées simultanément, les extensions ne peuvent pas effectuer de traitement post-appel pour des invocations individuelles comme elles le font traditionnellement sur les fonctions Lambda (par défaut).
Pour les instances gérées, les `responseLatency` intervalles `responseDuration` et qui y sont normalement inclus `platform.runtimeDone` sont plutôt disponibles lors de l'`platform.report`événement. Consultez [`platform.report`](#platform-report) pour plus de détails.
```
Event: Object
- time: String
- type: String = platform.runtimeDone
- record: PlatformRuntimeDone
```
L’objet `PlatformRuntimeDone` possède les attributs suivants :
+ **errorType?** – `String`
+ **metrics?** – Objet ``RuntimeDoneMetrics``
+ **requestId** – `String`
+ **status** – Objet ``Status``
+ **spans?** – Liste d’objets ``Span``
+ **tracing?** – Objet ``TraceContext``
Voici un exemple de `Event` de type `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`
Un événement `platform.report` contient un rapport global de la phase d’invocation de la fonction. Un objet `Event` `platform.report` a la forme suivante :
**Instances gérées Lambda**
L'`platform.report`événement pour les instances gérées Lambda a des métriques et des durées différentes par rapport aux fonctions Lambda (par défaut). Pour les instances gérées :
**Portée** : contient `responseLatency` et `responseDuration` au lieu de. `extensionOverhead` L'`extensionOverhead`intervalle n'est pas disponible car les extensions ne peuvent pas s'abonner à l'`INVOKE`événement sur les instances gérées en raison du modèle d'exécution simultanée.
**Métriques** : inclut uniquement`durationMs`. Les mesures suivantes ne sont pas incluses : `billedDurationMs``initDurationMs`,`maxMemoryUsedMB`, et`memorySizeMB`. Ces métriques par appel ne sont pas applicables dans l'environnement d'exécution simultanée. Pour les mesures d'utilisation des ressources, utilisez [Surveillance des instances gérées par Lambda](lambda-managed-instances-monitoring.md) [Lambda Insights](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-insights.html).
```
Event: Object
- time: String
- type: String = platform.report
- record: PlatformReport
```
L’objet `PlatformReport` possède les attributs suivants :
+ **metrics** – Objet ``ReportMetrics``
+ **requestId** – `String`
+ **spans?** – Liste d’objets ``Span``
+ **status** – Objet ``Status``
+ **tracing?** – Objet ``TraceContext``
Voici un exemple de `Event` de type `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`
Un événement `platform.restoreStart` indique qu’un événement de restauration d’environnement de fonction a commencé. Dans un événement de restauration d’environnement, Lambda crée l’environnement à partir d’un instantané mis en cache plutôt que de l’initialiser à partir de zéro. Pour de plus amples informations, veuillez consulter [Lambda SnapStart](snapstart.md). Un objet `Event` `platform.restoreStart` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.restoreStart
- record: PlatformRestoreStart
```
L’objet `PlatformRestoreStart` possède les attributs suivants :
+ **functionName** – `String`
+ **functionVersion** – `String`
+ **instanceId?** – `String`
+ **instanceMaxMemory?** – `String`
+ **runtimeVersion?** – `String`
+ **runtimeVersionArn?** – `String`
Voici un exemple de `Event` de type `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`
Un événement `platform.restoreRuntimeDone` indique qu’un événement de restauration d’environnement de fonction s’est terminé. Dans un événement de restauration d’environnement, Lambda crée l’environnement à partir d’un instantané mis en cache plutôt que de l’initialiser à partir de zéro. Pour de plus amples informations, veuillez consulter [Lambda SnapStart](snapstart.md). Un objet `Event` `platform.restoreRuntimeDone` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.restoreRuntimeDone
- record: PlatformRestoreRuntimeDone
```
L’objet `PlatformRestoreRuntimeDone` possède les attributs suivants :
+ **errorType?** – `String`
+ **spans?** – Liste d’objets ``Span``
+ **status** – Objet ``Status``
Voici un exemple de `Event` de type `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`
Un événement `platform.restoreReport` contient un rapport global d’un événement de restauration de fonction. Un objet `Event` `platform.restoreReport` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.restoreReport
- record: PlatformRestoreReport
```
L’objet `PlatformRestoreReport` possède les attributs suivants :
+ **errorType?** – chaîne
+ **metrics?** – Objet ``RestoreReportMetrics``
+ **spans?** – Liste d’objets ``Span``
+ **status** – Objet ``Status``
Voici un exemple de `Event` de type `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`
Un événement `extension` contient des journaux provenant du code d’extension. Un objet `Event` `extension` a la forme suivante :
```
Event: Object
- time: String
- type: String = extension
- record: {}
```
L’objet `PlatformExtension` possède les attributs suivants :
+ **events** – Liste de `String`
+ **nom** – `String`
+ **state** – `String`
Voici un exemple de `Event` de type `platform.extension` :
```
{
"time": "2022-10-12T00:02:15.000Z",
"type": "platform.extension",
"record": {
"events": [ "INVOKE", "SHUTDOWN" ],
"name": "my-telemetry-extension",
"state": "Ready"
}
}
```
### `platform.telemetrySubscription`
Un événement `platform.telemetrySubscription` contient des informations sur un abonnement d’extension. Un objet `Event` `platform.telemetrySubscription` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.telemetrySubscription
- record: PlatformTelemetrySubscription
```
L’objet `PlatformTelemetrySubscription` possède les attributs suivants :
+ **nom** – `String`
+ **state** – `String`
+ **types** – Liste de `String`
Voici un exemple de `Event` de type `platform.telemetrySubscription` :
```
{
"time": "2022-10-12T00:02:35.000Z",
"type": "platform.telemetrySubscription",
"record": {
"name": "my-telemetry-extension",
"state": "Subscribed",
"types": [ "platform", "function" ]
}
}
```
### `platform.logsDropped`
Un événement `platform.logsDropped` contient des informations sur les événements abandonnés. Lambda génère un événement `platform.logsDropped` lorsqu’une fonction génère des journaux à un rythme trop élevé pour que Lambda puisse les traiter. Lorsque Lambda ne parvient pas à envoyer des journaux vers CloudWatch ou vers l'extension abonnée à l'API de télémétrie au rythme où la fonction les produit, il supprime les journaux pour empêcher l'exécution de la fonction de ralentir. Un objet `Event` `platform.logsDropped` a la forme suivante :
```
Event: Object
- time: String
- type: String = platform.logsDropped
- record: PlatformLogsDropped
```
L’objet `PlatformLogsDropped` possède les attributs suivants :
+ **droppedBytes** – `Integer`
+ **droppedRecords** – `Integer`
+ **reason** – `String`
Voici un exemple de `Event` de type `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`
Un événement `function` contient des journaux provenant du code de fonction. Un objet `Event` `function` a la forme suivante :
```
Event: Object
- time: String
- type: String = function
- record: {}
```
Le format du champ `record` varie selon que les journaux de votre fonction sont formatés en texte brut ou au format JSON. Pour en savoir plus sur les options de configuration du format de journal, consultez [Configuration des formats de journal JSON et en texte brut](monitoring-cloudwatchlogs-logformat.md)
Voici un exemple `Event` de type `function` où le format du journal est en texte brut :
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "function",
"record": "[INFO] Hello world, I am a function!"
}
```
Voici un exemple `Event` de type `function` où le journal est au format JSON :
```
{
"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!"
}
}
```
**Note**
Si la version du schéma que vous utilisez est plus ancienne que la version `2022-12-13`, `"record"` est toujours affiché sous forme de chaîne, même lorsque le format de journalisation de votre fonction est configuré au format JSON. Pour les instances gérées Lambda, vous devez utiliser la version du schéma. `2025-01-29`
### `extension`
Un événement `extension` contient des journaux provenant du code d’extension. Un objet `Event` `extension` a la forme suivante :
```
Event: Object
- time: String
- type: String = extension
- record: {}
```
Le format du champ `record` varie selon que les journaux de votre fonction sont formatés en texte brut ou au format JSON. Pour en savoir plus sur les options de configuration du format de journal, consultez [Configuration des formats de journal JSON et en texte brut](monitoring-cloudwatchlogs-logformat.md)
Voici un exemple `Event` de type `extension` où le format du journal est en texte brut :
```
{
"time": "2022-10-12T00:03:50.000Z",
"type": "extension",
"record": "[INFO] Hello world, I am an extension!"
}
```
Voici un exemple `Event` de type `extension` où le journal est au format JSON :
```
{
"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!"
}
}
```
**Note**
Si la version du schéma que vous utilisez est plus ancienne que la version `2022-12-13`, `"record"` est toujours affiché sous forme de chaîne, même lorsque le format de journalisation de votre fonction est configuré au format JSON. Pour les instances gérées Lambda, vous devez utiliser la version du schéma. `2025-01-29`
## Types d’objets partagés
Cette section détaille les types d’objets partagés que l’API de télémétrie Lambda prend en charge.
### `InitPhase`
Une enum de chaînes de caractères qui décrit la phase où l’étape d’initialisation se produit. Dans la plupart des cas, Lambda exécute le code d’initialisation de la fonction pendant la phase `init`. Toutefois, dans certains cas d’erreur, Lambda peut réexécuter le code d’initialisation de la fonction pendant la phase `invoke`. (Cela s’appelle une *init supprimée*.)
+ **Type** – `String`
+ **Valeurs valides** : `init`\$1`invoke`\$1`snap-start`
### `InitReportMetrics`
Un objet qui contient des métriques sur une phase d’initialisation.
+ **Type** – `Object`
Un objet `InitReportMetrics` a la forme suivante :
```
InitReportMetrics: Object
- durationMs: Double
```
Voici un exemple d’objet `InitReportMetrics` :
```
{
"durationMs": 247.88
}
```
### `InitType`
Une enum de chaînes de caractères qui décrit comment Lambda a initialisé l’environnement.
+ **Type** – `String`
+ **Valeurs valides** – `on-demand`\$1`provisioned-concurrency`
### `ReportMetrics`
Un objet qui contient des métriques sur une phase terminée.
+ **Type** – `Object`
Un objet `ReportMetrics` a la forme suivante :
```
ReportMetrics: Object
- billedDurationMs: Integer
- durationMs: Double
- initDurationMs?: Double
- maxMemoryUsedMB: Integer
- memorySizeMB: Integer
- restoreDurationMs?: Double
```
Voici un exemple d’objet `ReportMetrics` :
```
{
"billedDurationMs": 694,
"durationMs": 693.92,
"initDurationMs": 397.68,
"maxMemoryUsedMB": 84,
"memorySizeMB": 128
}
```
### `RestoreReportMetrics`
Un objet qui contient des métriques sur une phase de restauration terminée.
+ **Type** – `Object`
Un objet `RestoreReportMetrics` a la forme suivante :
```
RestoreReportMetrics: Object
- durationMs: Double
```
Voici un exemple d’objet `RestoreReportMetrics` :
```
{
"durationMs": 15.19
}
```
### `RuntimeDoneMetrics`
Un objet qui contient des métriques sur une phase d’invocation.
+ **Type** – `Object`
Un objet `RuntimeDoneMetrics` a la forme suivante :
```
RuntimeDoneMetrics: Object
- durationMs: Double
- producedBytes?: Integer
```
Voici un exemple d’objet `RuntimeDoneMetrics` :
```
{
"durationMs": 200.0,
"producedBytes": 15
}
```
### `Span`
Un objet qui contient des détails sur un span. Un span représente une unité de travail ou une opération dans une trace. Pour plus d'informations sur les spans, consultez [Span](https://opentelemetry.io/docs/reference/specification/trace/api/#span) sur la page de l'**API de suivi** du site Web de OpenTelemetry Docs.
Lambda prend en charge les span suivants pour l’événement `platform.RuntimeDone` :
+ Le span `responseLatency` décrit le temps qu’il a fallu à votre fonction Lambda pour commencer à envoyer la réponse.
+ Le span `responseDuration` décrit le temps qu’il a fallu à votre fonction Lambda pour finir d’envoyer la réponse entière.
+ Le span `runtimeOverhead` décrit le temps qu’il a fallu à l’environnement d’exécution Lambda pour signaler qu’il était prêt à traiter la prochaine invocation de fonction. C’est le temps qu’il a fallu à l’environnement d’exécution pour appeler l’API d’[invocation suivante](runtimes-api.md#runtimes-api-next) pour obtenir le prochain événement après avoir renvoyé la réponse de votre fonction.
Voici un exemple d’objet span `responseLatency` :
```
{
"name": "responseLatency",
"start": "2022-08-02T12:01:23.521Z",
"durationMs": 23.02
}
```
### `Status`
Un objet qui décrit le statut d’une phase d’initialisation ou d’invocation. Si le statut est `failure` ou `error`, l’objet `Status` contient également un champ `errorType` décrivant l’erreur.
+ **Type** – `Object`
+ **Valeurs de status valides** : `success`\$1`failure`\$1`error`\$1`timeout`
### `TraceContext`
Un objet qui décrit les propriétés d’une trace.
+ **Type** – `Object`
Un objet `TraceContext` a la forme suivante :
```
TraceContext: Object
- spanId?: String
- type: TracingType enum
- value: String
```
Voici un exemple d’objet `TraceContext` :
```
{
"spanId": "073a49012f3c312e",
"type": "X-Amzn-Trace-Id",
"value": "Root=1-62e900b2-710d76f009d6e7785905449a;Parent=0efbd19962d95b05;Sampled=1"
}
```
### `TracingType`
Un enum de chaînes de caractères qui décrit le type de trace dans un objet ``TraceContext``.
+ **Type** – `String`
+ **Valeurs valides** – `X-Amzn-Trace-Id`
# Conversion d'objets de l'API de télémétrie Lambda en Spans `Event` OpenTelemetry
Le schéma de l'API AWS Lambda de télémétrie est sémantiquement compatible avec (). OpenTelemetry OTel Cela signifie que vous pouvez convertir les `Event` objets de votre API de AWS Lambda télémétrie en OpenTelemetry (OTel) Spans. Lors de la conversion, vous ne devez pas mapper un seul `Event` objet à un seul OTel Span. Vous devez plutôt présenter les trois événements liés à une phase du cycle de vie dans un seul OTel intervalle. Par exemple, les événements `start`, `runtimeDone` et `runtimeReport` représentent un seul appel de fonction. Présentez ces trois événements sous la forme d'un seul OTel Span.
Vous pouvez convertir vos événements en utilisant des événements Span ou des Spans enfants (imbriqués). Les tableaux de cette page décrivent les mappages entre les propriétés du schéma de l'API de télémétrie et les propriétés OTel Span pour les deux approches. Pour plus d'informations sur OTel Spans, consultez [Span](https://opentelemetry.io/docs/reference/specification/trace/api/#span) sur la page de l'**API de suivi** du site Web de OpenTelemetry Docs.
**Topics**
+ [
## Carte de OTel Spans avec Span Events
](#telemetry-otel-span-events)
+ [
## Carte des OTel travées avec des travées pour les enfants
](#telemetry-otel-child-spans)
## Carte de OTel Spans avec Span Events
Dans les tableaux suivants, `e` représente l’événement provenant de la source de télémétrie.
**Mappage des événements \$1Start**
| OpenTelemetry | Schéma de l’API de télémétrie Lambda |
| --- | --- |
| `Span.Name` | Votre extension génère cette valeur sur la base du champ `type`. |
| `Span.StartTime` | Utilisez `e.time`. |
| `Span.EndTime` | S/O, car l’événement n’est pas encore terminé. |
| `Span.Kind` | Définie sur `Server`. |
| `Span.Status` | Définie sur `Unset`. |
| `Span.TraceId` | Analysez l' AWS X-Ray en-tête trouvé dans`e.tracing.value`, puis utilisez la `TraceId` valeur. |
| `Span.ParentId` | Analysez l’en-tête X-Ray trouvé dans `e.tracing.value`, puis utilisez la valeur `Parent`. |
| `Span.SpanId` | Utilisez `e.tracing.spanId` si disponible. Sinon, générer un nouveau `SpanId`. |
| `Span.SpanContext.TraceState` | S/O pour un contexte de trace X-Ray. |
| `Span.SpanContext.TraceFlags` | Analysez l’en-tête X-Ray trouvé dans `e.tracing.value`, puis utilisez la valeur `Sampled`. |
| `Span.Attributes` | Votre extension peut ajouter toute valeur personnalisée ici. |
**Cartographie des RuntimeDone événements\$1**
| OpenTelemetry | Schéma de l’API de télémétrie Lambda |
| --- | --- |
| `Span.Name` | Votre extension génère la valeur basée sur le champ `type`. |
| `Span.StartTime` | Utilisez `e.time` à partir de l’événement `*Start` correspondant. Sinon, utilisez `e.time - e.metrics.durationMs`. |
| `Span.EndTime` | S/O, car l’événement n’est pas encore terminé. |
| `Span.Kind` | Définie sur `Server`. |
| `Span.Status` | Si `e.status` n’est pas égal à `success`, mettez `Error`. Sinon, définissez sur `Ok`. |
| `Span.Events[]` | Utilisez `e.spans[]`. |
| `Span.Events[i].Name` | Utilisez `e.spans[i].name`. |
| `Span.Events[i].Time` | Utilisez `e.spans[i].start`. |
| `Span.TraceId` | Analysez l' AWS X-Ray en-tête trouvé dans`e.tracing.value`, puis utilisez la `TraceId` valeur. |
| `Span.ParentId` | Analysez l’en-tête X-Ray trouvé dans `e.tracing.value`, puis utilisez la valeur `Parent`. |
| `Span.SpanId` | Utilisez le même `SpanId` de l’événement `*Start`. S’il n’est pas disponible, utilisez alors `e.tracing.spanId`, ou générez un nouveau `SpanId`. |
| `Span.SpanContext.TraceState` | S/O pour un contexte de trace X-Ray. |
| `Span.SpanContext.TraceFlags` | Analysez l’en-tête X-Ray trouvé dans `e.tracing.value`, puis utilisez la valeur `Sampled`. |
| `Span.Attributes` | Votre extension peut ajouter toute valeur personnalisée ici. |
**Mappage des événements \$1Report**
| OpenTelemetry | Schéma de l’API de télémétrie Lambda |
| --- | --- |
| `Span.Name` | Votre extension génère la valeur basée sur le champ `type`. |
| `Span.StartTime` | Utilisez `e.time` à partir de l’événement `*Start` correspondant. Sinon, utilisez `e.time - e.metrics.durationMs`. |
| `Span.EndTime` | Utilisez `e.time`. |
| `Span.Kind` | Définie sur `Server`. |
| `Span.Status` | Utilisez la même valeur que l’événement `*RuntimeDone`. |
| `Span.TraceId` | Analysez l' AWS X-Ray en-tête trouvé dans`e.tracing.value`, puis utilisez la `TraceId` valeur. |
| `Span.ParentId` | Analysez l’en-tête X-Ray trouvé dans `e.tracing.value`, puis utilisez la valeur `Parent`. |
| `Span.SpanId` | Utilisez le même `SpanId` de l’événement `*Start`. S’il n’est pas disponible, utilisez alors `e.tracing.spanId`, ou générez un nouveau `SpanId`. |
| `Span.SpanContext.TraceState` | S/O pour un contexte de trace X-Ray. |
| `Span.SpanContext.TraceFlags` | Analysez l’en-tête X-Ray trouvé dans `e.tracing.value`, puis utilisez la valeur `Sampled`. |
| `Span.Attributes` | Votre extension peut ajouter toute valeur personnalisée ici. |
## Carte des OTel travées avec des travées pour les enfants
Le tableau suivant décrit comment convertir les événements de l'API de télémétrie Lambda en OTel spans with Child (imbriqué) Spans for Spans. `*RuntimeDone` Pour les mappages `*Start` et `*Report`, reportez-vous aux tableaux de [Carte de OTel Spans avec Span Events](#telemetry-otel-span-events), car ils sont les mêmes pour les Spans enfant. Dans cette table, `e` représente l’événement provenant de la source de télémétrie.
**Cartographie des RuntimeDone événements\$1**
| OpenTelemetry | Schéma de l’API de télémétrie Lambda |
| --- | --- |
| `Span.Name` | Votre extension génère la valeur basée sur le champ `type`. |
| `Span.StartTime` | Utilisez `e.time` à partir de l’événement `*Start` correspondant. Sinon, utilisez `e.time - e.metrics.durationMs`. |
| `Span.EndTime` | S/O, car l’événement n’est pas encore terminé. |
| `Span.Kind` | Définie sur `Server`. |
| `Span.Status` | Si `e.status` n’est pas égal à `success`, mettez `Error`. Sinon, définissez sur `Ok`. |
| `Span.TraceId` | Analysez l' AWS X-Ray en-tête trouvé dans`e.tracing.value`, puis utilisez la `TraceId` valeur. |
| `Span.ParentId` | Analysez l’en-tête X-Ray trouvé dans `e.tracing.value`, puis utilisez la valeur `Parent`. |
| `Span.SpanId` | Utilisez le même `SpanId` de l’événement `*Start`. S’il n’est pas disponible, utilisez alors `e.tracing.spanId`, ou générez un nouveau `SpanId`. |
| `Span.SpanContext.TraceState` | S/O pour un contexte de trace X-Ray. |
| `Span.SpanContext.TraceFlags` | Analysez l’en-tête X-Ray trouvé dans `e.tracing.value`, puis utilisez la valeur `Sampled`. |
| `Span.Attributes` | Votre extension peut ajouter toute valeur personnalisée ici. |
| `ChildSpan[i].Name` | Utilisez `e.spans[i].name`. |
| `ChildSpan[i].StartTime` | Utilisez `e.spans[i].start`. |
| `ChildSpan[i].EndTime` | Utilisez `e.spans[i].start + e.spans[i].durations`. |
| `ChildSpan[i].Kind` | Identique au parent `Span.Kind`. |
| `ChildSpan[i].Status` | Identique au parent `Span.Status`. |
| `ChildSpan[i].TraceId` | Identique au parent `Span.TraceId`. |
| `ChildSpan[i].ParentId` | Utilisez le parent `Span.SpanId`. |
| `ChildSpan[i].SpanId` | Générer un nouveau `SpanId`. |
| `ChildSpan[i].SpanContext.TraceState` | S/O pour un contexte de trace X-Ray. |
| `ChildSpan[i].SpanContext.TraceFlags` | Identique au parent `Span.SpanContext.TraceFlags`. |
# Utilisation de l’API Logs Lambda
**Important**
L’API de télémétrie Lambda remplace l’API de journaux Lambda. **Bien que l’API de journaux reste entièrement fonctionnelle, nous vous recommandons d’utiliser uniquement l’API de télémétrie à l’avenir.** Vous pouvez abonner votre extension à un flux de télémétrie en utilisant l’API de télémétrie ou l’API de journaux. Après vous être abonné à l'aide de l'une de ces API APIs, toute tentative de souscription à l'aide de l'autre API renvoie une erreur.
**Les instances gérées Lambda ne prennent pas en charge l'API Logs**
Les instances gérées Lambda ne prennent pas en charge l'API Logs. Si vous utilisez des fonctions d'instance gérées, utilisez plutôt l'[API de télémétrie](telemetry-api.md). L'API de télémétrie fournit des fonctionnalités améliorées pour collecter et traiter les données de télémétrie à partir de vos fonctions Lambda.
Lambda capture automatiquement les journaux d'exécution et les diffuse vers Amazon. CloudWatch Ce flux de journaux contient les journaux que génèrent votre code de fonction et vos extensions, ainsi que les journaux que Lambda génère dans le cadre de l’appel de fonction.
Les [extensions Lambda](runtimes-extensions-api.md) peuvent utiliser l’API Lambda Runtime Logs pour s’abonner à des flux de journaux directement à partir de l’[environnement d’exécution](lambda-runtime-environment.md) Lambda. Lambda diffuse les journaux vers l’extension qui peut ensuite les traiter, les filtrer et les envoyer à n’importe quelle destination de prédilection.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/logs-api-concept-diagram.png)
L’API Logs permet aux extensions de s’abonner à trois flux de journaux différents :
+ Journaux de fonction que la fonction Lambda génère et écrit dans `stdout` ou `stderr`.
+ Journaux d’extension que le code d’extension génère.
+ Journaux de plateforme Lambda qui enregistrent les événements et les erreurs liés aux appels et aux extensions.
**Note**
Lambda envoie tous les journaux à CloudWatch, même lorsqu'une extension s'abonne à un ou plusieurs flux de journaux.
**Topics**
+ [
## S’abonner pour recevoir des journaux
](#runtimes-logs-api-subscribing)
+ [
## Utilisation de la mémoire
](#runtimes-logs-api-memory)
+ [
## Protocoles de destination
](#runtimes-logs-api-dest)
+ [
## Configuration de mise en mémoire tampon
](#runtimes-logs-api-buffering)
+ [
## Exemple d’abonnement
](#runtimes-logs-api-subs-example)
+ [
## Exemple de code pour l’API Logs
](#runtimes-logs-api-samples)
+ [
## Référence d’API Logs
](#runtimes-logs-api-ref)
+ [
## Messages de journaux
](#runtimes-logs-api-msg)
## S’abonner pour recevoir des journaux
Une extension Lambda peut s’abonner aux journaux en envoyant une demande d’abonnement à l’API Logs.
Pour vous abonner afin de recevoir des journaux, vous avez besoin de l’identifiant d’extension (`Lambda-Extension-Identifier`). [Enregistrez d’abord l’extension](runtimes-extensions-api.md#extensions-registration-api-a) pour recevoir l’identifiant de l’extension. Abonnez-vous ensuite à l’API Logs lors de [l’initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib). Une fois la phase d’initialisation terminée, Lambda ne traite pas les demandes d’abonnement.
**Note**
L’abonnement à l’API Logs est idempotent. Les demandes d’abonnement en double n’entraînent pas de doublons d’abonnements.
## Utilisation de la mémoire
L’utilisation de la mémoire augmente de façon linéaire à mesure que le nombre d’abonnés augmente. Les abonnements consomment des ressources de mémoire car chaque abonnement ouvre un nouveau tampon mémoire pour stocker les journaux. Pour optimiser l’utilisation de la mémoire tampon, vous pouvez ajuster la [configuration de la mise en mémoire tampon](#runtimes-logs-api-buffering). L’utilisation de la mémoire tampon compte pour la consommation globale de mémoire dans l’environnement d’exécution.
## Protocoles de destination
Vous pouvez choisir l’un des protocoles suivants pour recevoir les journaux :
1. **HTTP** (recommandé) – Lambda envoie les journaux à un point de terminaison HTTP local (`http://sandbox.localdomain:${PORT}/${PATH}`) sous la forme d’un tableau d’enregistrements au format JSON. Le paramètre `$PATH` est facultatif. Notez que seul HTTP est pris en charge, pas HTTPS. Vous pouvez choisir de recevoir des journaux via PUT ou POST.
1. **TCP** – Lambda envoie les journaux à un port TCP au [format NDJSON (Newline delimited JSON)](https://github.com/ndjson/ndjson-spec).
Nous vous recommandons d’utiliser HTTP plutôt que TCP. Avec TCP, la plateforme Lambda ne peut pas confirmer la livraison des journaux à la couche d’application. Vous risquez par conséquent de perdre des journaux si votre extension se bloque. HTTP ne partage pas cette limitation.
Nous vous recommandons également de configurer l’écouteur HTTP local ou le port TCP avant de vous abonner pour recevoir les journaux. Au cours de l’installation, notez ce qui suit :
+ Lambda n’envoie de journaux qu’à des destinations au sein de l’environnement d’exécution.
+ Lambda réessaie d’envoyer les journaux (avec une interruption) s’il n’y a pas d’écouteur, ou si la requête POST ou PUT génère une erreur. Si l’abonné aux journaux se bloque, il continue de recevoir des journaux après que Lambda a redémarré l’environnement d’exécution.
+ Lambda réserve le port 9001. Il n’y a pas d’autres restrictions ou recommandations relatives au numéro de port.
## Configuration de mise en mémoire tampon
Lambda peut mettre les journaux en mémoire tampon avant de les livrer à l’abonné. Vous pouvez configurer ce comportement dans la demande d’abonnement en spécifiant les champs facultatifs suivants. Notez que Lambda utilise la valeur par défaut pour tout champ que vous ne spécifiez pas.
+ **timeoutMs** – Durée maximum (en millisecondes) de mise en mémoire tampon d’un lot. Par défaut : 1 000. Minimum : 25. Maximum : 30 000.
+ **maxBytes** – Taille maximum (en octets) des journaux à mettre en mémoire tampon. Par défaut : 262 144. Minimum : 262 144. Maximum : 1 048 576.
+ **maxItems** – Nombre maximum d’événements à mettre en mémoire tampon. Par défaut : 10 000. Minimum : 1 000. Maximum : 10 000.
Lors de la configuration de la mise en mémoire tampon, notez les points suivants :
+ Lambda vide les journaux en cas de fermeture de l’un des flux d’entrée, par exemple, si le runtime se bloque.
+ Chaque abonné peut spécifier une configuration de mise en mémoire tampon différente dans sa demande d’abonnement.
+ Tenez compte de la taille de tampon dont vous avez besoin pour lire les données. Attendez-vous à recevoir des charges utiles aussi volumineuses que `2*maxBytes+metadata`, où `maxBytes` est configuré dans la demande d’abonnement. Par exemple, Lambda ajoute les octets de métadonnées suivants à chaque enregistrement :
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "function",
"record": "Hello World"
}
```
+ Si l’abonné ne peut pas traiter les journaux entrants assez rapidement, Lambda peut supprimer les journaux pour limiter l’utilisation de la mémoire. Pour indiquer le nombre d’enregistrements supprimés, Lambda envoie un journal `platform.logsDropped`. Pour de plus amples informations, veuillez consulter [Lambda : certains journaux de ma fonction n’apparaissent pas](troubleshooting-execution.md#troubleshooting-execution-missinglogs).
## Exemple d’abonnement
L’exemple suivant montre une demande d’abonnement aux journaux de la plateforme et des fonctions.
```
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"
}
}
```
Si la demande réussit, l’abonné reçoit une réponse de succès HTTP 200.
```
HTTP/1.1 200 OK
"OK"
```
## Exemple de code pour l’API Logs
Pour un exemple de code montrant comment envoyer des journaux vers une destination personnalisée, consultez la section [Utilisation d' AWS Lambda extensions pour envoyer des journaux vers des destinations personnalisées](https://aws.amazon.com/blogs/compute/using-aws-lambda-extensions-to-send-logs-to-custom-destinations/) sur le blog AWS Compute.
Pour des exemples de code Python et Go montrant comment développer une extension Lambda de base et s'abonner à l'API Logs, voir [AWS Lambda Extensions](https://github.com/aws-samples/aws-lambda-extensions) dans le référentiel AWS Samples GitHub . Pour plus d’informations sur la génération d’une extension Lambda, consultez [Utilisation de l’API d’extensions Lambda pour créer des extensions](runtimes-extensions-api.md).
## Référence d’API Logs
Vous pouvez extraire le point de terminaison d’API Logs à partir de la variable d’environnement `AWS_LAMBDA_RUNTIME_API`. Pour envoyer une demande d’API, utilisez le préfixe `2020-08-15/` avant le chemin d’accès de l’API. Par exemple :
```
http://${AWS_LAMBDA_RUNTIME_API}/2020-08-15/logs
```
[La spécification OpenAPI pour la version **2020-08-15** de l'API Logs est disponible ici : .zip logs-api-request](samples/logs-api-request.zip)
### S’abonner
Pour s’abonner à un ou plusieurs des flux de journal disponibles dans l’environnement d’exécution Lambda, les extensions envoient une demande d’API Subscribe.
**Chemin** – `/logs`
**Méthode** – **PUT**
**Paramètres de corps**
`destination` – Voir [Protocoles de destination](#runtimes-logs-api-dest). Obligatoire : oui. Type : chaînes.
`buffering` – Voir [Configuration de mise en mémoire tampon](#runtimes-logs-api-buffering). Requis : non. Type : chaînes.
`types` – Tableau des types de journaux à recevoir. Obligatoire : oui. Type : tableau de chaînes. Valeurs valides : « plateforme », « fonction», « extension ».
`schemaVersion` – Obligatoire : non. Valeur par défaut : « 2020-08-15 ». Attribuez la valeur « 2021-03-18 » pour que l’extension reçoive les messages [`platform.runtimeDone`](#runtimes-logs-api-ref-done).
****Paramètres de réponse****
Les spécifications OpenAPI pour les réponses d’abonnement version **2020-08-15** sont disponibles pour les protocoles HTTP et TCP :
+ HTTP : [logs-api-http-response.zip](samples/logs-api-http-response.zip)
+ [TCP : .zip logs-api-tcp-response](samples/logs-api-tcp-response.zip)
****Codes de réponse****
+ 200 – Demande effectuée avec succès.
+ 202 – Demande acceptée. Réponse à une demande d’abonnement pendant les tests locaux.
+ 4XX – Demande erronée.
+ 500 – Erreur de service.
Si la demande réussit, l’abonné reçoit une réponse de succès HTTP 200.
```
HTTP/1.1 200 OK
"OK"
```
Si la demande échoue, l’abonné reçoit une réponse d’erreur. Exemples :
```
HTTP/1.1 400 OK
{
"errorType": "Logs.ValidationError",
"errorMessage": URI port is not provided; types should not be empty"
}
```
## Messages de journaux
L’API Logs permet aux extensions de s’abonner à trois flux de journaux différents :
+ Fonction – Journaux que la fonction Lambda génère et écrit dans `stdout` ou `stderr`.
+ Extension – Journaux que le code d’extension génère.
+ Plateforme – Journaux que la plateforme de runtime génère, qui consignent des événements et des erreurs liés aux appels et aux extensions.
**Topics**
+ [
### Journaux de fonctions
](#runtimes-logs-api-msg-function)
+ [
### Journaux d’extension
](#runtimes-logs-api-msg-extension)
+ [
### Journaux de plateforme
](#runtimes-logs-api-msg-platform)
### Journaux de fonctions
La fonction Lambda et les extensions internes génèrent des journaux de fonction et les écrivent dans `stdout` ou `stderr`.
L’exemple suivant montre le format d’un message de journal de fonction. \$1 "time": "2020-08-20T12:31:32.123Z", "type": "function", "record": "ERROR encountered. Stack trace:\$1n\$1my-function (line 10)\$1n" \$1
### Journaux d’extension
Les extensions peuvent générer des journaux d’extensions. Le format du journal est le même que pour un journal de fonction.
### Journaux de plateforme
Lambda génère des messages de journal pour des événements de plateforme tels que `platform.start`, `platform.end` et `platform.fault`.
Vous pouvez éventuellement vous abonner à la version **2021-03-18** du schéma de l’API Logs, qui inclut le message de journal `platform.runtimeDone`.
#### Exemple de messages du journal de la plateforme
L’exemple suivant montre les journaux de début et de fin de la plateforme. Ces journaux indiquent l’heure de début et de fin de l’appel pour l’appel spécifié par le requestId.
```
{
"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"}
}
```
La **plateforme. initRuntimeDone**un message de journal indique l'état de la `Runtime init` sous-phase, qui fait partie de la phase du cycle de [vie d'initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib). Lorsque `Runtime init` est réussie, l’environnement d’exécution envoie une demande d’API d’exécution `/next` (pour les types d’initialisation `on-demand` et `provisioned-concurrency`) ou `restore/next` (pour le type d’initialisation `snap-start`). L'exemple suivant montre une **plateforme performante. initRuntimeDone**message de journal pour le type `snap-start` d'initialisation.
```
{
"time":"2022-07-17T18:41:57.083Z",
"type":"platform.initRuntimeDone",
"record":{
"initializationType":"snap-start",
"status":"success"
}
}
```
Le message de journal **platform.initReport** indique la durée de la phase `Init` et le nombre de millisecondes qui vous ont été facturées pendant cette phase. Lorsque le type d’initialisation est `provisioned-concurrency`, Lambda envoie ce message pendant l’appel. Lorsque le type d’initialisation est `snap-start`, Lambda envoie ce message après avoir restauré l’instantané. L’exemple suivant montre un message de journal **platform.initReport** pour le type d’initialisation `snap-start`.
```
{
"time":"2022-07-17T18:41:57.083Z",
"type":"platform.initReport",
"record":{
"initializationType":"snap-start",
"metrics":{
"durationMs":731.79,
"billedDurationMs":732
}
}
}
```
Le journal du rapport de la plateforme inclut des métriques relatives à l’appel spécifié par le requestId. Le champ `initDurationMs` n’est inclus dans le journal que si l’appel comprend un démarrage à froid. Si le suivi AWS X-Ray est actif, le journal inclut les métadonnées X-Ray. L’exemple suivant montre un journal de rapport de la plateforme pour un appel qui comprend un démarrage à froid.
```
{
"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
}
}
}
```
Le journal des pannes de la plateforme capture les erreurs d’exécution ou d’environnement d’exécution. L’exemple suivant montre un message de journal des erreurs de plateforme.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.fault",
"record": "RequestId: d783b35e-a91d-4251-af17-035953428a2c Process exited before completing request"
}
```
**Note**
AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.
L’une des sorties de journal concernées par cette modification est le champ `"record"` du journal des erreurs de plateforme. Les exemples suivants montrent des champs `"record"` illustratifs dans les anciens et les nouveaux formats. Le nouveau format de journal des erreurs contient un message plus concis
Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.
**Example enregistrement du journal des erreurs de plateforme (ancien format)**
```
"record":"RequestId: ...\tError: Runtime exited with error: exit status 255\nRuntime.ExitError"
```
**Example enregistrement du journal des erreurs de plateforme (nouveau format)**
```
"record":"RequestId: ... Status: error\tErrorType: Runtime.ExitError"
```
Lambda génère un journal d’extension de plateforme quand une extension s’enregistre auprès de l’API d’extensions. L’exemple suivant montre un message d’extension de la plateforme.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.extension",
"record": {"name": "Foo.bar",
"state": "Ready",
"events": ["INVOKE", "SHUTDOWN"]
}
}
```
Lambda génère un journal d’abonnement aux journaux de plateforme quand une extension s’abonne à l’API Logs. L’exemple suivant montre un message d’abonnement aux journaux.
```
{
"time": "2020-08-20T12:31:32.123Z",
"type": "platform.logsSubscription",
"record": {"name": "Foo.bar",
"state": "Subscribed",
"types": ["function", "platform"],
}
}
```
Lambda génère un journal des journaux de plateforme supprimés quand une extension n’est pas en mesure de traiter le nombre de journaux qu’elle reçoit. L’exemple suivant montre un message de journal `platform.logsDropped`.
```
{
"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
}
}
```
Le message de journal **platform.restoreStart** indique l’heure à laquelle la phase `Restore` a démarré (type d’initialisation `snap-start` uniquement). Exemple :
```
{
"time":"2022-07-17T18:43:44.782Z",
"type":"platform.restoreStart",
"record":{}
}
```
Le message de journal **platform.restoreReport** indique la durée de la phase `Restore` et le nombre de millisecondes qui vous ont été facturées pendant cette phase (type d’initialisation `snap-start` uniquement). Exemple :
```
{
"time":"2022-07-17T18:43:45.936Z",
"type":"platform.restoreReport",
"record":{
"metrics":{
"durationMs":70.87,
"billedDurationMs":13
}
}
}
```
#### Messages `runtimeDone` de plateforme
Si vous définissez la version du schéma sur « 2021-03-18 » dans la demande d’abonnement, Lambda envoie un message `platform.runtimeDone` une fois l’appel de fonction terminé avec succès ou avec une erreur. L’extension peut utiliser ce message pour arrêter toute la collecte de données télémétriques pour cet appel de fonction.
La spécification OpenAPI pour le type d’événement Log dans la version de schéma **2021-03-18** est disponible ici : [schema-2021-03-18.zip](samples/schema-2021-03-18.zip)
Lambda génère le message de journal `platform.runtimeDone` quand le runtime envoie une demande d’API de runtime `Next` ou `Error`. Le journal `platform.runtimeDone` informe les utilisateurs de l’API Logs que l’appel de fonction se termine. Les extensions peuvent utiliser ces informations pour décider quand envoyer toutes les données télémétriques collectées au cours de cet appel.
##### Exemples
Lambda envoie le message `platform.runtimeDone` après que le runtime a envoyé la demande NEXT à l’issue de l’appel de fonction. Les exemples suivants présentent des messages pour chacune des valeurs de statut : succès, échec et expiration du délai.
**Example Exemple de message de réussite**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "success"
}
}
```
**Example Exemple de message d’échec**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "failure"
}
}
```
**Example Exemple de message d’expiration du délai**
```
{
"time": "2021-02-04T20:00:05.123Z",
"type": "platform.runtimeDone",
"record": {
"requestId":"6f7f0961f83442118a7af6fe80b88",
"status": "timeout"
}
}
```
**Example Exemple de plateforme. restoreRuntimeDone message (type `snap-start` d'initialisation uniquement)**
La **plateforme. restoreRuntimeDone**un message de journal indique si la `Restore` phase a réussi ou non. Lambda envoie ce message lorsque l’environnement d’exécution envoie une demande d’API d’exécution `restore/next`. Il existe trois statuts possibles : succès, échec et dépassement de délai. L'exemple suivant montre une **plateforme performante. restoreRuntimeDone**message de journal.
```
{
"time":"2022-07-17T18:43:45.936Z",
"type":"platform.restoreRuntimeDone",
"record":{
"status":"success"
}
}
```