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.

Si vous avez activé le suivi X-Ray dans un service qui invoque votre fonction, Lambda envoie automatiquement les suivis à X-Ray. Le service en amont, tel qu'Amazon API Gateway, ou une application hébergée sur Amazon EC2 qui est instrumentée avec le X-RaySDK, échantillonne les demandes entrantes et ajoute un en-tête de suivi indiquant à Lambda d'envoyer des traces ou non. Les traces provenant des producteurs de messages en amont, tels qu'AmazonSQS, 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 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 (MSKAmazon), Apache Kafka autogéré, Amazon MQ avec ActiveMQ et RabbitMQ, ou les mappages de 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 (Fonctions) de la console Lambda.

2. Choisissez une fonction.

3. Choisissez Configuration, puis choisissez Outils de surveillance et d'opérations.

4. Choisissez Modifier.

5. Sous X-Ray, activer/désactiver Active tracing (Traçage actif).

6. Choisissez Save (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 de votre fonction. Dans le cas contraire, ajoutez la AWSXRayDaemonWriteAccesspolitique 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 la fréquence d'échantillonnage des rayons X 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 2 segments par trace, ce qui crée deux nœuds sur le graphe de service. L'image suivante met en évidence ces deux nœuds :

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 couvre toutes les étapes nécessaires à la préparation de l'environnement d'exécution Lambda. AWS::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 fonction et de toutes les couches.

Le AWS::Lambda::Function segment 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 trace émis par les différentes fonctions Lambda de votre ordinateur. Compte AWS

Cette modification affecte les sous-segments du segment de fonction. Les paragraphes suivants décrivent à la fois 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, passeront à l'utilisation du 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 du AWS::Lambda segment ressemble à ce qui suit :

Dans ce format, le segment de fonction comporte des sous-segments pour InitializationInvocation, etOverhead. Pour Lambda SnapStart uniquement, il existe également un Restore sous-segment (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 le moteur 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 runtime (JVM) et exécuter les éventuels hooks d'exécution. afterRestore 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 X-Ray SDK pour étendre le Invocation sous-segment avec des sous-segments supplémentaires pour les appels en aval, les annotations et les métadonnées. 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

Un exemple de trace utilisant l'ancienne structure X-Ray est illustré dans le schéma suivant.

Notez les deux segments de l'exemple. Les deux sont nommés my-function, mais l'un a une origine de AWS::Lambda et l'autre a une origine deAWS::Lambda::Function. Si le AWS::Lambda segment affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le AWS::Lambda::Function segment 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, 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 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.

Structure de segment AWS X-Ray Lambda de style nouveau

La nouvelle structure X-Ray du AWS::Lambda segment ressemble à ce qui suit :

Dans ce nouveau format, le Init sous-segment représente la phase d'initialisation du cycle de vie de l'environnement d'exécution Lambda, comme auparavant.

Il n'existe aucun segment d'invocation dans le nouveau format. Au lieu de cela, les sous-segments de clients sont directement rattachés au AWS::Lambda::Function segment. 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 nécessaire à l'exécution pour terminer

• aws.extensionOverhead- le temps supplémentaire nécessaire pour terminer les prolongations

Un exemple de trace utilisant la nouvelle structure X-Ray est illustré dans le schéma suivant.

Notez les deux segments de l'exemple. Les deux sont nommés my-function, mais l'un a une origine de AWS::Lambda et l'autre a une origine deAWS::Lambda::Function. Si le AWS::Lambda segment affiche une erreur, cela signifie que le service Lambda a rencontré un problème. Si le AWS::Lambda::Function segment 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

• Instrumentation du code Python dans AWS Lambda

• Instrumentation du code Ruby dans AWS Lambda

• Instrumentation du code Java dans AWS Lambda

• Instrumentation du code Go AWS Lambda

• Instrumentation du code C# dans AWS Lambda

Pour obtenir la liste complète des services qui prennent en charge l'instrumentation active, consultez la section AWS Services pris en charge dans le Guide du AWS X-Ray développeur.

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 de la fonction.

• radiographie : PutTraceSegments

• radiographie : PutTelemetryRecords

Ces autorisations sont incluses dans la politique AWSXRayDaemonWriteAccessgérée.

Le AWS X-Ray daemon

Au lieu d'envoyer des données de suivi directement au X-RayAPI, celui-ci SDK utilise un processus daemon. Le AWS X-Ray daemon est une application qui s'exécute dans l'environnement Lambda et écoute le trafic contenant des segments et UDP des sous-segments. Il met en mémoire tampon les données entrantes et les écrit par lots sur X-Ray, ce qui a pour effet de réduire la surcharge de traitement et de mémoire requise pour suivre les invocations.

L'environnement d'exécution Lambda permet au démon d'utiliser jusqu'à 3 % de la mémoire configurée pour votre fonction ou 16 Mo, selon la valeur la plus élevée. Si votre fonction manque de mémoire pendant l'invocation, l'environnement d'exécution arrête d'abord le processus de démon pour libérer de la mémoire.

Le processus de démon étant entièrement géré par Lambda, l'utilisateur ne peut pas le configurer. Tous les segments générés par les invocations de fonction sont enregistrés dans le même compte que la fonction Lambda. Le démon ne peut pas être configuré pour les rediriger vers un autre compte.

Pour plus d'informations, consultez Démon X-Ray dans le Guide du développeur X-Ray.

Activer le traçage actif avec le Lambda API

Pour gérer la configuration du suivi avec le AWS CLI ou AWS SDK, utilisez les API opérations suivantes :

• UpdateFunctionConfiguration

• GetFunctionConfiguration

• CreateFunction

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 suivi actif avec AWS CloudFormation

Pour activer le suivi d'une AWS::Lambda::Function ressource dans un AWS CloudFormation modèle, utilisez la TracingConfig propriété.

Exemple function-inline.yml – Configuration du suivi

Resources:
  function:
    Type: AWS::Lambda::Function
    Properties:
      TracingConfig:
        Mode: Active
      ...

Pour une AWS::Serverless::Function ressource AWS Serverless Application Model (AWS SAM), utilisez la Tracing propriété.

Exemple template.yml – Configuration du suivi

Resources:
  function:
    Type: AWS::Serverless::Function
    Properties:
      Tracing: Active
      ...