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.
Résoudre les problèmes d'exécution dans Lambda
Lorsque le runtime Lambda exécute le code de fonction, l'événement peut être traité sur une instance de la fonction qui traite déjà les événements depuis un certain temps, ou nécessiter l'initialisation d'une nouvelle instance. Des erreurs peuvent se produire lors de l'initialisation de la fonction, lorsque le code de gestionnaire traite l'événement ou lorsque la fonction renvoie (ou ne parvient pas à renvoyer) une réponse.
Les erreurs d'exécution de fonction peuvent être causées par des problèmes de code, de configuration de fonction, de ressources en aval ou d'autorisations. Si vous appelez la fonction directement, les erreurs de fonction sont visibles dans la réponse de Lambda. Si vous appelez la fonction de manière asynchrone, avec un mappage de source d'événement ou via un autre service, vous pouvez trouver les erreurs dans les journaux, une file d'attente de lettres mortes ou une destination réservées aux échecs. Les options de gestion des erreurs et le comportement des nouvelles tentatives varient en fonction de la façon dont vous appelez la fonction et du type d'erreur.
Lorsque le code de fonction ou le runtime Lambda renvoient une erreur, le code d'état indiqué dans la réponse de Lambda est 200 OK. La présence d'une erreur dans la réponse est indiquée par un en-tête nommé X-Amz-Function-Error. Les codes d'état des séries 400 et 500 sont réservés aux erreurs d'invocation.
Lambda : l'exécution prend trop de temps
Problème : l'exécution de la fonction prend trop de temps.
Si l'exécution de votre code est beaucoup plus longue dans Lambda que sur votre ordinateur local, cela peut être dû à une limite au niveau de la mémoire ou de la puissance de traitement disponible pour la fonction. Configurez la fonction avec de la mémoire supplémentaire pour augmenter à la fois la mémoire etCPU.
Lambda : les journaux ou les traces n'apparaissent pas
Problème : les journaux n'apparaissent pas dans CloudWatch les journaux.
Problème : les traces n'apparaissent pas dans AWS X-Ray.
Votre fonction doit être autorisée à appeler CloudWatch Logs and X-Ray. Mettez à jour son rôle d'exécution pour lui accorder l'autorisation. Ajoutez les stratégies gérées suivantes pour activer les journaux et le suivi.
-
AWSLambdaBasicExecutionRole
-
AWSXRayDaemonWriteAccess
Lorsque vous ajoutez des autorisations à votre fonction, effectuez également une mise à jour triviale de son code ou de sa configuration. Cela force l'arrêt et le remplacement des instances en cours d'exécution de votre fonction, qui ont des informations d'identification obsolètes.
Note
L’affichage des journaux après l’invocation d’une fonction peut prendre de 5 à 10 minutes .
Lambda : certains journaux de ma fonction n'apparaissent pas
Problème : les journaux des fonctions sont absents dans CloudWatch les journaux, même si mes autorisations sont correctes
Si vous atteignez Compte AWS les limites de quota de CloudWatch journalisation, CloudWatch les régulateurs fonctionnent à la journalisation. Dans ce cas, certains journaux générés par vos fonctions peuvent ne pas apparaître dans CloudWatch les journaux.
Si votre fonction produit des journaux à un taux trop élevé pour que Lambda puisse les traiter, cela peut également empêcher les sorties des journaux d'apparaître dans CloudWatch les journaux. Lorsque Lambda ne parvient pas à envoyer des journaux CloudWatch au rythme auquel votre fonction les produit, il supprime les journaux pour empêcher l'exécution de votre fonction de ralentir. Attendez-vous à observer régulièrement la perte de journaux lorsque le débit de vos journaux dépasse 2 Mo/s pour un seul flux de journaux.
Si votre fonction est configurée pour utiliser des journaux JSON formatés, Lambda essaie d'envoyer logsDroppedun événement CloudWatch à Logs lorsqu'elle supprime des journaux. Toutefois, lorsque vous CloudWatch limitez la journalisation de votre fonction, cet événement risque de ne pas atteindre les CloudWatch journaux. Vous ne verrez donc pas toujours d'enregistrement lorsque Lambda supprime les journaux.
Pour vérifier si votre quota de CloudWatch logs Compte AWS est atteint, procédez comme suit :
-
Ouvrez la console Service Quotas
. -
Dans le panneau de navigation, choisissez Services AWS .
-
Dans la liste des AWS services, recherchez Amazon CloudWatch Logs.
-
Dans la liste des quotas de service, choisissez les quotas
CreateLogGroup throttle limit in transactions per second,CreateLogStream throttle limit in transactions per secondetPutLogEvents throttle limit in transactions per secondpour afficher votre utilisation.
Vous pouvez également configurer des CloudWatch alarmes pour vous avertir lorsque l'utilisation de votre compte dépasse la limite que vous avez spécifiée pour ces quotas. Voir Créer une CloudWatch alarme basée sur un seuil statique pour en savoir plus.
Si les limites de quota par défaut pour CloudWatch les journaux ne sont pas suffisantes pour votre cas d'utilisation, vous pouvez demander une augmentation du quota.
Lambda : la fonction renvoie avant la fin de l'exécution
Problème : (Node.js) la fonction renvoie un objet avant la fin de l'exécution du code
De nombreuses bibliothèques, y compris la AWS SDK, fonctionnent de manière asynchrone. Lorsque vous effectuez un appel réseau ou toute autre opération nécessitant l'attente d'une réponse, les bibliothèques renvoient un objet appelé promesse, qui suit la progression de l'opération en arrière-plan.
Pour attendre que la promesse soit résolue en réponse, utilisez le mot-clé await. Celui-ci empêche le code de gestionnaire de s'exécuter jusqu'à ce que la promesse soit résolue en objet contenant la réponse. Si vous n'avez pas besoin d'utiliser les données de la réponse dans votre code, vous pouvez retourner la promesse directement à l'environnement d'exécution.
Certaines bibliothèques ne retournent pas de promesses, mais peuvent être enveloppées dans du code qui le fait. Pour de plus amples informations, veuillez consulter Définir le gestionnaire de fonctions Lambda dans Node.js.
AWS SDK: Versions et mises à jour
Problème : la version AWS SDK incluse dans le runtime n'est pas la dernière version
Problème : le contenu AWS SDKinclus dans le moteur d'exécution est automatiquement mis à jour
Les environnements d'exécution des langages de script incluent AWS SDK et sont régulièrement mis à jour vers la dernière version. La version actuelle de chaque moteur d'exécution est répertoriée sur la page d'exécution. Pour utiliser une version plus récente du AWS SDK ou pour verrouiller vos fonctions sur une version spécifique, vous pouvez regrouper la bibliothèque avec votre code de fonction ou créer une couche Lambda. Pour plus d'informations sur la création d'un package de déploiement avec des dépendances, consultez les rubriques suivantes :
Python : les bibliothèques se chargent de manière incorrecte
Problème : (Python) certaines bibliothèques ne se chargent pas correctement à partir du package de déploiement
Les bibliothèques avec des modules d'extension écrits en C ou C++ doivent être compilées dans un environnement avec la même architecture de processeur que Lambda (Amazon Linux). Pour de plus amples informations, veuillez consulter Travailler avec des archives de fichiers .zip pour les fonctions Lambda Python.
Java : votre fonction met plus de temps à traiter les événements après la mise à jour de Java 11 vers Java 17
Problème : (Java) Votre fonction met plus de temps à traiter les événements après la mise à jour de Java 11 vers Java 17
Réglez votre compilateur à l'aide du JAVA_TOOL_OPTIONS paramètre. Les environnements d'exécution Lambda pour Java 17 et versions ultérieures de Java modifient les options du compilateur par défaut. Cette modification améliore les temps de démarrage à froid pour les fonctions de courte durée, mais le comportement précédent est mieux adapté aux fonctions de longue durée nécessitant des calculs intensifs. Définissez JAVA_TOOL_OPTIONS cette valeur -XX:-TieredCompilation sur pour revenir au comportement de Java 11. Pour plus d'informations sur le paramètre JAVA_TOOL_OPTIONS, consultez Comprendre la variable d'JAVA_TOOL_OPTIONSenvironnement.
