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ésolution des problèmes dans Lambda Les rubriques suivantes fournissent des conseils de dépannage pour les erreurs et les problèmes que vous pouvez rencontrer lors de l'utilisation de l'API, de la console ou des outils Lambda. Si vous rencontrez un problème qui n’est pas répertorié ici, vous pouvez utiliser le bouton **Commentaire** sur cette page pour le signaler. Pour plus de conseils de dépannage et de réponses aux questions courantes de support, visitez le [Centre de connaissances AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Pour plus d’informations sur le débogage et le dépannage des applications Lambda, consultez [Débogage](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops) dans Serverless Land. **Topics** + [Résoudre les problèmes de configuration dans Lambda](troubleshooting-configuration.md) + [Résoudre les problèmes de déploiement dans Lambda](troubleshooting-deployment.md) + [Résoudre les problèmes d’invocation dans Lambda](troubleshooting-invocation.md) + [Résoudre les problèmes d’exécution dans Lambda](troubleshooting-execution.md) + [Résoudre les problèmes de mappage des sources d’événements dans Lambda](troubleshooting-event-source-mapping.md) + [Résolution des problèmes de réseaux dans Lambda](troubleshooting-networking.md) # Résoudre les problèmes de configuration dans Lambda Les paramètres de configuration de votre fonction peuvent avoir un impact sur les performances globales et le comportement de votre fonction Lambda. Ils peuvent ne pas provoquer d’erreurs de fonctionnement réelles, mais entraîner des délais et des résultats inattendus. Les rubriques suivantes fournissent des conseils de dépannage pour les problèmes courants que vous pourriez rencontrer avec les paramètres de configuration des fonctions Lambda. **Topics** + [Configurations de mémoire](#memory-config) + [Configurations dépendant du processeur](#cpu-bound-config) + [Délais](#timeouts) + [Fuite de mémoire entre les invocations](#memory-leakage) + [Résultats asynchrones renvoyés à une invocation ultérieure](#asynchronous-results) ## Configurations de mémoire Vous pouvez configurer une fonction Lambda à utiliser entre 128 Mo et 10 240 Mo de mémoire. Par défaut, la plus petite quantité de mémoire est affectée à toutes les fonctions créées dans la console. De nombreuses fonctions Lambda sont performantes à ce réglage le plus bas. Toutefois, si vous importez de grandes bibliothèques de code ou si vous effectuez des tâches gourmandes en mémoire 128 Mo ne suffisent pas. Si vos fonctions s’exécutent beaucoup plus lentement que prévu, la première étape consiste à augmenter le paramètre de mémoire. Cela vous permet de résoudre le goulet d’étranglement et peut améliorer les performances de votre fonction pour les fonctions dépendant de la mémoire. ## Configurations dépendant du processeur Pour les opérations de calcul intensif, si les performances de votre fonction sont plus lentes que prévu, cela peut être dû au fait que votre fonction est dépendante du processeur. Dans ce cas, la capacité de calcul de la fonction ne peut pas suivre le rythme de la tâche. Lambda ne vous permet pas de modifier directement la configuration du CPU ; ce dernier est contrôlé indirectement via les paramètres de mémoire. Le service Lambda alloue proportionnellement plus de processeur virtuel à mesure que vous allouez de la mémoire. Avec 1,8 Go de mémoire, un processeur virtuel entier est alloué à une fonction Lambda et, au-dessus de ce niveau, elle a accès à plusieurs cœurs de processeurs virtuels. Avec 10 240 Mo, elle dispose de six processeurs virtuels disponibles. En d’autres termes, vous pouvez améliorer les performances en augmentant l’allocation de mémoire, même si la fonction n’utilise pas toute la mémoire. ## Délais Les [délais d’expiration](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html) des fonctions Lambda peuvent être définis entre 1 et 900 secondes (15 minutes). Par défaut, la console Lambda définit ce paramètre sur 3 secondes. La valeur du délai d’expiration est une soupape de sécurité qui garantit que les fonctions ne s’exécutent pas indéfiniment. Une fois le délai d’expiration atteint, Lambda arrête l’invocation de fonction. Si une valeur de délai d’expiration est définie sur une valeur proche de la durée moyenne d’une fonction, cela augmente le risque que la fonction expire de façon inattendue. La durée d’une fonction peut varier en fonction de la quantité de données transférées et traitées, ainsi que de la latence des services avec lesquels la fonction interagit. Les causes courantes de délai d’expiration comprennent les suivantes : + Lorsque vous téléchargez des données depuis des compartiments S3 ou d’autres entrepôts de données, le téléchargement est plus important ou prend plus de temps que la moyenne. + Une fonction envoie une requête à un autre service, qui met plus de temps à répondre. + Les paramètres fournis à une fonction nécessitent une complexité de calcul accrue dans la fonction, ce qui fait que l’invocation prend plus de temps. Lors des tests de votre application, veillez à ce que ceux-ci reflètent fidèlement la taille et la quantité des données, et à ce que les valeurs des paramètres soient réalistes. Il est important d’utiliser des jeux de données se situant dans les limites supérieures de ce que l’on peut raisonnablement attendre de votre charge de travail. En outre, implémentez des limites supérieures à votre charge de travail dans la mesure du possible. Dans cet exemple, l’application peut utiliser une limite de taille maximale pour chaque type de fichier. Vous pouvez ensuite tester les performances de votre application pour une gamme de tailles de fichiers attendues, jusqu’aux limites maximales incluses. ## Fuite de mémoire entre les invocations Les variables globales et les objets stockés dans la phase INIT d’une invocation Lambda conservent leur état entre les invocations à chaud. Ils ne sont complètement réinitialisés que lorsque l’environnement d’exécution est exécuté pour la première fois (également appelé « démarrage à froid »). Toutes les variables stockées dans le gestionnaire sont détruites lorsque le gestionnaire se ferme. Il est recommandé d’utiliser la phase INIT pour configurer les connexions aux bases de données, charger des bibliothèques, créer des caches et charger des actifs immuables. Lorsque vous utilisez des bibliothèques tierces pour plusieurs invocations dans le même environnement d’exécution, consultez leur documentation pour en savoir plus sur leur utilisation dans un environnement de calcul sans serveur. Certaines bibliothèques de connexion à la base de données et de journalisation peuvent enregistrer des résultats d’invocation intermédiaires et d’autres données. Cela entraîne une augmentation de l’utilisation de la mémoire de ces bibliothèques lors des invocations à chaud ultérieures. Si c’est le cas, il se peut que la fonction Lambda soit à court de mémoire, même si votre code personnalisé élimine correctement les variables. Ce problème affecte les invocations survenant dans des environnements d’exécution à chaud. Par exemple, le code suivant crée une fuite de mémoire entre les invocations. La fonction Lambda consomme de la mémoire supplémentaire à chaque invocation en augmentant la taille d’un tableau global : ``` let a = [] exports.handler = async (event) => { a.push(Array(100000).fill(1)) } ``` Configuré avec 128 Mo de mémoire, après avoir invoqué cette fonction 1 000 fois, l’onglet **Surveillance** de la fonction Lambda affiche les modifications typiques des invocations, de la durée et du nombre d’erreurs en cas de fuite de mémoire : ![\[opérations de débogage (illustration 4)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-4.png) 1. **Invocations** : un taux de transaction stable est interrompu périodiquement, car les invocations prennent plus de temps à être effectuées. À son état stable, la fuite de mémoire ne consomme pas toute la mémoire allouée à la fonction. À mesure que les performances se dégradent, le système d’exploitation appelle le stockage local pour s’adapter à l’augmentation de la mémoire requise par la fonction, ce qui réduit le nombre de transactions effectuées. 1. **Durée** : avant que la fonction ne soit à court de mémoire, elle termine les invocations au rythme constant d’un nombre de millisecondes à deux chiffres. Au fur et à mesure que les appels se produisent, la durée s’allonge d’un ordre de grandeur. 1. **Nombre d’erreurs** : lorsque la fuite de mémoire dépasse la mémoire allouée, les erreurs de fonction finissent par se produire en raison du dépassement du délai d’expiration par le calcul, ou l’environnement d’exécution arrête la fonction. Après l’erreur, Lambda redémarre l’environnement d’exécution, ce qui explique pourquoi on observe un retour à l’état d’origine dans les trois graphiques. L’extension des métriques CloudWatch en fonction de la durée permet d’obtenir plus de détails sur les statistiques de durée minimale, maximale et moyenne : ![\[opérations de débogage (illustration 5)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-5.png) Pour identifier les erreurs générées lors des 1 000 invocations, vous pouvez utiliser le langage de requête CloudWatch Insights. La requête suivante exclut les journaux d’information pour signaler uniquement les erreurs : ``` fields @timestamp, @message | sort @timestamp desc | filter @message not like 'EXTENSION' | filter @message not like 'Lambda Insights' | filter @message not like 'INFO'  | filter @message not like 'REPORT' | filter @message not like 'END' | filter @message not like 'START' ``` Lorsqu’elle est exécutée sur le groupe de journaux pour cette fonction, cela montre que les délais d’expiration sont à l’origine des erreurs périodiques : ![\[opérations de débogage (illustration 6)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-6.png) ## Résultats asynchrones renvoyés à une invocation ultérieure Pour le code de fonction qui utilise des modèles asynchrones, il est possible que les résultats du rappel d’une invocation soient renvoyés lors d’une future invocation. Cet exemple utilise Node.js, mais la même logique peut s’appliquer à d’autres environnements d’exécution utilisant des modèles asynchrones. La fonction utilise la syntaxe de rappel traditionnelle en JavaScript. Elle appelle une fonction asynchrone avec un compteur incrémentiel qui suit le nombre d’invocations : ``` let seqId = 0 exports.handler = async (event, context) => { console.log(`Starting: sequence Id=${++seqId}`) doWork(seqId, function(id) { console.log(`Work done: sequence Id=${id}`) }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` Lorsqu’ils sont invoqués plusieurs fois de suite, les résultats des rappels apparaissent lors des invocations suivantes : ![\[opérations de débogage (illustration 7)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-7.png) 1. Le code appelle la fonction `doWork` en fournissant une fonction de rappel comme dernier paramètre. 1. La fonction `doWork` met un certain temps à s’exécuter avant d’invoquer le rappel. 1. La journalisation de la fonction indique que l’invocation prend fin avant la fin de l’exécution de la fonction `doWork`. De plus, après le démarrage d’une itération, les rappels des itérations précédentes sont traités, comme indiqué dans les journaux. En JavaScript, les rappels asynchrones sont gérés par une [boucle d’événements](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop). D’autres environnements d’exécution utilisent des mécanismes différents pour gérer la simultanéité. Lorsque l’environnement d’exécution de la fonction prend fin, Lambda gèle l’environnement jusqu’à la prochaine invocation. Après sa reprise, JavaScript poursuit le traitement de la boucle d’événements, qui inclut dans ce cas un rappel asynchrone issu d’une invocation précédente. Sans ce contexte, il peut sembler que la fonction exécute du code sans raison et renvoie des données arbitraires. En réalité, il s’agit vraiment d’un artefact de la façon dont la simultanéité d’exécution et les environnements d’exécution interagissent. Cela crée le risque que les données privées d’une précédente invocation apparaissent lors d’une invocation ultérieure. Il existe deux façons d’empêcher ou de détecter ce comportement. Tout d’abord, JavaScript fournit les [mots clés async et await](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function) afin de simplifier le développement asynchrone et de forcer l’exécution du code à attendre la fin d’un appel asynchrone. La fonction ci-dessus peut être réécrite en utilisant cette approche comme suit : ``` let seqId = 0 exports.handler = async (event) => { console.log(`Starting: sequence Id=${++seqId}`) const result = await doWork(seqId) console.log(`Work done: sequence Id=${result}`) } function doWork(id) { return new Promise(resolve => { setTimeout(() => resolve(id), 4000) }) } ``` L’utilisation de cette syntaxe empêche le gestionnaire de se fermer avant la fin de la fonction asynchrone. Dans ce cas, si le rappel prend plus de temps que le délai d’expiration de la fonction Lambda, la fonction générera une erreur au lieu de renvoyer le résultat du rappel lors d’une invocation ultérieure : ![\[opérations de débogage (illustration 8)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-8.png) 1. Le code appelle la fonction asynchrone `doWork` à l’aide du mot clé await dans le gestionnaire. 1. La fonction `doWork` met un certain temps à s’exécuter avant de résoudre la promesse. 1. La fonction expire, car `doWork` prend plus de temps que le délai imparti et le résultat du rappel n’est pas renvoyé lors d’une invocation ultérieure. En général, assurez-vous que les processus d’arrière-plan ou les rappels dans le code se terminent avant que l’exécution du code ne prenne fin. Si cela n’est pas possible dans votre cas d’utilisation, vous pouvez utiliser un identifiant pour vous assurer que le rappel appartient à l’invocation en cours. Pour ce faire, vous pouvez utiliser l’identifiant *awsRequestId* fourni par l’objet de contexte. En transmettant cette valeur au rappel asynchrone, vous pouvez comparer la valeur transmise à la valeur actuelle pour détecter si le rappel provient d’une autre invocation : ``` let currentContext exports.handler = async (event, context) => { console.log(`Starting: request id=$\{context.awsRequestId}`) currentContext = context doWork(context.awsRequestId, function(id) { if (id != currentContext.awsRequestId) { console.info(`This callback is from another invocation.`) } }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` ![\[opérations de débogage (illustration 9)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-9.png) 1. Le gestionnaire de fonctions Lambda utilise le paramètre context, qui donne accès à un ID de requête d’invocation unique. 1. L’`awsRequestId` est transmis à la fonction doWork. Dans le rappel, l’ID est comparé à la valeur `awsRequestId` de l’invocation en cours. Si ces valeurs sont différentes, le code peut agir en conséquence. # Résoudre les problèmes de déploiement dans Lambda Lorsque vous mettez à jour votre fonction, Lambda déploie la modification en lançant de nouvelles instances de cette fonction avec le code ou les paramètres mis à jour. Les erreurs de déploiement empêchent l’utilisation de la nouvelle version et peuvent résulter de problèmes liés au package de déploiement, au code, à vos autorisations ou à vos outils. Lorsque vous déployez des mises à jour de votre fonction directement avec l'API Lambda ou avec un client tel que le AWS CLI, vous pouvez voir les erreurs provenant de Lambda directement dans la sortie. Si vous utilisez des services tels que AWS CloudFormation AWS CodeDeploy, ou AWS CodePipeline, recherchez la réponse de Lambda dans les journaux ou le flux d'événements de ce service. Les rubriques suivantes fournissent des conseils de dépannage pour les erreurs et les problèmes que vous pouvez rencontrer lors de l’utilisation de l’API, de la console ou des outils Lambda. Si vous rencontrez un problème qui n’est pas répertorié ici, vous pouvez utiliser le bouton **Commentaire** sur cette page pour le signaler. Pour plus de conseils de dépannage et de réponses aux questions courantes de support, visitez le [Centre de connaissances AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda). Pour plus d’informations sur le débogage et le dépannage des applications Lambda, consultez [Débogage](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops) dans Serverless Land. **Topics** + [Général : autorisation refusée/impossible de charger ce fichier](#troubleshooting-deployment-denied) + [Général : Une erreur se produit lors de l'appel du UpdateFunctionCode](#troubleshooting-deployment-updatefunctioncode) + [Amazon S3 : code d'erreur PermanentRedirect.](#troubleshooting-deployment-PermanentRedirect) + [Général : impossible de trouver, impossible de charger, impossible d’importer, classe introuvable, aucun fichier ou répertoire de ce type](#troubleshooting-deployment-functionHandler1) + [Général : gestionnaire de méthode non défini](#troubleshooting-deployment-functionHandler2) + [Général : limite de stockage du code Lambda dépassée](#troubleshooting-deployment-CodeStorageExceeded) + [Lambda : échec de la conversion de couche](#troubleshooting-deployment-LayerConversionFailed) + [Lambda : ou InvalidParameterValueException RequestEntityTooLargeException](#troubleshooting-deployment-InvalidParameterValueException1) + [Lambda : InvalidParameterValueException](#troubleshooting-deployment-InvalidParameterValueException2) + [Lambda : quotas de simultanéité et de mémoire](#troubleshooting-deployment-quotas) + [Lambda : configuration d’alias non valide pour la simultanéité provisionnée.](#troubleshooting-deployment-provisioned-concurrency) ## Général : autorisation refusée/impossible de charger ce fichier **Erreur :** *EACCES : autorisation refusée, ouvrez « var/task/index*/.js » **Erreur :** *impossible de charger ce fichier - cette fonction* **Erreur :** *[Erron 13] Autorisation refusée : var/task/function '/* .py' Le runtime Lambda a besoin d’une autorisation pour lire les fichiers de votre package de déploiement. Dans la notation octale des autorisations Linux, Lambda a besoin de 644 autorisations pour les fichiers non exécutables (rw-r--r--) et de 755 autorisations () pour les répertoires et les fichiers exécutables. rwxr-xr-x Sous Linux et macOS, utilisez la commande `chmod` pour modifier les autorisations de fichiers sur les fichiers et les répertoires de votre package de déploiement. Par exemple, pour octroyer à un fichier non exécutable les autorisations correctes, exécutez la commande suivante. ``` chmod 644 ``` Pour modifier les autorisations relatives aux fichiers dans Windows, voir [Définir, afficher, modifier ou supprimer des autorisations sur un objet](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10)) dans la documentation Microsoft Windows. **Note** Si vous n'accordez pas à Lambda les autorisations nécessaires pour accéder aux répertoires de votre package de déploiement, Lambda définit les autorisations pour ces répertoires sur 755 (). rwxr-xr-x ## Général : Une erreur se produit lors de l'appel du UpdateFunctionCode **Erreur :** *une erreur s'est produite (RequestEntityTooLargeException) lors de l'appel de l' UpdateFunctionCode opération* Lorsque vous chargez un package de déploiement ou une archive de couche directement dans Lambda, la taille du fichier ZIP est limitée à 50 Mo. Pour charger un fichier plus volumineux, stockez-le dans Amazon S3, puis utilisez les paramètres S3Bucket et S3Key. **Note** Lorsque vous téléchargez un fichier directement avec le AWS CLI AWS SDK ou autre, le fichier ZIP binaire est converti en base64, ce qui augmente sa taille d'environ 30 %. Pour permettre cela et aussi prendre en compte la taille d’autres paramètres dans la demande, la limite de taille réelle de demande que Lambda applique est supérieure. Pour cette raison, la limite de 50 Mo est approximative. ## Amazon S3 : code d'erreur PermanentRedirect. **Erreur : une** *erreur s'est produite pendant GetObject. Code d'erreur S3 : PermanentRedirect. Message d’erreur S3 : Le compartiment se trouve dans cette région : us-east-2. Veuillez utiliser cette région pour renouveler la demande* Lorsque vous chargez le package de déploiement d’une fonction à partir d’un compartiment Amazon S3, le compartiment doit se trouver dans la même région que la fonction. Ce problème peut se produire lorsque vous spécifiez un objet Amazon S3 dans un appel à [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html), ou lorsque vous utilisez les commandes de package et de déploiement dans la AWS SAM CLI AWS CLI ou. Créez un compartiment d’artefact de déploiement pour chaque région dans laquelle vous développez des applications. ## Général : impossible de trouver, impossible de charger, impossible d’importer, classe introuvable, aucun fichier ou répertoire de ce type **Erreur :** *module ’function’ introuvable* **Erreur :** *impossible de charger ce fichier - cette fonction* **Erreur :** *impossible d’importer le module ’function’* **Erreur :** *Classe introuvable : Function.handler* **Erreur fork/exec /var/task/function :** *aucun fichier ou répertoire de ce type* **Erreur :** *impossible de charger le type ’Function.Handler’ à partir de l’assemblage ’Function’.* Le nom du fichier ou de la classe dans la configuration du gestionnaire de votre fonction ne correspond pas à votre code. Consultez la section suivante pour plus d’informations. ## Général : gestionnaire de méthode non défini **Erreur :** *index.handler n’est pas défini ou n’est pas exporté* **Erreur :** *gestionnaire ’handler’ manquant dans le module ’function’* **Erreur :** *« gestionnaire » de méthode non défini pour \$1<:0x000055b76ccebf98> LambdaHandler* **Erreur :** *aucune méthode publique nommée handleRequest avec la signature de méthode appropriée trouvée dans la classe function.Handler* **Erreur :** *méthode ’handleRequest’ introuvable dans le type ’Function.Handler’ de l’assemblage ’Function’* Le nom de la méthode du gestionnaire dans la configuration du gestionnaire de votre fonction ne correspond pas à votre code. Chaque environnement d'exécution définit une convention de dénomination pour les gestionnaires, telle que*filename*. *methodname*. Le gestionnaire correspond à la méthode dans le code de votre fonction que l’environnement d’exécution exécute lorsque la fonction est invoquée. Pour certains langages, Lambda fournit une bibliothèque avec une interface pour laquelle une méthode de gestionnaire doit avoir un nom spécifique. Pour plus d’informations sur l’attribution de noms de gestionnaire pour chaque langue, consultez les rubriques suivantes. + [Création de fonctions Lambda avec Node.js](lambda-nodejs.md) + [Création de fonctions Lambda avec Python](lambda-python.md) + [Création de fonctions Lambda avec Ruby](lambda-ruby.md) + [Création de fonctions Lambda avec Java](lambda-java.md) + [Création de fonctions Lambda avec Go](lambda-golang.md) + [Création de fonctions Lambda avec C\$1](lambda-csharp.md) + [Création de fonctions Lambda avec PowerShell](lambda-powershell.md) ## Général : limite de stockage du code Lambda dépassée **Erreur :** *limite de stockage de code dépassée.* Lambda stocke le code de votre fonction dans un compartiment S3 interne réservé à votre compte. Chaque AWS compte dispose de 75 Go de stockage dans chaque région. Le stockage de code inclut le stockage total utilisé à la fois par les fonctions et les couches Lambda. Si vous atteignez le quota, vous recevez un *CodeStorageExceededException*lorsque vous tentez de déployer de nouvelles fonctions. Gérez l’espace de stockage disponible en nettoyant les anciennes versions des fonctions, en supprimant le code inutilisé ou en utilisant des couches Lambda. En outre, il est recommandé d'[utiliser des AWS comptes distincts pour des charges de travail distinctes](concepts-application-design.md#multiple-accounts) afin de gérer les quotas de stockage. Vous pouvez consulter votre utilisation totale du stockage dans la console Lambda, dans le sous-menu **Tableau de bord** : ![\[surveillance de l’observabilité (illustration 26)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/monitoring-observability-figure-26.png) ## Lambda : échec de la conversion de couche **Erreur :** *la conversion de la couche Lambda a échoué. Pour obtenir des conseils sur la résolution de ce problème, consultez la page Résolution des problèmes de déploiement dans Lambda du Guide de l’utilisateur Lambda.* Lorsque vous configurez une fonction Lambda avec une couche, Lambda fusionne la couche avec le code de votre fonction. Si ce processus échoue, Lambda renvoie cette erreur. Si vous rencontrez cette erreur, réalisez les actions suivantes : + Supprimer tous les fichiers inutiles de votre couche + Supprimer tous les liens symboliques de votre couche + Renommer tous les fichiers qui ont le même nom qu’un répertoire dans l’une des couches de votre fonction ## Lambda : ou InvalidParameterValueException RequestEntityTooLargeException **Erreur InvalidParameterValueException :** *Lambda n'a pas pu configurer vos variables d'environnement car les variables d'environnement que vous avez fournies ont dépassé la limite de 4 Ko. Chaîne mesurée : \$1"A1" : « u SFe Y5 cyPiPn 7atNx5bSM...* **Erreur RequestEntityTooLargeException :** *la demande doit être inférieure à 5120 octets pour l'opération UpdateFunctionConfiguration * La taille maximale de l’objet variable stocké dans la configuration de la fonction ne doit pas dépasser 4096 octets. Cela inclut les noms de clés, les valeurs, les guillemets, les virgules et les crochets. La taille totale du corps de requête HTTP est également limitée. ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Runtime": "nodejs24.x", "Role": "arn:aws:iam::123456789012:role/lambda-role", "Environment": { "Variables": { "BUCKET": "amzn-s3-demo-bucket", "KEY": "file.txt" } }, ... } ``` Dans cet exemple, l’objet comporte 39 caractères et utilise 39 octets lorsqu’il est stocké (sans espace) comme chaîne `{"BUCKET":"amzn-s3-demo-bucket","KEY":"file.txt"}`. Les caractères ASCII standard dans les valeurs des variables d’environnement utilisent un octet chacun. Les caractères ASCII et Unicode étendus peuvent utiliser entre 2 et 4 octets par caractère. ## Lambda : InvalidParameterValueException **Erreur InvalidParameterValueException :** *Lambda n'a pas pu configurer vos variables d'environnement car les variables d'environnement que vous avez fournies contiennent des clés réservées dont la modification n'est actuellement pas prise en charge*. Lambda réserve certaines clés de variables d’environnement pour une utilisation interne. Par exemple, `AWS_REGION` est utilisé par l’environnement d’exécution pour déterminer la région actuelle et ne peut pas être remplacé. D’autres variables, comme `PATH`, sont utilisées par l’environnement d’exécution, mais peuvent être étendues dans la configuration de votre fonction. Pour obtenir une liste complète, veuillez consulter [Variables d’environnement d’exécution définies](configuration-envvars.md#configuration-envvars-runtime). ## Lambda : quotas de simultanéité et de mémoire **Erreur :** la *fonction spécifiée ConcurrentExecutions réduit le compte en UnreservedConcurrentExecution dessous de sa valeur minimale* **Erreur :** *la valeur MemorySize « » n'a pas satisfait la contrainte : le membre doit avoir une valeur inférieure ou égale à 3008* Ces erreurs se produisent lorsque vous dépassez les [quotas](gettingstarted-limits.md) de simultanéité ou de mémoire pour votre compte. AWS Les nouveaux comptes ont réduit la simultanéité et les quotas de mémoire. Pour résoudre les erreurs liées à la simultanéité, vous pouvez [demander une augmentation des quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). Vous ne pouvez pas demander d’augmentation des quotas de mémoire. + **Simultanéité :** vous pouvez recevoir un message d'erreur si vous essayez de créer une fonction à l'aide de la simultanéité réservée ou provisionnée, ou si votre demande de simultanéité par fonction ([PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html)) excède le quota de simultanéité de votre compte. + **Mémoire :** des erreurs surviennent lorsque la capacité de mémoire allouée à la fonction dépasse le quota de mémoire de votre compte. ## Lambda : configuration d’alias non valide pour la simultanéité provisionnée. **Erreur :** *configuration d’alias non valide pour la simultanéité provisionnée* Cette erreur se produit lorsque vous essayez de mettre à jour le code ou la configuration d’une fonction Lambda alors qu’un alias doté d’une simultanéité provisionnée pointe vers une version présentant des problèmes. Lambda pré-initialise les environnements d’exécution pour une simultanéité provisionnée, et si ces environnements ne peuvent pas être correctement initialisés en raison d’erreurs de code, de contraintes de ressources ou de l’utilisation d’une pile ou d’un alias affecté, le déploiement échoue. Si vous rencontrez ce problème, réalisez les actions suivantes : 1. **Restaurer l’alias :** mettez temporairement à jour l’alias pour qu’il pointe vers la version qui fonctionnait auparavant. ``` aws lambda update-alias \ --function-name \ --name \ --function-version ``` 1. **Corriger le code d’initialisation Lambda :** assurez-vous que le code d’initialisation exécuté en dehors du gestionnaire ne contient aucune exception non détectée et initialisez les clients et les connexions. 1. **Redéployer de façon sûre :** déployez le code corrigé et publiez une nouvelle version. Mettez ensuite à jour l’alias pour qu’il pointe vers la version corrigée. Réactivez éventuellement la [simultanéité provisionnée](provisioned-concurrency.md), si nécessaire. Si vous l'utilisez AWS CloudFormation, mettez à jour la définition de la pile `FunctionVersion:!GetAtt version.Version` afin que l'alias pointe vers la version de travail : ``` alias: Type: AWS::Lambda::Alias Properties: FunctionName: !Ref function FunctionVersion: !GetAtt version.Version Name: BLUE ProvisionedConcurrencyConfig: ProvisionedConcurrentExecutions: 1 ``` # Résoudre les problèmes d’invocation dans Lambda Lorsque vous invoquez une fonction Lambda, Lambda valide la demande et vérifie la capacité de dimensionnement avant d’envoyer l’événement à votre fonction ou, pour une invocation asynchrone, à la file d’attente d’événements. Les erreurs d’invocation peuvent être causées par des problèmes de paramètres de demande, de structure d’événement, de paramètres de fonction, d’autorisations utilisateur, d’autorisations de ressources ou de limites. Si vous invoquez la fonction directement, les erreurs d’invocation sont visibles dans la réponse de Lambda. Si vous invoquez la fonction de manière asynchrone avec un mappage de source d’événement ou via un autre service, vous pouvez trouver des erreurs dans les journaux, une file d’attente de lettres mortes ou une destination en cas d’échec. Les options de gestion des erreurs et le comportement des nouvelles tentatives varient en fonction de la façon dont vous invoquez la fonction et du type d’erreur. Pour obtenir la liste des types d’erreur que l’opération `Invoke` peut renvoyer, consultez [Invoquer](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html). **Topics** + [Lambda : expiration de la fonction pendant la phase d’initialisation (Sandbox.Timedout)](#troubleshooting-timeouts) + [IAM : lambda : non autorisé InvokeFunction](#troubleshooting-invocation-noauth) + [Lambda : Impossible de trouver un bootstrap valide (Runtime). InvalidEntrypoint)](#troubleshooting-invocation-bootstrap) + [Lambda : L'opération ne peut pas être effectuée ResourceConflictException](#troubleshooting-invocation-ResourceConflictException) + [Lambda : La fonction est bloquée à l’état Pending (En attente)](#troubleshooting-invocation-pending) + [Lambda : Une fonction utilise toute la simultanéité](#troubleshooting-invocation-allconcurrency) + [Général : Impossible d’invoquer la fonction avec d’autres comptes ou services](#troubleshooting-invocation-cannotinvoke) + [Général : L’invocation de la fonction boucle](#troubleshooting-invocation-loop) + [Lambda : Routage d’alias avec une simultanéité approvisionnée](#troubleshooting-invocation-alias) + [Lambda : Démarrages à froid avec la simultanéité allouée](#troubleshooting-invocation-coldstart) + [Lambda : Démarrages à froid avec de nouvelles versions](#troubleshooting-invocation-newversion) + [Lambda : sortie inattendue de Node.js pendant l'exécution (Runtime). NodejsExit)](#troubleshooting-invocation-nodejs-exit) + [EFS : La fonction n’a pas pu monter le système de fichiers EFS](#troubleshooting-invocation-efsmount) + [EFS : La fonction n’a pas pu se connecter au système de fichiers EFS](#troubleshooting-invocation-efsconnect) + [EFS : La fonction n’a pas pu monter le système de fichiers EFS en raison d’une expiration de délai](#troubleshooting-invocation-efstimeout) + [Lambda : Lambda a détecté un processus d’E/S qui prenait trop de temps](#troubleshooting-invocation-ioprocess) + [Conteneur : CodeArtifactUserException erreurs](#troubleshooting-deployment-container-artifact) + [Conteneur : InvalidEntrypoint erreurs](#troubleshooting-deployment-container-entrypoint) ## Lambda : expiration de la fonction pendant la phase d’initialisation (Sandbox.Timedout) **Erreur :** *Task timed out after 3.00 seconds* Lorsque la phase d’[initialisation](lambda-runtime-environment.md#runtimes-lifecycle-ib) expire, Lambda initialise à nouveau l’environnement d’exécution en relançant la phase `Init` lorsque la prochaine demande d’invocation arrive. Cela s’appelle une [init supprimée](lambda-runtime-environment.md#suppressed-init). Toutefois, si votre fonction est configurée avec un [délai d’expiration court](configuration-timeout.md) (généralement environ 3 secondes), l’initialisation supprimée risque de ne pas se terminer pendant le délai imparti, ce qui provoquera une nouvelle expiration de la phase `Init`. Sinon, l’initialisation supprimée se termine mais ne laisse pas suffisamment de temps à la phase d’[invocation](lambda-runtime-environment.md#runtimes-lifecycle-invoke) pour se terminer, ce qui entraîne l’expiration de la phase `Invoke`. Pour réduire les erreurs d’expiration, utilisez l’une des stratégies suivantes : + **Augmentez la durée du délai d’expiration de la fonction** : prolongez le [délai d’expiration](configuration-timeout.md) pour donner aux phases `Invoke` et `Init` et le temps de se terminer. + **Augmentez l’allocation de mémoire de la fonction** : plus de [mémoire](configuration-memory.md) signifie également une allocation plus proportionnelle du processeur, ce qui peut accélérer à la fois les phases `Invoke` et `Init`. + **Optimisez le code d’initialisation de la fonction** : réduisez le temps nécessaire à l’initialisation afin de garantir que les phases `Init` et `Invoke` puissent se terminer dans le délai configuré. ## IAM : lambda : non autorisé InvokeFunction **Erreur : L'utilisateur :** *arn:aws:iam : :123456789012 : l'utilisateur/développeur* n'est pas autorisé à exécuter : lambda : on resource : my-function InvokeFunction Votre utilisateur, ou le rôle que vous assumez, doit avoir une autorisation pour invoquer une fonction. Cette exigence s’applique également aux fonctions Lambda et à d’autres ressources de calcul qui invoquent des fonctions. Ajoutez le **AWSLambdarôle** de stratégie AWS géré à votre utilisateur ou ajoutez une politique personnalisée qui autorise l'`lambda:InvokeFunction`action sur la fonction cible. **Note** Le nom de l’action IAM (`lambda:InvokeFunction`) fait référence à l’opération de l’API Lambda `Invoke`. Pour plus d’informations, consultez [Gestion des autorisations dans AWS Lambda](lambda-permissions.md). ## Lambda : Impossible de trouver un bootstrap valide (Runtime). InvalidEntrypoint) **Erreur :** *Impossible de trouver un ou plusieurs bootstrap valides : [/var/task/bootstrap /opt/bootstrap]* Cette erreur se produit généralement lorsque la racine de votre package de déploiement ne contient pas de fichier exécutable nommé `bootstrap`. Par exemple, si vous déployez une fonction `provided.al2023` avec un fichier .zip, le fichier `bootstrap` doit se trouver à la racine du fichier .zip, et non dans un répertoire. ## Lambda : L'opération ne peut pas être effectuée ResourceConflictException **Erreur ResourceConflictException :** *Impossible d'effectuer l'opération pour le moment. La fonction est actuellement dans l’état suivant : En attente* Lorsque vous connectez une fonction à un cloud privé virtuel (Virtual Private Cloud, VPC) au moment de la création, la fonction passe à l’état `Pending` pendant que Lambda crée des interfaces réseau Elastic. Pendant ce temps, vous ne pouvez pas invoquer ni modifier votre fonction. Si vous connectez votre fonction à un VPC après la création, vous pouvez l’invoquer pendant que la mise à jour est en attente, mais vous ne pouvez pas modifier son code ni sa configuration. Pour plus d’informations, consultez [États de la fonction Lambda](functions-states.md). ## Lambda : La fonction est bloquée à l’état Pending (En attente) **Erreur :** *Une fonction est bloquée à l’état `Pending` depuis plusieurs minutes.* Si une fonction est bloquée à l’état `Pending` depuis plus de six minutes, appelez l’une des opérations d’API suivantes pour la débloquer : + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) Lambda annule l’opération en attente et met la fonction à l’état `Failed`. Vous pouvez ensuite essayer une autre mise à jour. ## Lambda : Une fonction utilise toute la simultanéité **Problème :** *une fonction utilise toute la simultanéité disponible, limitant ainsi d’autres fonctions.* Pour diviser la simultanéité disponible de votre AWS compte dans une AWS région en groupes, utilisez la simultanéité [réservée.](configuration-concurrency.md) La simultanéité réservée garantit qu’une fonction s’adapte toujours à la simultanéité qui lui est assignée et qu’elle n’utilise pas plus de simultanéité que ce qui lui est attribué. ## Général : Impossible d’invoquer la fonction avec d’autres comptes ou services **Problème :** *vous pouvez invoquer la fonction directement, mais elle ne s’exécute pas lorsqu’elle est invoquée par un autre service ou compte.* Vous accordez à [d’autres services](lambda-services.md) et comptes l’autorisation d’invoquer une fonction dans la [stratégie basée sur les ressources](access-control-resource-based.md)de la fonction. Si l’appelant se trouve dans un autre compte, cet utilisateur doit également avoir [l’autorisation d’invoquer des fonctions](access-control-identity-based.md). ## Général : L’invocation de la fonction boucle **Problème :** *La fonction est invoquée en continu dans une boucle.* Cela se produit généralement lorsque votre fonction gère les ressources du même AWS service qui la déclenche. Par exemple, il est possible de créer une fonction qui stocke un objet dans un compartiment Amazon Simple Storage Service (Amazon S3) configuré avec une [notification qui invoque à nouveau la fonction](with-s3.md). Pour arrêter l’exécution de la fonction, réduisez la [simultanéité](lambda-concurrency.md) disponible de votre fonction à zéro, ce qui limite toutes les invocations futures. Identifiez ensuite le chemin de code ou l’erreur de configuration qui a provoqué l’invocation récursive. Lambda détecte et arrête automatiquement les boucles récursives pour certains AWS services et. SDKs Pour de plus amples informations, veuillez consulter [Utilisation de la détection de boucle récursive Lambda pour prévenir les boucles infinies](invocation-recursion.md). ## Lambda : Routage d’alias avec une simultanéité approvisionnée **Problème:** *invocations de débordement de simultanéité approvisionnée pendant le routage d’alias.* Lambda utilise un modèle probabiliste simple pour distribuer le trafic entre les deux versions de la fonction. Quand le niveau de trafic est faible, il se peut que vous observiez une variance élevée entre les pourcentages de trafic configuré et réel sur chaque version. Si votre fonction utilise une simultanéité approvisionnée, vous pouvez éviter des [invocations de débordement](monitoring-metrics-types.md#invocation-metrics) en configurant un plus grand nombre d’instances de simultanéité approvisionnées pendant que le routage d’alias est actif. ## Lambda : Démarrages à froid avec la simultanéité allouée **Problème : ** *Vous remarquez des démarrages à froid après avoir activé la simultanéité allouée.* Lorsque le nombre d’exécutions simultanées sur une fonction est inférieur ou égal au [niveau de simultanéité configuré](provisioned-concurrency.md), il ne devrait pas y avoir de démarrage à froid. Pour vous aider à vérifier le bon fonctionnement de la simultanéité, procédez comme suit : + [Vérifiez que la simultanéité allouée est activée](provisioned-concurrency.md) sur la version de fonction ou l’alias. **Note** La simultanéité allouée n’est pas configurable sur la [version non publiée de la fonction](configuration-versions.md) (\$1LATEST). + Assurez-vous que vos déclencheurs invoquent la version ou l’alias de fonction correct. Par exemple, si vous utilisez Amazon API Gateway, vérifiez qu’API Gateway invoque la version de fonction ou l’alias avec la simultanéité approvisionnée, et non \$1LATEST. Pour confirmer que la simultanéité provisionnée est utilisée, vous pouvez consulter la métrique [ProvisionedConcurrencyInvocations Amazon CloudWatch ](monitoring-concurrency.md#provisioned-concurrency-metrics). Une valeur non nulle indique que la fonction traite des invocations sur les environnements d’exécution initialisés. + [Déterminez si la simultanéité de vos fonctions dépasse le niveau configuré de simultanéité provisionnée en vérifiant la métrique. ProvisionedConcurrencySpilloverInvocations CloudWatch](monitoring-concurrency.md#provisioned-concurrency-metrics) Une valeur différente de zéro indique que toute la simultanéité allouée est en cours d’utilisation et qu’une invocation s’est produite avec un démarrage à froid. + Vérifiez la [fréquence des invocations](gettingstarted-limits.md#api-requests) (demandes par seconde). Les fonctions avec simultanéité allouée ont un taux maximal de 10 demandes par seconde par simultanéité allouée. Par exemple, une fonction configurée avec une simultané allouée de 100 peut traiter 1 000 demandes par seconde. Si le taux d’invocations dépasse 1 000 requêtes par seconde, certains démarrages à froid peuvent se produire. ## Lambda : Démarrages à froid avec de nouvelles versions **Problème : ** *Vous notez des démarrages à froid lors du déploiement de nouvelles versions de votre fonction.* Lorsque vous mettez à jour un alias de fonction, Lambda déplace automatiquement la simultanéité approvisionnée vers la nouvelle version en fonction des pondérations configurées sur l’alias. **Erreur : KMSDisabled exception :** *Lambda n'a pas pu déchiffrer les variables d'environnement car la clé KMS utilisée est désactivée. Veuillez vérifier les paramètres de clé KMS de la fonction.* Cette erreur peut se produire si votre clé AWS Key Management Service (AWS KMS) est désactivée ou si l'autorisation permettant à Lambda d'utiliser la clé est révoquée. Si l’octroi est manquant, configurez la fonction pour utiliser une autre clé. Ensuite, réaffectez la clé personnalisée pour recréer l’octroi. ## Lambda : sortie inattendue de Node.js pendant l'exécution (Runtime). NodejsExit) **Problème :** le *client d'exécution Lambda a détecté un code de sortie Node.js inattendu*. Cette erreur se produit lorsque votre fonction se ferme avant que toutes les promesses ne soient réglées, par exemple en raison d'un bogue de code. Cela peut également se produire lorsque Node.js détecte un blocage empêchant le règlement des promesses. Cette erreur affecte uniquement les gestionnaires de style asynchrone, pas les gestionnaires de style rappel. **Runtimes concernés :** Node.js 18 et versions ultérieures. **Pour résoudre ce problème, procédez comme suit :** 1. Vérifiez que le code de votre fonction ne contient pas de promesses non réglées dans les gestionnaires asynchrones. 1. Assurez-vous que toutes les promesses sont correctement réglées (résolues ou rejetées) avant la fin de la fonction. 1. Vérifiez votre code pour détecter les conditions de course potentielles lors d'opérations asynchrones. Pour plus d'informations sur les codes de sortie de Node.js et l'arrêt des processus, consultez la [documentation Node.js](https://nodejs.org/docs/latest/api/process.html#exit-codes). ## EFS : La fonction n’a pas pu monter le système de fichiers EFS **Erreur EFSMount FailureException :** *La fonction n'a pas pu monter le système de fichiers EFS avec le point d'accès arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd*. La demande de montage sur le [système de fichiers](configuration-filesystem.md) de la fonction a été rejetée. Vérifiez les autorisations de la fonction et confirmez que son système de fichiers et son point d’accès existent et sont prêts à l’emploi. ## EFS : La fonction n’a pas pu se connecter au système de fichiers EFS **Erreur EFSMount ConnectivityException :** *La fonction n'a pas pu se connecter au système de fichiers Amazon EFS avec le point d'accès arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd. Vérifiez la configuration de votre réseau et réessayez.* La fonction n’a pas pu établir de connexion au [système de fichiers](configuration-filesystem.md) de la fonction avec le protocole NFS (port TCP 2049). Vérifiez le [groupe de sécurité et la configuration de routage](https://docs.aws.amazon.com/efs/latest/ug/network-access.html) pour les sous-réseaux du VPC. Si vous rencontrez ces erreurs après avoir mis à jour les paramètres de configuration VPC de votre fonction, essayez de démonter puis de remonter le système de fichiers. ## EFS : La fonction n’a pas pu monter le système de fichiers EFS en raison d’une expiration de délai **Erreur EFSMount TimeoutException :** *La fonction n'a pas pu monter le système de fichiers EFS avec le point d'accès \$1arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd*\$1 en raison d'un délai de montage dépassé. La fonction a pu se connecter au [système de fichiers](configuration-filesystem.md) de la fonction, mais l’opération de montage a expiré. Réessayez après un court laps de temps et envisagez de limiter la [concurrence](configuration-concurrency.md) de la fonction pour réduire la charge sur le système de fichiers. ## Lambda : Lambda a détecté un processus d’E/S qui prenait trop de temps *EFSIOException: Cette instance de fonction a été arrêtée car Lambda a détecté un processus d'E/S trop long.* Une invocation précédente a expiré et Lambda n’a pas pu mettre fin à l’exécution du gestionnaire de fonction. Ce problème peut se produire lorsqu’un système de fichiers joint manque de crédits de rafale et que le débit de base est insuffisant. Pour augmenter le débit, vous pouvez augmenter la taille du système de fichiers ou utiliser le débit provisionné. ## Conteneur : CodeArtifactUserException erreurs **Erreur :** *message CodeArtifactUserPendingException d'erreur* L'optimisation CodeArtifact est en attente. La fonction passera à l’[état Actif](functions-states.md) lorsque Lambda aura terminé l’optimisation. Code de réponse HTTP : 409. **Erreur :** *message CodeArtifactUserDeletedException d'erreur* CodeArtifact Il est prévu de le supprimer. Code de réponse HTTP : 409. **Erreur :** *message CodeArtifactUserFailedException d'erreur* Lambda n'a pas réussi à optimiser le code. Vous devez corriger le code et le charger à nouveau. Code de réponse HTTP : 409. ## Conteneur : InvalidEntrypoint erreurs **Erreur :** *Runtime. ExitError ou « ErrorType » : « Runtime. InvalidEntrypoint*« Vérifiez que l'ENTRYPOINT de votre image de conteneur inclut le chemin absolu comme emplacement. Vérifiez également que l'image ne contient pas de lien symbolique en tant qu'ENTRYPOINT. **Erreur :** *vous utilisez un CloudFormation modèle et votre conteneur ENTRYPOINT est remplacé par une valeur nulle ou* vide. Passez en revue la [ImageConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-lambda-function-imageconfig.html)ressource dans le CloudFormation modèle. Si vous déclarez une ressource `ImageConfig` dans votre modèle, vous devez fournir des valeurs non vides pour les trois propriétés. # 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](troubleshooting-invocation.md). **Topics** + [Lambda : débogage à distance avec Visual Studio Code](#troubleshooting-execution-remote-debugging) + [Lambda : l’exécution prend trop de temps](#troubleshooting-execution-toolong) + [Lambda : données utiles d’événement imprévu](#troubleshooting-execution-unexpected-payload) + [Lambda : données utiles plus volumineuses qu’attendu](#troubleshooting-execution-large-payload) + [Lambda : erreurs de codage et de décodage JSON](#troubleshooting-execution-json-encoding) + [Lambda : les journaux ou les traces n’apparaissent pas](#troubleshooting-execution-logstraces) + [Lambda : certains journaux de ma fonction n’apparaissent pas](#troubleshooting-execution-missinglogs) + [Lambda : la fonction renvoie avant la fin de l’exécution](#troubleshooting-execution-unfinished) + [Lambda : exécution d’une version ou d’un alias de fonction imprévu](#unintended-function) + [Lambda : détection de boucles infinies](#infinite-loops) + [Général : indisponibilité du service en aval](#downstream-unavailability) + [AWS SDK : versions et mises à jour](#troubleshooting-execution-versions) + [Python : les bibliothèques se chargent de manière incorrecte](#troubleshooting-execution-libraries) + [Java : votre fonction met plus de temps à traiter les événements après la mise à jour de Java 11 vers Java 17](#troubleshooting-execution-java-perf) + [Kafka : Problèmes de gestion des erreurs et de configuration des nouvelles tentatives](#troubleshooting-kafka-error-handling) ## Lambda : débogage à distance avec Visual Studio Code **Problème :** *difficulté à résoudre les problèmes liés au comportement complexe des fonctions Lambda dans l'environnement réel AWS * Lambda fournit une fonctionnalité de débogage à distance via AWS Toolkit for Visual Studio Code. Pour instructions générales et de configuration, consultez [Déboguer à distance des fonctions Lambda avec Visual Studio Code](debugging.md). Pour obtenir des instructions détaillées sur le dépannage, les cas d'utilisation avancés et la disponibilité régionale, consultez la section [Débogage à distance des fonctions Lambda](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html) dans AWS Toolkit for Visual Studio Code le guide de l'utilisateur. ## 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](configuration-memory.md) pour augmenter à la fois la mémoire et la capacité d’UC. ## Lambda : données utiles d’événement imprévu **Problème :** *erreurs de fonctionnement liées à du JSON mal formé ou à une validation inadéquate des données*. Toutes les fonctions Lambda reçoivent des données utiles d’événement dans le premier paramètre du gestionnaire. Les données utiles de l’événement sont une structure JSON qui peut contenir des tableaux et des éléments imbriqués. Un JSON mal formé peut se produire lorsqu’il est fourni par des services en amont qui n’utilisent pas de processus robuste pour vérifier les structures JSON. Cela se produit lorsque les services concatènent des chaînes de texte ou intègrent des entrées utilisateur qui n’ont pas été nettoyées. Le JSON est également fréquemment sérialisé pour le transfert d’un service à l’autre. Analysez toujours les structures JSON en tant que producteur et consommateur de JSON pour vous assurer que la structure est valide. De même, le fait de ne pas vérifier les plages de valeurs dans les données utiles de l’événement peut entraîner des erreurs. L’exemple suivant montre une fonction qui calcule une retenue d’impôt : ``` exports.handler = async (event) => { let pct = event.taxPct let salary = event.salary // Calculate % of paycheck for taxes return (salary * pct) } ``` Cette fonction utilise un salaire et un taux d’imposition issus des données utiles de l’événement pour effectuer le calcul. Cependant, le code ne vérifie pas si les attributs sont présents. Il ne vérifie pas non plus les types de données ou ne garantit pas les limites, par exemple en s’assurant que le pourcentage de taxe est compris entre 0 et 1. Par conséquent, les valeurs situées en dehors de ces limites produisent des résultats absurdes. Un type incorrect ou un attribut manquant provoque une erreur d’exécution. Créez des tests pour vous assurer que votre fonction gère des données utiles plus importantes. La taille maximale des données utiles d’un événement Lambda est de 1 Mo. Selon le contenu, des données utiles plus importantes peuvent entraîner la transmission d’un plus grand nombre d’éléments à la fonction ou l’intégration d’un plus grand nombre de données binaires dans un attribut JSON. Dans les deux cas, cela peut entraîner un traitement supplémentaire pour une fonction Lambda. Des données utiles plus importantes peuvent également entraîner des délais d’expiration. Par exemple, une fonction Lambda traite un enregistrement toutes les 100 ms et son délai d’expiration est de 3 secondes. Le traitement est réussi pour 0 à 29 éléments des données utiles. Cependant, une fois que les données utiles contiennent plus de 30 éléments, la fonction expire et génère une erreur. Pour éviter cela, assurez-vous que les délais sont définis de manière à gérer le temps de traitement supplémentaire pour le nombre maximal d’éléments attendus. ## Lambda : données utiles plus volumineuses qu’attendu **Problème :** *les fonctions expirent ou provoquent des erreurs en raison de données utiles volumineuses.* Des données utiles plus importantes peuvent entraîner des expirations de délai et des erreurs. Nous vous recommandons de créer des tests pour vous assurer que votre fonction gère les données utiles attendues les plus importantes et vous assurer que le délai d’expiration de la fonction est correctement défini. Par ailleurs, certaines données utiles d’événements peuvent contenir des pointeurs vers d’autres ressources. Par exemple, une fonction Lambda dotée de 128 Mo de mémoire peut effectuer le traitement d’image sur un fichier JPG stocké sous forme d’objet dans S3. La fonction fonctionne comme prévu avec des fichiers image plus petits. Toutefois, lorsqu’un fichier JPG plus volumineux est fourni en entrée, la fonction Lambda génère une erreur en raison d’un manque de mémoire. Pour éviter cela, les cas de test doivent inclure des exemples tirés des limites supérieures des tailles de données attendues. Le code doit également valider les tailles des données utiles. ## Lambda : erreurs de codage et de décodage JSON **Problème : NoSuchKey ** *exception lors de l'analyse des entrées JSON*. Vérifiez que vous traitez correctement les attributs JSON. Par exemple, pour les événements générés par S3, l’attribut `s3.object.key` contient un nom de clé d’objet codé par URL. De nombreuses fonctions traitent cet attribut sous forme de texte pour charger l’objet S3 référencé : **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: event.Records[0].s3.object.key }).promise() ``` Ce code fonctionne avec le nom de clé `james.jpg`, mais génère une erreur `NoSuchKey` lorsque le nom est `james beswick.jpg`. Étant donné que le codage URL convertit les espaces et les autres caractères d’un nom de clé, vous devez vous assurer que les fonctions décodent les clés avant d’utiliser ces données : **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " ")) }).promise() ``` ## 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](lambda-intro-execution-role.md) 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, modifiez légèrement son code ou 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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html), 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 votre débit de journaux dépasse 2 MB/s pour un seul flux de journaux. Si votre fonction est configurée pour utiliser des [journaux au format JSON](monitoring-cloudwatchlogs-logformat.md), Lambda essaie d'envoyer [`logsDropped`](telemetry-schema-reference.md#platform-logsDropped)un événement CloudWatch à Logs lorsqu'il 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 : 1. Ouvrez la console [Service Quotas](https://console.aws.amazon.com/servicequotas). 1. Dans le panneau de navigation, choisissez **Services AWS **. 1. Dans la liste des **AWS services**, recherchez Amazon CloudWatch Logs. 1. Dans la liste des **quotas de service**, choisissez les quotas `CreateLogGroup throttle limit in transactions per second`, `CreateLogStream throttle limit in transactions per second` et `PutLogEvents throttle limit in transactions per second` pour 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éation d'une CloudWatch alarme basée sur un seuil statique](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) 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](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html). ## 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 le 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éfinition du gestionnaire de fonction Lambda dans Node.js](nodejs-handler.md). ## Lambda : exécution d’une version ou d’un alias de fonction imprévu **Problème :** *la version ou l’alias de la fonction n’est pas invoqué* Lorsque vous publiez de nouvelles fonctions Lambda dans la console ou que vous utilisez AWS SAM, la dernière version du code est représentée par. `$LATEST` Par défaut, les invocations qui ne spécifient pas de version ou d’alias ciblent automatiquement la version `$LATEST` du code de votre fonction. Si vous utilisez des versions de fonction ou des alias spécifiques, il s’agit de versions publiées immuables d’une fonction en plus de `$LATEST`. Lors du dépannage de ces fonctions, déterminez d’abord si l’appelant a invoqué la version ou l’alias souhaité. Vous pouvez le faire en consultant vos journaux de fonction. La version de la fonction qui a été invoquée est toujours affichée dans la ligne de journal START : ![\[opérations de débogage (illustration 1)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-1.png) ## Lambda : détection de boucles infinies **Problème :** *modèles de boucles infinis liés aux fonctions Lambda* Il existe deux types de boucles infinies dans les fonctions Lambda. Le premier se trouve dans la fonction elle-même, à cause d’une boucle qui ne sort jamais. L’invocation prend fin uniquement lorsque la fonction expire. Vous pouvez identifier ces boucles en surveillant les expirations de délai, puis en corrigeant le comportement de bouclage. Le second type de boucle se situe entre les fonctions Lambda et les autres AWS ressources. Elles se produisent lorsqu’un événement provenant d’une ressource telle qu’un compartiment S3 appelle une fonction Lambda, qui interagit ensuite avec la même ressource source pour déclencher un autre événement. Cela invoque à nouveau la fonction, qui crée une autre interaction avec le même compartiment S3, et ainsi de suite. Ces types de boucles peuvent être provoqués par différentes sources d' AWS événements, notamment les files d'attente Amazon SQS et les tables DynamoDB. Vous pouvez utiliser la [détection de boucle récursive](invocation-recursion.md) pour identifier ces modèles. ![\[opérations de débogage (illustration 2)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-2.png) Vous pouvez éviter ces boucles en veillant à ce que les fonctions Lambda écrivent dans des ressources différentes de celles qui les consomment. Si vous devez republier les données sur la ressource consommatrice, assurez-vous que les nouvelles données ne déclenchent pas le même événement. Vous pouvez également utiliser le [filtrage des événements](invocation-eventfiltering.md). Par exemple, voici deux solutions proposées pour les boucles infinies avec les ressources S3 et DynamoDB : + Si vous réécrivez dans le même compartiment S3, utilisez un préfixe ou un suffixe différent de celui du déclencheur d’événement. + Si vous écrivez des éléments dans la même table DynamoDB, incluez un attribut sur lequel une fonction Lambda consommatrice peut filtrer. Si Lambda trouve l’attribut, il n’en résultera aucune autre invocation. ## Général : indisponibilité du service en aval **Problème :** *les services en aval sur lesquels repose votre fonction Lambda ne sont pas disponibles* Pour les fonctions Lambda qui font appel à des points de terminaison tiers ou à d’autres ressources en aval, assurez-vous qu’elles sont capables de gérer les erreurs de service et les délais d’expiration. Ces ressources en aval peuvent avoir des temps de réponse variables ou devenir indisponibles en raison d’interruptions de service. Selon l’implémentation, ces erreurs en aval peuvent apparaître sous forme de délais d’expiration ou d’exceptions Lambda, si la réponse d’erreur du service n’est pas traitée dans le code de la fonction. Chaque fois qu’une fonction dépend d’un service en aval, tel qu’un appel d’API, implémentez une gestion des erreurs et une logique de nouvelle tentative appropriées. Pour les services critiques, la fonction Lambda doit publier des métriques ou des journaux sur. CloudWatch Par exemple, si une API de paiement tierce n’est plus disponible, votre fonction Lambda peut journaliser ces informations. Vous pouvez ensuite configurer des CloudWatch alarmes pour envoyer des notifications relatives à ces erreurs. Étant donné que Lambda peut rapidement se mettre à l’échelle, les services en aval avec serveur peuvent avoir du mal à gérer les pics de trafic. Il existe trois approches courantes pour gérer ce problème : + **Mise en cache** : envisagez de mettre en cache le résultat des valeurs renvoyées par des services tiers si elles ne changent pas fréquemment. Vous pouvez stocker ces valeurs dans une variable globale, dans votre fonction ou dans un autre service. Par exemple, les résultats d’une requête de liste de produits provenant d’une instance Amazon RDS peuvent être enregistrés pendant un certain temps dans la fonction afin d’éviter les requêtes redondantes. + **Mise en file d’attente** : lors de l’enregistrement ou de la mise à jour de données, ajoutez une file d’attente Amazon SQS entre la fonction Lambda et la ressource. La file d’attente conserve les données de manière durable pendant que le service en aval traite les messages. + **Proxies** : lorsque des connexions de longue durée sont généralement utilisées, comme pour les instances Amazon RDS, utilisez une couche proxy pour regrouper et réutiliser ces connexions. Pour les bases de données relationnelles, le [Proxy Amazon RDS](https://github.com/aws-samples/s3-to-lambda-patterns/tree/master/docrepository) est un service conçu pour améliorer la capacité de mise à l’échelle et la résilience des applications basées sur Lambda. ## AWS SDK : versions et mises à jour **Problème :** *le AWS SDK inclus dans le moteur d'exécution n'est pas la dernière version* **Problème :** *le AWS SDK inclus dans le moteur d'exécution est automatiquement mis à jour* Les environnements d'exécution pour les langages interprétés incluent une version du AWS SDK. Lambda met régulièrement à jour ces environnements d’exécution pour utiliser la dernière version du SDK. Pour trouver la version du SDK incluse dans votre environnement d’exécution, consultez les sections suivantes : + [Versions du SDK incluses dans l’environnement d’exécution (Node.js)](lambda-nodejs.md#nodejs-sdk-included) + [Versions du SDK incluses dans l’environnement d’exécution (Python)](lambda-python.md#python-sdk-included) + [Versions du SDK incluses dans l’environnement d’exécution (Ruby)](lambda-ruby.md#ruby-sdk-included) 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](chapter-layers.md). Pour plus d’informations sur la création d’un package de déploiement avec des dépendances, consultez les rubriques suivantes : ------ #### [ Node.js ] [Déployer des fonctions Lambda en Node.js avec des archives de fichiers .zip](nodejs-package.md) ------ #### [ Python ] [Travailler avec des archives de fichiers .zip pour les fonctions Lambda Python](python-package.md) ------ #### [ Ruby ] [Déployer des fonctions Lambda en Ruby avec des archives de fichiers .zip](ruby-package.md) ------ #### [ Java ] [Déployer des fonctions Lambda en Java avec des archives de fichiers .zip ou JAR](java-package.md) ------ #### [ Go ] [Déployer des fonctions Lambda Go avec des archives de fichiers .zip](golang-package.md) ------ #### [ C\$1 ] [Créez et déployez des fonctions Lambda C\$1 à l’aide des archives de fichiers .zip](csharp-package.md) ------ #### [ PowerShell ] [Déployer des fonctions Lambda PowerShell avec des archives de fichiers .zip](powershell-package.md) ------ ## 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\$1\$1 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](python-package.md). ## Java : votre fonction met plus de temps à traiter les événements après la mise à jour de Java 11 vers Java 17 **Probè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 paramètre `JAVA_TOOL_OPTIONS`. Les environnements d’exécution Lambda pour Java 17 et versions ultérieures 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 gourmandes en calcul. Définissez `JAVA_TOOL_OPTIONS` sur `-XX:-TieredCompilation` pour revenir au comportement de Java 11. Pour plus d’informations sur le paramètre `JAVA_TOOL_OPTIONS`, consultez [Présentation de la variable d’environnement `JAVA_TOOL_OPTIONS`](java-customization.md#java-tool-options). ## Kafka : Problèmes de gestion des erreurs et de configuration des nouvelles tentatives **Problème :** le *mappage de la source d'événements Kafka ne parvient pas à configurer les paramètres de nouvelle tentative ou les destinations* en cas d'échec Les configurations de nouvelle tentative de Kafka et les destinations en cas d'échec ne sont disponibles que pour les mappages de sources d'événements avec le mode provisionné activé. Assurez-vous d'avoir configuré votre configuration `ProvisionedPollerConfig` avant `MinimumPollers` de tenter de définir des configurations de nouvelle tentative. Erreurs de configuration courantes : + **Nombre infini de tentatives avec un lot divisé en deux** : vous ne pouvez pas l'activer `BisectBatchOnFunctionError` lorsque `MaximumRetryAttempts` ce paramètre est défini sur -1 (infini). Définissez une limite de tentatives limitée ou désactivez le traitement par lots en deux. + **Récursivité sur le même sujet** — Le sujet de destination de Kafka en cas d'échec ne peut être identique à aucun de vos sujets source. Choisissez un autre nom de sujet pour votre sujet lettre morte. + **Format de destination Kafka non valide** : utilisez le `kafka://` format lorsque vous spécifiez un sujet Kafka comme destination en cas d'échec. + **kafka : problèmes WriteData d'autorisation** — Assurez-vous que votre rôle d'exécution dispose `kafka-cluster:WriteData` des autorisations pour le sujet de destination. Le sujet n'existe pas, les exceptions de délai d'expiration ou les problèmes de limitation de l'API d'écriture peuvent nécessiter une augmentation des limites du compte. # Résoudre les problèmes de mappage des sources d’événements dans Lambda Dans Lambda, les problèmes liés au [mappage des sources d’événements](invocation-eventsourcemapping.md) peuvent être plus complexes, car ils impliquent le débogage sur plusieurs services. De plus, le comportement de la source d’événements peut différer en fonction de la source d’événements exacte utilisée. Cette section répertorie les problèmes courants liés aux mappages des sources d’événements et fournit des conseils sur la manière de les identifier et de les résoudre. **Note** Cette section utilise une source d’événements Amazon SQS à titre d’illustration, mais les principes s’appliquent aux autres mappages des sources d’événements qui mettent en file d’attente des messages pour les fonctions Lambda. ## Identification et gestion de la limitation Dans Lambda, la limitation se produit lorsque vous atteignez la limite de simultanéité de votre fonction ou de votre compte. Prenons l’exemple suivant, où une fonction Lambda lit les messages d’une file d’attente Amazon SQS. Cette fonction Lambda simule des appels de 30 secondes et a une taille de lot de 1. Cela signifie que la fonction ne traite qu’un seul message toutes les 30 secondes : ``` const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms)) exports.handler = async (event) => { await doWork(30000) } ``` Avec une durée d’invocation aussi longue, les messages commencent à arriver dans la file d’attente plus rapidement qu’ils sont traités. Si la simultanéité non réservée de votre compte est de 100, Lambda augmente verticalement jusqu’à 100 exécutions simultanées, puis une limitation se produit. Vous pouvez voir ce schéma dans les métriques CloudWatch relatives à la fonction : ![\[opérations de débogage (illustration 10)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-10.png) Les métriques CloudWatch relatives à la fonction n’indiquent aucune erreur, mais le graphique **Exécutions simultanées** indique que la simultanéité maximale de 100 est atteinte. Par conséquent, le graphique **Limitations** montre la limitation en place. Vous pouvez détecter la limitation avec les alarmes CloudWatch et en définissant une alarme chaque fois que la métrique de limitation d’une fonction est supérieure à 0. Après avoir identifié le problème de limitation, plusieurs options s’offrent à vous pour le résoudre : + Demander une augmentation de la simultanéité auprès d’AWS Support dans cette région. + Identifier les problèmes de performance de la fonction afin d’améliorer la vitesse de traitement et donc le débit. + Augmenter la taille du lot de la fonction, de sorte que davantage de messages soient traités à chaque invocation. ## Erreurs dans la fonction de traitement Si la fonction de traitement génère des erreurs, Lambda renvoie les messages dans la file d’attente SQS. Lambda empêche la mise à l’échelle de votre fonction afin d’éviter les erreurs à grande échelle. Les métriques SQS suivantes dans CloudWatch indiquent qu’il existe un problème de traitement des files d’attente : ![\[opérations de débogage (illustration 11)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-11.png) En particulier, l’âge du message le plus ancien et le nombre de messages visibles augmentent, alors qu’aucun message n’est supprimé. La file d’attente continue de croître, mais les messages ne sont pas traités. Les métriques CloudWatch relatives à la fonction Lambda de traitement indiquent également l’existence d’un problème : ![\[opérations de débogage (illustration 12)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-12.png) La métrique du **Nombre d’erreurs** est différente de zéro et augmente, tandis que les **Exécutions simultanées** ont diminué et que la limitation a cessé. Cela montre que Lambda a cessé de se mettre à l’échelle votre fonction en raison d’erreurs. Les journaux CloudWatch de cette fonction fournissent des informations détaillées sur le type d’erreur. Vous pouvez résoudre ce problème en identifiant la fonction à l’origine de l’erreur, puis en recherchant et en résolvant l’erreur. Après avoir corrigé l'erreur et déployé le nouveau code de fonction, les métriques CloudWatch devraient indiquer que le traitement a repris : ![\[opérations de débogage (illustration 13)\]](http://docs.aws.amazon.com/fr_fr/lambda/latest/dg/images/debugging-ops-figure-13.png) Ici, la métrique **Nombre d’erreurs** tombe à zéro et la métrique **Taux de réussite** revient à 100 %. Lambda recommence à augmenter verticalement la fonction, comme indiqué dans le graphique **Exécutions simultanées**. ## Identification et gestion de la contre-pression Si un producteur d’événements génère régulièrement des messages pour une file d’attente SQS plus rapidement qu’une fonction Lambda peut le gérer, une contre-pression se produit. Dans ce cas, la surveillance SQS doit indiquer que l’âge du message le plus ancien augmente de façon linéaire, ainsi que le nombre approximatif de messages visibles. Vous pouvez détecter la contre-pression dans les files d’attente à l’aide des alarmes CloudWatch. Les étapes à suivre pour remédier à la contre-pression dépendent de votre charge de travail. Si l’objectif principal est d’augmenter la capacité de traitement et le débit par la fonction Lambda, plus options se présentent à vous : + Demander une augmentation de la simultanéité dans la région concernée auprès d’AWS Support. + Augmenter la taille du lot de la fonction, de sorte que davantage de messages soient traités à chaque invocation. # Résolution des problèmes de réseaux dans Lambda Par défaut, Lambda exécute vos fonctions dans un cloud privé virtuel (Virtual Private Cloud, VPC) interne disposant d’connectivité aux services AWS et à Internet. Pour accéder aux ressources réseau en local, vous pouvez [configurer votre fonction afin qu’elle se connecte à un VPC de votre compte](configuration-vpc.md). Lorsque vous utilisez cette fonctionnalité, vous gérez l’accès Internet et la connectivité réseau de la fonction avec les ressources Amazon Virtual Private Cloud (Amazon VPC). Les erreurs de connectivité réseau peuvent être dues à des problèmes liés à la configuration du routage de votre VPC, aux règles du groupe de sécurité, aux autorisations de rôle Gestion des identités et des accès AWS (IAM) ou à la traduction d'adresses réseau (NAT), ou à la disponibilité de ressources telles que les adresses IP ou les interfaces réseau. En fonction du problème, vous pouvez voir une erreur spécifique ou un délai d’attente si une requête ne peut pas atteindre sa destination. **Topics** + [VPC : la fonction perd l’accès à Internet ou expire](#troubleshooting-networking-cfn) + [VPC : échec intermittent de la connexion TCP ou UDP](#troubleshooting-networking-tcp-udp) + [VPC : la fonction doit être accessible Services AWS sans utiliser Internet](#troubleshooting-networking-access) + [VPC : limite d’interface réseau Elastic atteinte](#troubleshooting-networking-limit) + [EC2: interface réseau élastique de type « lambda »](#troubleshooting-networking-eni) + [DNS : échec de la connexion aux hôtes avec UNKNOWNHOSTEXCEPTION](#troubleshooting-networking-dns-tcp) ## VPC : la fonction perd l’accès à Internet ou expire **Problème :** *votre fonction Lambda perd l’accès Internet après la connexion à un VPC.* **Erreur :** *Error: connect ETIMEDOUT 176.32.98.189:443* **Erreur :** *Error: Task timed out after 10.00 seconds* **Erreur ReadTimeoutError :** *Le délai de lecture a expiré. (délai de lecture = 15)* Lorsque vous connectez une fonction à un VPC, toutes les demandes sortantes passent par le VPC. Pour vous connecter à Internet, configurez votre VPC pour envoyer le trafic sortant depuis le sous-réseau de la fonction vers une passerelle NAT dans un sous-réseau public. Pour obtenir plus d’informations et des exemples de configurations VPC, consultez [Activation de l’accès Internet pour les fonctions Lambda connectées à un VPC](configuration-vpc-internet.md). Si certaines de vos connexions TCP sont interrompues, consultez [VPC : échec intermittent de la connexion TCP ou UDP](#troubleshooting-networking-tcp-udp) si votre sous-réseau utilise une liste de contrôle d’accès (NACL). Dans le cas contraire, cela est probablement dû à la fragmentation des paquets. Les fonctions Lambda ne peuvent pas traiter les requêtes TCP fragmentées entrantes, car Lambda ne prend pas en charge la fragmentation IP pour TCP ou ICMP. ## VPC : échec intermittent de la connexion TCP ou UDP **Note** Ce problème ne s’applique que si votre sous-réseau utilise une [liste de contrôle d’accès (ACL) réseau](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html#nacl-basics). Le réseau ACLs n'est pas nécessaire pour que Lambda se connecte à vos sous-réseaux. **Problème :** *Lambda perd par intermittence la connexion à vos sous-réseaux VPC, pour lesquels vous avez configuré une liste de contrôle d’accès (ACL) réseau*. Pour les fonctions Lambda activées par VPC, AWS crée un [hyperplan ENIs](configuration-vpc.md#configuration-vpc-enis) dans le compte du client et utilise des ports éphémères pour connecter Lambda `1024` `65535` au VPC du client. Si vous utilisez le réseau ACLs dans le sous-réseau cible, vous devez autoriser la plage de ports à la fois `1024` `65535` pour TCP et UDP. Ne pas autoriser cette plage complète de ports peut entraîner des défaillances de connexion intermittentes. ## VPC : la fonction doit être accessible Services AWS sans utiliser Internet **Problème :** *Votre fonction Lambda doit être accessible Services AWS sans utiliser Internet*. Pour connecter une fonction Services AWS depuis un sous-réseau privé sans accès à Internet, utilisez des points de terminaison VPC. ## VPC : limite d’interface réseau Elastic atteinte **Erreur ENILimit ReachedException :** *La limite de l'interface Elastic network a été atteinte pour le VPC de la fonction*. Lorsque vous connectez une fonction Lambda à un VPC, Lambda crée une interface réseau Elastic pour chaque combinaison de sous-réseau et de groupe de sécurité attaché à cette fonction. Le quota de service par défaut est de 250 interfaces réseau par VPC. Pour demander une augmentation d’un quota, vous pouvez utiliser la [console Service Quotas](https://console.aws.amazon.com/servicequotas/home/services/lambda/quotas/L-9FEE3D26). ## EC2: interface réseau élastique de type « lambda » **Code d'erreur :** *client. OperationNotPermitted* **Message d’erreur :** *le groupe de sécurité ne peut pas être modifié pour ce type d’interface* Vous recevrez cette erreur si vous tentez de modifier une Interface réseau Elastic (ENI) gérée par Lambda. Le `ModifyNetworkInterfaceAttribute` n’est pas inclus dans l’API Lambda pour les opérations de mise à jour sur les interfaces réseau élastiques créées par Lambda. ## DNS : échec de la connexion aux hôtes avec UNKNOWNHOSTEXCEPTION **Message d’erreur :** *UNKNOWNHOSTEXCEPTION* Les fonctions Lambda prennent en charge un maximum de 20 connexions TCP simultanées pour la résolution DNS. Votre fonction est peut-être en train d’épuiser cette limite. Les requêtes DNS les plus courantes sont effectuées via UDP. Si votre fonction établit uniquement des connexions DNS UDP, il est peu probable que ce soit votre problème. Cette erreur est souvent due à une mauvaise configuration ou à une infrastructure dégradée. Par conséquent, avant d’examiner votre trafic DNS en profondeur, vérifiez que votre infrastructure DNS est correctement configurée et saine et que votre fonction Lambda fait référence à un hôte spécifié dans le DNS. Si vous diagnostiquez que votre problème est lié à la connexion TCP maximale, notez que vous ne pouvez pas demander d’augmentation de cette limite. Si votre fonction Lambda revient au DNS TCP en raison de données utiles DNS importantes, vérifiez que votre solution utilise des bibliothèques compatibles EDNS. Pour plus d’informations sur l’extension EDNS, consultez la [RFC 6891](https://datatracker.ietf.org/doc/html/rfc6891). Si vos données utiles DNS dépassent régulièrement les tailles maximales EDNS, votre solution risque d’épuiser la limite DNS TCP.