

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 C\$1
<a name="csharp-logging"></a>

AWS Lambda surveille automatiquement les fonctions Lambda et envoie des entrées de journal à 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 détails sur chaque invocation et d’autres sorties provenant du code de votre fonction au flux de journaux. Pour plus d'informations sur CloudWatch les journaux, consultez[Envoi automatique des journaux de la fonction Lambda à CloudWatch Logs](monitoring-cloudwatchlogs.md).

**Topics**
+ [

## Création d’une fonction qui renvoie des journaux
](#csharp-logging-output)
+ [

## Utilisation des contrôles de journalisation avancés de Lambda avec .NET
](#csharp-logging-advanced)
+ [

## Outils de journalisation et bibliothèques supplémentaires
](#csharp-tools-libraries)
+ [

## Utilisation de Powertools pour AWS Lambda (.NET) et AWS SAM pour la journalisation structurée
](#dotnet-logging-sam)
+ [

## Affichage des journaux dans la console Lambda
](#csharp-logging-console)
+ [

## Afficher les journaux dans la CloudWatch console
](#csharp-logging-cwconsole)
+ [

## Afficher les journaux à l'aide de AWS Command Line Interface (AWS CLI)
](#csharp-logging-cli)
+ [

## Suppression de journaux
](#csharp-logging-delete)

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

Pour générer des journaux à partir de votre code de fonction, vous pouvez utiliser le [ILambdaLogger](https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.Core/ILambdaLogger.cs) sur l'objet de contexte, les méthodes de la [classe Console](https://docs.microsoft.com/en-us/dotnet/api/system.console) ou toute bibliothèque de journalisation qui écrit dans `stdout` ou`stderr`.

L’environnement d’exécution .NET enregistre les lignes `START`, `END` et `REPORT` pour chaque invocation. 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.

## Utilisation des contrôles de journalisation avancés de Lambda avec .NET
<a name="csharp-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 .NET pris en charge :
+ **Format de journal** : choisissez entre le format texte brut et le format JSON structuré pour les journaux de votre fonction
+ **Niveau du journal** : pour les journaux au format JSON, choisissez le niveau de détail des journaux auxquels Lambda envoie 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 Lambda .NET, consultez les instructions des sections suivantes.

### Utilisation du format de journal JSON structuré avec .NET
<a name="csharp-logging-advanced-JSON"></a>

Si vous sélectionnez JSON pour le format de journal de votre fonction, Lambda enverra les journaux en sortie à l'aide de [ILambdaLogger](https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.Core/ILambdaLogger.cs) sous forme de JSON structuré. Chaque objet de journal JSON contient au moins cinq 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
+ `"requestId"` - identifiant unique de la demande pour l’invocation de la fonction
+ `"traceId"` : la variable d’environnement `_X_AMZN_TRACE_ID`
+ `"message"` - contenu du message de journal

L’instance `ILambdaLogger` peut ajouter des paires clé-valeur supplémentaires, par exemple lors de la journalisation des exceptions. Vous pouvez également fournir vos propres paramètres supplémentaires, comme décrit dans la section [Paramètres de journal fournis par le client](#csharp-logging-advanced-JSON-user-supplied).

**Note**  
Si votre code utilise déjà une autre bibliothèque de journalisation pour produire des journaux au format JSON, assurez-vous que le format de journal de votre fonction est défini sur du texte brut. Si vous définissez le format de journal sur JSON, les sorties de votre journal seront encodées deux fois.

L’exemple de commande de journalisation suivant montre comment écrire un message de journal de niveau `INFO`.

**Example Code de journalisation .NET**  

```
context.Logger.LogInformation("Fetching cart from database");
```

Vous pouvez également utiliser une méthode de journal générique qui prend le niveau de journal comme argument, comme le montre l’exemple suivant.

```
context.Logger.Log(LogLevel.Information, "Fetching cart from database");
```

La sortie du journal par ces exemples d'extraits de code serait capturée dans CloudWatch Logs comme suit :

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "Fetching cart from database"
}
```

**Note**  
Si vous configurez le format de journal de votre fonction pour utiliser du texte brut plutôt que du JSON, le niveau de journal capturé dans le message suit la convention de Microsoft qui consiste à utiliser une étiquette à quatre caractères. Par exemple, un niveau de journalisation `Debug` est représenté dans le message sous la forme `dbug`.  
Lorsque vous configurez votre fonction pour utiliser des journaux au format JSON, le niveau de journal capturé dans le journal utilise l’étiquette complète, comme indiqué dans l’exemple d’enregistrement de journal JSON.

Si vous n’attribuez aucun niveau à la sortie de votre journal, Lambda lui attribuera automatiquement le niveau INFO.

#### Exceptions de journalisation au format JSON
<a name="csharp-logging-advanced-JSON-exceptions"></a>

Lorsque vous utilisez la journalisation JSON structurée avec `ILambdaLogger`, vous pouvez journaliser les exceptions dans votre code, comme indiqué dans l’exemple suivant.

**Example utilisation de la journalisation des exceptions**  

```
try
{
    connection.ExecuteQuery(query);
}
catch(Exception e)
{
    context.Logger.LogWarning(e, "Error executing query");
}
```

Le format de journal généré par ce code est illustré dans l’exemple de JSON suivant. Notez que la propriété `message` du JSON est renseignée à l’aide de l’argument message fourni dans l’appel `LogWarning`, tandis que la propriété `errorMessage` provient de la propriété `Message` de l’exception elle-même.

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Warning",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "Error executing query",
    "errorType": "System.Data.SqlClient.SqlException",
    "errorMessage": "Connection closed",
    "stackTrace": ["<call exception.StackTrace>"]
}
```

Si le format de journalisation de votre fonction est défini sur JSON, Lambda produit également des messages de journal au format JSON lorsque votre code génère une exception non détectée. L’exemple d’extrait de code et de message de journal suivants montre comment les exceptions non détectées sont journalisées.

**Example code d’exception**  

```
throw new ApplicationException("Invalid data");
```

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Error",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "Invalid data",
    "errorType": "System.ApplicationException",
    "errorMessage": "Invalid data",
    "stackTrace": ["<call exception.StackTrace>"]
}
```

#### Paramètres de journal fournis par le client
<a name="csharp-logging-advanced-JSON-user-supplied"></a>

Avec les messages de journal au format JSON, vous pouvez fournir des paramètres de journal supplémentaires et les inclure dans le journal `message`. L’exemple d’extrait de code suivant montre une commande permettant d’ajouter deux paramètres fournis par l’utilisateur et étiquetés `retryAttempt` et `uri`. Dans l’exemple, la valeur de ces paramètres provient des arguments `retryAttempt` et `uriDestination` transmis à la commande de journalisation.

**Example Commande de journalisation JSON avec paramètres supplémentaires**  

```
context.Logger.LogInformation("Starting retry {retryAttempt} to make GET request to {uri}", retryAttempt, uriDestination);
```

Le message du journal généré par cette commande est illustré dans l’exemple de fichier JSON suivant.

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "Starting retry 1 to make GET request to http://example.com/",
    "retryAttempt": 1,
    "uri": "http://example.com/"
}
```

**Astuce**  
Vous pouvez également utiliser des propriétés de positionnement plutôt que des noms lorsque vous spécifiez des paramètres supplémentaires. Par exemple, dans l’exemple précédent, la commande peut également être écrite comme suit :  

```
context.Logger.LogInformation("Starting retry {0} to make GET request to {1}", retryAttempt, uriDestination);
```

Notez que lorsque vous fournissez des paramètres de journalisation supplémentaires, Lambda les capture en tant que propriétés de premier niveau dans l’enregistrement de journal JSON. Cette approche diffère de certaines bibliothèques de journalisation .NET populaires `Serilog`, telles que celles qui capturent des paramètres supplémentaires dans un objet enfant distinct.

Si l’argument que vous fournissez pour un paramètre supplémentaire est un objet complexe, Lambda utilise par défaut la méthode `ToString()` pour fournir la valeur. Pour indiquer qu’un argument doit être sérialisé au format JSON, utilisez le préfixe `@` tel qu’illustré dans l’extrait de code suivant. Dans cet exemple, `User` est un objet doté de propriétés `FirstName` et `LastName`.

**Example Commande de journalisation JSON avec objet sérialisé JSON**  

```
context.Logger.LogInformation("User {@user} logged in", User);
```

Le message du journal généré par cette commande est illustré dans l’exemple de fichier JSON suivant.

**Example Enregistrement de journaux JSON**  

```
{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "User {@user} logged in",
    "user": 
    {
        "FirstName": "John",
        "LastName": "Doe"
    }
}
```

Si l’argument d’un paramètre supplémentaire est un tableau ou implémente `IList` ou `IDictionary`, alors Lambda ajoute l’argument au message de journal JSON sous forme de tableau, comme indiqué dans l’exemple d’enregistrement de journal JSON suivant. Dans cet exemple, `{users}` prend un argument `IList` contenant des instances de la propriété `User` au même format que dans l’exemple précédent. Lambda le convertit cet `IList` en tableau, chaque valeur étant créée à l’aide de la méthode `ToString`.

**Example Enregistrement de journal JSON avec un argument `IList`**  

```
{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "{users} have joined the group",
    "users": 
    [
        "Rosalez, Alejandro",
        "Stiles, John"       
    ] 
}
```

Vous pouvez également sérialiser la liste au format JSON en utilisant le préfixe `@` dans votre commande de journalisation. Dans l’exemple d’enregistrement de journal JSON suivant, la propriété `users` est sérialisée au format JSON.

**Example Enregistrement de journal JSON avec un argument sérialisé JSON `IList`**  

```
{
    "timestamp": "2025-09-07T01:30:06.977Z",
    "level": "Information",
    "requestId": "8f711428-7e55-46f9-ae88-2a65d4f85fc5",
    "traceId": "1-6408af34-50f56f5b5677a7d763973804",
    "message": "{@users} have joined the group",
    "users": 
    [
        {
            "FirstName": "Alejandro",
            "LastName": "Rosalez"
        },
        {
            "FirstName": "John",
            "LastName": "Stiles"
        }        
    ] 
}
```

### Utilisation du filtrage au niveau du journal avec .NET
<a name="csharp-logging-advanced-levels"></a>

En configurant le filtrage au niveau des journaux, vous pouvez choisir de n'envoyer que les journaux d'un certain niveau de détail ou inférieur à CloudWatch Logs. Pour savoir comment configurer le filtrage de niveau journal de votre fonction, consultez [Filtrage au niveau du journal](monitoring-cloudwatchlogs-log-level.md).

 AWS Lambda Pour filtrer vos messages de journal par niveau de journal, vous pouvez soit utiliser des journaux au format JSON, soit utiliser les `Console` méthodes .NET pour générer des messages de journal. Pour créer des journaux au format JSON, [configurez le type de journal de votre fonction sur JSON](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format) et utilisez l’instance `ILambdaLogger`.

Avec les journaux formatés en JSON, Lambda filtre les sorties de votre journal à l’aide de la paire clé-valeur « niveau » de l’objet JSON décrit dans [Utilisation du format de journal JSON structuré avec .NET](#csharp-logging-advanced-JSON).

Si vous utilisez les `Console` méthodes .NET pour écrire des messages dans CloudWatch Logs, Lambda applique les niveaux de journalisation à vos messages comme suit :
+ **Console. WriteLine **méthode - Lambda applique un niveau de journalisation de `INFO`
+ **Méthode Console.Error** : Lambda applique une journalisation de niveau `ERROR`

Lorsque vous configurez votre fonction pour utiliser le filtrage au niveau des journaux, vous devez sélectionner l'une des options suivantes pour le niveau de journaux que Lambda doit envoyer à Logs. CloudWatch Notez le mappage des niveaux de journalisation utilisés par Lambda avec les niveaux Microsoft standard utilisés par l’attribut .NET `ILambdaLogger`.


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

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

## Outils de journalisation et bibliothèques supplémentaires
<a name="csharp-tools-libraries"></a>

[Powertools for AWS Lambda (.NET)](https://docs.aws.amazon.com/powertools/dotnet/) est une boîte à outils destinée aux développeurs qui permet de mettre en œuvre les meilleures pratiques sans serveur et d'accroître la rapidité des développeurs. L’[utilitaire Logging](https://docs.aws.amazon.com/powertools/dotnet/core/logging/) (français non garanti) fournit un enregistreur optimisé pour Lambda qui inclut des informations supplémentaires sur le contexte de fonction pour toutes vos fonctions avec une sortie structurée en JSON. Utilisez cet utilitaire pour effectuer les opérations suivantes :
+ Capturer les champs clés du contexte Lambda, démarrer à froid et structurer la sortie de la journalisation sous forme de JSON
+ Journaliser les événements d’invocation Lambda lorsque cela est demandé (désactivé par défaut)
+ Imprimer tous les journaux uniquement pour un pourcentage d’invocations via l’échantillonnage des journaux (désactivé par défaut)
+ Ajouter des clés supplémentaires au journal structuré à tout moment
+ Utiliser un formateur de journaux personnalisé (Apportez votre propre formateur) pour produire des journaux dans une structure compatible avec le RFC de journalisation de votre organisation

## Utilisation de Powertools pour AWS Lambda (.NET) et AWS SAM pour la journalisation structurée
<a name="dotnet-logging-sam"></a>

Suivez les étapes ci-dessous pour télécharger, créer et déployer un exemple d'application Hello World C\$1 avec des modules [Powertools pour AWS Lambda (.NET)](https://docs.powertools.aws.dev/lambda-dotnet) intégrés à l'aide du. AWS SAM Cette application met en œuvre un backend API de base et utilise Powertools pour émettre des journaux, des métriques et des traces. Elle se compose d’un point de terminaison Amazon API Gateway et d’une fonction Lambda. Lorsque vous envoyez une requête GET au point de terminaison API Gateway, la fonction Lambda appelle, envoie des journaux et des métriques au format métrique intégré à CloudWatch, et envoie des traces à. AWS X-Ray La fonction renvoie un message `hello world`.

**Conditions préalables**

Pour exécuter la procédure indiquée dans cette section, vous devez satisfaire aux exigences suivantes :
+ .NET 8
+ [AWS CLI version 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)
+ [AWS SAM CLI version 1.75 ou ultérieure](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html). Si vous disposez d'une ancienne version de la AWS SAM CLI, reportez-vous [à la section Mise à niveau de la AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/manage-sam-cli-versions.html#manage-sam-cli-versions-upgrade).

**Déployer un exemple d' AWS SAM application**

1. Initialisez l'application à l'aide du TypeScript modèle Hello World.

   ```
   sam init --app-template hello-world-powertools-dotnet --name sam-app --package-type Zip --runtime dotnet6 --no-tracing
   ```

1. Créez l’application.

   ```
   cd sam-app && sam build
   ```

1. Déployez l’application.

   ```
   sam deploy --guided
   ```

1. Suivez les invites à l’écran. Appuyez sur `Enter` pour accepter les options par défaut fournies dans l’expérience interactive.
**Note**  
Car l'**autorisation n'a HelloWorldFunction peut-être pas été définie, est-ce que ça va ?** , assurez-vous de participer`y`.

1. Obtenez l’URL de l’application déployée :

   ```
   aws cloudformation describe-stacks --stack-name sam-app --query 'Stacks[0].Outputs[?OutputKey==`HelloWorldApi`].OutputValue' --output text
   ```

1. Invoquez le point de terminaison de l’API :

   ```
   curl -X GET <URL_FROM_PREVIOUS_STEP>
   ```

   En cas de succès, vous obtiendrez cette réponse :

   ```
   {"message":"hello world"}
   ```

1. Pour obtenir les journaux de la fonction, exécutez [sam logs](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-logs.html). Pour en savoir plus, consultez [Utilisation des journaux](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-logging.html) dans le *Guide du développeur AWS Serverless Application Model *.

   ```
   sam logs --stack-name sam-app
   ```

   La sortie du journal se présente comme suit :

   ```
   2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:27.988000 INIT_START Runtime Version: dotnet:6.v13        Runtime Version ARN: arn:aws:lambda:ap-southeast-2::runtime:699f346a05dae24c58c45790bc4089f252bf17dae3997e79b17d939a288aa1ec
   2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:28.229000 START RequestId: bed25b38-d012-42e7-ba28-f272535fb80e Version: $LATEST
   2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:29.259000 2025-09-20T14:15:29.201Z        bed25b38-d012-42e7-ba28-f272535fb80e    info   {"_aws":{"Timestamp":1676902528962,"CloudWatchMetrics":[{"Namespace":"sam-app-logging","Metrics":[{"Name":"ColdStart","Unit":"Count"}],"Dimensions":[["FunctionName"],["Service"]]}]},"FunctionName":"sam-app-HelloWorldFunction-haKIoVeose2p","Service":"PowertoolsHelloWorld","ColdStart":1}
   2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.479000 2025-09-20T14:15:30.479Z        bed25b38-d012-42e7-ba28-f272535fb80e    info   {"ColdStart":true,"XrayTraceId":"1-63f3807f-5dbcb9910c96f50742707542","CorrelationId":"d3d4de7f-4ccc-411a-a549-4d67b2fdc015","FunctionName":"sam-app-HelloWorldFunction-haKIoVeose2p","FunctionVersion":"$LATEST","FunctionMemorySize":256,"FunctionArn":"arn:aws:lambda:ap-southeast-2:123456789012:function:sam-app-HelloWorldFunction-haKIoVeose2p","FunctionRequestId":"bed25b38-d012-42e7-ba28-f272535fb80e","Timestamp":"2025-09-20T14:15:30.4602970Z","Level":"Information","Service":"PowertoolsHelloWorld","Name":"AWS.Lambda.Powertools.Logging.Logger","Message":"Hello world API - HTTP 200"}
   2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.599000 2025-09-20T14:15:30.599Z        bed25b38-d012-42e7-ba28-f272535fb80e    info   {"_aws":{"Timestamp":1676902528922,"CloudWatchMetrics":[{"Namespace":"sam-app-logging","Metrics":[{"Name":"ApiRequestCount","Unit":"Count"}],"Dimensions":[["Service"]]}]},"Service":"PowertoolsHelloWorld","ApiRequestCount":1}
   2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.680000 END RequestId: bed25b38-d012-42e7-ba28-f272535fb80e
   2025/02/20/[$LATEST]4eaf8445ba7a4a93b999cb17fbfbecd8 2025-09-20T14:15:30.680000 REPORT RequestId: bed25b38-d012-42e7-ba28-f272535fb80e  Duration: 2450.99 ms   Billed Duration: 2692 ms Memory Size: 256 MB     Max Memory Used: 74 MB  Init Duration: 240.05 ms
   XRAY TraceId: 1-63f3807f-5dbcb9910c96f50742707542       SegmentId: 16b362cd5f52cba0
   ```

1. Il s’agit d’un point de terminaison d’API public accessible par Internet. Nous vous recommandons de supprimer le point de terminaison après un test.

   ```
   sam delete
   ```

### Gestion de la conservation des journaux
<a name="csharp-log-retention"></a>

Les groupes de journaux ne sont pas supprimés automatiquement quand vous supprimez une fonction. Pour éviter de stocker les journaux indéfiniment, supprimez le groupe de journaux ou configurez une période de conservation après laquelle les journaux CloudWatch sont automatiquement supprimés. Pour configurer la conservation des journaux, ajoutez ce qui suit à votre AWS SAM modèle :

```
Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function
    Properties:
      # Omitting other properties

  LogGroup:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub "/aws/lambda/${HelloWorldFunction}"
      RetentionInDays: 7
```

## Affichage des journaux dans la console Lambda
<a name="csharp-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="csharp-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="csharp-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="csharp-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.