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.
# Envoi automatique des journaux de la fonction Lambda à CloudWatch Logs
Par défaut, Lambda capture automatiquement les journaux de toutes les invocations de fonction et les envoie à CloudWatch Logs, à condition que le rôle d’exécution de votre fonction dispose des autorisations nécessaires. Par défaut, ces journaux sont stockés dans un groupe de journaux nommé /aws/lambda/**. Pour améliorer le débogage, vous pouvez insérer des instructions de journalisation personnalisées dans votre code, que Lambda intégrera de manière transparente à CloudWatch Logs. Si nécessaire, vous pouvez configurer votre fonction pour envoyer les journaux à un groupe différent à l’aide de la console Lambda, AWS CLI, ou de l’API Lambda. Pour en savoir plus, veuillez consulter [Configuration des groupes de CloudWatch journaux](monitoring-cloudwatchlogs-loggroups.md).
Pour afficher les journaux des fonctions Lambda à l’aide de la console Lambda, utilisez la console CloudWatch, l’AWS Command Line Interface (AWS CLI) ou l’API CloudWatch. Pour plus d’informations, consultez [Affichage CloudWatch des journaux pour les fonctions Lambda](monitoring-cloudwatchlogs-view.md).
**Note**
L’affichage des journaux après l’invocation d’une fonction peut prendre de 5 à 10 minutes .
## Autorisations IAM requises
Votre [rôle d’exécution](lambda-intro-execution-role.md) doit disposer d’une autorisation pour charger des journaux sur CloudWatch Logs :
+ `logs:CreateLogGroup`
+ `logs:CreateLogStream`
+ `logs:PutLogEvents`
Pour de plus amples informations, consultez [Using identity-based policies (IAM policies) for CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/iam-identity-based-access-control-cwl.html) dans le* Guide de l’utilisateur Amazon CloudWatch.*
Vous pouvez ajouter des autorisations CloudWatch Logs à l’aide de la politique `AWSLambdaBasicExecutionRole` gérée par AWS, fournie par Lambda. Exécutez la commande suivante pour ajouter cette politique à votre rôle :
```
aws iam attach-role-policy --role-name your-role --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
```
Pour de plus amples informations, consultez [Utilisation de politiques AWS gérées dans le rôle d'exécution](permissions-managed-policies.md).
## Tarification
L’utilisation de journaux Lambda n’occasionne aucun coût supplémentaire. En revanche, les frais CloudWatch Logs standard s’appliquent. Pour plus d’informations, consultez [Tarification CloudWatch.](https://aws.amazon.com/cloudwatch/pricing/)
# Configuration des groupes de CloudWatch journaux
Par défaut, crée CloudWatch automatiquement un groupe de journaux `/aws/lambda/` portant le nom de votre fonction lors de son appel initial. Pour configurer votre fonction afin d’envoyer des journaux à un groupe de journaux existant, ou pour créer un nouveau groupe de journaux pour votre fonction, vous pouvez utiliser la console Lambda ou AWS CLI. Vous pouvez également configurer des groupes de journaux personnalisés à l'aide des commandes [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)et de l'API [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)Lambda et de la ressource AWS Serverless Application Model (AWS SAM) [AWS: :Serverless : :Function]().
Vous pouvez configurer plusieurs fonctions Lambda pour envoyer des journaux au même groupe de CloudWatch journaux. Par exemple, vous pouvez utiliser un seul groupe de journaux pour stocker les journaux de toutes les fonctions Lambda qui constituent une application particulière. Lorsque vous utilisez un groupe de journaux personnalisé pour une fonction Lambda, les flux de journaux créés par Lambda incluent le nom et la version de la fonction. Cela garantit que le mappage entre les messages du journal et les fonctions est préservé, même si vous utilisez le même groupe de journaux pour plusieurs fonctions.
Le format de dénomination des flux de journaux pour les groupes de journaux personnalisés suit cette convention :
```
YYYY/MM/DD/[][]
```
Notez que lors de la configuration d'un groupe de journaux personnalisé, le nom que vous sélectionnez pour votre groupe de journaux doit respecter les [règles de dénomination CloudWatch des journaux](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateLogGroup.html). En outre, les noms de groupes de journaux personnalisés ne doivent pas commencer par la chaîne `aws/`. Si vous créez un groupe de journaux personnalisé en commençant par `aws/`, Lambda ne sera pas en mesure de créer le groupe de journaux. Par conséquent, les journaux de votre fonction ne seront pas envoyés à CloudWatch.
**Pour modifier le groupe de journaux d’une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Dans la page de configuration de la fonction, choisissez **Outils de surveillance et d’exploitation**.
1. Dans le volet de **configuration de la journalisation**, choisissez **Modifier**.
1. Dans le volet **Groupe de journalisation**, pour le **groupe de CloudWatch journaux**, sélectionnez **Personnalisé**.
1. Sous **Groupe de journaux personnalisé**, entrez le nom du groupe de CloudWatch journaux auquel votre fonction doit envoyer des journaux. Si vous entrez le nom d’un groupe de journaux existant, votre fonction utilisera ce groupe. S’il n’existe aucun groupe de journaux portant le nom que vous entrez, Lambda créera un nouveau groupe de journaux portant ce nom pour votre fonction.
**Pour modifier le groupe de journaux d’une fonction (AWS CLI)**
+ Pour modifier le groupe de journaux d’une fonction existante, utilisez la commande [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html).
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogGroup=myLogGroup
```
**Pour indiquer un groupe de journaux personnalisé lorsque vous créez une fonction (AWS CLI)**
+ Pour spécifier un groupe de journaux personnalisé lorsque vous créez une nouvelle fonction Lambda à l'aide de AWS CLI, utilisez l'`--logging-config`option. L’exemple de commande suivant crée une fonction Lambda Node.js qui envoie des journaux à un groupe de journaux nommé `myLogGroup`.
```
aws lambda create-function \
--function-name myFunction \
--runtime nodejs24.x \
--handler index.handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::123456789012:role/LambdaRole \
--logging-config LogGroup=myLogGroup
```
## Autorisations du rôle d’exécution
Pour que votre fonction puisse envoyer des CloudWatch journaux à Logs, elle doit disposer de l'PutLogEventsautorisation [logs :](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html). Lorsque vous configurez le groupe de journaux de votre fonction à l’aide de la console Lambda, Lambda ajoute cette autorisation au rôle dans les conditions suivantes :
+ La destination du service est définie sur CloudWatch Logs
+ Le rôle d'exécution de votre fonction n'est pas autorisé à télécharger les journaux dans CloudWatch Logs (la destination par défaut)
**Note**
Lambda n’ajoute aucune autorisation Put pour les destinations de journal Amazon S3 ou Firehose.
Lorsque Lambda ajoute cette autorisation, elle autorise la fonction à envoyer des journaux à n'importe quel groupe de CloudWatch journaux Logs.
Pour empêcher Lambda de mettre automatiquement à jour le rôle d’exécution de la fonction et de le modifier manuellement, développez **Autorisations** et décochez **Ajouter les autorisations requises**.
Lorsque vous configurez le groupe de journaux de votre fonction à l'aide de AWS CLI, Lambda n'ajoute pas automatiquement l'`logs:PutLogEvents`autorisation. Ajoutez l’autorisation au rôle d’exécution de votre fonction si elle ne l’a pas déjà. Cette autorisation est incluse dans la politique [AWSLambdaBasicExecutionRole](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole$jsonEditor)gérée.
## CloudWatch journalisation pour les instances gérées Lambda
Lorsque vous utilisez des [instances gérées Lambda](lambda-managed-instances.md), d'autres considérations s'appliquent à l'envoi de journaux vers CloudWatch Logs :
### Exigences de mise en réseau VPC
Les instances gérées Lambda s'exécutent sur des instances appartenant au client EC2 au sein de votre VPC. Pour envoyer des CloudWatch journaux à Logs et des traces à X-Ray, vous devez vous assurer qu' AWS APIs ils sont routables depuis votre VPC. Vous avez plusieurs options:
+ **AWS PrivateLink (recommandé)** : [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)à utiliser pour créer des points de terminaison VPC pour les services Logs CloudWatch et X-Ray. Cela permet à vos instances d'accéder à ces services en privé sans avoir besoin d'une passerelle Internet ou d'une passerelle NAT. Pour plus d'informations, consultez la section [Utilisation CloudWatch des journaux avec les points de terminaison VPC de l'interface](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html).
+ **Passerelle NAT** : configurez une passerelle NAT pour autoriser l'accès Internet sortant à partir de vos sous-réseaux privés.
+ **Passerelle Internet** : pour les sous-réseaux publics, assurez-vous qu'une passerelle Internet est configurée sur votre VPC.
Si CloudWatch Logs ou X-Ray ne APIs sont pas routables depuis votre VPC, vos journaux de fonctions et vos traces ne seront pas fournis.
### Invocations simultanées et attribution de journaux
Les environnements d'exécution des instances gérées Lambda peuvent traiter plusieurs appels simultanément. Lorsque plusieurs appels sont exécutés simultanément, leurs entrées de journal sont entrelacées dans le même flux de journal. Pour filtrer et analyser efficacement les journaux provenant d'appels simultanés, vous devez vous assurer que chaque entrée de journal inclut l'ID de AWS demande.
Nous recommandons l'une des approches suivantes :
+ **Utiliser des enregistreurs d'exécution Lambda par défaut (recommandé)** : Les bibliothèques de journalisation par défaut fournies par les environnements d'exécution gérés par Lambda incluent automatiquement l'ID de demande dans chaque entrée de journal.
+ **Implémenter une journalisation JSON structurée** : si vous créez un [environnement d'exécution personnalisé](runtimes-custom.md) ou si vous avez besoin d'une journalisation personnalisée, implémentez des journaux au format JSON qui incluent l'ID de demande dans chaque entrée. Les instances gérées Lambda ne prennent en charge que le format de journal JSON. Incluez le `requestId` champ dans vos journaux JSON pour activer le filtrage par invocation :
```
{
"timestamp": "2025-01-15T10:30:00.000Z",
"level": "INFO",
"requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"message": "Processing request"
}
```
Grâce à l'attribution de l'ID de demande, vous pouvez filtrer CloudWatch les entrées du journal Logs pour un appel spécifique à l'aide des requêtes CloudWatch Logs Insights. Par exemple :
```
fields @timestamp, @message
| filter requestId = "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
| sort @timestamp asc
```
Pour plus d'informations sur les exigences de journalisation des instances gérées Lambda, consultez. [Comprendre l'environnement d'exécution des instances gérées Lambda](lambda-managed-instances-execution-environment.md)
# Affichage CloudWatch des journaux pour les fonctions Lambda
Vous pouvez consulter les CloudWatch journaux Amazon de votre fonction Lambda à l'aide de la console Lambda, de la CloudWatch console ou du (). AWS Command Line Interface AWS CLI Suivez les instructions dans les sections suivantes pour accéder aux journaux de votre fonction.
## Diffusez les journaux des fonctions avec CloudWatch Logs Live Tail
Amazon CloudWatch Logs Live Tail vous aide à résoudre rapidement les problèmes liés à vos fonctions en affichant une liste de diffusion des nouveaux événements de journal directement dans la console Lambda. Vous pouvez afficher et filtrer les journaux ingérés depuis votre fonction Lambda en temps quasi réel, ce qui vous permet de détecter et de résoudre rapidement les problèmes.
**Note**
Le coût des sessions Live Tail est calculé en fonction du temps d'utilisation de la session, par minute. Pour plus d'informations sur les tarifs, consultez [Amazon CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
### Comparaison entre Live Tail et --log-type Tail
Il existe plusieurs différences entre CloudWatch Logs Live Tail et l'option [LogType: Tail](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html#lambda-Invoke-request-LogType) de l'API Lambda (`--log-type Tail`dans le AWS CLI) :
+ `--log-type Tail` ne renvoie que les quatre premiers Ko des journaux d’invocation. Live Tail ne partage pas cette limite et peut recevoir jusqu’à 500 événements de journal par seconde.
+ `--log-type Tail` capture et envoie les journaux avec la réponse, ce qui peut avoir un impact sur la latence de réponse de la fonction. Live Tail n’affecte pas la latence de réponse des fonctions.
+ `--log-type Tail` ne prend en charge que les invocations synchrones. Live Tail fonctionne à la fois pour les invocations synchrones et asynchrones.
**Note**
Les [instances gérées Lambda](lambda-managed-instances.md) ne prennent pas en charge cette option. `--log-type Tail` Utilisez CloudWatch Logs Live Tail ou interrogez directement CloudWatch les journaux pour consulter les journaux des fonctions Managed Instances.
### Permissions
Les autorisations suivantes sont requises pour démarrer et arrêter les sessions CloudWatch Logs Live Tail :
+ `logs:DescribeLogGroups`
+ `logs:StartLiveTail`
+ `logs:StopLiveTail`
### Démarrage d’une session Live Tail dans la console Lambda
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez le nom de la fonction.
1. Choisissez l’onglet **Test**.
1. Dans le volet **Test event**, sélectionnez **CloudWatch Logs Live Tail**.
1. Pour **Sélectionner des groupes de journaux**, le groupe de journaux de la fonction est sélectionné par défaut. Vous pouvez sélectionner jusqu’à cinq groupes de journaux à la fois.
1. (Facultatif) Pour m’afficher que les événements du journal contenant certains mots ou d’autres chaînes de caractères, saisissez le mot ou la chaîne dans la zone **Ajouter un modèle de filtre**. Le champ des filtres est sensible à la casse. Vous pouvez inclure plusieurs termes et opérateurs de motifs dans ce champ, y compris des expressions régulières (regex). Pour plus d'informations sur la syntaxe des modèles, consultez la section [Syntaxe des modèles de filtres](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) dans le *guide de l'utilisateur Amazon CloudWatch Logs*.
1. Sélectionnez **Démarrer**. Les événements du journal correspondants commencent à apparaître dans la fenêtre.
1. Pour arrêter la session Live Tail, choisissez **Arrêter**.
**Note**
La session Live Tail s’arrête automatiquement après 15 minutes d’inactivité ou lorsque la session de la console Lambda expire.
## Accès aux journaux de fonctions à l’aide de la console
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez une fonction.
1. Choisissez l’onglet **Surveiller**.
1. Choisissez **Afficher CloudWatch les journaux** pour ouvrir la CloudWatch console.
1. Faites défiler la page vers le bas et choisissez le **flux de journaux** pour les invocations de fonctions que vous souhaitez consulter.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/log-stream.png)
Chaque instance d’une fonction Lambda possède un flux de journaux dédié. Si une fonction augmente verticalement, chaque instance simultanée possède son propre flux de journaux. Chaque fois qu’un nouvel environnement d’exécution est créé en réponse à une invocation, cela génère un nouveau flux de journaux. La convention de dénomination pour les flux de journaux est la suivante :
```
YYYY/MM/DD[Function version][Execution environment GUID]
```
Un environnement d’exécution unique écrit dans le même flux de journaux pendant sa durée de vie. Le flux de journaux contient les messages provenant de cet environnement d’exécution, ainsi que toute sortie du code de votre fonction Lambda. Chaque message est horodaté, y compris vos journaux personnalisés. Même si votre fonction ne journalise aucune sortie de votre code, trois instructions de journal minimales sont générées par invocation (START, END et REPORT) :
![\[surveillance de l’observabilité (illustration 3)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/monitoring-observability-figure-3.png)
Ces journaux indiquent :
+ **RequestId**— il s'agit d'un identifiant unique généré par demande. Si la fonction Lambda relance une requête, cet identifiant ne change pas et apparaît dans les journaux à chaque nouvelle tentative suivante.
+ **Début/Fin** : ces éléments marquent une seule invocation, de sorte que chaque ligne de journal située entre eux appartient à la même invocation.
+ **Durée** : durée totale d’invocation de la fonction de gestionnaire, à l’exception du code `INIT`.
+ **Durée facturée** : applique la logique d’arrondi à des fins de facturation.
+ **Memory Size** : la quantité de mémoire allouée à la fonction.
+ **Mémoire maximale utilisée** : quantité de mémoire maximale utilisée lors de l’invocation.
+ **Durée d’initialisation** : temps nécessaire pour exécuter la section `INIT` de code, en dehors du gestionnaire principal.
## Accédez aux journaux avec AWS CLI
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"
}
```
## Analyse des journaux et journalisation structurée
Avec CloudWatch Logs Insights, vous pouvez rechercher et analyser les données des journaux à l'aide d'une [syntaxe de requête](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html) spécialisée. Le service exécute des requêtes sur plusieurs groupes de journaux et fournit un filtrage puissant grâce à la correspondance de modèles [glob](https://en.wikipedia.org/wiki/Glob_(programming)) ou d’[expressions régulières](https://en.wikipedia.org/wiki/Regular_expression).
Vous pouvez tirer parti de ces fonctionnalités en implémentant une journalisation structurée dans vos fonctions Lambda. La journalisation structurée organise vos journaux dans un format prédéfini, ce qui permet de les interroger plus facilement. L’utilisation des niveaux de journaux est une première étape importante pour générer des journaux filtrables qui séparent les messages d’information des avertissements ou des erreurs. Prenons le code Node.js suivant :
```
exports.handler = async (event) => {
console.log("console.log - Application is fine")
console.info("console.info - This is the same as console.log")
console.warn("console.warn - Application provides a warning")
console.error("console.error - An error occurred")
}
```
Le fichier CloudWatch journal obtenu contient un champ distinct spécifiant le niveau de journalisation :
![\[surveillance de l’observabilité (illustration 10)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/monitoring-observability-figure-10.png)
Une requête CloudWatch Logs Insights peut ensuite filtrer au niveau du journal. Par exemple, pour rechercher uniquement les erreurs, vous pouvez utiliser la requête suivante :
```
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
```
### Journalisation structurée JSON
Le format JSON est couramment utilisé pour fournir une structure aux journaux d’applications. Dans l’exemple suivant, les journaux ont été convertis en JSON pour générer trois valeurs distinctes :
![\[surveillance de l’observabilité (illustration 11)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/monitoring-observability-figure-11.png)
La fonctionnalité CloudWatch Logs Insights découvre automatiquement les valeurs dans la sortie JSON et analyse les messages sous forme de champs, sans avoir besoin d'une expression globale ou régulière personnalisée. À l’aide des journaux structurés JSON, la requête suivante trouve les invocations pour lesquelles le fichier chargé était supérieur à 1 Mo, le temps de chargement était supérieur à 1 seconde et l’invocation n’était pas un démarrage à froid :
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
```
Cette requête peut produire le résultat suivant :
![\[surveillance de l’observabilité (illustration 12)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/monitoring-observability-figure-12.png)
Les champs découverts en JSON sont automatiquement renseignés dans le menu *Champs découvert* à droite. Les champs standard émis par le service Lambda comportent le préfixe « @ » et vous pouvez effectuer des requêtes sur ces champs de la même manière. Les logs Lambda incluent toujours les champs @timestamp, @logStream, @message, @requestId, @duration, @billedDuration, @type, @maxMemoryUsed, @memorySize. Si X-Ray est activé pour une fonction, les journaux incluent également @ xrayTraceId et @xraySegmentId.
Lorsqu'une source d' AWS événement telle qu'Amazon S3, Amazon SQS ou Amazon EventBridge invoque votre fonction, l'événement complet est fourni à la fonction sous forme d'entrée d'objet JSON. En enregistrant cet événement dans la première ligne de la fonction, vous pouvez ensuite effectuer une requête sur l'un des champs imbriqués à l'aide de CloudWatch Logs Insights.
### Requêtes Insights utiles
Le tableau suivant présente des exemples de requêtes Insights qui peuvent être utiles pour surveiller les fonctions Lambda.
| Description | Exemple de syntaxe de requête |
| --- | --- |
| Les 100 dernières erreurs |
```
fields Timestamp, LogLevel, Message
\| filter LogLevel == "ERR"
\| sort @timestamp desc
\| limit 100
``` |
| Les 100 invocations les plus facturées |
```
filter @type = "REPORT"
\| fields @requestId, @billedDuration
\| sort by @billedDuration desc
\| limit 100
``` |
| Pourcentage de démarrages à froid dans le nombre total d’invocations |
```
filter @type = "REPORT"
\| stats sum(strcontains(@message, "Init Duration"))/count(*) * 100 as
coldStartPct, avg(@duration)
by bin(5m)
``` |
| Rapport de percentile sur la durée Lambda |
```
filter @type = "REPORT"
\| stats
avg(@billedDuration) as Average,
percentile(@billedDuration, 99) as NinetyNinth,
percentile(@billedDuration, 95) as NinetyFifth,
percentile(@billedDuration, 90) as Ninetieth
by bin(30m)
``` |
| Rapport de percentile sur l’utilisation de la mémoire Lambda |
```
filter @type="REPORT"
\| stats avg(@maxMemoryUsed/1024/1024) as mean_MemoryUsed,
min(@maxMemoryUsed/1024/1024) as min_MemoryUsed,
max(@maxMemoryUsed/1024/1024) as max_MemoryUsed,
percentile(@maxMemoryUsed/1024/1024, 95) as Percentile95
``` |
| Invocations utilisant 100 % de la mémoire assignée |
```
filter @type = "REPORT" and @maxMemoryUsed=@memorySize
\| stats
count_distinct(@requestId)
by bin(30m)
``` |
| Mémoire moyenne utilisée lors des invocations |
```
avgMemoryUsedPERC,
avg(@billedDuration) as avgDurationMS
by bin(5m)
``` |
| Visualisation des statistiques de mémoire |
```
filter @type = "REPORT"
\| stats
max(@maxMemoryUsed / 1024 / 1024) as maxMemMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemMB,
min(@maxMemoryUsed / 1024 / 1024) as minMemMB,
(avg(@maxMemoryUsed / 1024 / 1024) / max(@memorySize / 1024 / 1024)) * 100 as avgMemUsedPct,
avg(@billedDuration) as avgDurationMS
by bin(30m)
``` |
| Invocations pour lesquelles Lambda s’est fermé |
```
filter @message like /Process exited/
\| stats count() by bin(30m)
``` |
| Invocations dont le délai a expiré |
```
filter @message like /Task timed out/
\| stats count() by bin(30m)
``` |
| Rapport de latence |
```
filter @type = "REPORT"
\| stats avg(@duration), max(@duration), min(@duration)
by bin(5m)
``` |
| Mémoire surallouée |
```
filter @type = "REPORT"
\| stats max(@memorySize / 1024 / 1024) as provisonedMemMB,
min(@maxMemoryUsed / 1024 / 1024) as smallestMemReqMB,
avg(@maxMemoryUsed / 1024 / 1024) as avgMemUsedMB,
max(@maxMemoryUsed / 1024 / 1024) as maxMemUsedMB,
provisonedMemMB - maxMemUsedMB as overProvisionedMB
``` |
## Visualisation des journaux et tableaux de bord
Pour toute requête CloudWatch Logs Insights, vous pouvez exporter les résultats au format Markdown ou CSV. Dans certains cas, il peut être plus utile de créer des [visualisations à partir de requêtes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_Insights-Visualizing-Log-Data.html), à condition qu’il existe au moins une fonction d’agrégation. La fonction `stats` vous permet de définir des agrégations et des regroupements.
L’exemple *logInsightsJSON* précédent filtrait en fonction de la taille et de la durée du chargement et excluait les premières invocations. Cela générait un tableau de données. Pour surveiller un système de production, il peut être plus utile de visualiser les tailles de fichier minimales, maximales et moyennes afin de détecter les valeurs aberrantes. Pour ce faire, appliquez la fonction stats avec les agrégats requis et effectuez un regroupement en fonction d’une valeur temporelle, par exemple chaque minute :
Par exemple, réfléchissez à la requête suivante. Il s’agit du même exemple de requête que celui de la section [Journalisation structurée JSON](#querying-logs-json), mais avec des fonctions d’agrégation supplémentaires :
```
fields @message
| filter @message like /INFO/
| filter uploadedBytes > 1000000
| filter uploadTimeMS > 1000
| filter invocation != 1
| stats min(uploadedBytes), avg(uploadedBytes), max(uploadedBytes) by bin (1m)
```
Nous avons inclus ces agrégats, car il peut être plus utile de visualiser les tailles de fichier minimales, maximales et moyennes afin de détecter les valeurs aberrantes. Vous pouvez voir les résultats dans l’onglet **Visualisation** :
![\[surveillance de l’observabilité (illustration 14)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/monitoring-observability-figure-14.png)
Une fois que vous avez terminé de créer la visualisation, vous pouvez éventuellement ajouter le graphique à un CloudWatch tableau de bord. Pour ce faire, choisissez **Ajouter au tableau de bord** au-dessus de la visualisation. Cela ajoute la requête sous forme de widget et vous permet de sélectionner des intervalles d’actualisation automatiques, ce qui facilite le suivi continu des résultats :
![\[surveillance de l’observabilité (illustration 15)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/monitoring-observability-figure-15.png)