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. # 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" } } ```