Journalisation des fonctions AWS Lambda dans Node.js - AWS Lambda

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.

Journalisation des fonctions AWS Lambda dans Node.js

AWS Lambdasurveille automatiquement les fonctions Lambda en votre nom et envoie les journaux à Amazon. CloudWatch Votre fonction Lambda est fournie avec un groupe de CloudWatch journaux Logs et un flux de journaux pour chaque instance de votre fonction. L’environnement d’exécution Lambda envoie des informations sur chaque invocation au flux de journaux et transmet les journaux et autres sorties provenant du code de votre fonction. Pour plus d’informations, consultez Utilisation d'Amazon CloudWatch Logs avec AWS Lambda.

Cette page explique comment générer une sortie de journal à partir du code de votre fonction Lambda ou comment accéder aux journaux à l'aide de la AWS Command Line Interface console Lambda ou de la console. CloudWatch

Création d’une fonction qui renvoie des journaux

Pour générer les journaux à partir de votre code de fonction, vous pouvez utiliser des méthodes sur l’objet console ou n’importe quelle bibliothèque de journalisation qui écrit dans stdout ou stderr. L’exemple suivant consigne les valeurs des variables d’environnement et l’objet d’événement.

Exemple Fichier index.js – Journalisation
exports.handler = async function(event, context) { console.log("ENVIRONMENT VARIABLES\n" + JSON.stringify(process.env, null, 2)) console.info("EVENT\n" + JSON.stringify(event, null, 2)) console.warn("Event not processed.") return context.logStreamName }
Exemple format des journaux
START RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac Version: $LATEST 2019-06-07T19:11:20.562Z c793869b-ee49-115b-a5b6-4fd21e8dedac INFO ENVIRONMENT VARIABLES { "AWS_LAMBDA_FUNCTION_VERSION": "$LATEST", "AWS_LAMBDA_LOG_GROUP_NAME": "/aws/lambda/my-function", "AWS_LAMBDA_LOG_STREAM_NAME": "2019/06/07/[$LATEST]e6f4a0c4241adcd70c262d34c0bbc85c", "AWS_EXECUTION_ENV": "AWS_Lambda_nodejs12.x", "AWS_LAMBDA_FUNCTION_NAME": "my-function", "PATH": "/var/lang/bin:/usr/local/bin:/usr/bin/:/bin:/opt/bin", "NODE_PATH": "/opt/nodejs/node10/node_modules:/opt/nodejs/node_modules:/var/runtime/node_modules", ... } 2019-06-07T19:11:20.563Z c793869b-ee49-115b-a5b6-4fd21e8dedac INFO EVENT { "key": "value" } 2019-06-07T19:11:20.564Z c793869b-ee49-115b-a5b6-4fd21e8dedac WARN Event not processed. END RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac REPORT RequestId: c793869b-ee49-115b-a5b6-4fd21e8dedac Duration: 128.83 ms Billed Duration: 200 ms Memory Size: 128 MB Max Memory Used: 74 MB Init Duration: 166.62 ms XRAY TraceId: 1-5d9d007f-0a8c7fd02xmpl480aed55ef0 SegmentId: 3d752xmpl1bbe37e Sampled: true

Le runtime Node.js enregistre les lignes START, END et REPORT pour chaque invocation. Il ajoute un horodatage, un ID de demande et un niveau de journalisation sur chaque entrée consignée par la fonction. La ligne de rapport fournit les détails suivants.

Champs de données de la ligne REPORT
  • RequestId— L'identifiant de demande unique pour l'invocation.

  • Duration – Temps que la méthode de gestion du gestionnaire de votre fonction a consacré au traitement de l’événement.

  • Billed Duration : temps facturé pour l’invocation.

  • Memory Size – Quantité de mémoire allouée à la fonction.

  • Max Memory Used – Quantité de mémoire utilisée par la fonction.

  • Init Duration : pour la première requête servie, temps qu’il a pris à l’exécution charger la fonction et exécuter le code en dehors de la méthode du gestionnaire.

  • XRAY TraceId — Pour les demandes suivies, l'ID de AWS X-Ray trace.

  • SegmentId— Pour les demandes tracées, l'identifiant du segment X-Ray.

  • Sampled – Pour les demandes suivies, résultat de l’échantillonnage.

Vous pouvez consulter les journaux dans la console Lambda, dans la console CloudWatch Logs ou depuis la ligne de commande.

Utilisation des contrôles de journalisation avancés de Lambda avec Node.js

Pour mieux contrôler la manière dont les journaux de vos fonctions sont capturés, traités et consommés, vous pouvez configurer les options de journalisation suivantes pour les environnements d’exécution Node.js pris en charge :

  • Format de journal : choisissez entre le format texte brut et le format JSON structuré pour les journaux de votre fonction

  • Niveau de journalisation : pour les journaux au format JSON, choisissez le niveau de détail des journaux que Lambda envoie à Amazon CloudWatch, par exemple ERROR, DEBUG ou INFO

  • Groupe de journaux : choisissez le groupe de CloudWatch journaux auquel votre fonction envoie les journaux

Pour plus d’informations sur ces options de journalisation et pour savoir comment configurer votre fonction pour les utiliser, consultez Configuration de commandes de journalisation avancées pour votre fonction Lambda.

Pour utiliser le format de journal et les options de niveau de journal avec vos fonctions Node.js Lambda, consultez les instructions des sections suivantes.

Utilisation de journaux JSON structurés avec Node.js

Si vous sélectionnez JSON pour le format de journal de votre fonction, Lambda enverra la sortie des journaux à l'aide des méthodes de consoleconsole.trace,,,console.debug, console.log console.infoconsole.error, et console.warn vers CloudWatch sous forme de JSON structuré. Chaque objet de journal JSON contient au moins quatre paires clé-valeur avec les clés suivantes :

  • "timestamp" - heure à laquelle le message de journal a été généré

  • "level" - niveau de journalisation attribué au message

  • "message" - contenu du message de journal

  • "requestId" - identifiant unique de la demande pour l’invocation de la fonction

Selon la méthode de journalisation utilisée par votre fonction, cet objet JSON peut également contenir des paires de clés supplémentaires. Par exemple, si votre fonction utilise des méthodes console pour enregistrer les objets d'erreur à l'aide de plusieurs arguments, l'objet JSON contiendra des paires clé-valeur supplémentaires avec les clés errorMessage, errorType et stackTrace.

Si votre code utilise déjà une autre bibliothèque de journaux, telle que Powertools for AWS Lambda, pour produire des journaux structurés JSON, vous n’avez pas besoin d’apporter de modifications. Lambda n’encode pas deux fois les journaux déjà codés en JSON. Les journaux d’application de votre fonction continueront donc d’être capturés comme avant.

Pour plus d’informations sur l’utilisation du package de journalisation Powertools for AWS Lambda afin de créer des journaux structurés JSON dans l’exécution Node.js, consultez AWS Lambdafonction de connexion TypeScript.

Exemple de sorties de journal au format JSON

Les exemples suivants montrent comment les différentes sorties de journal générées à l'aide console des méthodes avec des arguments uniques et multiples sont capturées dans CloudWatch Logs lorsque vous définissez le format de journal de votre fonction sur JSON.

Le premier exemple utilise la méthode console.error pour générer une chaîne simple.

Exemple Code de journalisation Node.js
export const handler = async (event) => { console.error("This is a warning message"); ... }
Exemple Enregistrement de journaux JSON
{ "timestamp":"2023-11-01T00:21:51.358Z", "level":"ERROR", "message":"This is a warning message", "requestId":"93f25699-2cbf-4976-8f94-336a0aa98c6f" }

Vous pouvez également générer des messages de journal structurés plus complexes en utilisant un ou plusieurs arguments avec les méthodes console. Dans l'exemple suivant, vous pouvez utiliser console.log pour générer deux paires clé-valeur avec un seul argument. Notez que le "message" champ de l'objet JSON envoyé par Lambda à CloudWatch Logs n'est pas stringifié.

Exemple Code de journalisation Node.js
export const handler = async (event) => { console.log({data: 12.3, flag: false}); ... }
Exemple Enregistrement de journaux JSON
{ "timestamp": "2023-12-08T23:21:04.664Z", "level": "INFO", "requestId": "405a4537-9226-4216-ac59-64381ec8654a", "message": { "data": 12.3, "flag": false } }

Dans l'exemple suivant, vous utilisez à nouveau la méthode console.log pour créer une sortie de journal. Cette fois, la méthode prend deux arguments, une carte contenant deux paires clé-valeur et une chaîne d'identification. Notez que dans ce cas, parce que vous avez fourni deux arguments, Lambda stringifie le champ "message".

Exemple Code de journalisation Node.js
export const handler = async (event) => { console.log('Some object - ', {data: 12.3, flag: false}); ... }
Exemple Enregistrement de journaux JSON
{ "timestamp": "2023-12-08T23:21:04.664Z", "level": "INFO", "requestId": "405a4537-9226-4216-ac59-64381ec8654a", "message": "Some object - { data: 12.3, flag: false }" }

Lambda attribue les sorties générées à l’aide de console.log du niveau de journalisation INFO.

Le dernier exemple montre comment les objets d'erreur peuvent être générés dans CloudWatch Logs à l'aide console des méthodes. Notez que lorsque vous enregistrez des objets d'erreur à l'aide de plusieurs arguments, Lambda ajoute les champs errorMessage, errorType et stackTrace à la sortie du journal. Pour en savoir plus sur les erreurs de fonction en Node.js, voir Erreurs de fonction AWS Lambda dans Node.js.

Exemple Code de journalisation Node.js
export const handler = async (event) => { let e1 = new ReferenceError("some reference error"); let e2 = new SyntaxError("some syntax error"); console.log(e1); console.log("errors logged - ", e1, e2); };
Exemple Enregistrement de journaux JSON
{ "timestamp": "2023-12-08T23:21:04.632Z", "level": "INFO", "requestId": "405a4537-9226-4216-ac59-64381ec8654a", "message": { "errorType": "ReferenceError", "errorMessage": "some reference error", "stackTrace": [ "ReferenceError: some reference error", " at Runtime.handler (file:///var/task/index.mjs:3:12)", " at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)" ] } } { "timestamp": "2023-12-08T23:21:04.646Z", "level": "INFO", "requestId": "405a4537-9226-4216-ac59-64381ec8654a", "message": "errors logged - ReferenceError: some reference error\n at Runtime.handler (file:///var/task/index.mjs:3:12)\n at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29) SyntaxError: some syntax error\n at Runtime.handler (file:///var/task/index.mjs:4:12)\n at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)", "errorType": "ReferenceError", "errorMessage": "some reference error", "stackTrace": [ "ReferenceError: some reference error", " at Runtime.handler (file:///var/task/index.mjs:3:12)", " at Runtime.handleOnceNonStreaming (file:///var/runtime/index.mjs:1173:29)" ] }

Lors de la journalisation de plusieurs types d'erreur, les champs supplémentaires errorMessage, errorType, et stackTrace sont extraits du premier type d'erreur fourni à la méthode console.

Utilisation de bibliothèques clientes au format métrique intégré (EMF) avec des journaux JSON structurés

AWS fournit des bibliothèques clientes ouvertes pour Node.js que vous pouvez utiliser pour créer des journaux au format EMF (embedded metric format). Si vous avez des fonctions existantes qui utilisent ces bibliothèques et que vous modifiez le format de journal de votre fonction en JSON, il est CloudWatch possible que les métriques émises par votre code ne soient plus reconnues.

Si votre code émet actuellement des journaux EMF directement en utilisant console.log ou en utilisant Powertools for AWS Lambda (TypeScript), vous ne pourrez pas CloudWatch non plus les analyser si vous modifiez le format de journal de votre fonction en JSON.

Important

Pour vous assurer que les journaux EMF de vos fonctions continuent d'être correctement analysés CloudWatch, mettez à jour vos bibliothèques EMF et Powertools pour les AWS Lambda bibliothèques avec les dernières versions. Si vous passez au format de journal JSON, nous vous recommandons également d’effectuer des tests pour garantir la compatibilité avec les métriques intégrées de votre fonction. Si votre code émet des journaux EMF directement à l’aide de console.log, modifiez votre code pour qu’il affiche directement ces métriques vers stdout, comme indiqué dans l’exemple de code suivant.

Exemple code émettant des métriques intégrées pour stdout
process.stdout.write(JSON.stringify( { "_aws": { "Timestamp": Date.now(), "CloudWatchMetrics": [{ "Namespace": "lambda-function-metrics", "Dimensions": [["functionVersion"]], "Metrics": [{ "Name": "time", "Unit": "Milliseconds", "StorageResolution": 60 }] }] }, "functionVersion": "$LATEST", "time": 100, "requestId": context.awsRequestId } ) + "\n")

Utilisation du filtrage au niveau du journal avec Node.js

Pour qu’AWS Lambda filtre les journaux de votre application en fonction de leur niveau de journalisation, votre fonction doit utiliser des journaux au format JSON. Vous pouvez effectuer cette opération de deux façons :

  • Créez des sorties de journal à l’aide des méthodes de console standard et configurez votre fonction pour utiliser le format de journal JSON. AWS Lambda filtre ensuite les sorties de votre journal à l’aide de la paire clé-valeur « niveau » de l’objet JSON décrit dans Utilisation de journaux JSON structurés avec Node.js. Pour savoir comment configurer le format de journal de votre fonction, consultez Configuration de commandes de journalisation avancées pour votre fonction Lambda.

  • Utilisez une autre bibliothèque ou méthode de journalisation pour créer des journaux structurés JSON dans votre code qui incluent une paire clé-valeur « niveau » définissant le niveau de sortie du journal. Par exemple, vous pouvez utiliser Powertools for AWS Lambda pour générer des sorties de journal structurées JSON à partir de votre code. Consultez AWS Lambdafonction de connexion TypeScript pour en savoir plus sur l’utilisation de Powertools avec l’exécution Node.js.

    Pour que Lambda puisse filtrer les journaux de votre fonction, vous devez également inclure une paire "timestamp" clé-valeur dans la sortie de votre journal JSON. L'heure doit être spécifiée dans un format d'horodatage RFC 3339 valide. Si vous ne fournissez pas d’horodatage valide, Lambda attribuera au journal le niveau INFO et ajoutera un horodatage pour vous.

Lorsque vous configurez votre fonction pour utiliser le filtrage au niveau des journaux, vous sélectionnez le niveau de journaux que vous souhaitez envoyer AWS Lambda à CloudWatch Logs parmi les options suivantes :

Niveau de journalisation Utilisation standard
TRACE (le plus détaillé) Les informations les plus précises utilisées pour tracer le chemin d’exécution de votre code
DEBUG Informations détaillées pour le débogage du système
INFO Messages qui enregistrent le fonctionnement normal de votre fonction
WARN Messages relatifs à des erreurs potentielles susceptibles d’entraîner un comportement inattendu si elles ne sont pas traitées
ERROR Messages concernant les problèmes qui empêchent le code de fonctionner comme prévu
FATAL (moindre détail) Messages relatifs à des erreurs graves entraînant l’arrêt du fonctionnement de l’application

Lambda envoie les journaux du niveau sélectionné et d'un niveau inférieur à. CloudWatch Par exemple, si vous configurez un niveau de journalisation WARN, Lambda envoie des journaux correspondant aux niveaux WARN, ERROR et FATAL.

Utilisation de la console Lambda

Vous pouvez utiliser la console Lambda pour afficher la sortie du journal après avoir invoqué une fonction Lambda.

Si votre code peut être testé à partir de l’éditeur Code intégré, vous trouverez les journaux dans les résultats d’exécution. Lorsque vous utilisez la fonctionnalité de test de console pour invoquer une fonction, vous trouverez Sortie du journal dans la section Détails.

Utilisation de la CloudWatch console

Vous pouvez utiliser la CloudWatch console Amazon pour consulter les journaux de toutes les invocations de fonctions Lambda.

Pour afficher les journaux sur la CloudWatch console
  1. Ouvrez la page Groupes de journaux sur la CloudWatch console.

  2. Choisissez le groupe de journaux pour votre fonction (your-function-name/aws/lambda/).

  3. Choisissez un flux de journaux.

Chaque flux de journal correspond à une instance de votre fonction. Un flux de journaux apparaît lorsque vous mettez à jour votre fonction Lambda et lorsque des instances supplémentaires sont créées pour traiter plusieurs invocations simultanées. Pour trouver des journaux pour une invocation spécifique, nous vous recommandons d’utiliser votre fonction avec AWS X-Ray. X-Ray enregistre des détails sur la demande et le flux de journaux dans le suivi.

Pour un exemple d’application qui met en corrélation les journaux et les suivis avec X-Ray, consultez Exemple d'application du processeur d'erreurs pour AWS Lambda.

Utilisation de AWS Command Line Interface (AWS CLI)

La AWS CLI est un outil open-source qui vous permet d’interagir avec des services AWS à l’aide des commandes de votre shell de ligne de commande. Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :

Vous pouvez utiliser AWS CLI pour récupérer les journaux d’une invocation à l’aide de l’option de commande --log-type. La réponse inclut un champ LogResult qui contient jusqu’à 4 Ko de journaux codés en base64 provenant de l’invocation.

Exemple récupérer un ID de journal

L’exemple suivant montre comment récupérer un ID de journal à partir du champ LogResult d’une fonction nommée my-function.

aws lambda invoke --function-name my-function out --log-type Tail

Vous devriez voir la sortie suivante:

{ "StatusCode": 200, "LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...", "ExecutedVersion": "$LATEST" }
Exemple décoder les journaux

Dans la même invite de commandes, utilisez l’utilitaire base64 pour décoder les journaux. L’exemple suivant montre comment récupérer les journaux encodés en base64 pour my-function.

aws lambda invoke --function-name my-function out --log-type Tail \ --query 'LogResult' --output text --cli-binary-format raw-in-base64-out | base64 --decode

L’option cli-binary-format est obligatoire si vous utilisez AWS CLI version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez aws configure set cli-binary-format raw-in-base64-out. Pour plus d’informations, consultez les options de ligne de commande globales AWS CLI prises en charge dans le Guide de l’utilisateur AWS Command Line Interface version 2.

Vous devriez voir la sortie suivante :

START RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Version: $LATEST "AWS_SESSION_TOKEN": "AgoJb3JpZ2luX2VjELj...", "_X_AMZN_TRACE_ID": "Root=1-5d02e5ca-f5792818b6fe8368e5b51d50;Parent=191db58857df8395;Sampled=0"",ask/lib:/opt/lib", END RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 REPORT RequestId: 57f231fb-1730-4395-85cb-4f71bd2b87b8 Duration: 79.67 ms Billed Duration: 80 ms Memory Size: 128 MB Max Memory Used: 73 MB

L’utilitaire base64 est disponible sous Linux, macOS et Ubuntu sous Windows. Les utilisateurs de macOS auront peut-être besoin d’utiliser base64 -D.

Exemple Script get-logs.sh

Dans la même invite de commandes, utilisez le script suivant pour télécharger les cinq derniers événements de journalisation. Le script utilise sed pour supprimer les guillemets du fichier de sortie et attend 15 secondes pour permettre la mise à disposition des journaux. La sortie comprend la réponse de Lambda, ainsi que la sortie de la commande get-log-events.

Copiez le contenu de l’exemple de code suivant et enregistrez-le dans votre répertoire de projet Lambda sous get-logs.sh.

L’option cli-binary-format est obligatoire si vous utilisez AWS CLI version 2. Pour faire de ce paramètre le paramètre par défaut, exécutez aws configure set cli-binary-format raw-in-base64-out. Pour plus d’informations, consultez les options de ligne de commande globales AWS CLI prises en charge dans le Guide de l’utilisateur AWS Command Line Interface version 2.

#!/bin/bash aws lambda invoke --function-name my-function --cli-binary-format raw-in-base64-out --payload '{"key": "value"}' out sed -i'' -e 's/"//g' out sleep 15 aws logs get-log-events --log-group-name /aws/lambda/my-function --log-stream-name stream1 --limit 5
Exemple macOS et Linux (uniquement)

Dans la même invite de commandes, les utilisateurs macOS et Linux peuvent avoir besoin d’exécuter la commande suivante pour s’assurer que le script est exécutable.

chmod -R 755 get-logs.sh
Exemple récupérer les cinq derniers événements de journal

Dans la même invite de commande, exécutez le script suivant pour obtenir les cinq derniers événements de journalisation.

./get-logs.sh

Vous devriez voir la sortie suivante:

{ "StatusCode": 200, "ExecutedVersion": "$LATEST" } { "events": [ { "timestamp": 1559763003171, "message": "START RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf Version: $LATEST\n", "ingestionTime": 1559763003309 }, { "timestamp": 1559763003173, "message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tENVIRONMENT VARIABLES\r{\r \"AWS_LAMBDA_FUNCTION_VERSION\": \"$LATEST\",\r ...", "ingestionTime": 1559763018353 }, { "timestamp": 1559763003173, "message": "2019-06-05T19:30:03.173Z\t4ce9340a-b765-490f-ad8a-02ab3415e2bf\tINFO\tEVENT\r{\r \"key\": \"value\"\r}\n", "ingestionTime": 1559763018353 }, { "timestamp": 1559763003218, "message": "END RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\n", "ingestionTime": 1559763018353 }, { "timestamp": 1559763003218, "message": "REPORT RequestId: 4ce9340a-b765-490f-ad8a-02ab3415e2bf\tDuration: 26.73 ms\tBilled Duration: 27 ms \tMemory Size: 128 MB\tMax Memory Used: 75 MB\t\n", "ingestionTime": 1559763018353 } ], "nextForwardToken": "f/34783877304859518393868359594929986069206639495374241795", "nextBackwardToken": "b/34783877303811383369537420289090800615709599058929582080" }

Suppression de journaux

Les groupes de journaux ne sont pas supprimés automatiquement quand vous supprimez une fonction. Pour éviter de stocker des journaux indéfiniment, supprimez le groupe de journaux ou configurez une période de conservation à l’issue de laquelle les journaux sont supprimés automatiquement.