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.

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 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. Toutefois, si votre fonction est configurée avec un délai d’expiration court (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 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 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 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é.

• Ajoutez une gestion des erreurs : une gestion appropriée des erreurs dans le code de fonction peut empêcher l’échec de l’environnement d’exécution Lambda et le déclenchement de tentatives d’initialisation répétées.

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:InvokeFunctionaction 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 : 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.

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

• UpdateFunctionConfiguration

• PublishVersion

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. 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 et comptes l’autorisation d’invoquer une fonction dans la stratégie basée sur les ressourcesde la fonction. Si l’appelant se trouve dans un autre compte, cet utilisateur doit également avoir l’autorisation d’invoquer des fonctions.

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. Pour arrêter l’exécution de la fonction, réduisez la simultanéité 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.

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 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é, 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 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 ($LATEST).

• 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 $LATEST. Pour confirmer que la simultanéité provisionnée est utilisée, vous pouvez consulter la métrique ProvisionedConcurrencyInvocations Amazon CloudWatch . 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 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 (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.

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 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 de la fonction avec le protocole NFS (port TCP 2049). Vérifiez le groupe de sécurité et la configuration de routage 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 {arn:aws:elasticfilesystem:us-east- 2:123456789012:access-point/fsap-015cxmplb72b405fd} en raison d'un délai de montage dépassé.

La fonction a pu se connecter au système de fichiers 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 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é.