Affichage des journaux CloudWatch des fonctions Lambda

Vous pouvez afficher les journaux Amazon CloudWatch pour votre fonction Lambda à l’aide de la console Lambda, de la console CloudWatch ou de l’AWS Command Line Interface (AWS CLI). Suivez les instructions dans les sections suivantes pour accéder aux journaux de votre fonction.

Diffusion des journaux de fonctions avec CloudWatch Logs Live Tail

Amazon CloudWatch Logs Live Tail vous aide à résoudre rapidement vos fonctions en consultant une liste en continu des nouveaux événements du 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.

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 Tail dans l’AWS CLI) :

Autorisations

Les autorisations suivantes sont requises pour démarrer et arrêter les sessions CloudWatch Logs Live Tail :

Démarrage d’une session Live Tail dans la console Lambda

Accès aux journaux de fonctions à l’aide de la console

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) :

Ces journaux indiquent :

Accès aux journaux avec l’AWS CLI

La AWS CLI est un outil open-source qui vous permet d’interagir avec des services AWS à l’aide des commandes de votre shell de ligne de commande. Pour 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.

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

{
    "StatusCode": 200,
    "LogResult": "U1RBUlQgUmVxdWVzdElkOiA4N2QwNDRiOC1mMTU0LTExZTgtOGNkYS0yOTc0YzVlNGZiMjEgVmVyc2lvb...",
    "ExecutedVersion": "$LATEST"
}

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

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

#!/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

chmod -R 755 get-logs.sh

./get-logs.sh

{
    "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 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 journal CloudWatch résultant contient un champ distinct spécifiant le niveau de journal :

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 :

La fonctionnalité CloudWatch Logs Insights découvre automatiquement les valeurs dans la sortie JSON et analyse les messages sous forme de champs, sans qu’il soit nécessaire de recourir à une expression régulière ou à un modèle glob personnalisé. À 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 :

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 journaux 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’événement AWS comme Amazon S3, Amazon SQS ou Amazon EventBridge invoque votre fonction, l’événement complet est fourni à la fonction sous forme d’objet JSON. En déconnectant 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.

 fields Timestamp, LogLevel, Message
 | filter LogLevel == "ERR"
 | sort @timestamp desc
 | limit 100

filter @type = "REPORT"
| fields @requestId, @billedDuration
| sort by @billedDuration desc
| limit 100

filter @type = "REPORT"
| stats sum(strcontains(@message, "Init Duration"))/count(*) * 100 as
  coldStartPct, avg(@duration)
  by bin(5m)

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)

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

filter @type = "REPORT" and @maxMemoryUsed=@memorySize
| stats
    count_distinct(@requestId)
    by bin(30m)

avgMemoryUsedPERC,
    avg(@billedDuration) as avgDurationMS
    by bin(5m)

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)

filter @message like /Process exited/
| stats count() by bin(30m)

filter @message like /Task timed out/
| stats count() by bin(30m)

filter @type = "REPORT"
| stats avg(@duration), max(@duration), min(@duration)
  by bin(5m)

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 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, 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 :

Une fois que vous avez terminé de créer la visualisation, vous pouvez éventuellement ajouter le graphique à un tableau de bord CloudWatch. 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 :