

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.

# Visualisez les invocations de fonctions Lambda à l'aide de AWS X-Ray
<a name="services-xray"></a>

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
<a name="services-xray-traces"></a>

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
<a name="services-xray-default"></a>

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
<a name="services-xray-permissions"></a>

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
<a name="services-xray-api"></a>

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
<a name="services-xray-cloudformation"></a>

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