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. # Journaux des fonctions Web dans Amazon CloudWatch Logs AWS Lambda capture tout ce que votre application écrit en sortie standard et en erreur standard et l'envoie à Amazon CloudWatch Logs, avec les journaux système générés par Lambda elle-même. DansNode.js, les résultats de chaque `console` méthode, tels que`console.log`, et `console.info``console.error`, sont capturés automatiquement et filtrés en fonction du `applicationLogLevel` paramètre. Les bibliothèques de journalisation qui écrivent sur une sortie standard ou sur une erreur standard sont également capturées. Vous n'avez pas besoin d'agent de journalisation ni du SDK Amazon CloudWatch Logs. Lambda écrit la `console` sortie sous forme d'événements de journal JSON et ajoute les `region` champs `requestId``endpointName`, et à chaque événement. Pour obtenir un exemple, consultez [Rédaction de journaux structurés](#web-functions-logging-structured). Lambda collecte les journaux dans chaque Région AWS endroit où votre fonction Web s'exécute, puis les centralise dans la région d'origine de la fonction. Un `HomeRegion` point de terminaison s'exécute uniquement dans la région d'origine. Un `MultiRegion` point de `PerRegion` terminaison s'exécute également dans les autres régions que vous spécifiez. Lambda centralise donc les journaux de chacune de ces régions. Pour plus d’informations, consultez [Types de point de terminaison](web-functions-endpoints.md#web-functions-endpoint-types). ## Groupes de journaux Par défaut, Lambda envoie les journaux de votre fonction Web à un groupe de journaux nommé d'après la fonction : ``` /aws/lambda/web/{{function-name}} ``` Outre le groupe de journaux centralisé, Lambda utilise un groupe de journaux complémentaire pour conserver les journaux régionaux avant qu'ils ne soient centralisés. Le nom du compagnon est le nom du groupe de journaux centralisé suivi de`.local`, à la fois pour le groupe de journaux par défaut et pour un groupe de journaux personnalisé. Pour le groupe de journaux par défaut, le compagnon est : ``` /aws/lambda/web/{{function-name}}.local ``` Lambda écrit des journaux dans le groupe de `.local` journaux de chaque région où les demandes sont exécutées, y compris la région d'origine, puis les centralise dans le groupe de journaux sans le suffixe dans la région d'origine. Chaque groupe de `.local` journaux contient uniquement les journaux de sa propre région. Lambda ne supprime pas les événements du groupe de `.local` journaux après la centralisation. Le paramètre de conservation du groupe de journaux détermine sa durée de conservation. Les groupes de journaux n'existent pas tant que votre fonction Web n'a pas répondu à sa première demande. Le groupe de journaux centralisé de la région d'origine peut apparaître après le groupe de `.local` journaux. Pour le calendrier de centralisation, voir[Latence de centralisation](web-functions-monitoring.md#web-functions-monitoring-delays). Lambda crée le groupe de journaux par défaut et chaque `.local` groupe de CloudWatch journaux avec les paramètres Amazon Logs par défaut, de sorte que leurs événements n'expirent jamais, sauf si vous définissez une politique de rétention. Vous pouvez modifier leur politique de rétention, de chiffrement et de ressources une fois que Lambda les a créés. Définissez-les sur le groupe de `.local` journaux de chaque région où s'exécute le point de terminaison et sur le groupe de journaux centralisé de la région d'origine. Comme le groupe de `.local` journaux n'attend pas la centralisation, il est utile pour résoudre un problème dans une région spécifique. Le groupe de journaux centralisé contient les journaux de chaque région. Créez donc des requêtes partagées, des filtres d'abonnement, des filtres métriques et une automatisation qui doivent couvrir l'ensemble de l'application dans le groupe de journaux centralisé. Pour connaître le comportement de la télémétrie dans chaque région, voir. [Télémétrie dans chaque région](web-functions-monitoring.md#web-functions-monitoring-replica-telemetry) ## Utilisation d'un groupe de journaux personnalisé Vous pouvez envoyer les journaux de votre fonction Web à un groupe de journaux que vous choisissez à la place du groupe par défaut. Utilisez un groupe de journaux personnalisé lorsque vous souhaitez mettre en place des politiques de rétention, de chiffrement ou de ressources avant l'arrivée du premier événement de journal. Un groupe de journaux personnalisé vous permet également de regrouper les journaux de plusieurs fonctions. Pour appliquer ces paramètres dès le départ, créez vous-même le groupe de journaux et son `.local` compagnon avant d'acheminer le trafic vers la révision. Si l'un des groupes de journaux n'existe pas, Lambda le crée lors de la première utilisation avec les paramètres par défaut, et vous pouvez mettre à jour ses paramètres par la suite. Lambda ne peut créer un groupe de journaux que si le rôle d'exécution est autorisé à créer des groupes de journaux. Pour les autorisations requises, consultez [Rôle d'exécution](web-functions-permissions.md#web-functions-permissions-execution-role). **Pour envoyer des journaux à un groupe de journaux personnalisé (AWS CLI)** 1. Dans la région d'origine, créez le groupe de journaux et son `.local` compagnon, puis définissez la durée de conservation que vous souhaitez pour chacun d'eux. Pour un point de `PerRegion` terminaison `MultiRegion` ou un point de terminaison, créez également le groupe de `.local` journaux dans chaque autre région desservie par le point de terminaison, en exécutant `.local` les commandes `--region` définies sur cette région. ``` aws logs create-log-group --log-group-name {{/my-app/web-logs}} aws logs create-log-group --log-group-name {{/my-app/web-logs}}.local aws logs put-retention-policy \ --log-group-name {{/my-app/web-logs}} \ --retention-in-days 30 aws logs put-retention-policy \ --log-group-name {{/my-app/web-logs}}.local \ --retention-in-days 30 ``` 1. Créez une révision qui spécifie le groupe de journaux dans la `telemetryConfig` section de`serviceConfig`. ``` aws lambda-web create-web-function-revision \ --function-name {{my-web-app}} \ --build-config '{ "codeConfig": { "s3Object": { "bucket": "{{my-bucket}}", "key": "{{my-app.zip}}" } }, "runtimeConfig": { "runtime": "nodejs24.x" } }' \ --service-config '{ "executionRoleArn": "arn:aws:iam::{{111122223333}}:role/{{my-web-function-role}}", "telemetryConfig": { "loggingConfig": { "logGroup": "{{/my-app/web-logs}}" } } }' ``` 1. Acheminez le trafic vers la nouvelle révision. Pour plus d’informations, consultez [Modèles de déploiement](web-functions-deployment.md). Comme la configuration de journalisation fait partie de la révision, elle est immuable pour cette révision. Pour modifier le groupe de journaux ultérieurement, créez une autre révision. Pour plus d’informations, consultez [Gestion des révisions des fonctions Web](web-functions-revisions.md). ## Contrôles de journalisation La `loggingConfig` section contrôle la destination et la sévérité minimale des journaux. Ces paramètres font partie de la révision. | Paramètre | Valeurs | Par défaut | Description | | --- | --- | --- | --- | | logGroup | Nom du groupe de journaux | /aws/lambda/web/{{function-name}} | Le groupe de CloudWatch journaux Amazon Logs qui reçoit vos journaux. | | applicationLogLevel | TRACE \| DEBUG \| INFO \| WARN \| ERROR \| FATAL | INFO | La sévérité minimale des journaux de votre application que Lambda envoie à Amazon CloudWatch Logs. Les journaux inférieurs à ce niveau sont supprimés. Node.jsn'a pas de méthode FATAL console, donc un niveau de FATAL se comporte commeERROR. | | systemLogLevel | DEBUG \| INFO \| WARN | INFO | La sévérité minimale des journaux Lambda-generated système que Lambda envoie à Amazon CloudWatch Logs. Pour le niveau de chaque événement système, voir[Journaux du système](#web-functions-logging-system-logs). | L'exemple suivant crée une révision qui supprime les journaux d'application ci-dessous `WARN` : ``` aws lambda-web create-web-function-revision \ --function-name {{my-web-app}} \ --build-config '{ "codeConfig": { "s3Object": { "bucket": "{{my-bucket}}", "key": "{{my-app.zip}}" } }, "runtimeConfig": { "runtime": "nodejs24.x" } }' \ --service-config '{ "executionRoleArn": "arn:aws:iam::{{111122223333}}:role/{{my-web-function-role}}", "telemetryConfig": { "loggingConfig": { "applicationLogLevel": "WARN", "systemLogLevel": "INFO" } } }' ``` L'`applicationLogLevel`augmentation de la production réduit à la fois le volume des grumes et les coûts. Réduisez-le temporairement à `DEBUG` ou `TRACE` lorsque vous étudiez un problème. ## Journaux du système Outre les résultats de votre application, votre groupe de journaux reçoit les journaux système générés par Lambda concernant le cycle de vie de l'environnement d'exécution, tels que l'initialisation et l'arrêt de l'environnement. `systemLogLevel`À utiliser pour contrôler la quantité de cette Lambda émise. Les journaux système sont utiles pour corréler le comportement des applications avec les événements de plate-forme. Par exemple, un pic de latence correspondant à l'initialisation de l'environnement indique un démarrage à froid plutôt que le code de votre application. Pour le cycle de vie décrit par ces journaux, voir[Cycle de vie des environnements d'exécution](web-functions-env-lifecycle.md). Les fonctions Web émettent les événements système suivants. Réglez `systemLogLevel` le niveau le plus bas dont vous avez besoin. Par exemple, configurez-le pour qu'il reçoive `platform.requestComplete` ou `DEBUG` pour qu'il ne reçoive que `WARN` les avertissements d'échec et de perte de journal. | Type d’événement | Niveau | Remarques | | --- | --- | --- | | platform.initStart | INFO | Aucune | | platform.initReport | INFOsur le succès, WARN sur l'échec | Un échec indique une erreur d'initialisation, telle qu'une erreur lors de l'importation de votre code. | | platform.invokeStart | INFO | Aucune | | platform.requestComplete | DEBUG | Émis une fois pour chaque requête HTTP, y compris les demandes ayant échoué. Comme il s'agit d'un volume élevé, il n'est pas émis au niveau du journal système par défaut. | | platform.invokeSummary | INFO | Périodique. Émis toutes les 60 secondes environ pour chaque environnement d'exécution actif. | | platform.invokeReport | INFOsur le succès, WARN sur l'échec | | | platform.spinDownStart | INFO | | | platform.spinDownReport | INFOsur le succès, WARN sur l'échec | Un échec indique que votre application ne s'est pas fermée dans la seconde suivant la réception SIGTERM (Runtime.SpinDownTimeout) ou qu'elle s'est terminée avec une erreur (Runtime.ExitError). | | platform.logsDropped | WARN | Indique que Lambda a supprimé les événements du journal. | Pour les champs de chaque événement système, voir[Schéma des événements du journal système pour Lambda Web Functions](web-functions-logging-system-log-schema.md). L'en-tête de `lambda-web-request-id` réponse identifie la demande et l'en-tête de `lambda-web-logstream` réponse identifie le flux de journal de l'environnement qui l'a traitée. Utilisez ces valeurs pour corréler la réponse d'un client avec les journaux de l'application et du système. Pour plus d’informations, consultez [En-têtes de réponse](web-functions-http.md#web-functions-http-response-headers). Pour rechercher les événements du flux de journal identifié dans le groupe de journaux centralisé de la région d'origine, filtrez par le nom du flux en tant que préfixe. Vous pouvez également lire le flux par son nom exact dans le groupe de `.local` journaux de la région qui a répondu à la demande. ``` aws logs filter-log-events \ --log-group-name /aws/lambda/web/{{my-web-app}} \ --log-stream-name-prefix "{{LAMBDA_WEB_LOGSTREAM}}" \ --region {{us-east-1}} ``` Pour suivre les journaux récents tout en reproduisant un problème, utilisez : ``` aws logs tail /aws/lambda/web/{{my-web-app}} \ --follow \ --region {{us-east-1}} ``` ## Rédaction de journaux structurés Passez un objet à une `console` méthode afin que Lambda l'écrive sous forme d'objet JSON dans le `message` champ. Vous pouvez ensuite interroger des champs individuels dans Amazon CloudWatch Logs Insights plutôt que de les faire correspondre sur des sous-chaînes. Ne transmettez pas une chaîne avec laquelle vous avez créé`JSON.stringify`. Lambda écrit une chaîne sous forme de valeur de chaîne échappée, de sorte que ses champs ne peuvent pas être interrogés. ``` function logRequest(req, statusCode, durationMs) { console.info({ method: req.method, path: req.url, statusCode: statusCode, durationMs: durationMs }); } ``` Lambda écrit un événement de journal similaire au suivant : ``` { "timestamp": "2026-09-25T11:29:02.711Z", "level": "INFO", "message": { "method": "GET", "path": "/hello-world", "statusCode": 200, "durationMs": 100 }, "requestId": "US3NHLM77IRXDFLBADYHGIZZNM", "endpointName": "prod", "region": "us-east-1" } ``` Vous pouvez ensuite interroger les champs directement. Par exemple, la requête Amazon CloudWatch Logs Insights suivante renvoie les 20 demandes les plus récentes ayant renvoyé un statut 5xx : ``` fields @timestamp, message.method, message.path, message.statusCode, message.durationMs | filter message.statusCode >= 500 | sort @timestamp desc | limit 20 ``` Pour publier des métriques personnalisées à partir de vos journaux au lieu de simplement les interroger, utilisez le format de métrique intégré. Pour plus d’informations, consultez [Publication de métriques personnalisées avec le format de métrique intégré](web-functions-emf.md). ## Utilisation des fonctionnalités d'Amazon CloudWatch Logs avec vos journaux Les journaux étant centralisés dans la région d'origine, vous pouvez utiliser les fonctionnalités standard d'Amazon CloudWatch Logs dans cette région, notamment : + **Live Tail** — Diffusez les événements du journal au fur et à mesure qu'ils arrivent pendant que vous reproduisez un problème. Les événements atteignent le groupe de journaux centralisé après la centralisation. Par conséquent, dans les plus brefs délais, exécutez Live Tail sur le groupe de `.local` journaux de la région qui répond à vos demandes. + **Logs Insights** : champs de requête dans vos événements de journal JSON. + **Centralisation des journaux** : transférez vos journaux vers un autre compte ou une autre destination à l'aide des fonctionnalités de centralisation d'Amazon CloudWatch Logs, si vous regroupez des journaux en dehors du compte de la fonction. + **Filtres d'abonnement et filtres métriques** : déclenchez le traitement en aval ou déduisez des métriques à partir de modèles de journalisation. Appliquez les fonctionnalités qui doivent couvrir l'ensemble de l'application au groupe de journaux centralisé de la région d'origine. Un groupe de `.local` journaux ne contient que les journaux de sa propre région. Pour plus d'informations, consultez [Télémétrie dans chaque région](web-functions-monitoring.md#web-functions-monitoring-replica-telemetry).