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 queconsole.log, et console.infoconsole.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 requestIdendpointName, et à chaque événement. Pour obtenir un exemple, consultez Rédaction de journaux structurés.

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.

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, voirLatence de centralisation.

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

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.

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

2. Créez une révision qui spécifie le groupe de journaux dans la telemetryConfig section deserviceConfig.

   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"
           }
         }
       }'

3. Acheminez le trafic vers la nouvelle révision. Pour plus d’informations, consultez Modèles de déploiement.

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.

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, voirJournaux du système.

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'applicationLogLevelaugmentation 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, voirCycle de vie des environnements d'exécution.

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, voirSchéma des événements du journal système pour Lambda Web Functions.

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.

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é.

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.