Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Affichage CloudWatch des journaux pour les fonctions Lambda

Mode de mise au point
Affichage CloudWatch des journaux pour les fonctions Lambda - 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.

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.

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.

Comparaison entre Live Tail et --log-type Tail

Il existe plusieurs différences entre CloudWatch Logs Live Tail et l'option LogType: Tail de l'API Lambda (--log-type Taildans 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.

Autorisations

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 (Fonctions) de la console Lambda.

  2. Choisissez le nom de la fonction.

  3. Choisissez l’onglet Test.

  4. Dans le volet Test event, sélectionnez CloudWatch Logs Live Tail.

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

  6. (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 dans le guide de l'utilisateur Amazon CloudWatch Logs.

  7. Sélectionnez Démarrer. Les événements du journal correspondants commencent à apparaître dans la fenêtre.

  8. 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 (Fonctions) de la console Lambda.

  2. Sélectionnez une fonction.

  3. Choisissez l’onglet Surveiller.

  4. Choisissez Afficher CloudWatch les journaux pour ouvrir la CloudWatch console.

  5. Faites défiler la page vers le bas et choisissez le flux de journaux pour les invocations de fonctions que vous souhaitez consulter.

    Liste des flux de journaux pour une fonction Lambda.

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 à un appel, cela génère un nouveau flux de journal. 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)

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 : ils marquent une seule invocation dans les favoris, de sorte que chaque ligne de journal entre elles appartient à la même invocation.

  • Durée : durée totale d'invocation de la fonction de gestion, code non INIT compris.

  • Durée facturée : applique la logique d'arrondissement aux fins de facturation.

  • Taille de la mémoire : quantité de mémoire allouée à la fonction.

  • Mémoire maximale utilisée : quantité maximale de mémoire utilisée pendant l'invocation.

  • Durée d'initialisation : temps nécessaire pour exécuter la INIT section 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.

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'cli-binary-formatoption 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 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'cli-binary-formatoption 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 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" }

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 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 ou d’expressions régulières.

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 facilite les requêtes. L'utilisation des niveaux de journalisation 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. Par exemple, considérez 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)

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 au format JSON pour générer trois valeurs distinctes :

surveillance de l’observabilité (illustration 11)

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)

Les champs découverts en JSON sont automatiquement renseignés dans le menu Champs découverts sur le côté droit. Les champs standard émis par le service Lambda sont préfixés par « @ », 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, à condition qu'il existe au moins une fonction d'agrégation. La stats fonction 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, considérez la requête suivante. Il s'agit du même exemple de requête que celui de la Journalisation structurée JSON section, 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 minimale, maximale et moyenne pour identifier les valeurs aberrantes. Vous pouvez consulter les résultats dans l'onglet Visualisation :

surveillance de l’observabilité (illustration 14)

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)
ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.