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.
# Surveillance, débogage et dépannage des fonctions Lambda
AWS Lambda s’intègre avec d’autres Services AWS pour vous aider à surveiller, suivre, déboguer et dépanner vos fonctions Lambda. Lambda surveille automatiquement les fonctions Lambda pour vous, et rapporte les métriques via Amazon CloudWatch. Pour vous aider à surveiller votre code lors de l'exécution de celui-ci, Lambda suit automatiquement le nombre de demandes, la durée d'invocation par demande et le nombre de demandes générant une erreur.
Vous pouvez utiliser d’autres Services AWS pour dépanner vos fonctions Lambda. Cette section explique comment utiliser ces Services AWS pour surveiller, suivre, déboguer et dépanner vos fonctions et applications Lambda. Pour plus de détails sur la journalisation des fonctions et les erreurs dans chaque environnement d'exécution, consultez les sections relatives à chaque environnement d'exécution.
**Topics**
+ [Tarification](#monitoring-console-metrics-pricing)
+ [Utilisation des métriques CloudWatch avec Lambda](monitoring-metrics.md)
+ [Utilisation des journaux de fonction Lambda](monitoring-logs.md)
+ [Journalisation des appels AWS Lambda d'API à l'aide AWS CloudTrail](logging-using-cloudtrail.md)
+ [Visualisez les invocations de fonctions Lambda à l'aide de AWS X-Ray](services-xray.md)
+ [Surveillance des performances de fonctions avec Amazon CloudWatch Lambda Insights](monitoring-insights.md)
+ [Surveillance des applications Lambda](applications-console-monitoring.md)
+ [Surveillance des performances d’applications avec la vigie applicative Amazon CloudWatch](monitoring-application-signals.md)
+ [Déboguer à distance des fonctions Lambda avec Visual Studio Code](debugging.md)
## Tarification
CloudWatch propose une offre gratuite perpétuelle. Au-delà du seuil de cette offre gratuite, CloudWatch facture les métriques, les tableaux de bord, les alarmes, les journaux et les informations. Pour plus d’informations, consultez [Tarification Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
# Utilisation des métriques CloudWatch avec Lambda
Lorsque votre fonction AWS Lambda termine le traitement d’un événement, Lambda envoie des métriques d’invocation à Amazon CloudWatch. Vous n’avez pas besoin d’octroyer des autorisations supplémentaires à votre rôle d’exécution pour recevoir des métriques de fonction, et il n’y a pas de frais supplémentaires pour ces métriques.
De nombreux types de métriques sont associés aux fonctions Lambda. Il s’agit notamment des métriques d’invocation, des métriques de performance, des métriques de simultanéité, des métriques d’invocation asynchrone et des métriques de mappage des sources d’événements. Pour de plus amples informations, consultez [Types de métriques pour les fonctions Lambda](monitoring-metrics-types.md).
Dans la console CloudWatch, vous pouvez [afficher ces métriques](monitoring-metrics-view.md) et créer des graphiques et des tableaux de bord à partir de celles-ci. Il est également possible de définir des alarmes pour réagir aux changements dans l’utilisation, les performances ou les taux d’erreur. Lambda envoie les données des métriques à CloudWatch à intervalles d'une minute. Si vous souhaitez obtenir des informations plus immédiates sur votre fonction Lambda, vous pouvez créer de [métriques personnalisées haute définition](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html). Des frais s’appliquent aux métriques personnalisées et aux alarmes CloudWatch. Pour en savoir plus, consultez [Tarification Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
# Affichage des métriques pour une fonction Lambda
Utilisez la console CloudWatch pour consulter les métriques de vos fonctions Lambda. Dans la console, vous pouvez filtrer et trier les métriques des fonctions par nom de fonction, alias, version ou UUID de mappage des sources d’événements.
**Pour afficher des métriques dans la console CloudWatch**
1. Ouvrez la [page Metrics (Métriques)](https://console.aws.amazon.com/cloudwatch/home?region=us-east-1#metricsV2:graph=~();namespace=~'AWS*2fLambda) (espace de noms `AWS/Lambda`) dans la console CloudWatch.
1. Dans l'onglet **Parcourir**, sous **Métriques**, choisissez l'une des dimensions suivantes :
+ **By Function Name (Par nom de fonction)** (`FunctionName`) – Affichez les métriques agrégées pour l'ensemble des versions et alias d'une fonction.
+ **By Resource (Par ressource)** (`Resource`) – Affichez les métriques pour une version ou un alias d'une fonction.
+ **By Executed Version (Par version exécutée)** (`ExecutedVersion`) – Affichez les métriques pour une combinaison d'alias et de version. Utilisez la dimension `ExecutedVersion` pour comparer les taux d'erreur pour deux versions d'une fonction qui sont les cibles d'un [alias pondéré](configuration-aliases.md).
+ **Par UUID de mappage des sources d’événement** (`EventSourceMappingUUID`) : affiche les métriques d’un mappage des sources d’événement.
+ **Sur toutes les fonctions** (aucun) : affichez les métriques agrégées pour toutes les fonctions dans la Région AWS actuelle.
1. Choisissez une métrique. La métrique doit apparaître automatiquement dans le graphique visuel, ainsi que sous l’onglet **Graphiques des métriques**.
Par défaut, les graphiques utilisent la statistique `Sum` pour toutes les métriques. Pour choisir une autre statistique et personnaliser le graphique, utilisez les options de l'onglet **Graphique des métriques**.
**Note**
L'horodatage d'une métrique indique le moment où la fonction a été invoquée. En fonction de la durée de l'invocation, il peut se rapporter à plusieurs minutes avant l'émission de la métrique. Par exemple, si le délai d'expiration de votre fonction est de 10 minutes, effectuez une recherche plus de 10 minutes dans le passé pour obtenir des métriques précises.
Pour de plus amples informations sur Amazon CloudWatch, consultez le [Guide de l’utilisateur Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html).
# Types de métriques pour les fonctions Lambda
Cette section décrit les types de métriques Lambda disponibles dans la CloudWatch console.
**Topics**
+ [Métriques d'invocation](#invocation-metrics)
+ [Métriques de déploiement](#deployment-metrics)
+ [Métriques de performances](#performance-metrics)
+ [Métriques de simultanéité](#concurrency-metrics)
+ [Métriques d'invocations asynchrones](#async-invocation-metrics)
+ [Métriques de mappage des sources d’événements](#event-source-mapping-metrics)
## Métriques d'invocation
Les métriques d'invocation sont des indicateurs binaires du résultat d'une invocation de fonction Lambda. Vous devez visualiser les métriques suivantes avec la statistique `Sum`. Par exemple, si la fonction renvoie une erreur, Lambda envoie la métrique `Errors` avec une valeur de 1. Pour obtenir le nombre d'erreurs de fonction qui se sont produites chaque minute, examinez la somme `Sum` de la métrique `Errors` avec une période d'une minute.
+ `Invocations` – Nombre de fois où votre code de fonction est invoqué, y compris les invocations réussies et les invocations qui entraînent une erreur de fonction. Les invocations ne sont pas enregistrés si la demande d'invocation est limitée ou si elle entraîne une erreur d'invocation. La valeur de `Invocations` est égale au nombre de demandes facturées.
+ `Errors` – Nombre d'invocations entraînant une erreur de fonction. Les erreurs de fonction incluent les exceptions levées par votre code et par l'exécution Lambda. L'environnement d'exécution renvoie des erreurs pour des problèmes tels que les expirations de délai et les erreurs de configuration. Pour calculer le taux d'erreur, divisez la valeur `Errors` par la valeur `Invocations`. Notez que l'horodatage d'une métrique d'erreur reflète l'heure d'invocation de la fonction, et non l'heure à laquelle l'erreur s'est produite.
+ `DeadLetterErrors` : pour un [invocation asynchrone](invocation-async.md), le nombre de fois où Lambda tente sans succès d'envoyer un événement à une file d'attente de lettres mortes (DLQ). Des erreurs de type « lettre morte » peuvent se produire en raison d’une définition incorrecte des ressources ou des limites de taille.
+ `DestinationDeliveryFailures` – Pour l'invocation asynchrone et les [mappages des sources d'événements](https://docs.aws.amazon.com/lambda/latest/dg/invocation-eventsourcemapping.html) pris en charge, le nombre de fois où Lambda tente d'envoyer un événement à une [destination](invocation-async-retain-records.md#invocation-async-destinations), mais échoue. Pour les mappages des sources d'événements, Lambda prend en charge les destinations des sources de flux (DynamoDB et Kinesis). Des erreurs de remise peuvent se produire en raison d’erreurs d’autorisations, de ressources mal configurées ou des limites de taille. Des erreurs peuvent également se produire si la destination que vous avez configurée est un type non pris en charge, tel qu'une file d'attente FIFO Amazon SQS ou une rubrique FIFO Amazon SNS.
+ `Throttles` – Nombre de demandes d'invocation limitées. Lorsque toutes les instances de fonction traitent des requêtes et qu'aucune simultanéité n'est disponible pour effectuer une augmentation, Lambda rejette les requêtes supplémentaires avec une erreur `TooManyRequestsException`. Les demandes limitées et les autres erreurs d'invocation ne comptent pas comme `Invocations` ou `Errors`.
**Note**
Avec les [instances gérées Lambda](lambda-managed-instances.md), Lambda fournit des métriques d'accélération granulaires qui identifient la contrainte spécifique à l'origine de l'accélération. Lorsqu'un accélérateur se produit dans l'environnement d'exécution, exactement l'une des sous-métriques suivantes est émise avec une valeur de 1, tandis que les trois autres sont émises avec une valeur de 0. La `Throttles` métrique est toujours émise à côté de ces sous-métriques.
`CPUThrottles`— Les appels sont limités en raison de l'épuisement du processeur dans l'environnement d'exécution.
`MemoryThrottles`— Les appels sont limités en raison de l'épuisement de la mémoire dans l'environnement d'exécution.
`DiskThrottles`— Les appels sont limités en raison de l'épuisement du disque dans l'environnement d'exécution.
`ConcurrencyThrottles`— Les appels sont limités lorsque la limite de simultanéité de l'environnement d'exécution est atteinte.
+ `OversizedRecordCount` – Pour les sources d'événements Amazon DocumentDB, le nombre d'événements que votre fonction reçoit de votre flux de modifications et dont la taille est supérieure à 6 Mo. Lambda supprime le message et émet cette métrique.
+ `ProvisionedConcurrencyInvocations` : le nombre d'invocation de votre code de fonction à l'aide de la [simultanéité provisionnée](provisioned-concurrency.md).
+ `ProvisionedConcurrencySpilloverInvocations` : le nombre d'invocations de votre code de fonction à l'aide d'une simultanéité standard lorsque toutes les simultanéités provisionnées sont utilisées.
+ `RecursiveInvocationsDropped` : le nombre de fois où Lambda a arrêté l’invocation de votre fonction parce qu’il a détecté que votre fonction faisait partie d’une boucle récursive infinie. La détection de boucle récursive surveille le nombre de fois qu'une fonction est invoquée dans le cadre d'une chaîne de requêtes en suivant les métadonnées ajoutées par support AWS SDKs. Si votre fonction est invoquée dans le cadre d’une chaîne de requêtes environ plus de 16 fois, Lambda abandonne l’invocation suivante. Si vous désactivez la détection des boucles récursives, cette métrique n’est pas émise. Pour en savoir plus sur cette fonction, consultez [Utilisation de la détection de boucle récursive Lambda pour prévenir les boucles infinies](invocation-recursion.md).
## Métriques de déploiement
Les métriques de déploiement fournissent des informations sur les événements de déploiement de la fonction Lambda et les processus de validation associés.
+ `SignatureValidationErrors` : le nombre de fois qu’un déploiement de package de code s’est produit avec des échecs de validation de signature lorsque la politique de configuration de signature de code est définie sur `Warn`. Cette métrique est émise lorsque les vérifications d’expiration, d’incompatibilité ou de révocation échouent, mais que le déploiement est toujours autorisé en raison du paramètre de politique `Warn`. Pour plus d'informations sur la signature de code, consultez [Utilisation de la signature de code pour vérifier l’intégrité du code avec Lambda](configuration-codesigning.md).
## Métriques de performances
Les métriques de performance fournissent des détails sur les performances d'un invocation de fonction individuel. Par exemple, la métrique `Duration` indique la durée en millisecondes que votre fonction consacre au traitement d'un événement. Pour avoir une idée de la rapidité avec laquelle votre fonction traite les événements, affichez ces métriques avec la statistique `Average` ou `Max`.
+ `Duration` – Durée de traitement d'un événement par votre code de fonction. La durée facturée pour une invocation est la valeur de la `Duration` arrondie à la milliseconde la plus proche. La `Duration` n'inclut pas le temps de démarrage à froid.
+ `PostRuntimeExtensionsDuration` – Durée cumulée que l'environnement d'exécution a consacrée à l'exécution de code pour des extensions une fois l'exécution du code de la fonction terminée.
+ `IteratorAge` : pour les sources d’événements DynamoDB, Kinesis et Amazon DocumentDB, l’âge en millisecondes du dernier enregistrement dans l’événement. Ce métrique mesure le temps écoulé entre le moment où un flux reçoit l'enregistrement et le moment où le mappage des sources d'événements envoie l'événement à la fonction.
+ `OffsetLag` : pour les sources d'événements autogérées Apache Kafka et Amazon Managed Streaming for Apache Kafka (Amazon MSK), la différence de décalage entre le dernier enregistrement écrit sur une rubrique et le dernier enregistrement traité par le groupe de consommateurs de votre fonction. Bien qu'une rubrique Kafka puisse comporter plusieurs partitions, cette métrique mesure le décalage de décalage au niveau de la rubrique.
`Duration` prend également en charge les statistiques de centiles (`p`). Utilisez les centiles pour exclure les valeurs aberrantes qui faussent les statistiques `Average` et `Maximum`. Par exemple, la statistique `p95` indique la durée maximale de 95 % des invocations, en excluant les 5 % les plus lentes. Pour plus d'informations, consultez la section [Percentiles](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Percentiles) dans le guide de * CloudWatch l'utilisateur Amazon*.
## Métriques de simultanéité
Lambda signale les métriques de simultanéité sous la forme d'une valeur agrégée du nombre d'instances traitant des événements au sein d'une fonction, d'une version, d'un alias ou d'une Région AWS. Pour voir la distance qui vous sépare des [limites de simultanéité](lambda-concurrency.md#concurrency-quotas), affichez ces métriques à l'aide de la statistique `Max`.
+ `ConcurrentExecutions` – Nombre d'instances de fonction qui traitent des événements. Si ce nombre atteint votre [quota d'exécutions simultanées](gettingstarted-limits.md#compute-and-storage) pour la région ou la [limite de simultanéité réservée](configuration-concurrency.md) sur la fonction, Lambda limite les demandes d'invocation supplémentaires.
+ `ProvisionedConcurrentExecutions` : le nombre d'instances de fonction qui traitent des événements à l'aide de la [simultanéité provisionnée](provisioned-concurrency.md). Pour chaque invocation d'alias ou de version avec une simultanéité approvisionnée, Lambda émet le nombre actuel. Si votre fonction est inactive ou ne reçoit pas de requêtes, Lambda n’émet pas cette métrique.
+ `ProvisionedConcurrencyUtilization` : pour une version ou un alias, la valeur de `ProvisionedConcurrentExecutions` divisée par la quantité totale de simultanéité allouée configurée. Par exemple, si vous configurez une simultanéité allouée de 10 pour votre fonction et que votre `ProvisionedConcurrentExecutions` est 7, alors votre `ProvisionedConcurrencyUtilization` est 0,7.
Si votre fonction est inactive ou ne reçoit pas de requêtes, Lambda n’émet pas cette métrique, car elle est basée sur `ProvisionedConcurrentExecutions`. Gardez cela à l'esprit si vous l'utilisez `ProvisionedConcurrencyUtilization` comme base pour les CloudWatch alarmes.
+ `UnreservedConcurrentExecutions` – Pour une région, nombre d'événements traités par des fonctions qui n'ont pas de simultanéité réservée.
+ `ClaimedAccountConcurrency` – Pour une région, le niveau de simultanéité qui n'est pas disponible pour les appels à la demande. `ClaimedAccountConcurrency` est égal à `UnreservedConcurrentExecutions` plus le montant de la simultanéité allouée (c'est-à-dire le total de la simultanéité réservée plus le total de la simultanéité provisionnée). Pour de plus amples informations, veuillez consulter [Travailler avec la métrique `ClaimedAccountConcurrency`](monitoring-concurrency.md#claimed-account-concurrency).
## Métriques d'invocations asynchrones
Les métriques d'invocations asynchrones fournissent des informations détaillées sur les invocations asynchrones à partir des sources d'événements et des invocations directes. Vous pouvez définir des seuils et des alarmes pour vous avertir de certaines modifications. Par exemple, en cas d'augmentation indésirable du nombre d'événements mis en file d'attente pour traitement (`AsyncEventsReceived`). Ou encore lorsqu'un événement attend depuis longtemps d'être traité (`AsyncEventAge`).
+ `AsyncEventsReceived` : le nombre d'événements que Lambda met correctement en file d'attente pour traitement. Cette métrique fournit des informations sur le nombre d'événements qu'une fonction Lambda reçoit. Surveillez cette métrique et définissez des alarmes pour des seuils afin de détecter les problèmes. Par exemple, pour détecter un nombre indésirable d'événements envoyés à Lambda et pour diagnostiquer rapidement les problèmes résultant de configurations de déclencheurs ou de fonctions incorrectes. Les incompatibilités entre `AsyncEventsReceived` et `Invocations` peuvent indiquer une disparité de traitement, des événements abandonnés ou un éventuel backlog dans les files d'attente.
+ `AsyncEventAge` : le temps entre le moment où Lambda met correctement l'événement en file d'attente et le moment où la fonction est invoquée. La valeur de cette métrique augmente lorsque des événements font l'objet d'une nouvelle tentative en raison d'échecs d'invocation ou de limitation. Surveillez cette métrique et définissez des alarmes pour les seuils sur différentes statistiques lorsqu'une accumulation de file d'attente se produit. Pour résoudre le problème d'une augmentation de cette métrique, examinez la métrique `Errors` pour identifier les erreurs de fonction et la métrique `Throttles` pour identifier les problèmes de simultanéité.
+ `AsyncEventsDropped` : le nombre d'événements supprimés sans que la fonction ne soit exécutée correctement. Si vous configurez une file d'attente de lettres mortes (DLQ) ou une destination `OnFailure`, les événements y sont envoyés avant d'être supprimés. Les événements sont supprimés pour diverses raisons. Par exemple, les événements peuvent dépasser l'âge maximal de l'événement ou atteindre le nombre maximal de nouvelles tentatives, ou la simultanéité réservée peut être définie sur 0. Pour déterminer pourquoi les événements sont supprimés, examinez la métrique `Errors` pour identifier les erreurs de fonction et la métrique `Throttles` pour identifier les problèmes de simultanéité.
## Métriques de mappage des sources d’événements
Les métriques de mappage des sources d’événements fournissent des informations sur le comportement de traitement de votre mappage des sources d’événements.
Actuellement, les métriques de mappage des sources d'événements sont disponibles pour Amazon SQS, Kinesis, DynamoDB, Amazon MSK et les sources d'événements Apache Kafka autogérées.
Pour le mappage des sources d'événements avec la configuration des métriques, vous pouvez également vérifier toutes les métriques liées à ESM dans l'onglet **Monitor** depuis la page Console **Lambda** **> Ressources supplémentaires >** mappages de **sources d'événements maintenant**.
**Pour activer des métriques ou un mappage des sources d’événements (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Sélectionnez la fonction pour laquelle vous souhaitez activer les métriques.
1. Choisissez **Configuration**, puis **Déclencheurs**.
1. Choisissez le mappage des sources d’événements pour lequel vous souhaitez activer les métriques, puis choisissez **Modifier**.
1. Sous **Configuration du mappage des sources d'événements**, choisissez **Activer les mesures** ou sélectionnez-les dans la liste déroulante des **mesures**.
1. Choisissez **Enregistrer**.
Vous pouvez également activer les métriques pour le mappage de la source de votre événement par programmation à l'aide de l'[ EventSourceMappingMetricsConfig](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingMetricsConfig.html)objet contenu dans votre. [EventSourceMappingConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_EventSourceMappingConfiguration.html) Par exemple, la commande [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)CLI suivante active les métriques pour le mappage d'une source d'événement :
```
aws lambda update-event-source-mapping \
--uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \
--metrics-config Metrics=EventCount
```
Il existe 3 groupes de métriques :`EventCount`, `ErrorCount` et`KafkaMetrics`, et chaque groupe possède plusieurs métriques. Toutes les métriques ne sont pas disponibles pour chaque source d'événement. Le tableau suivant récapitule les mesures prises en charge pour chaque type de source d'événement.
Vous devez activer le groupe de métriques pour recevoir les métriques associées aux métriques. Par exemple, définissez EventCount dans la configuration des métriques les valeurs suivantes : (`PolledEventCount`,,`FilteredOutEventCount`,`InvokedEventCount`, `FailedInvokeEventCount` `DroppedEventCount``OnFailureDestinationDeliveredEventCount`, et). `DeletedEventCount`
| Métrique de mappage des sources d’événements | Groupe de métriques | Amazon SQS | Streams Kinesis et DynamoDB | Amazon MSK et Apache Kafka autogéré |
| --- | --- | --- | --- | --- |
| `PolledEventCount` | `EventCount` | Oui | Oui | Oui |
| `FilteredOutEventCount` | `EventCount` | Oui | Oui | Oui |
| `InvokedEventCount` | `EventCount` | Oui | Oui | Oui |
| `FailedInvokeEventCount` | `EventCount` | Oui | Oui | Oui |
| `DroppedEventCount` | `EventCount` | Non | Oui | Oui |
| `OnFailureDestinationDeliveredEventCount` | `EventCount` | Non | Oui | Oui |
| `DeletedEventCount` | `EventCount` | Oui | Non | Non |
| `CommittedEventCount` | `EventCount` | Non | Non | Oui |
| `PollingErrorCount` | `ErrorCount` | Non | Non | Oui |
| `InvokeErrorCount` | `ErrorCount` | Non | Non | Oui |
| `OnFailureDestinationDeliveryErrorCount` | `ErrorCount` | Non | Non | Oui |
| `SchemaRegistryErrorCount` | `ErrorCount` | Non | Non | Oui |
| `CommitErrorCount` | `ErrorCount` | Non | Non | Oui |
| `MaxOffsetLag` | `KafkaMetrics` | Non | Non | Oui |
| `SumOffsetLag` | `KafkaMetrics` | Non | Non | Oui |
En outre, si votre mappage des sources d’événements est en [mode alloué](invocation-eventsourcemapping.md#invocation-eventsourcemapping-provisioned-mode), Lambda fournit la métrique suivante :
+ `ProvisionedPollers` : pour les mappages des sources d’événements en mode alloué, le nombre de sondeurs d’événements qui s’exécutent activement. Visualisez cette métrique à l'aide des `MAX` calculs.
+ (Amazon MSK et sources d'événements Apache Kafka autogérées uniquement) `EventPollerUnit` — Pour les mappages de sources d'événements en mode provisionné, le nombre d'unités d'interrogation d'événements en cours d'exécution. Visualisez cette métrique à l'aide des `SUM` calculs.
+ (Amazon MSK et sources d'événements Apache Kafka autogérées) `EventPollerThroughputInBytes` — Pour les mappages de sources d'événements en mode provisionné, taille d'enregistrement totale des sondeurs d'événements interrogés à partir de la source d'événements. Il peut vous indiquer le débit d'interrogation actuel. Visualisez cette métrique à l'aide des `SUM` calculs.
Voici plus de détails sur chacune des métriques :
+ `PolledEventCount` : le nombre d’événements que Lambda lit correctement depuis la source des événements. Si Lambda interroge des événements, mais reçoit un sondage vide (aucun nouvel enregistrement), Lambda émet une valeur nulle pour cette métrique. Utilisez cette métrique pour détecter si votre mappage des sources d’événements interroge correctement les nouveaux événements.
+ `FilteredOutEventCount` :pour le mappage des sources d’événements avec un [critère de filtre](invocation-eventfiltering.md), le nombre d’événements filtrés selon ces critères de filtre. Utilisez cette métrique pour détecter si votre mappage des sources d’événements filtre correctement les événements. Pour les événements qui répondent aux critères de filtre, Lambda émet une métrique nulle.
+ `InvokedEventCount` : le nombre d’événements qui ont invoqué votre fonction Lambda. Utilisez cette métrique pour vérifier que les événements invoquent correctement votre fonction. Si un événement entraîne une erreur de fonctionnement ou une limitation, `InvokedEventCount` peut prendre en compte plusieurs fois pour le même événement interrogé en raison des nouvelles tentatives automatiques.
**Avertissement**
Les mappages des sources d’événements Lambda traitent chaque événement au moins une fois, et le traitement des enregistrements peut être dupliqué. De ce fait, les événements peuvent être comptés plusieurs fois dans les métriques qui impliquent le décompte des événements.
+ `FailedInvokeEventCount` : le nombre d’événements pour lesquels Lambda a essayé d’invoquer votre fonction, mais qui ont échoué. Les appels peuvent échouer pour des raisons telles que des problèmes de configuration réseau, des autorisations incorrectes ou la suppression d’une fonction, d’une version ou d’un alias Lambda. Si l’option [Réponse par lots partielle](services-sqs-errorhandling.md#services-sqs-batchfailurereporting) est activée pour votre mappage des sources d’événements, `FailedInvokeEventCount` inclut tout événement dont la réponse contient un champ `BatchItemFailures` non vide.
**Note**
L’horodatage de la métrique `FailedInvokeEventCount` représente la fin de l’invocation de la fonction. Ce comportement est différent des autres métriques d’erreur d’appel Lambda, qui sont horodatées au début de l’invocation de la fonction.
+ `DroppedEventCount` : le nombre d’événements que Lambda a abandonnés en raison de l’expiration ou de l’épuisement des tentatives. Plus précisément, il s’agit du nombre d’enregistrements qui dépassent les valeurs configurées pour `MaximumRecordAgeInSeconds` ou `MaximumRetryAttempts`. Il est important de noter que cela n’inclut pas le nombre d’enregistrements qui expirent en raison du dépassement des paramètres de conservation de la source de votre événement. Les événements abandonnés excluent également les événements que vous envoyez vers une [destination en cas d’échec.](invocation-async-retain-records.md) Utilisez cette métrique pour détecter un arriéré croissant d’événements.
+ `OnFailureDestinationDeliveredEventCount` : pour les mappages des sources d’événements avec une [destination en cas d’échec](invocation-async-retain-records.md) configurée, le nombre d’événements envoyés vers cette destination. Utilisez cette métrique pour surveiller les erreurs de fonctionnement liées aux appels provenant de cette source d’événements. Si la livraison à destination échoue, Lambda gère les métriques comme suit :
+ Lambda n’émet pas la métrique `OnFailureDestinationDeliveredEventCount`.
+ Pour la métrique `DestinationDeliveryFailures`, Lambda émet un 1.
+ Pour la métrique `DroppedEventCount`, Lambda émet un nombre égal au nombre d’événements ayant échoué à la livraison.
+ `DeletedEventCount` : le nombre d’événements que Lambda a réussi à supprimer après traitement. Si Lambda échoue à la tentative de suppression d’un événement, il émet une métrique nulle. Utilisez cette métrique pour vous assurer que les événements traités avec succès sont supprimés de votre source d’événements.
+ `CommittedEventCount`— Le nombre d'événements que Lambda a correctement validés après leur traitement. Il s'agit de la somme des deltas du dernier décalage validé et du décalage actuel par rapport à chaque partition dans le mappage des sources d'événements Kafka.
+ `PollingErrorCount`— Le nombre d'erreurs pendant lesquelles Lambda n'a pas réussi à interroger les demandes provenant de la source de l'événement. Lambda n'émet ces données métriques qu'en cas d'erreur.
+ `InvokeErrorCount`— Le nombre d'erreurs pendant lesquelles Lambda n'a pas réussi à appeler votre fonction. Notez que l'invocation est enregistrée par lots. Le numéro est indiqué au niveau du lot, et non au niveau du nombre d'enregistrements. Lambda n'émet ces données métriques qu'en cas d'erreur.
+ `SchemaRegistryErrorCount`— Le nombre d'erreurs que Lambda n'a pas réussi à récupérer le schéma ou à désérialiser avec le schéma. Lambda n'émet ces données métriques qu'en cas d'erreur.
+ `CommitErrorCount`— Le nombre d'erreurs que Lambda n'a pas réussi à commettre dans le cluster Kafka. Lambda n'émet ces données métriques qu'en cas d'erreur.
+ `MaxOffsetLag`— Le maximum des décalages de décalage (différence entre les derniers décalages et les décalages validés) sur toutes les partitions du mappage des sources d'événements.
+ `SumOffsetLag`— La somme des décalages entre toutes les partitions du mappage des sources d'événements.
Si le mappage des sources d’événements est désactivé, vous ne recevrez pas de statistiques de mappage des sources d’événements. Vous pouvez également voir des métriques manquantes si CloudWatch Lambda connaît une dégradation de la disponibilité.
# Utilisation des journaux de fonction Lambda
Pour vous aider à résoudre les défaillances, surveille AWS Lambda automatiquement les fonctions Lambda en votre nom. Vous pouvez consulter les journaux des fonctions Lambda à l'aide de la console Lambda, de la console, du CloudWatch AWS Command Line Interface (AWS CLI) et de l'API. CloudWatch Vous pouvez également configurer Lambda pour envoyer les journaux à Amazon S3 et Firehose.
Tant que le [rôle d'exécution](lambda-intro-execution-role.md) de votre fonction dispose des autorisations nécessaires, Lambda capture les journaux de toutes les demandes traitées par votre fonction et les envoie à Amazon CloudWatch Logs, qui est la destination par défaut. Vous pouvez également laisser la console Lambda configurer Amazon S3 ou Firehose comme destinations de journalisation.
+ **CloudWatch Logs** est la destination de journalisation par défaut pour les fonctions Lambda. CloudWatch Logs fournit des fonctionnalités de visualisation et d'analyse des journaux en temps réel, ainsi qu'une assistance pour créer des métriques et des alarmes basées sur les données de vos journaux.
+ **Amazon S3** est économique pour le stockage à long terme, et des services comme Athena peuvent être utilisés pour analyser les journaux. La latence est généralement plus élevée.
+ **Firehose** propose une diffusion en continu gérée des journaux vers différentes destinations. Si vous devez envoyer des logs à d'autres AWS services (par exemple, OpenSearch Service ou Redshift Data API) ou à des plateformes tierces (comme Datadog, New Relic ou Splunk), Firehose simplifie ce processus en fournissant des intégrations prédéfinies. Vous pouvez également diffuser vers des points de terminaison HTTP personnalisés sans configurer d’infrastructure supplémentaire.
## Choix d’une destination de service à laquelle envoyer les journaux
Tenez compte des facteurs clés suivants lorsque vous choisissez un service comme destination pour les journaux de fonction :
+ **La gestion des coûts varie selon le service.** Amazon S3 constitue généralement l'option la plus économique pour le stockage à long terme, tandis que CloudWatch Logs vous permet de consulter les journaux, de traiter les journaux et de configurer des alertes en temps réel. Les coûts de Firehose incluent à la fois le service de diffusion en continu et le coût associé à la destination vers laquelle vous diffusez.
+ **Les capacités d'analyse varient d'un service à l'autre.** CloudWatch Logs excelle dans la surveillance en temps réel et s'intègre nativement à d'autres CloudWatch fonctionnalités, telles que Logs Insights et Live Tail. Amazon S3 fonctionne bien avec des outils d’analyse comme Athena, et peut s’intégrer à divers services, même s’il peut nécessiter une configuration supplémentaire. Firehose simplifie le streaming direct vers des AWS services spécifiques (tels que OpenSearch Service et Redshift Data API) et des plateformes tierces prises en charge (telles que Datadog et Splunk) en fournissant des intégrations prédéfinies, ce qui peut réduire le travail de configuration.
+ **La configuration et la facilité d'utilisation varient selon le service.** CloudWatch Les journaux sont la destination par défaut des journaux. Elle fonctionne immédiatement, sans configuration supplémentaire, et permet de visualiser et d'analyser les journaux directement via la CloudWatch console. Si vous avez besoin d’envoyer les journaux à Amazon S3, vous devez effectuer une configuration initiale dans la console Lambda et configurer les autorisations du compartiment. Si vous avez besoin de journaux envoyés directement à des services tels que OpenSearch Service ou à des plateformes d'analyse tierces, Firehose peut simplifier ce processus.
## Configuration des destinations de journal
AWS Lambda prend en charge plusieurs destinations pour vos journaux de fonctions. Ce guide explique les destinations de journalisation disponibles et vous aide à choisir l’option adaptée à vos besoins. Quelle que soit la destination choisie, Lambda propose des options pour contrôler le format, le filtrage et la diffusion des journaux.
Lambda prend en charge les formats JSON et texte brut pour les journaux de votre fonction. Les journaux structurés JSON offrent une meilleure facilité de recherche et permettent une analyse automatisée, tandis que les journaux en texte brut offrent une simplicité et des coûts de stockage potentiellement réduits. Vous pouvez contrôler les journaux que Lambda envoie à la destination que vous avez choisie en configurant les niveaux de journal pour les journaux du système et des applications. Le filtrage vous aide à gérer les coûts de stockage et trouver plus facilement les entrées de journal pertinentes lors du débogage.
Pour obtenir des instructions de configuration détaillées pour chaque destination, consultez les sections suivantes :
+ [Envoi automatique des journaux de la fonction Lambda à CloudWatch Logs](monitoring-cloudwatchlogs.md)
+ [Envoi de journaux de fonction Lambda à Firehose](logging-with-firehose.md)
+ [Envoi des journaux de fonction Lambda à Amazon S3](logging-with-s3.md)
## Configuration de commandes de journalisation avancées pour votre fonction Lambda
Pour vous permettre de mieux contrôler la manière dont les journaux de votre fonction sont capturés, traités et consommés, Lambda propose les options de configuration de journalisation suivantes :
+ **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 structurés JSON, choisissez le niveau de détail des journaux auxquels Lambda envoie CloudWatch, par exemple`FATAL`,`ERROR`,, `WARN` `INFO``DEBUG`, et. `TRACE`
+ **Groupe de journaux** : choisissez le groupe de CloudWatch journaux auquel votre fonction envoie les journaux.
Pour en savoir plus sur la configuration des contrôles de journalisation avancés, consultez les sections suivantes :
+ [Configuration des formats de journal JSON et en texte brut](monitoring-cloudwatchlogs-logformat.md)
+ [Filtrage au niveau du journal](monitoring-cloudwatchlogs-log-level.md)
+ [Configuration des groupes de CloudWatch journaux](monitoring-cloudwatchlogs-loggroups.md)
# Configuration des formats de journal JSON et en texte brut
La capture des sorties de votre journal sous forme de paires clé-valeur JSON facilite la recherche et le filtrage lors du débogage de vos fonctions. Avec les journaux au format JSON, vous pouvez également ajouter des balises et des informations contextuelles à vos journaux. Cela peut vous aider à effectuer une analyse automatique de gros volumes de données de journal. À moins que votre flux de développement ne repose sur des outils existants qui utilisent les journaux Lambda en texte brut, nous vous recommandons de sélectionner JSON pour le format de journal.
**Instances gérées par Lambda**
Les instances gérées Lambda ne prennent en charge que le format de journal JSON. Lorsque vous créez une fonction Managed Instances, Lambda configure automatiquement le format du journal en JSON et vous ne pouvez pas le modifier en texte brut. Pour plus d'informations sur les instances gérées, consultez[Instances gérées par Lambda](lambda-managed-instances.md).
Pour tous les environnements d'exécution gérés par Lambda, vous pouvez choisir si les journaux système de votre fonction sont envoyés à CloudWatch Logs en texte brut non structuré ou au format JSON. Les journaux système sont les journaux générés par Lambda et sont parfois appelés journaux d’événements de plate-forme.
Pour les [environnements d’exécution pris en charge](#monitoring-cloudwatchlogs-logformat-supported), lorsque vous utilisez l’une des méthodes de journalisation intégrées prises en charge, Lambda peut également générer les journaux d’application de votre fonction (les journaux générés par votre code de fonction) au format JSON structuré. Lorsque vous configurez le format de journal de votre fonction pour ces environnements d’exécution, la configuration que vous choisissez s’applique à la fois aux journaux du système et aux journaux des applications.
Pour les environnements d’exécution pris en charge, si votre fonction utilise une bibliothèque ou une méthode de journalisation prise en charge, vous n’avez pas besoin de modifier votre code existant pour que Lambda capture les journaux au format JSON structuré.
**Note**
L’utilisation du format de journal JSON ajoute des métadonnées supplémentaires et code les messages de journal sous forme d’objets JSON contenant une série de paires clé-valeur. De ce fait, la taille des messages du journal de votre fonction peut augmenter.
## Temps d’exécution et méthodes de journalisation pris en charge
Lambda prend actuellement en charge la possibilité de générer des journaux d’application structurés en JSON pour les environnements d’exécution suivants.
| Language | Versions prises en charge |
| --- | --- |
| Java | Tous les environnements d'exécution Java sauf Java 8 sur Amazon Linux 1 |
| .NET | .NET 8 et versions ultérieures |
| Node.js | Node.js 16 et versions ultérieures |
| Python | Python 3.8 et versions ultérieures |
| Rust | N/A |
Pour que Lambda envoie les journaux d'application de votre fonction CloudWatch au format JSON structuré, votre fonction doit utiliser les outils de journalisation intégrés suivants pour générer les journaux :
+ **Java** : L'`LambdaLogger`enregistreur ou Log4j2. Pour de plus amples informations, veuillez consulter [Journalisation et surveillance des fonctions Lambda Java](java-logging.md).
+ **.NET** : `ILambdaLogger` instance de l'objet de contexte. Pour de plus amples informations, veuillez consulter [Journalisation et surveillance des fonctions Lambda C\$1](csharp-logging.md).
+ **Node.js** - Les méthodes de console `console.trace``console.debug`,`console.log`,`console.info`,`console.error`, et`console.warn`. Pour de plus amples informations, veuillez consulter [Journalisation et surveillance des fonctions Lambda Node.js](nodejs-logging.md).
+ **Python** : `logging` bibliothèque Python standard. Pour de plus amples informations, veuillez consulter [Journalisation et surveillance des fonctions Lambda Python](python-logging.md).
+ **Rust** : La `tracing` caisse. Pour de plus amples informations, veuillez consulter [Journalisation et surveillance des fonctions Lambda Rust](rust-logging.md).
Pour les autres environnements d’exécution Lambda gérés, Lambda ne prend actuellement en charge de manière native que la capture des journaux système au format JSON structuré. Cependant, vous pouvez toujours capturer les journaux d'applications au format JSON structuré dans n'importe quel environnement d'exécution en utilisant des outils de journalisation tels que Powertools pour générer AWS Lambda des sorties de journal au format JSON.
## Formats de journal par défaut
Actuellement, le format de journal par défaut pour tous les environnements d’exécution Lambda est le texte brut. Pour les instances gérées Lambda, le format du journal est toujours JSON et ne peut pas être modifié.
Si vous utilisez déjà des bibliothèques de journalisation telles que Powertools AWS Lambda pour générer vos journaux de fonctions au format structuré JSON, vous n'avez pas besoin de modifier votre code si vous sélectionnez le formatage des journaux JSON. Lambda n’encode pas deux fois les journaux déjà codés en JSON. Les journaux d’application de votre fonction continueront donc d’être capturés comme avant.
## Format JSON pour les journaux du système
Lorsque vous définissez le format de journal de votre fonction sur JSON, chaque élément du journal système (événement de plate-forme) est capturé sous la forme d’un objet JSON contenant des paires clé-valeur avec les clés suivantes :
+ `"time"` - heure à laquelle le message de journal a été généré
+ `"type"` - type d’événement enregistré
+ `"record"` - contenu de la sortie du journal
Le format de la valeur `"record"` varie en fonction du type d’événement enregistré. Pour de plus amples informations, veuillez consulter [Types d’objets `Event` de l’API de télémétrie](telemetry-schema-reference.md#telemetry-api-events). Pour plus d’informations sur les niveaux de journalisation attribués aux événements du journal système, consultez [Mappage des événements au niveau du journal système](monitoring-cloudwatchlogs-log-level.md#monitoring-cloudwatchlogs-log-level-mapping).
À titre de comparaison, les deux exemples suivants montrent le même résultat de journal à la fois au format texte brut et au format JSON structuré. Notez que dans la plupart des cas, les événements du journal système contiennent plus d’informations lorsqu’ils sont produits au format JSON que lorsqu’ils sont produits en texte brut.
**Example texte brut :**
```
2024-03-13 18:56:24.046000 fbe8c1 INIT_START Runtime Version: python:3.12.v18 Runtime Version ARN: arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0
```
**Example JSON structuré :**
```
{
"time": "2024-03-13T18:56:24.046Z",
"type": "platform.initStart",
"record": {
"initializationType": "on-demand",
"phase": "init",
"runtimeVersion": "python:3.12.v18",
"runtimeVersionArn": "arn:aws:lambda:eu-west-1::runtime:edb5a058bfa782cb9cedc6d534ac8b8c193bc28e9a9879d9f5ebaaf619cd0fc0"
}
}
```
**Note**
L’API [Accès aux données de télémétrie en temps réel pour les extensions à l’aide de l’API de télémétrie](telemetry-api.md) toujours des événements de plate-forme tels que `START` et `REPORT` au format JSON. La configuration du format des journaux système auxquels Lambda envoie des messages CloudWatch n'affecte pas le comportement de l'API de télémétrie Lambda.
## Format JSON pour les journaux d’applications
Lorsque vous configurez le format de journal de votre fonction au format JSON, les sorties du journal d'application écrites à l'aide des bibliothèques et méthodes de journalisation prises en charge sont capturées sous forme d'objet JSON contenant des paires clé-valeur avec les clés suivantes.
+ `"timestamp"` - heure à laquelle le message de journal a été généré
+ `"level"` - niveau de journalisation attribué au message
+ `"message"` - contenu du message de journal
+ `"requestId"` (Python, .NET et Node.js) ou `"AWSrequestId"` (Java) : l’ID de requête unique pour l’invocation de la fonction
Selon la méthode d’exécution et journalisation utilisée par votre fonction, cet objet JSON peut également contenir des paires de clés supplémentaires. Par exemple, dans Node.js, si votre fonction utilise des méthodes `console` pour enregistrer les objets d'erreur à l'aide de plusieurs arguments, l'objet JSON contiendra des paires clé-valeur supplémentaires avec les clés `errorMessage`, `errorType` et `stackTrace`. Pour en savoir plus sur les journaux au format JSON dans les différents environnements d'exécution Lambda, consultez [Journalisation et surveillance des fonctions Lambda Python](python-logging.md), [Journalisation et surveillance des fonctions Lambda Node.js](nodejs-logging.md) et [Journalisation et surveillance des fonctions Lambda Java](java-logging.md).
**Note**
La clé utilisée par Lambda pour la valeur d’horodatage est différente pour les journaux système et les journaux des applications. Pour les journaux système, Lambda utilise la clé `"time"` pour maintenir la cohérence avec l’API de télémétrie. Pour les journaux d’applications, Lambda suit les conventions des environnements d’exécution et utilise `"timestamp"`.
À titre de comparaison, les deux exemples suivants montrent le même résultat de journal à la fois au format texte brut et au format JSON structuré.
**Example texte brut :**
```
2024-10-27T19:17:45.586Z 79b4f56e-95b1-4643-9700-2807f4e68189 INFO some log message
```
**Example JSON structuré :**
```
{
"timestamp":"2024-10-27T19:17:45.586Z",
"level":"INFO",
"message":"some log message",
"requestId":"79b4f56e-95b1-4643-9700-2807f4e68189"
}
```
## Configuration du format du journal de votre fonction
Pour configurer le format du journal pour votre fonction, vous pouvez utiliser la console Lambda ou le AWS Command Line Interface ()AWS CLI. Vous pouvez également configurer le format de journal d'une fonction à 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, de la [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)ressource AWS Serverless Application Model (AWS SAM) et de la CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)ressource.
La modification du format de journal de votre fonction n'affecte pas les journaux existants stockés dans CloudWatch Logs. Seuls les nouveaux journaux utiliseront le format mis à jour.
Si vous modifiez le format de journal de votre fonction en JSON sans définir le niveau de journal, Lambda définit automatiquement le niveau de journal d'application et le niveau de journal système de votre fonction sur INFO. Cela signifie que Lambda envoie uniquement des sorties de journal de niveau INFO ou inférieur à CloudWatch Logs. Pour en savoir plus sur le filtrage au niveau des journaux d'applications et de systèmes, consultez [Filtrage au niveau du journal](monitoring-cloudwatchlogs-log-level.md)
**Note**
Pour les environnements d'exécution Python, lorsque le format de journal de votre fonction est défini sur du texte brut, le paramètre de niveau de journal par défaut est WARN. Cela signifie que Lambda envoie uniquement des sorties de journal de niveau WARN ou inférieur à CloudWatch Logs. La modification du format de journal de votre fonction en JSON modifie ce comportement par défaut. Pour en savoir plus sur la journalisation dans Python, consultez [Journalisation et surveillance des fonctions Lambda Python](python-logging.md).
Pour les fonctions Node.js qui émettent des journaux au format EMF (Embedded Metric Format), la modification du format de journal de votre fonction en CloudWatch JSON peut empêcher la reconnaissance de vos métriques.
**Important**
Si votre fonction utilise Powertools for AWS Lambda (TypeScript) ou les bibliothèques clientes EMF open source pour émettre des journaux EMF, mettez à jour vos bibliothèques [Powertools](https://github.com/aws-powertools/powertools-lambda-typescript) et [EMF](https://www.npmjs.com/package/aws-embedded-metrics) avec les dernières versions pour vous assurer qu'elles CloudWatch peuvent continuer à analyser correctement vos journaux. Si vous passez au format de journal JSON, nous vous recommandons également d’effectuer des tests pour garantir la compatibilité avec les métriques intégrées de votre fonction. Pour plus d’informations sur les fonctions node.js qui émettent des journaux EMF, consultez [Utilisation de bibliothèques clientes au format métrique intégré (EMF) avec des journaux JSON structurés](nodejs-logging.md#nodejs-logging-advanced-emf).
**Configurer le format de journal d’une fonction (console)**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisir 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. Sous **Contenu du journal**, pour **Format du journal**, sélectionnez **Texte** ou **JSON**.
1. Choisissez **Enregistrer**.
**Pour modifier le format du journal d’une fonction existante (AWS CLI)**
+ Pour modifier le format de journalisation d’une fonction existante, utilisez la commande [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Définissez l'option `LogFormat` dans `LoggingConfig` sur `JSON` ou `Text`.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON
```
**Pour définir le format du journal lorsque vous créez une fonction (AWS CLI)**
+ Pour configurer le format du journal lorsque vous créez une fonction, utilisez l’option `--logging-config` de la commande [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). Définissez `LogFormat` sur `JSON` ou `Text`. L’exemple de commande suivant crée une fonction Node.js qui génère des journaux au format JSON structuré.
Si vous ne spécifiez pas de format de journal lorsque vous créez une fonction, Lambda utilisera le format de journal par défaut pour la version d’exécution que vous sélectionnez. Pour plus d’informations sur les formats de journalisation par défaut, consultez [Formats de journal par défaut](#monitoring-cloudwatchlogs-format-default).
```
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 LogFormat=JSON
```
# Filtrage au niveau du journal
Lambda peut filtrer les journaux de votre fonction afin que seuls les journaux d'un certain niveau de détail ou inférieur soient envoyés à CloudWatch Logs. Vous pouvez configurer le filtrage au niveau des journaux séparément pour les journaux système de votre fonction (les journaux générés par Lambda) et les journaux des applications (les journaux générés par le code de votre fonction).
Pour [Temps d’exécution et méthodes de journalisation pris en charge](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-logformat-supported), vous n’avez pas besoin d’apporter de modifications au code de votre fonction pour que Lambda filtre les journaux d’application de votre fonction.
Pour tous les autres environnements d’exécution et méthodes de journalisation, le code de votre fonction doit générer les événements de journal vers `stdout` ou `stderr` sous forme d’objets au format JSON contenant une paire clé-valeur avec la clé `"level"`. Par exemple, Lambda interprète la sortie suivante vers `stdout` comme un journal de niveau DEBUG.
```
print('{"level": "debug", "msg": "my debug log", "timestamp": "2024-11-02T16:51:31.587199Z"}')
```
Si le champ de valeur `"level"` n’est pas valide ou est manquant, Lambda attribuera à la sortie du journal le niveau INFO. Pour que Lambda utilise le champ d'horodatage, vous devez spécifier le temps dans un format d'horodatage [RFC 3339](https://www.ietf.org/rfc/rfc3339.txt) valide. Si vous ne fournissez pas d’horodatage valide, Lambda attribuera au journal le niveau INFO et ajoutera un horodatage pour vous.
Lorsque vous nommez la clé d’horodatage, suivez les conventions du moteur d’exécution que vous utilisez. Lambda prend en charge les conventions de dénomination les plus courantes utilisées par les environnements d'exécution gérés.
**Note**
Pour utiliser le filtrage au niveau du journal, votre fonction doit être configurée pour utiliser le format de journal JSON. Le format de journal par défaut pour tous les environnements d’exécution Lambda est actuellement le texte brut. Pour savoir comment configurer le format de journal de votre fonction sur JSON, consultez [Configuration du format du journal de votre fonction](monitoring-cloudwatchlogs-logformat.md#monitoring-cloudwatchlogs-set-format).
Pour les journaux d’applications (les journaux générés par votre code de fonction), vous pouvez choisir entre les niveaux de journalisation suivants.
| Niveau de journalisation | Utilisation standard |
| --- | --- |
| TRACE (le plus détaillé) | Les informations les plus précises utilisées pour tracer le chemin d’exécution de votre code |
| DEBUG | Informations détaillées pour le débogage du système |
| INFO | Messages qui enregistrent le fonctionnement normal de votre fonction |
| WARN | Messages relatifs à des erreurs potentielles susceptibles d’entraîner un comportement inattendu si elles ne sont pas traitées |
| ERROR | Messages concernant les problèmes qui empêchent le code de fonctionner comme prévu |
| FATAL (moindre détail) | Messages relatifs à des erreurs graves entraînant l’arrêt du fonctionnement de l’application |
Lorsque vous sélectionnez un niveau de journal, Lambda envoie les journaux à ce niveau et aux niveaux inférieurs à CloudWatch Logs. Par exemple, si vous définissez le niveau de journal d’application d’une fonction sur WARN, Lambda n’envoie pas de sorties de journal aux niveaux INFO et DEBUG. Le niveau de journal d’application par défaut pour le filtrage des journaux est INFO.
Lorsque Lambda filtre les journaux d’application de votre fonction, les messages de journal sans niveau se voient attribuer le niveau de journal INFO.
Pour les journaux système (les journaux générés par le service Lambda), vous pouvez choisir entre les niveaux de journalisation suivants.
| Niveau de journalisation | Usage |
| --- | --- |
| DEBUG (le plus détaillé) | Informations détaillées pour le débogage du système |
| INFO | Messages qui enregistrent le fonctionnement normal de votre fonction |
| WARN (moindre détail) | Messages relatifs à des erreurs potentielles susceptibles d’entraîner un comportement inattendu si elles ne sont pas traitées |
Lorsque vous sélectionnez un niveau de journal, Lambda envoie des journaux à ce niveau ou à un niveau inférieur. Par exemple, si vous définissez le niveau de journal système d’une fonction sur INFO, Lambda n’envoie pas de sorties de journal au niveau DEBUG.
Par défaut, Lambda définit le niveau de journalisation du système sur INFO. Avec ce paramètre, Lambda envoie `"start"` et `"report"` enregistre automatiquement des messages à. CloudWatch Pour recevoir des journaux système plus ou moins détaillés, définissez le niveau de journal sur DEBUG ou WARN. Pour consulter la liste des niveaux de journalisation auxquels Lambda mappe les différents événements du journal système, consultez. [Mappage des événements au niveau du journal système](#monitoring-cloudwatchlogs-log-level-mapping)
## Configuration du filtrage au niveau du journal
Pour configurer le filtrage au niveau du journal des applications et du système pour votre fonction, vous pouvez utiliser la console Lambda ou le (). AWS Command Line Interface AWS CLI Vous pouvez également configurer le niveau de journalisation d'une fonction à 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, de la [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)ressource AWS Serverless Application Model (AWS SAM) et de la CloudFormation [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)ressource.
Notez que si vous définissez le niveau de journalisation de votre fonction dans votre code, ce paramètre a priorité sur tous les autres paramètres de journalisation que vous configurez. Par exemple, si vous utilisez la méthode Python `logging` `setLevel()` pour définir le niveau de journalisation de votre fonction sur INFO, ce paramètre a priorité sur le paramètre WARN que vous configurez à l'aide de la console Lambda.
**Pour configurer le niveau de journal de l’application ou du système d’une fonction existante (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. Sous **Contenu du journal**, pour le **format du journal**, assurez-vous que **JSON** est sélectionné.
1. À l’aide des boutons d’option, sélectionnez le **niveau de journal des applications** et le **niveau de journal du système** souhaités pour votre fonction.
1. Choisissez **Enregistrer**.
**Pour configurer le niveau de journal de l’application ou du système d’une fonction existante (AWS CLI)**
+ Pour modifier le niveau du journal de l’application ou du système d’une fonction existante, utilisez la commande [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html). Utilisez `--logging-config` pour définir `SystemLogLevel` sur l’une des valeurs suivantes : `DEBUG`, `INFO` ou `WARN`. Défini `ApplicationLogLevel` sur l’une des valeurs `DEBUG`, `INFO`, `WARN`, `ERROR` ou `FATAL`.
```
aws lambda update-function-configuration \
--function-name myFunction \
--logging-config LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
**Pour configurer le filtrage au niveau du journal lorsque vous créez une fonction**
+ Pour configurer le filtrage au niveau du journal lorsque vous créez une fonction, utilisez l’option `--logging-config` pour définir les clés `SystemLogLevel` et `ApplicationLogLevel` de la commande [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html). A défini `SystemLogLevel` sur l’une des valeurs `DEBUG`, `INFO` ou `WARN`. Défini `ApplicationLogLevel` sur l’une des valeurs `DEBUG`, `INFO`, `WARN`, `ERROR` ou `FATAL`.
```
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 LogFormat=JSON,ApplicationLogLevel=ERROR,SystemLogLevel=WARN
```
## Mappage des événements au niveau du journal système
Pour les événements de journal au niveau du système générés par Lambda, le tableau suivant définit le niveau de journal attribué à chaque événement. Pour plus d’informations sur les événements répertoriés dans le tableau, consultez [Référence du schéma `Event` de l’API de télémétrie Lambda](telemetry-schema-reference.md)
| Nom de l’événement | Condition | Niveau de journalisation attribué |
| --- | --- | --- |
| initStart | runtimeVersion est définie | INFO |
| initStart | runtimeVersion est définie | DEBUG |
| initRuntimeDone | status=success | DEBUG |
| initRuntimeDone | status\$1=success | WARN |
| initReport | initializationType\$1=on-demand | INFO |
| initReport | initializationType=on-demand | DEBUG |
| initReport | status\$1=success | WARN |
| restoreStart | runtimeVersion est définie | INFO |
| restoreStart | runtimeVersion n’est pas définie | DEBUG |
| restoreRuntimeDone | status=success | DEBUG |
| restoreRuntimeDone | status\$1=success | WARN |
| restoreReport | status=success | INFO |
| restoreReport | status\$1=success | WARN |
| démarrer | - | INFO |
| runtimeDone | status=success | DEBUG |
| runtimeDone | status\$1=success | WARN |
| report | status=success | INFO |
| report | status\$1=success | WARN |
| Extension | status=success | INFO |
| Extension | status=success | WARN |
| LogSubscription | - | INFO |
| telemetrySubscription | - | INFO |
| logsDropped | - | WARN |
**Note**
L’API [Accès aux données de télémétrie en temps réel pour les extensions à l’aide de l’API de télémétrie](telemetry-api.md) toujours l’ensemble complet des événements de la plateforme. La configuration du niveau des journaux système auxquels Lambda envoie des messages CloudWatch n'affecte pas le comportement de l'API de télémétrie Lambda.
## Filtrage au niveau du journal des applications avec des environnements d’exécution personnalisés
Lorsque vous configurez le filtrage au niveau du journal des applications pour votre fonction, Lambda définit en arrière-plan le niveau du journal des applications au moment de l’exécution à l’aide de la variable d’environnement `AWS_LAMBDA_LOG_LEVEL`. Lambda définit également le format du journal de votre fonction à l’aide de la variable d’environnement `AWS_LAMBDA_LOG_FORMAT`. Vous pouvez utiliser ces variables pour intégrer les commandes de journalisation avancées de Lambda dans un [environnement d’exécution personnalisé](runtimes-custom.md).
Pour pouvoir configurer les paramètres de journalisation d'une fonction à l'aide d'un environnement d'exécution personnalisé avec la console Lambda et Lambda AWS CLI APIs, configurez votre environnement d'exécution personnalisé pour vérifier la valeur de ces variables d'environnement. Vous pouvez ensuite configurer les enregistreurs de votre environnement d’exécution conformément au format de journal et aux niveaux de journal que vous avez sélectionnés.
# 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)
# Envoi de journaux de fonction Lambda à Firehose
La console Lambda offre désormais la possibilité d’envoyer des journaux de fonction à Firehose. Cela permet de diffuser en temps réel vos journaux vers diverses destinations prises en charge par Firehose, notamment des outils d’analytique tiers et des points de terminaison personnalisés.
**Note**
Vous pouvez configurer les journaux de fonction Lambda à envoyer à Firehose à l’aide de la console Lambda, AWS CLI, AWS CloudFormation et de tous les SDK AWS.
## Tarification
Pour plus d’informations de tarification, consultez [Tarification d’Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Autorisations requises pour la destination du journal Firehose
Lorsque vous utilisez la console Lambda pour configurer Firehose comme destination de journal de votre fonction, vous devez :
1. Avoir les [autorisations IAM requises](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) pour utiliser CloudWatch Logs avec Lambda.
1. [Configurer des filtres d’abonnement avec Firehose](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/SubscriptionFilters.html#FirehoseExample). Ce filtre définit quels événements de journal sont fournis à votre flux Firehose.
## Envoi de journaux de fonction Lambda à Firehose
Dans la console Lambda, vous pouvez envoyer des journaux de fonction directement à Firehose après avoir créé une nouvelle fonction. Pour ce faire, effectuez ces étapes :
1. Connectez-vous à Gestion de la console AWS et ouvrez la console Lambda.
1. Choisissez le nom de votre fonction.
1. Cliquez sur l’onglet **Configuration**.
1. Choisissez l’onglet **Outils de surveillance et d’exploitation**.
1. Dans le volet « Configuration de la journalisation », choisissez **Modifier**.
1. Dans la section « Contenu du journal », sélectionnez un format de journal.
1. Dans la section « Destination du journal » procédez comme suit :
1. Sélectionnez un service de destination.
1. Choisissez **Créer un nouveau groupe de journaux** ou utilisez un **Groupe de journaux existant**.
**Note**
Si vous choisissez un groupe de journaux existant pour une destination Firehose, assurez-vous que le groupe de journaux que vous choisissez est un type de groupe de journaux `Delivery`.
1. Choisissez un flux Firehose.
1. Le groupe de journaux `Delivery` CloudWatch s’affichera.
1. Choisissez **Enregistrer**.
**Note**
Si le rôle IAM fourni dans la console ne dispose pas de l’autorisation requise, la configuration de la destination échouera. Pour résoudre ce problème, reportez-vous à Autorisations requises pour la destination du journal Firehose afin de fournir les autorisations requises.
## Journalisation entre comptes
Vous pouvez configurer Lambda pour envoyer des journaux au flux de diffusion Firehose via un autre compte AWS. Cela nécessite de définir une destination et de configurer les autorisations appropriées dans les deux comptes.
Pour obtenir des instructions détaillées sur la configuration de la journalisation entre comptes, y compris les rôles et politiques IAM requis, consultez [Configuration d’un nouvel abonnement entre comptes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) dans la documentation CloudWatch Logs.
# Envoi des journaux de fonction Lambda à Amazon S3
Vous pouvez configurer votre fonction Lambda pour envoyer des journaux directement à Amazon S3 à l’aide de la console Lambda. Cette fonctionnalité fournit une solution rentable pour le stockage des journaux à long terme et permet d’utiliser de puissantes options d’analyse à l’aide de services comme Athena.
**Note**
Vous pouvez configurer les journaux de fonction Lambda à envoyer à Amazon S3 à l’aide de la console Lambda, AWS CLI, AWS CloudFormation et de tous les SDK AWS.
## Tarification
Pour plus d’informations de tarification, consultez [Tarification d’Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/#Vended_Logs).
## Autorisations requises pour la destination du journal Amazon S3
Lorsque vous utilisez la console Lambda pour configurer Amazon S3 comme destination de journal de votre fonction, vous devez :
1. Avoir les [autorisations IAM requises](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-prereqs) pour utiliser CloudWatch Logs avec Lambda.
1. Pour [Configurer un filtre d’abonnements CloudWatch Logs pour envoyer les journaux de fonction Lambda à Amazon S3](#using-cwl-subscription-filter-lambda-s3). Ce filtre définit quels événements de journal sont fournis à votre compartiment Amazon S3.
## Configurer un filtre d’abonnements CloudWatch Logs pour envoyer les journaux de fonction Lambda à Amazon S3
Pour envoyer des journaux depuis CloudWatch Logs vers Amazon S3, vous devez créer un filtre d’abonnement. Ce filtre définit quels événements de journal sont fournis à votre compartiment Amazon S3. Le groupe de journaux doit se trouver dans la même région que votre compartiment Amazon S3.
### Pour créer un filtre d’abonnements pour Amazon S3
1. Créez un compartiment Amazon Simple Storage Service (Amazon S3). Nous vous recommandons d'utiliser un compartiment qui a été créé spécifiquement pour CloudWatch Logs. Toutefois, si vous souhaitez utiliser un compartiment existant, passez directement à l'étape 2.
Exécutez la commande suivante en remplaçant l'espace réservé à la région par la région que vous voulez utiliser :
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
**Note**
`amzn-s3-demo-bucket2` est un exemple de nom de compartiment Amazon S3. Il est *réservé*. Pour que cette procédure fonctionne, vous devez le remplacer par le nom unique de votre compartiment Amazon S3.
Voici un exemple de sortie :
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Créez le rôle IAM qui accorde à CloudWatch Logs l’autorisation de placer des données dans votre compartiment Amazon S3. Cette politique comprend une clé de contexte de condition aws:SourceArn globale pour aider à prévenir le problème de sécurité du député confus. Pour plus d’informations consultez [Prévention du problème de l’adjoint confus](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Subscriptions-confused-deputy.html).
1. Utilisez un éditeur de texte pour créer une politique d’approbation dans un fichier `~/TrustPolicyForCWL.json` comme suit :
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
},
"Action": "sts:AssumeRole"
}
}
```
1. Utilisez la commande create-role pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Notez la valeur retournée de Role.Arn, car vous en aurez besoin ultérieurement :
```
aws iam create-role \
--role-name CWLtoS3Role \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoS3Role"
}
}
```
1. Créez une politique d'autorisations pour définir les actions permises à CloudWatch Logs sur votre compte. D'abord, utilisez un éditeur de texte pour créer une stratégie d'autorisations dans un fichier `~/PermissionsForCWL.json`:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": ["arn:aws:s3:::amzn-s3-demo-bucket2/*"]
}
]
}
```
Associez la politique d’autorisations au rôle à la commande `put-role-policy` suivante :
```
aws iam put-role-policy --role-name CWLtoS3Role --policy-name Permissions-Policy-For-S3 --policy-document file://~/PermissionsForCWL.json
```
1. Créez un groupe de journaux `Delivery` ou utilisez un groupe de journaux `Delivery` existant.
```
aws logs create-log-group --log-group-name my-logs --log-group-class DELIVERY --region REGION_NAME
```
1. `PutSubscriptionFilter` pour configurer la destination
```
aws logs put-subscription-filter
--log-group-name my-logs
--filter-name my-lambda-delivery
--filter-pattern ""
--destination-arn arn:aws:s3:::amzn-s3-demo-bucket2
--role-arn arn:aws:iam::123456789012:role/CWLtoS3Role
--region REGION_NAME
```
## Envoi de journaux de fonction Lambda à Amazon S3
Dans la console Lambda, vous pouvez envoyer des journaux de fonction directement à Amazon S3 après avoir créé une nouvelle fonction. Pour ce faire, effectuez ces étapes :
1. Connectez-vous à Gestion de la console AWS et ouvrez la console Lambda.
1. Choisissez le nom de votre fonction.
1. Cliquez sur l’onglet **Configuration**.
1. Choisissez l’onglet **Outils de surveillance et d’exploitation**.
1. Dans le volet « Configuration de la journalisation », choisissez **Modifier**.
1. Dans la section « Contenu du journal », sélectionnez un format de journal.
1. Dans la section « Destination du journal » procédez comme suit :
1. Sélectionnez un service de destination.
1. Choisissez **Créer un nouveau groupe de journaux** ou utilisez un **Groupe de journaux existant**.
**Note**
Si vous choisissez un groupe de journaux existant pour une destination Amazon S3, assurez-vous que le groupe de journaux que vous choisissez est un type de groupe de journaux `Delivery`.
1. Choisissez un compartiment Amazon S3 comme destination pour vos journaux de fonction.
1. Le groupe de journaux `Delivery` CloudWatch s’affichera.
1. Choisissez **Enregistrer**.
**Note**
Si le rôle IAM fourni dans la console ne dispose pas des autorisations requises, la configuration de la destination échouera. Pour résoudre ce problème, reportez-vous à la section [Autorisations requises pour la destination du journal Amazon S3](#logging-s3-permissions).
## Journalisation entre comptes
Vous pouvez configurer Lambda pour envoyer des journaux vers un compartiment Amazon S3 dans un autre compte AWS. Cela nécessite de définir une destination et de configurer les autorisations appropriées dans les deux comptes.
Pour obtenir des instructions détaillées sur la configuration de la journalisation entre comptes, y compris les rôles et politiques IAM requis, consultez [Configuration d’un nouvel abonnement entre comptes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html) dans la documentation CloudWatch Logs.
# Journalisation des appels AWS Lambda d'API à l'aide AWS CloudTrail
AWS Lambda est intégré à [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)un service qui fournit un enregistrement des actions entreprises par un utilisateur, un rôle ou un Service AWS. CloudTrail capture les appels d'API pour Lambda sous forme d'événements. Les appels capturés incluent des appels de la console Lambda et les appels de code vers les opérations d’API Lambda. À l'aide des informations collectées par CloudTrail, vous pouvez déterminer la demande qui a été faite à Lambda, l'adresse IP à partir de laquelle la demande a été faite, la date à laquelle elle a été faite et des informations supplémentaires.
Chaque événement ou entrée de journal contient des informations sur la personne ayant initié la demande. Les informations relatives à l’identité permettent de déterminer :
+ Si la demande a été effectuée avec des informations d’identification d’utilisateur root ou d’utilisateur root.
+ Si la demande a été faite au nom d'un utilisateur du centre d'identité IAM.
+ Si la demande a été effectuée avec les informations d’identification de sécurité temporaires d’un rôle ou d’un utilisateur fédéré.
+ Si la requête a été effectuée par un autre Service AWS.
CloudTrail est actif dans votre compte Compte AWS lorsque vous créez le compte et vous avez automatiquement accès à l'**historique des CloudTrail événements**. L'**historique des CloudTrail événements** fournit un enregistrement consultable, consultable, téléchargeable et immuable des 90 derniers jours des événements de gestion enregistrés dans un. Région AWS Pour plus d'informations, consultez la section [Utilisation de l'historique des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html) dans le *guide de AWS CloudTrail l'utilisateur*. La consultation de CloudTrail l'**historique des événements est gratuite**.
Pour un enregistrement continu des événements de vos 90 Compte AWS derniers jours, créez un magasin de données sur les événements de Trail ou [CloudTrailLake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html).
**CloudTrail sentiers**
Un *suivi* permet CloudTrail de fournir des fichiers journaux à un compartiment Amazon S3. Tous les sentiers créés à l'aide du AWS Management Console sont multirégionaux. Vous ne pouvez créer un journal de suivi en une ou plusieurs régions à l'aide de l' AWS CLI. Il est recommandé de créer un parcours multirégional, car vous capturez l'activité dans l'ensemble Régions AWS de votre compte. Si vous créez un journal de suivi pour une seule région, il convient de n'afficher que les événements enregistrés dans le journal de suivi pour une seule région Région AWS. Pour plus d'informations sur les journaux de suivi, consultez [Créez un journal de suivi dans vos Compte AWS](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) et [Création d'un journal de suivi pour une organisation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html) dans le *AWS CloudTrail Guide de l'utilisateur*.
Vous pouvez envoyer une copie de vos événements de gestion en cours dans votre compartiment Amazon S3 gratuitement CloudTrail en créant un journal. Toutefois, des frais de stockage Amazon S3 sont facturés. Pour plus d'informations sur la CloudTrail tarification, consultez la section [AWS CloudTrail Tarification](https://aws.amazon.com/cloudtrail/pricing/). Pour obtenir des informations sur la tarification Amazon S3, consultez [Tarification Amazon S3](https://aws.amazon.com/s3/pricing/).
**CloudTrail Stockages de données sur les événements du lac**
*CloudTrail Lake* vous permet d'exécuter des requêtes SQL sur vos événements. CloudTrail Lake convertit les événements existants au format JSON basé sur les lignes au format [Apache ORC](https://orc.apache.org/). ORC est un format de stockage en colonnes qui est optimisé pour une récupération rapide des données. Les événements sont agrégés dans des *magasins de données d’événement*. Ceux-ci constituent des collections immuables d’événements basées sur des critères que vous sélectionnez en appliquant des [sélecteurs d’événements avancés](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors). Les sélecteurs que vous appliquez à un magasin de données d’événement contrôlent les événements qui persistent et que vous pouvez interroger. Pour plus d'informations sur CloudTrail Lake, consultez la section [Travailler avec AWS CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) dans le *guide de AWS CloudTrail l'utilisateur*.
CloudTrail Les stockages et requêtes de données sur les événements de Lake entraînent des coûts. Lorsque vous créez un magasin de données d’événement, vous choisissez l’[option de tarification](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option) que vous voulez utiliser pour le magasin de données d’événement. L’option de tarification détermine le coût d’ingestion et de stockage des événements, ainsi que les périodes de conservation par défaut et maximale pour le magasin de données d’événement. Pour plus d'informations sur la CloudTrail tarification, consultez la section [AWS CloudTrail Tarification](https://aws.amazon.com/cloudtrail/pricing/).
## Événements relatifs aux données Lambda dans CloudTrail
Les [événements de données](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events) fournissent des informations sur les opérations de ressources effectuées sur ou dans une ressource (par exemple, lecture ou écriture de données dans un objet Amazon S3). Ils sont également connus sous le nom opérations de plans de données. Les événements de données sont souvent des activités à fort volume. Par défaut, CloudTrail n'enregistre pas la plupart des événements liés aux données et l'**historique des CloudTrail événements** ne les enregistre pas.
Un événement de CloudTrail données enregistré par défaut pour les services pris en charge est`LambdaESMDisabled`. Pour en savoir plus sur l’utilisation de cet événement afin de résoudre les problèmes liés aux mappages des sources d’événements Lambda, consultez [Utilisation CloudTrail pour résoudre les problèmes liés aux sources d'événements Lambda désactivées](#cloudtrail-ESM-troubleshooting).
Des frais supplémentaires s’appliquent pour les événements de données. Pour plus d'informations sur la CloudTrail tarification, consultez la section [AWS CloudTrail Tarification](https://aws.amazon.com/cloudtrail/pricing/).
Vous pouvez enregistrer les événements de données pour le type de `AWS::Lambda::Function` ressource à l'aide de la CloudTrail console ou AWS CLI des opérations de CloudTrail l'API. Pour plus d’informations sur la façon de journaliser les événements de données, consultez [Journalisation des événements de données avec la AWS Management Console](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) et [Journalisation des événements de données avec l’ AWS Command Line Interface](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI) dans le *Guide de l’utilisateur AWS CloudTrail *.
Le tableau suivant répertorie les types de ressources Lambda pour lesquels vous pouvez journaliser les événements de données. La colonne **Type d'événement de données (console)** indique la valeur à choisir dans la liste des **types d'événements de données** de la CloudTrail console. La colonne de valeur **resources.type indique la `resources.type` valeur** que vous devez spécifier lors de la configuration de sélecteurs d'événements avancés à l'aide du ou. AWS CLI CloudTrail APIs La CloudTrail colonne **Données APIs enregistrées** indique les appels d'API enregistrés CloudTrail pour le type de ressource.
| Type d’événement de données (console) | valeur resources.type | Données APIs enregistrées sur CloudTrail |
| --- | --- | --- |
| Lambda | AWS::Lambda::Function | [Invoke](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html) |
Vous pouvez configurer des sélecteurs d’événements avancés pour filtrer les champs `eventName`, `readOnly` et `resources.ARN` afin de ne journaliser que les événements importants pour vous. L’exemple suivant est la vue JSON d’une configuration d’événements de données qui journalise les événements pour une fonction spécifique uniquement. Pour plus d’informations sur ces champs, consultez [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) dans la *Référence des API AWS CloudTrail *.
```
[
{
"name": "function-invokes",
"fieldSelectors": [
{
"field": "eventCategory",
"equals": [
"Data"
]
},
{
"field": "resources.type",
"equals": [
"AWS::Lambda::Function"
]
},
{
"field": "resources.ARN",
"equals": [
"arn:aws:lambda:us-east-1:111122223333:function:hello-world"
]
}
]
}
]
```
## Événements de gestion Lambda dans CloudTrail
[Les événements de gestion](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events) fournissent des informations sur les opérations de gestion effectuées sur les ressources de votre Compte AWS. Ils sont également connus sous le nom opérations de plan de contrôle. Par défaut, CloudTrail enregistre les événements de gestion.
Lambda prend en charge la journalisation des actions suivantes sous forme d'événements de gestion dans des fichiers CloudTrail journaux.
**Note**
Dans le fichier CloudTrail journal, ils `eventName` peuvent inclure des informations de date et de version, mais cela fait toujours référence à la même action d'API publique. Par exemple, l’action `GetFunction` apparaît sous la forme de `GetFunction20150331v2`. La liste suivante indique les cas où le nom de l’événement diffère du nom de l’action d’API.
+ [AddLayerVersionPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddLayerVersionPermission.html)
+ [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)(nom de l'événement :`AddPermission20150331v2`)
+ [CreateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_CreateAlias.html)(nom de l'événement :`CreateAlias20150331`)
+ [CreateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_CreateEventSourceMapping.html)(nom de l'événement :`CreateEventSourceMapping20150331`)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)(nom de l'événement :`CreateFunction20150331`)
(Les paramètres `Environment` et `ZipFile` ne figurent pas dans les journaux CloudTrail pour `CreateFunction`.)
+ [CreateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunctionUrlConfig.html)
+ [DeleteAlias](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteAlias.html)(nom de l'événement :`DeleteAlias20150331`)
+ [DeleteCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteCodeSigningConfig.html)
+ [DeleteEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteEventSourceMapping.html)(nom de l'événement :`DeleteEventSourceMapping20150331`)
+ [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)(nom de l'événement :`DeleteFunction20150331`)
+ [DeleteFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionConcurrency.html)(nom de l'événement :`DeleteFunctionConcurrency20171031`)
+ [DeleteFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunctionUrlConfig.html)
+ [DeleteProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteProvisionedConcurrencyConfig.html)
+ [GetAlias](https://docs.aws.amazon.com/lambda/latest/api/API_GetAlias.html)(nom de l'événement :`GetAlias20150331`)
+ [GetEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_GetEventSourceMapping.html)
+ [GetFunction](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunction.html)
+ [GetFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionUrlConfig.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [GetLayerVersionPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetLayerVersionPolicy.html)
+ [GetPolicy](https://docs.aws.amazon.com/lambda/latest/api/API_GetPolicy.html)
+ [ListEventSourceMappings](https://docs.aws.amazon.com/lambda/latest/api/API_ListEventSourceMappings.html)
+ [ListFunctions](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctions.html)
+ [ListFunctionUrlConfigs](https://docs.aws.amazon.com/lambda/latest/api/API_ListFunctionUrlConfigs.html)
+ [PublishLayerVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishLayerVersion.html)(nom de l'événement :`PublishLayerVersion20181031`)
(Le `ZipFile` paramètre est omis dans les CloudTrail journaux de`PublishLayerVersion`.)
+ [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)(nom de l'événement :`PublishVersion20150331`)
+ [PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)(nom de l'événement :`PutFunctionConcurrency20171031`)
+ [PutFunctionCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionCodeSigningConfig.html)
+ [PutFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionEventInvokeConfig.html)
+ [PutProvisionedConcurrencyConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutProvisionedConcurrencyConfig.html)
+ [PutRuntimeManagementConfig](https://docs.aws.amazon.com/lambda/latest/api/API_PutRuntimeManagementConfig.html)
+ [RemovePermission](https://docs.aws.amazon.com/lambda/latest/api/API_RemovePermission.html)(nom de l'événement :`RemovePermission20150331v2`)
+ [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html)(nom de l'événement :`TagResource20170331v2`)
+ [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html)(nom de l'événement :`UntagResource20170331v2`)
+ [UpdateAlias](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateAlias.html)(nom de l'événement :`UpdateAlias20150331`)
+ [UpdateCodeSigningConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateCodeSigningConfig.html)
+ [UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)(nom de l'événement :`UpdateEventSourceMapping20150331`)
+ [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html)(nom de l'événement :`UpdateFunctionCode20150331v2`)
(Le `ZipFile` paramètre est omis dans les CloudTrail journaux de`UpdateFunctionCode`.)
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)(nom de l'événement :`UpdateFunctionConfiguration20150331v2`)
(Le `Environment` paramètre est omis dans les CloudTrail journaux de`UpdateFunctionConfiguration`.)
+ [UpdateFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionEventInvokeConfig.html)
+ [UpdateFunctionUrlConfig](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionUrlConfig.html)
## Utilisation CloudTrail pour résoudre les problèmes liés aux sources d'événements Lambda désactivées
Lorsque vous modifiez l'état du mappage d'une source d'événement à l'aide de l'action d'[UpdateEventSourceMapping](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateEventSourceMapping.html)API, l'appel d'API est enregistré en tant qu'événement de gestion CloudTrail. Les mappages de sources d’événements peuvent également passer directement à l’état `Disabled` en raison d’erreurs.
Pour les services suivants, Lambda publie l'événement de `LambdaESMDisabled` données CloudTrail lorsque votre source d'événements passe à l'état Désactivé :
+ Amazon Simple Queue Service (Amazon SQS)
+ Amazon DynamoDB
+ Amazon Kinesis
Lambda ne prend en charge cet événement pour aucun autre type de mappage des sources d’événements.
Pour recevoir des alertes lorsque les mappages de sources d'événements pour les services pris en charge passent à l'`Disabled`état, configurez une alarme dans Amazon à CloudWatch l'aide de l'`LambdaESMDisabled` CloudTrail événement. Pour en savoir plus sur la configuration d'une CloudWatch alarme, voir [Création d' CloudWatch alarmes pour CloudTrail des événements : exemples](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudwatch-alarms-for-cloudtrail.html).
L’entité `serviceEventDetails` figurant dans le message d’événement `LambdaESMDisabled` contient l’un des codes d’erreur suivants.
**`RESOURCE_NOT_FOUND`**
La ressource spécifiée dans la demande n’existe pas.
**`FUNCTION_NOT_FOUND`**
La fonction attachée à la source d’événement n’existe pas.
**`REGION_NAME_NOT_VALID`**
Un nom de région fourni à la source ou à la fonction d’événement n’est pas valide.
**`AUTHORIZATION_ERROR`**
Les autorisations n’ont pas été définies ou sont mal configurées.
**`FUNCTION_IN_FAILED_STATE`**
Le code de fonction ne compile pas, a rencontré une exception irrécupérable ou un mauvais déploiement s’est produit.
## Exemples d’événements Lambda
Un événement représente une demande unique provenant de n'importe quelle source et inclut des informations sur l'opération d'API demandée, la date et l'heure de l'opération, les paramètres de la demande, etc. CloudTrail les fichiers journaux ne constituent pas une trace ordonnée des appels d'API publics. Les événements n'apparaissent donc pas dans un ordre spécifique.
L'exemple suivant montre les entrées du CloudTrail journal pour les `DeleteFunction` actions `GetFunction` et.
**Note**
`eventName` peut inclure des informations de date et de version, comme `"GetFunction20150331"`, mais il s’agit toujours de la même API publique.
```
{
"Records": [
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:03:36Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "GetFunction",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::111122223333:user/myUserName is not authorized to perform: lambda:GetFunction on resource: arn:aws:lambda:us-west-2:111122223333:function:other-acct-function",
"requestParameters": null,
"responseElements": null,
"requestID": "7aebcd0f-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "e92a3e85-8ecd-4d23-8074-843aabfe89bf",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
},
{
"eventVersion": "1.03",
"userIdentity": {
"type": "IAMUser",
"principalId": "A1B2C3D4E5F6G7EXAMPLE",
"arn": "arn:aws:iam::111122223333:user/myUserName",
"accountId": "111122223333",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "myUserName"
},
"eventTime": "2015-03-18T19:04:42Z",
"eventSource": "lambda.amazonaws.com",
"eventName": "DeleteFunction20150331",
"awsRegion": "us-east-1",
"sourceIPAddress": "127.0.0.1",
"userAgent": "Python-httplib2/0.8 (gzip)",
"requestParameters": {
"functionName": "basic-node-task"
},
"responseElements": null,
"requestID": "a2198ecc-cda1-11e4-aaa2-e356da31e4ff",
"eventID": "20b84ce5-730f-482e-b2b2-e8fcc87ceb22",
"eventType": "AwsApiCall",
"recipientAccountId": "111122223333"
}
]
}
```
Pour plus d'informations sur le contenu des CloudTrail enregistrements, voir [le contenu des CloudTrail enregistrements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html) dans le *Guide de AWS CloudTrail l'utilisateur*.
# Visualisez les invocations de fonctions Lambda à l'aide de AWS X-Ray
Vous pouvez l'utiliser AWS X-Ray pour visualiser les composants de votre application, identifier les goulots d'étranglement liés aux performances et résoudre les demandes ayant entraîné une erreur. Vos fonctions Lambda envoient des données de suivi à X-Ray qui les traite pour générer une cartographie de service et des résumés de suivi pouvant faire l’objet d’une recherche.
Lambda prend en charge deux modes de suivi pour X-Ray : `Active` et `PassThrough`. Grâce au suivi `Active`, Lambda crée automatiquement des segments de suivi pour les invocations de fonction et les envoie à X-Ray. Le mode `PassThrough`, quant à lui, propage simplement le contexte de suivi aux services en aval. Si vous avez activé le suivi `Active` pour votre fonction, Lambda envoie automatiquement les suivis à X-Ray pour les demandes échantillonnées. Généralement, le service en amont, par exemple Amazon API Gateway ou une application hébergée sur Amazon EC2 instrumentée avec le kit SDK X-Ray, décide si les demandes entrantes doivent être suivies, puis ajoute cette décision d’échantillonnage en tant qu’en-tête de suivi. Lambda utilise cet en-tête pour décider d’envoyer des traces ou non. Les traces provenant des producteurs de messages en amont, tels qu'Amazon SQS, sont automatiquement liées aux traces des fonctions Lambda en aval, créant ainsi une end-to-end vue de l'ensemble de l'application. Pour plus d’informations, consultez [Traçage des applications événementielles](https://docs.aws.amazon.com//xray/latest/devguide/xray-tracelinking.html) dans le *Guide du développeur AWS X-Ray *.
**Note**
Le suivi X-Ray n’est actuellement pas pris en charge pour les fonctions Lambda avec Amazon Managed Streaming for Apache Kafka (Amazon MSK), Apache Kafka autogéré, Amazon MQ avec ActiveMQ et RabbitMQ ou les mappages des sources d’événements Amazon DocumentDB.
Pour activer/désactiver le traçage actif sur votre fonction Lambda avec la console, procédez comme suit :
**Pour activer le traçage actif**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez une fonction.
1. Choisissez **Configuration**, puis choisissez **Outils de surveillance et d’opérations**.
1. Dans **Outils de surveillance supplémentaires**, choisissez **Modifier**.
1. Sous **Signaux CloudWatch d'application et AWS X-Ray** sélectionnez **Activer les traces** de **service Lambda**.
1. Choisissez **Enregistrer**.
Votre fonction a besoin d’une autorisation pour charger des données de suivi vers X-Ray. Lorsque vous activez le suivi actif dans la console Lambda, Lambda ajoute les autorisations requises au [rôle d’exécution](lambda-intro-execution-role.md) de votre fonction. Sinon, ajoutez la [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)politique au rôle d'exécution.
X-Ray ne trace pas toutes les requêtes vers votre application. X-Ray applique un algorithme d’échantillonnage pour s’assurer que le suivi est efficace, tout en fournissant un échantillon représentatif de toutes les demandes. Le taux d’échantillonnage est 1 demande par seconde et 5 % de demandes supplémentaires. Vous ne pouvez pas configurer ce taux d’échantillonnage X-Ray pour vos fonctions.
## Comprendre les suivis X-Ray
Dans X-Ray, un *suivi* enregistre des informations sur une demande traitée par un ou plusieurs *services*. Lambda enregistre deux segments par suivi, ce qui a pour effet de créer deux nœuds sur le graphique du service. L’image suivante met en évidence ces deux nœuds :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/xray-servicemap-function.png)
Le premier nœud sur la gauche représente le service Lambda qui reçoit la demande d’invocation. Le deuxième nœud représente votre fonction Lambda spécifique.
Le segment enregistré pour le service Lambda, `AWS::Lambda`, couvre toutes les étapes nécessaires à la préparation de l’environnement d’exécution Lambda. Cela inclut la planification de la MicroVM, la création ou le déblocage d’un environnement d’exécution avec les ressources que vous avez configurées, ainsi que le téléchargement de votre code de la fonction et de toutes les couches.
Le segment `AWS::Lambda::Function` concerne le travail effectué par la fonction.
**Note**
AWS met actuellement en œuvre des modifications du service Lambda. En raison de ces modifications, vous pouvez constater des différences mineures entre la structure et le contenu des messages du journal système et des segments de suivi émis par les différentes fonctions Lambda de votre Compte AWS.
Cette modification affecte les sous-segments du segment de fonction. Les paragraphes suivants décrivent les anciens et les nouveaux formats de ces sous-segments.
Ces modifications seront mises en œuvre au cours des prochaines semaines, et toutes les fonctions, Régions AWS sauf en Chine et dans les GovCloud régions, seront transférées pour utiliser le nouveau format des messages de journal et des segments de trace.
**Structure de segment AWS X-Ray Lambda à l'ancienne**
L’ancienne structure X-Ray de segment `AWS::Lambda` ressemble à ce qui suit :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/v1_XRay_structure.png)
Dans ce format, le segment de fonction comporte des sous-segments pour `Initialization`, `Invocation` et `Overhead`. Pour [Lambda SnapStart](snapstart.md) uniquement, il existe également un sous-segment `Restore` (non représenté sur ce schéma).
Le sous-segment `Initialization` représente la phase d’initialisation du cycle de vie de l’environnement d’exécution Lambda. Au cours de cette phase, Lambda initialise les extensions, initialise l’environnement d’exécution, et exécute le code d’initialisation de la fonction.
Le sous-segment `Invocation` représente la phase d’invocation où Lambda invoque le gestionnaire de fonction. Cela commence par l’enregistrement de l’exécution et de l’extension et se termine lorsque l’exécution est prête à envoyer la réponse.
[(Lambda SnapStart uniquement) Le `Restore` sous-segment indique le temps nécessaire à Lambda pour restaurer un instantané, charger le moteur d'exécution et exécuter les éventuels hooks d'exécution après la restauration.](snapstart-runtime-hooks.md) Le processus de restauration des instantanés peut inclure du temps consacré à des activités en dehors de la MicroVM. Cette heure est indiquée dans le sous-segment `Restore`. Le temps passé en dehors de la microVM pour restaurer un instantané ne vous est pas facturé.
Le sous-segment `Overhead` représente la phase qui se produit entre le moment où l’exécution envoie la réponse et le signal pour l’invocation suivante. Pendant ce temps, l’exécution termine toutes les tâches liées à une invocation et se prépare à geler l’environnement de test (sandbox).
**Important**
Vous pouvez utiliser le kit SDK X-Ray pour étendre le sous-segment `Invocation` avec des sous-segments supplémentaires pour les appels, les annotations et les métadonnées en aval. Vous ne pouvez pas accéder directement au segment de fonction ou enregistrer une tâche effectuée en dehors de la portée d’invocation du gestionnaire.
Pour plus d’informations sur les phases de l’environnement d’exécution Lambda, consultez [Comprendre le cycle de vie de l’environnement d’exécution Lambda](lambda-runtime-environment.md).
Un exemple de suivi utilisant l’ancienne structure X-Ray est illustré dans le schéma suivant.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v1.png)
Notez les deux segments de l’exemple. Les deux sont nommés **my-function**, mais l’un a pour origine `AWS::Lambda` et l’autre a pour origine `AWS::Lambda::Function`. Si le segment `AWS::Lambda` affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le segment `AWS::Lambda::Function` affiche une erreur, cela signifie que votre fonction a rencontré un problème.
**Note**
Occasionnellement, vous pouvez remarquer un grand écart entre les phases d’initialisation et d’invocation de la fonction dans vos traces X-Ray. Pour les fonctions utilisant la [simultanéité provisionnée](provisioned-concurrency.md), cela est dû au fait que Lambda initialise vos instances de fonction bien avant l’invocation. Pour les fonctions utilisant la [simultanéité non réservée (à la demande)](lambda-concurrency.md), Lambda peut initialiser de manière proactive une instance de fonction, même s’il n’y a pas d’invocation. Visuellement, ces deux cas se manifestent par un écart de temps entre les phases d’initialisation et d’invocation.
**Nouvelle structure de segment AWS X-Ray Lambda**
La nouvelle structure X-Ray de segment `AWS::Lambda` ressemble à ce qui suit :
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/v2_XRay_structure.png)
Dans ce nouveau format, le sous-segment `Init` représente la phase d’initialisation du cycle de vie de l’environnement d’exécution Lambda comme auparavant.
Le nouveau format ne contient pas de segment d’invocation. À la place, les sous-segments du client sont directement rattachés au segment `AWS::Lambda::Function`. Ce segment contient les métriques suivantes sous forme d’annotations :
+ `aws.responseLatency` : le temps nécessaire à l’exécution de la fonction
+ `aws.responseDuration` : le temps nécessaire pour transmettre la réponse au client
+ `aws.runtimeOverhead` : le temps supplémentaire dont l’exécution a eu besoin pour se terminer
+ `aws.extensionOverhead` : le temps supplémentaire dont les extensions ont eu besoin pour se terminer
Un exemple de suivi utilisant la nouvelle structure X-Ray est illustré dans le schéma suivant.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/V2_sandbox_images/my-function-2-v2.png)
Notez les deux segments de l’exemple. Les deux sont nommés **my-function**, mais l’un a pour origine `AWS::Lambda` et l’autre a pour origine `AWS::Lambda::Function`. Si le segment `AWS::Lambda` affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le segment `AWS::Lambda::Function` affiche une erreur, cela signifie que votre fonction a rencontré un problème.
Consultez les rubriques suivantes pour une présentation du suivi dans Lambda spécifique de chaque langage :
+ [Instrumentation du code Node.js dans AWS Lambda](nodejs-tracing.md)
+ [Instrumentation du code Python dans AWS Lambda](python-tracing.md)
+ [Instrumentation du code Ruby dans AWS Lambda](ruby-tracing.md)
+ [Instrumentation du code Java dans AWS Lambda](java-tracing.md)
+ [Instrumentation du code Go AWS Lambda](golang-tracing.md)
+ [Instrumentation du code C\$1 dans AWS Lambda](csharp-tracing.md)
Pour obtenir la liste complète des services qui prennent en charge l’instrumentation active, consultez [Services AWS pris en charge](https://docs.aws.amazon.com/xray/latest/devguide/xray-usage.html#xray-usage-codechanges) dans le Guide du développeur AWS X-Ray .
## Comportement de suivi par défaut dans Lambda
Si le suivi `Active` n’est pas activé, Lambda passe en mode de suivi `PassThrough` par défaut.
En mode `PassThrough`, Lambda transmet l’en-tête de suivi X-Ray aux services en aval, mais n’envoie pas de suivis automatiquement. Cela est vrai même si l’en-tête de suivi contient la décision d’échantillonner la demande. Si le service en amont ne fournit pas d’en-tête de suivi X-Ray, Lambda génère un en-tête et prend la décision de ne pas échantillonner. Cependant, vous pouvez envoyer vos propres suivis en appelant des bibliothèques de suivi à partir du code de votre fonction.
**Note**
Auparavant, Lambda envoyait automatiquement des traces lorsque des services en amont, comme Amazon API Gateway, ajoutaient un en-tête de suivi. En n’envoyant pas de traces automatiquement, Lambda vous permet de contrôler les fonctions qui sont importantes pour vous. Si votre solution repose sur ce comportement de suivi passif, passez au suivi `Active`.
## Autorisations du rôle d’exécution
Lambda a besoin des autorisations suivantes pour envoyer des données de suivi à X-Ray. Ajoutez-les au [rôle d’exécution](lambda-intro-execution-role.md) de la fonction.
+ [radiographie : PutTraceSegments](https://docs.aws.amazon.com/xray/latest/api/API_PutTraceSegments.html)
+ [radiographie : PutTelemetryRecords](https://docs.aws.amazon.com/xray/latest/api/API_PutTelemetryRecords.html)
Ces autorisations sont incluses dans la politique [AWSXRayDaemonWriteAccess](https://console.aws.amazon.com/iam/home?#/policies/arn:aws:iam::aws:policy/AWSXRayDaemonWriteAccess)gérée.
## Activation du suivi `Active` avec l’API Lambda
Pour gérer la configuration du suivi avec le AWS SDK AWS CLI ou le SDK, utilisez les opérations d'API suivantes :
+ [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)
+ [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)
+ [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)
L'exemple de AWS CLI commande suivant active le suivi actif sur une fonction nommée **my-function**.
```
aws lambda update-function-configuration --function-name my-function \
--tracing-config Mode=Active
```
Le mode de suivi fait partie de la configuration spécifique de la version lorsque vous publiez une version de votre fonction. Vous ne pouvez pas modifier le mode de suivi sur une version publiée.
## Activation du `Active` suivi avec CloudFormation
Pour activer le suivi d'une `AWS::Lambda::Function` ressource dans un CloudFormation modèle, utilisez la `TracingConfig` propriété.
**Example [function-inline.yml](https://github.com/awsdocs/aws-lambda-developer-guide/blob/master/templates/function-inline.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Lambda::Function](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html)
Properties:
TracingConfig:
Mode: Active
...
```
Pour une `AWS::Serverless::Function` ressource AWS Serverless Application Model (AWS SAM), utilisez la `Tracing` propriété.
**Example [template.yml](https://github.com/awsdocs/aws-lambda-developer-guide/tree/main/sample-apps/blank-nodejs/template.yml) – Configuration du suivi**
```
Resources:
function:
Type: [AWS::Serverless::Function](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html)
Properties:
Tracing: Active
...
```
# Surveillance des performances de fonctions avec Amazon CloudWatch Lambda Insights
Amazon CloudWatch Lambda Insights collecte et agrège les métriques et journaux de performances de runtime de fonction Lambda pour vos applications sans serveur. Cette page explique comment activer et utiliser Lambda Insights pour diagnostiquer des problèmes liés à vos fonctions Lambda.
**Topics**
+ [Comment Lambda Insights surveille les applications sans serveur](#monitoring-insights-how)
+ [Tarification](#monitoring-insights-pricing)
+ [Environnements d'exécution pris en charge](#monitoring-insights-runtimes)
+ [Activation de Lambda Insights dans la console Lambda](#monitoring-insights-enabling-console)
+ [Activation de Lambda Insights par programme](#monitoring-insights-enabling-programmatically)
+ [Utilisation du tableau de bord Lambda Insights](#monitoring-insights-multifunction)
+ [Exemple de flux de travail permettant de détecter les anomalies de fonction](#monitoring-insights-anomalies)
+ [Exemple de flux de travail utilisant des demandes pour dépanner une fonction](#monitoring-insights-queries)
+ [Quelle est la prochaine étape ?](#monitoring-console-next-up)
## Comment Lambda Insights surveille les applications sans serveur
CloudWatch Lambda Insights est une solution de surveillance et de dépannage pour les applications sans serveur s'exécutant sur AWS Lambda. La solution collecte, agrège et résume les métriques de niveau système, notamment l'utilisation de temps d'UC, de mémoire, de disque et de réseau. Elle collecte, agrège et résume également des informations de diagnostic telles que des démarrages à froid et des arrêts de rôle de travail Lambda pour vous aider à circonscrire des problèmes liés à vos fonctions Lambda, ainsi qu'à les résoudre rapidement.
Lambda Insights utilise une nouvelle [extension](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) CloudWatch Lambda Insights, fournie sous la forme d'une [couche Lambda](chapter-layers.md). Lorsque vous activez cette extension sur une fonction Lambda pour une exécution prise en charge, elle collecte des métriques au niveau du système et émet un événement du journal des performances unique pour chaque invocation de cette fonction Lambda. CloudWatch utilise une mise en forme de métrique intégrée pour extraire les métriques des événements de journal. Pour de plus amples informations, veuillez consulter la section relative à l'[utilisation des extensions AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html).
La couche Lambda Insights étend `CreateLogStream` et `PutLogEvents` pour le groupe de journaux `/aws/lambda-insights/`.
## Tarification
Lorsque vous activez Lambda Insights pour votre fonction Lambda, Lambda Insights signale 8 métriques par fonction et chaque invocation de fonction envoie environ 1 Ko de données de journal à CloudWatch. Vous payez uniquement les métriques et les journaux signalés pour votre fonction par Lambda Insights. Aucun frais minimum ni aucune politique d'utilisation obligatoire des services ne sont appliqués. Vous ne payez pas pour Lambda Insights si la fonction n'est pas appelée. Pour un exemple de tarification, consultez [Tarification Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Environnements d'exécution pris en charge
Vous pouvez utiliser Lambda Insights avec n'importe quel runtime prenant en charge les [extensions Lambda](runtimes-extensions-api.md).
## Activation de Lambda Insights dans la console Lambda
Vous pouvez activer la surveillance améliorée de Lambda Insights sur des fonctions Lambda nouvelles et existantes. Lorsque vous activez Lambda Insights sur une fonction dans la console Lambda pour un runtime pris en charge, Lambda ajoute l'[extension](https://docs.aws.amazon.com/lambda/latest/dg/lambda-extensions.html) Lambda Insights en tant que couche à votre fonction, et vérifie ou tente d'attacher la stratégie [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) au [rôle d'exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) de votre fonction.
**Pour activer Lambda Insights dans la console Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez votre fonction.
1. Choisissez l'onglet **Configuration**.
1. Dans le menu de gauche, sélectionnez **Outils de surveillance et d’exploitation**.
1. Dans le volet **Outils de surveillance supplémentaires**, choisissez **Modifier**.
1. Sous **CloudWatch Lambda Insights**, activez **Surveillance améliorée**.
1. Choisissez **Enregistrer**.
## Activation de Lambda Insights par programme
Vous pouvez également activer Lambda Insights à l'aide de l'AWS Command Line Interface (AWS CLI), de l'interface de ligne de commande AWS Serverless Application Model (SAM), d'CloudFormation ou de l'AWS Cloud Development Kit (AWS CDK). Lorsque vous activez Lambda Insights par programmation sur une fonction pour un runtime pris en charge, CloudWatch attache la stratégie [https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor](https://console.aws.amazon.com/iam/home#/policies/arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy$jsonEditor) au [rôle d'exécution](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) de votre fonction.
Pour plus d'informations, consultez [Mise en route avec Lambda Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Lambda-Insights-Getting-Started.html) dans le *Guide de l'utilisateur Amazon CloudWatch*.
## Utilisation du tableau de bord Lambda Insights
Le tableau de bord Lambda Insights a deux modes d'affichage dans la console CloudWatch : la vue d'ensemble multifonction et la vue de fonction unique. La vue d'ensemble multifonction regroupe les métriques de runtime pour les fonctions Lambda dans le compte AWS et la région actuels. La vue de fonction unique affiche les métriques de runtime disponibles pour une seule fonction Lambda.
Vous pouvez utiliser la vue d'ensemble multifonction du tableau de bord Lambda Insights dans la console CloudWatch pour identifier les fonctions Lambda sur-utilisées et sous-utilisées. Vous pouvez utiliser la vue de fonction unique du tableau de bord Lambda Insights dans la console CloudWatch pour résoudre des demandes individuelles.
**Pour afficher les métriques d'environnement d'exécution pour toutes les fonctions**
1. Ouvrez la page [Multi-function (Multifonction)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) dans la console CloudWatch.
1. Choisissez parmi les plages de temps prédéfinies ou choisissez une plage de temps personnalisée.
1. (Facultatif) Choisissez **Add to dashboard (Ajouter au tableau de bord)** pour ajouter les widgets à votre tableau de bord CloudWatch.
![\[Vue d'ensemble multifonction sur le tableau de bord Lambda Insights.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambdainsights-multifunction-view.png)
**Pour afficher les métriques d'environnement d'exécution d'une fonction unique**
1. Ouvrez la page [Single-function (Fonction unique)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions) dans la console CloudWatch.
1. Choisissez parmi les plages de temps prédéfinies ou choisissez une plage de temps personnalisée.
1. (Facultatif) Choisissez **Add to dashboard (Ajouter au tableau de bord)** pour ajouter les widgets à votre tableau de bord CloudWatch.
![\[Vue de fonction unique sur le tableau de bord Lambda.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambainsights-singlefunction-view.png)
Pour amples d'informations, consultez [Création et utilisation de widgets sur des tableaux de bord CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html).
## Exemple de flux de travail permettant de détecter les anomalies de fonction
Vous pouvez utiliser la vue d'ensemble multifonction sur le tableau de bord Lambda Insights pour identifier et détecter des anomalies de mémoire de calcul liées à votre fonction. Par exemple, si la vue d'ensemble multifonction indique qu'une fonction utilise une grande quantité de mémoire, vous pouvez afficher les métriques détaillées d'utilisation de la mémoire dans le volet **Memory Usage (Utilisation de la mémoire)**. Vous pouvez ensuite accéder au tableau de bord des métriques pour activer la détection d'anomalies ou créer une alarme.
**Pour activer la détection d'anomalies pour une fonction**
1. Ouvrez la page [Multi-function (Multifonction)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) dans la console CloudWatch.
1. Sous **Function summary (Récapitulatif de fonction)**, choisissez le nom de votre fonction.
La vue de fonction unique s'ouvre avec les métriques d'environnement d'exécution de la fonction.
![\[Volet récapitulatif de la fonction sur le tableau de bord Lambda Insights.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambdainsights-function-summary.png)
1. Dans le volet **Memory Usage (Utilisation de la mémoire)** sélectionnez les trois points verticaux, puis choisissez **View in metrics (Afficher dans les métriques)** pour ouvrir le tableau de bord **Metrics (Métriques)**.
![\[Menu sur le volet Memory Usage (Utilisation de la mémoire).\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambdainsights-memory-usage.png)
1. Dans l'onglet **Graphique des métriques**, dans la colonne **Actions**, choisissez la première icône pour activer la détection d'anomalies pour la fonction.
![\[Onglet Graphed metrics (Métriques tracées) du volet Memory Usage (Utilisation de la mémoire).\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambdainsights-graphed-metrics.png)
Pour plus d'informations, consultez [Utilisation de la détection d'anomalies CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html).
## Exemple de flux de travail utilisant des demandes pour dépanner une fonction
Vous pouvez utiliser la vue de fonction unique sur le tableau de bord Lambda Insights pour identifier la cause première d'un pic de durée de fonction. Par exemple, si la vue d'ensemble multifonction indique une augmentation importante de la durée de la fonction, vous pouvez suspendre ou choisir chaque fonction dans le volet **Durée** afin de déterminer la fonction à l'origine de l'augmentation. Vous pouvez ensuite accéder à la vue de fonction unique et consulter les **journaux d'application** pour déterminer la cause principale.
**Pour exécuter des requêtes sur une fonction**
1. Ouvrez la page [Multi-function (Multifonction)](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:performance) dans la console CloudWatch.
1. Dans le volet **Durée** choisissez votre fonction pour filtrer les métriques de durée.
![\[Fonction choisie dans le volet Duration (Durée).\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambdainsights-choose-function.png)
1. Ouvrez la page [Fonction unique](https://console.aws.amazon.com/cloudwatch/home#lambda-insights:functions).
1. Choisissez la liste déroulante **Filter metrics by function name (Filtrer les métriques par nom de fonction)**, puis choisissez votre fonction.
1. Pour afficher les **1000 journaux d'application les plus récents**, choisissez l'onglet **Application logs (Journaux d'application)**.
1. Examinez l'**horodatage** et le **message** pour identifier la demande d'invocation que vous souhaitez résoudre.
![\[Les 1 000 journaux d'application les plus récents.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambdainsights-application-logs.png)
1. Pour afficher les **Most recent 1000 invocations (1000 appels les plus récents)**, choisissez l'onglet **Appels**.
1. Sélectionnez l'**horodatage** ou le **message** pour la demande d'invocation que vous souhaitez résoudre.
![\[Sélection d'une demande d'invocation récente.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambdainsights-invocations-function-select.png)
1. Choisissez la liste déroulante **Afficher les journaux**, puis **Afficher les journaux de performance**.
Une requête générée automatiquement pour votre fonction s'ouvre dans le tableau de bord **Logs Insights**.
1. Choisissez **Exécuter la requête** pour générer un message **Journaux** pour la demande d'invocation.
![\[Interrogation de la fonction sélectionnée dans le tableau de bord Logs Insights.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/lambdainsights-query.png)
## Quelle est la prochaine étape ?
+ Découvrez comment créer un tableau de bord CloudWatch Logs dans la section [Créer un tableau de bord](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html) du *Guide de l'utilisateur Amazon CloudWatch*.
+ Découvrez comment ajouter des requêtes à un tableau de bord CloudWatch Logs dans la section [Ajouter une requête au tableau de bord ou exporter les résultats de requête](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) du *Manuel du développeur Amazon CloudWatch*.
# Surveillance des applications Lambda
La section **Applications** de la console Lambda inclut un onglet **Surveillance** dans lequel vous pouvez consulter un tableau de bord Amazon CloudWatch avec des métriques agrégées pour les ressources de votre application.
**Pour surveiller une application Lambda**
1. Ouvrez la [page Applications](https://console.aws.amazon.com/lambda/home#/applications) de la console Lambda.
1. Choisissez **Surveillance**.
1. Pour afficher plus de détails sur les métriques dans un graphique, choisissez **Afficher dans les métriques** dans le menu déroulant.
![\[Un widget de surveillance.\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/applications-monitoring-widget.png)
Le graphique s'affiche dans un nouvel onglet, avec les métriques correspondantes répertoriées sous le graphique. Vous pouvez personnaliser votre affichage de ce graphique, en modifiant les métriques et les ressources affichées, les statistiques, la période, et d'autres facteurs, afin de mieux comprendre la situation actuelle.
Par défaut, la console Lambda affiche un tableau de bord de base. Vous pouvez personnaliser cette page en ajoutant un ou plusieurs tableaux de bord Amazon CloudWatch à votre modèle d’application avec le type de ressource [AWS::CloudWatch::Dashboard](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cw-dashboard.html). Lorsque votre modèle inclut un ou plusieurs tableaux de bord, la page affiche vos tableaux de bord à la place du tableau de bord par défaut. Vous pouvez basculer entre les tableaux de bord avec le menu déroulant en haut à droite de la page. L'exemple suivant permet de créer un tableau de bord avec un seul widget qui représente graphiquement le nombre d'appels d'une fonction nommée `my-function`.
**Example modèle de tableau de bord de fonction**
```
Resources:
MyDashboard:
Type: AWS::CloudWatch::Dashboard
Properties:
DashboardName: my-dashboard
DashboardBody: |
{
"widgets": [
{
"type": "metric",
"width": 12,
"height": 6,
"properties": {
"metrics": [
[
"AWS/Lambda",
"Invocations",
"FunctionName",
"my-function",
{
"stat": "Sum",
"label": "MyFunction"
}
],
[
{
"expression": "SUM(METRICS())",
"label": "Total Invocations"
}
]
],
"region": "us-east-1",
"title": "Invocations",
"view": "timeSeries",
"stacked": false
}
}
]
}
```
Pour plus d'informations sur la création des widgets et des tableaux de bord CloudWatch, consultez [Syntaxe et structure du corps d'un tableau de bord](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html) dans la *Référence d'API Amazon CloudWatch*.
# Surveillance des performances d’applications avec la vigie applicative Amazon CloudWatch
La vigie applicative Amazon CloudWatch est une solution de surveillance des performances des applications (APM) qui permet aux développeurs et aux opérateurs de surveiller l’état et les performances de leurs applications sans serveur créées à l’aide de Lambda. Vous pouvez activer la vigie applicative en un clic depuis la console Lambda, et vous n’avez pas besoin d’ajouter de code d’instrumentation ou de dépendances externes à votre fonction Lambda. Une fois que vous avez activé la vigie applicative, vous pouvez afficher toutes les métriques et suivis collectés dans la console CloudWatch. Cette page explique comment activer et afficher les données de télémétrie de la vigie applicative pour vos applications.
**Topics**
+ [Mode d’intégration de la vigie applicative à Lambda](#monitoring-application-signals-how)
+ [Tarification](#monitoring-application-signals-pricing)
+ [Environnements d'exécution pris en charge](#monitoring-application-signals-runtimes)
+ [Activation de la vigie applicative dans la console Lambda](#monitoring-application-signals-console)
+ [Utilisation du tableau de bord de la vigie applicative](#monitoring-application-signals-dashboard)
## Mode d’intégration de la vigie applicative à Lambda
La vigie applicative instrumente automatiquement vos fonctions Lambda à l’aide des bibliothèques [AWS Distro for OpenTelemetry (ADOT)](https://aws-otel.github.io/) améliorées, fournies via une [couche Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html). La vigie applicative lit les données collectées par la couche et génère des tableaux de bord contenant des indicateurs de performance clés pour vos applications.
Vous pouvez attacher cette couche en un clic en [activant la vigie applicative](#monitoring-application-signals-console) dans la console Lambda. Lorsque vous activez la vigie applicative à partir de la console, Lambda effectue les opérations suivantes en votre nom :
+ Mise à jour du rôle d’exécution de la fonction pour inclure `CloudWatchLambdaApplicationSignalsExecutionRolePolicy`. [ Cette politique](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchLambdaApplicationSignalsExecutionRolePolicy.html) fournit un accès en écriture à AWS X-Ray et aux groupes de journaux CloudWatch utilisés pour la vigie applicative.
+ Ajout d’une couche à votre fonction qui instrument automatiquement la fonction pour capturer les données de télémétrie telles que les requêtes, la disponibilité, la latence, les erreurs et les défauts. Pour garantir le bon fonctionnement de la vigie applicative, supprimez tout code d’instrumentation du kit SDK X-Ray existant de votre fonction. Le code d’instrumentation personnalisé du kit SDK X-Ray peut interférer avec l’instrumentation fournie par la couche.
+ Ajout de la variable d’environnement `AWS_LAMBDA_EXEC_WRAPPER` à votre fonction et définition de sa valeur sur `/opt/otel-instrument`. Cette variable d’environnement modifie le comportement de démarrage de votre fonction afin d’utiliser la couche de la vigie applicative. Elle est requise pour une instrumentation appropriée. Si cette variable d’environnement existe déjà, assurez-vous qu’elle est définie sur la valeur adéquate.
## Tarification
L’utilisation de la vigie applicative pour vos fonctions Lambda entraîne des coûts. Pour de plus amples informations, consultez la [Tarification d’Amazon CloudWatch](https://aws.amazon.com/cloudwatch/pricing/).
## Environnements d'exécution pris en charge
L’intégration de la vigie applicative à Lambda fonctionne avec les environnements d’exécution suivants :
+ .NET 8
+ Java 11
+ Java 17
+ Java 21
+ Python 3.10
+ Python 3.11
+ Python 3.12
+ Python 3.13
+ Node.js 18.x
+ Node.js 20.x
+ Node.js 22.x
## Activation de la vigie applicative dans la console Lambda
Vous pouvez activer la vigie applicative sur n’importe quelle fonction Lambda existante à l’aide d’un [environnement d’exécution compatible](#monitoring-application-signals-runtimes). Les étapes suivantes expliquent comment activer la vigie applicative en un clic dans la console Lambda.
**Pour activer la vigie applicative dans la console Lambda**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez votre fonction.
1. Choisissez l'onglet **Configuration**.
1. Dans le menu de gauche, sélectionnez **Outils de surveillance et d’exploitation**.
1. Dans le volet **Outils de surveillance supplémentaires**, choisissez **Modifier**.
1. Sous **Vigie applicative CloudWatch et AWS X-Ray**, et sous **Vigie applicative**, choisissez **Activer**.
1. Choisissez **Enregistrer**.
Si c’est la première fois que vous activez la vigie applicative pour votre fonction, vous devez également effectuer une configuration unique de découverte de service pour la vigie applicative dans la console CloudWatch. Une fois que vous avez terminé cette configuration unique de découverte de service, la vigie applicative découvre automatiquement toutes les fonctions Lambda supplémentaires pour lesquelles vous activez la vigie applicative, dans toutes les régions.
**Note**
Après avoir invoqué votre fonction mise à jour, il peut s’écouler jusqu’à dix minutes avant que les données de service n’apparaissent dans le tableau de bord de la vigie applicative de la console CloudWatch.
## Utilisation du tableau de bord de la vigie applicative
Après avoir activé la vigie applicative pour votre fonction, vous pouvez visualiser les métriques de votre application dans la console CloudWatch. Vous pouvez rapidement consulter le tableau de bord de la vigie applicative associé depuis la console Lambda en procédant comme suit :
**Pour consulter le tableau de bord de la vigie applicative de votre fonction**
1. Ouvrez la [page Functions](https://console.aws.amazon.com/lambda/home#/functions) (Fonctions) de la console Lambda.
1. Choisissez votre fonction.
1. Choisissez l'onglet **Monitor** (Surveiller).
1. Cliquez sur le bouton **Afficher la vigie applicative**. Vous accédez ainsi directement à la vue d’ensemble de la vigie applicative pour votre service dans la console CloudWatch.
Par exemple, la capture d’écran suivante montre les métriques relatives à la latence, au nombre de requêtes, à la disponibilité, au taux de défaillance et au taux d’erreur pour une fonction sur une période de dix minutes.
![\[\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/monitoring-application-signals-dashboard.png)
Pour tirer le meilleur parti de votre intégration à la vigie applicative, vous pouvez créer des objectifs de niveau de service (SLO) pour votre application. Par exemple, vous pouvez créer des SLO de latence pour garantir que votre application répond rapidement aux requêtes des utilisateurs, et des SLO de disponibilité pour suivre la durée de fonctionnement. Les SLO peuvent vous aider à détecter la dégradation des performances ou les pannes avant qu’elles n’affectent vos utilisateurs. Pour plus d’informations, consultez [Service level objectives (SLOs)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html) dans le Guide de l’utilisateur Amazon CloudWatch.
# Déboguer à distance des fonctions Lambda avec Visual Studio Code
Grâce à la fonction de débogage à distance intégrée à [AWS Toolkit for Visual Studio Code](https://aws.amazon.com/visualstudiocode/), vous pouvez déboguer vos fonctions Lambda exécutées directement dans le cloud AWS. Cela est utile lorsque vous étudiez des problèmes difficiles à reproduire localement ou à diagnostiquer uniquement à l’aide de journaux.
Grâce au débogage à distance, vous pouvez :
+ Définir des points d’arrêt dans le code de votre fonction Lambda.
+ Exécuter le code étape par étape en temps réel.
+ Inspecter les variables et leur état pendant l’exécution.
+ Déboguer les fonctions Lambda déployées sur AWS, y compris celles qui se trouvent dans des VPC ou avec des autorisations IAM spécifiques.
## Environnements d'exécution pris en charge
Le débogage à distance est pris en charge pour les environnements d’exécution suivants :
+ Python (AL2023)
+ Java
+ JavaScript/Node.js (AL2023)
**Note**
Le débogage à distance est pris en charge pour les architectures x86\$164 et arm64.
## Sécurité et débogage à distance
Le débogage à distance fonctionne dans les limites de sécurité Lambda existantes. Les utilisateurs peuvent associer des couches à une fonction à l’aide de l’autorisation `UpdateFunctionConfiguration`, qui permet déjà d’accéder aux variables d’environnement et à la configuration de la fonction. Le débogage à distance ne s’étend pas au-delà de ces autorisations existantes. Il ajoute plutôt des contrôles de sécurité supplémentaires grâce à un tunneling sécurisé et à une gestion automatique des sessions. En outre, le débogage à distance est une fonctionnalité entièrement contrôlée par le client nécessitant des autorisations et des actions explicites :
+ **Création d’un tunnel sécurisé IoT** : AWS Toolkit doit créer un tunnel sécurisé IoT, ce qui n’est possible qu’avec l’autorisation explicite de l’utilisateur en utilisant `iot:OpenTunnel`.
+ **Attachement de la couche de débogage et gestion des jetons** : le processus de débogage assure la sécurité via les contrôles suivants :
+ La couche de débogage doit être attachée à la fonction Lambda, et ce processus nécessite les autorisations suivantes : `lambda:UpdateFunctionConfiguration` et `lambda:GetLayerVersion`.
+ Un jeton de sécurité (généré via `iot:OpenTunnel`) doit être mis à jour dans la variable d’environnement de la fonction avant chaque session de débogage, ce qui nécessite également `lambda:UpdateFunctionConfiguration`.
+ Pour des raisons de sécurité, ce jeton est automatiquement pivoté, et la couche de débogage est automatiquement supprimée à la fin de chaque session de débogage et ne peut pas être réutilisée.
**Note**
Le débogage à distance est pris en charge pour les architectures x86\$164 et arm64.
## Prérequis
Avant de commencer le débogage à distance, vérifiez que vous disposez des éléments suivants :
1. Une fonction Lambda déployée sur votre compte AWS.
1. AWS Toolkit for Visual Studio Code. Consultez [Configuration d’AWS Toolkit for Visual Studio Code](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/setup-toolkit.html) pour les instructions d’installation.
1. La version d’AWS Toolkit que vous avez installée est la version **3.69.0** ou une version ultérieure.
1. Informations d’identification AWS configurées dans AWS Toolkit for Visual Studio Code. Pour de plus amples informations, consultez [Authentification et contrôle d’accès](foundation-iac-local-development.md#lambda-functions-vscode-authentication-and-access-control).
## Débogage à distance de fonctions Lambda
Pour démarrer une session de débogage à distance, procédez comme suit :
1. Ouvrez l’explorateur AWS dans VS Code en sélectionnant l’icône AWS dans la barre latérale gauche.
1. Développez la section Lambda pour voir vos fonctions.
1. Cliquez sur la fonction que vous souhaitez déboguer avec le bouton droit de la souris.
1. Dans le menu contextuel, sélectionnez **Invoquer à distance**.
1. Dans la fenêtre d’invocation qui s’ouvre, cochez la case **Activer le débogage**.
1. Cliquez sur **Invoquer** pour démarrer la session de débogage à distance.
**Note**
Les fonctions Lambda ont une limite combinée de 250 Mo pour le code de fonction et toutes les couches associées. La couche de débogage à distance ajoute environ 40 Mo à la taille de votre fonction.
Une session de débogage à distance se termine quand vous :
+ Choisissez **Supprimer la configuration de débogage** sur l’écran de configuration de l’invocation à distance.
+ Sélectionnez l’icône de déconnexion dans les commandes de débogage de VS Code.
+ Sélectionnez le fichier de gestionnaire dans l’éditeur VS Code.
**Note**
La couche de débogage est automatiquement supprimée après 60 secondes d’inactivité après votre dernière invocation.
## Désactiver le débogage à distance
Vous pouvez désactiver cette fonctionnalité de trois manières :
+ **Refuser les mises à jour de fonction** : définissez `lambda:UpdateFunctionConfiguration` sur `deny`.
+ **Restreindre les autorisations IoT** : refusez les autorisations IoT
+ **Bloquer les couches de débogage** : refusez `lambda:GetLayerVersion` pour les ARN suivants :
+ `arn:aws:lambda:*:*:layer:LDKLayerX86:*`
+ `arn:aws:lambda:*:*:layer:LDKLayerArm64:*`
**Note**
La désactivation de cette fonctionnalité empêche l’ajout de la couche de débogage lors des mises à jour de configuration des fonctions.
## Informations supplémentaires
Pour plus d’informations sur l’utilisation de Lambda dans VS Code, reportez-vous à la section [Développement de fonctions Lambda localement avec VS Code](foundation-iac-local-development.md).
Pour obtenir des instructions détaillées sur le dépannage, les cas d’utilisation avancés et la disponibilité régionale, consultez [Débogage à distance des fonctions Lambda](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) dans le Guide de l’utilisateur AWS Toolkit for Visual Studio Code.