

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 et surveillance des fonctions Lambda Node.js
<a name="nodejs-logging"></a>

AWS Lambda surveille 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 de plus amples informations, veuillez consulter [Envoi automatique des journaux de la fonction Lambda à CloudWatch Logs](monitoring-cloudwatchlogs.md).

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

**Topics**
+ [Création d’une fonction qui renvoie des journaux](#node-logging-output)
+ [Utilisation des contrôles de journalisation avancés de Lambda avec Node.js](#node-js-logging-advanced)
+ [Affichage des journaux dans la console Lambda](#nodejs-logging-console)
+ [Afficher les journaux dans la CloudWatch console](#nodejs-logging-cwconsole)
+ [Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)](#nodejs-logging-cli)
+ [Suppression de journaux](#nodejs-logging-delete)

## Création d’une fonction qui renvoie des journaux
<a name="node-logging-output"></a>

Pour générer les journaux à partir de votre code de fonction, vous pouvez utiliser des méthodes sur [l’objet console](https://developer.mozilla.org/en-US/docs/Web/API/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.

**Note**  
Nous vous recommandons d’utiliser des techniques telles que la validation des entrées et le codage des sorties lors de la journalisation des entrées. Si vous journalisez directement les données d’entrée, un attaquant peut utiliser votre code pour rendre les altérations difficiles à détecter, falsifier des entrées de journal ou contourner les moniteurs de journal. Pour plus d’informations, consultez [Improper Output Neutralization for Logs](https://cwe.mitre.org/data/definitions/117.html) dans la *Common Weakness Enumeration*. 

**Example 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
}
```

**Example 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: 296 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. Lorsque les appels partagent un environnement d’exécution, Lambda indique la mémoire maximale utilisée pour toutes les invocations. Ce comportement peut entraîner une valeur signalée plus élevée que prévu.
+ **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.](services-xray.md)
+ **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
<a name="node-js-logging-advanced"></a>

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](monitoring-logs.md#monitoring-cloudwatchlogs-advanced).

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
<a name="nodejs-logging-advanced-JSON"></a>

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 console`console.trace`,,,`console.debug`, `console.log` `console.info``console.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 journalisation, telle que Powertools for AWS Lambda, pour produire des journaux structurés en 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 Powertools for AWS Lambda logging afin de créer des journaux structurés JSON dans le runtime Node.js, consultez[Enregistrez et surveillez les fonctions TypeScript Lambda](typescript-logging.md).

#### Exemple de sorties de journal au format JSON
<a name="nodejs-logging-examples"></a>

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.

**Example Code de journalisation Node.js**  

```
export const handler = async (event) => {
  console.error("This is a warning message");
  ...
}
```

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp":"2025-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é.

**Example Code de journalisation Node.js**  

```
export const handler = async (event) => {
  console.log({data: 12.3, flag: false});
  ...
}
```

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp": "2025-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"`.

**Example Code de journalisation Node.js**  

```
export const handler = async (event) => {
  console.log('Some object - ', {data: 12.3, flag: false});
  ...
}
```

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp": "2025-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.

**Example 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);
};
```

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp": "2025-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": "2025-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
<a name="nodejs-logging-advanced-emf"></a>

AWS fournit des bibliothèques clientes open source pour Node.js que vous pouvez utiliser pour créer des journaux [au format métrique intégré](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) (EMF). 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](https://www.npmjs.com/package/aws-embedded-metrics) et [Powertools pour](https://github.com/aws-powertools/powertools-lambda-typescript) 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.

**Example 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
<a name="nodejs-logging-advanced-level"></a>

 AWS Lambda Pour filtrer 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](#nodejs-logging-advanced-JSON). Pour savoir comment configurer le format de journal de votre fonction, consultez [Configuration de commandes de journalisation avancées pour votre fonction Lambda](monitoring-logs.md#monitoring-cloudwatchlogs-advanced).
+ 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 pour générer des sorties AWS Lambda de journal structurées JSON à partir de votre code. Consultez [Enregistrez et surveillez les fonctions TypeScript Lambda](typescript-logging.md) 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](https://www.ietf.org/rfc/rfc3339.txt) 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.

## Affichage des journaux dans la console Lambda
<a name="nodejs-logging-console"></a>

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

## Afficher les journaux dans la CloudWatch console
<a name="nodejs-logging-cwconsole"></a>

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](https://console.aws.amazon.com/cloudwatch/home?#logs:) sur la CloudWatch console.

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

1. Choisissez un flux de journaux.

Chaque flux de journal correspond à une [instance de votre fonction](lambda-runtime-environment.md). Un flux de journal apparaît lorsque vous mettez à jour votre fonction Lambda et lorsque des instances supplémentaires sont créées pour gérer les appels simultanés. Pour trouver les journaux d'un appel spécifique, nous vous recommandons d'instrumenter votre fonction avec. AWS X-Ray X-Ray enregistre des détails sur la demande et le flux de journaux dans le suivi.

## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
<a name="nodejs-logging-cli"></a>

 AWS CLI Il s'agit d'un outil open source qui vous permet d'interagir avec les AWS services à l'aide de commandes dans votre interface de ligne de commande. Pour effectuer les étapes de cette section, vous devez disposer de la [version 2 de l’AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

Vous pouvez utiliser [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html) 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.

**Example 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"
}
```

**Example 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'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) 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](https://docs.microsoft.com/en-us/windows/wsl/install-win10). Les utilisateurs de macOS auront peut-être besoin d’utiliser `base64 -D`.

**Example 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'**cli-binary-format**option est obligatoire si vous utilisez AWS CLI la 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](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) 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
```

**Example 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
```

**Example 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
<a name="nodejs-logging-delete"></a>

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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#SettingLogRetention) à l’issue de laquelle les journaux sont supprimés automatiquement.