Résoudre les problèmes d’exécution dans Lambda

Lorsque le runtime Lambda exécute le code de fonction, l’événement peut être traité sur une instance de la fonction qui traite déjà les événements depuis un certain temps, ou nécessiter l’initialisation d’une nouvelle instance. Des erreurs peuvent se produire lors de l’initialisation de la fonction, lorsque le code de gestionnaire traite l’événement ou lorsque la fonction renvoie (ou ne parvient pas à renvoyer) une réponse.

Les erreurs d’exécution de fonction peuvent être causées par des problèmes de code, de configuration de fonction, de ressources en aval ou d’autorisations. Si vous appelez la fonction directement, les erreurs de fonction sont visibles dans la réponse de Lambda. Si vous appelez la fonction de manière asynchrone, avec un mappage de source d’événement ou via un autre service, vous pouvez trouver les erreurs dans les journaux, une file d’attente de lettres mortes ou une destination réservées aux échecs. Les options de gestion des erreurs et le comportement des nouvelles tentatives varient en fonction de la façon dont vous appelez la fonction et du type d’erreur.

Lorsque le code de fonction ou le runtime Lambda renvoient une erreur, le code d’état indiqué dans la réponse de Lambda est 200 OK. La présence d’une erreur dans la réponse est indiquée par un en-tête nommé X-Amz-Function-Error. Les codes d’état des séries 400 et 500 sont réservés aux erreurs d’invocation.

Lambda : l’exécution prend trop de temps

Problème : l’exécution de la fonction prend trop de temps.

Si l’exécution de votre code est beaucoup plus longue dans Lambda que sur votre ordinateur local, cela peut être dû à une limite au niveau de la mémoire ou de la puissance de traitement disponible pour la fonction. Configurez la fonction avec de la mémoire supplémentaire pour augmenter à la fois la mémoire et la capacité d’UC.

Lambda : charge utile liée à un événement inattendu

Problème : erreurs de fonctionnement liées à un 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 256 Ko. 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 : des charges utiles étonnamment importantes

Problème : les fonctions expirent ou provoquent des erreurs en raison de charges utiles importantes.

Des charges utiles plus importantes peuvent provoquer des délais d'attente et des erreurs. Nous vous recommandons de créer des tests pour vous assurer que votre fonction gère les charges utiles attendues les plus importantes et de vous assurer que le délai d'expiration de la fonction est correctement défini.

En outre, certaines charges 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 un 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 scénarios 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 de charge utile.

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's3.object.keyattribut 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é :

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 :

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 pour lui accorder l’autorisation. Ajoutez les stratégies gérées suivantes pour activer les journaux et le suivi.

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.

Lambda : certains journaux de ma fonction n’apparaissent pas

Problème : les journaux des fonctions sont absents dans CloudWatch les journaux, même si mes autorisations sont correctes

Si vous atteignez Compte AWS les limites de quota de CloudWatch journalisation, CloudWatch les régulateurs fonctionnent à la journalisation. Dans ce cas, certains journaux générés par vos fonctions peuvent ne pas apparaître dans CloudWatch les journaux.

Si votre fonction produit des journaux à un taux trop élevé pour que Lambda puisse les traiter, cela peut également empêcher les sorties des journaux d'apparaître dans CloudWatch les journaux. Lorsque Lambda ne parvient pas à envoyer des journaux CloudWatch à la vitesse à laquelle 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 suppression de journaux lorsque le débit de vos journaux dépasse 2 Mbit/s pour un seul flux de journaux.

Si votre fonction est configurée pour utiliser des journaux au format JSON, Lambda essaie d'envoyer logsDroppedun é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 :

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 pour en savoir plus.

Si les limites de quota par défaut pour CloudWatch les journaux ne sont pas suffisantes pour votre cas d'utilisation, vous pouvez demander une augmentation du quota.

Lambda : la fonction renvoie avant la fin de l’exécution

Problème : (Node.js) la fonction renvoie un objet avant la fin de l’exécution du code

De nombreuses bibliothèques, y compris 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.

Lambda : exécution d'une version ou d'un alias de fonction involontaire

Problème : la version de la fonction ou l'alias 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 appels qui ne spécifient pas de version ou d'alias ciblent automatiquement la $LATEST version de votre code de fonction.

Si vous utilisez des versions de fonction ou des alias spécifiques, il s'agit en plus de versions publiées immuables d'une fonction. $LATEST Lors du dépannage de ces fonctions, déterminez d'abord que l'appelant a invoqué la version ou l'alias souhaité. Vous pouvez le faire en consultant vos journaux de fonctions. La version de la fonction invoquée est toujours affichée dans la ligne du journal START :

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. La première se trouve dans la fonction elle-même, causée par une boucle qui ne s'arrête jamais. L'invocation prend fin uniquement lorsque la fonction expire. Vous pouvez les identifier en surveillant les délais d'expiration, puis en corrigeant le comportement en boucle.

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 appelle à nouveau la fonction, ce 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 pour identifier ces modèles.

Vous pouvez éviter ces boucles en vous assurant que les fonctions Lambda écrivent dans des ressources qui ne sont pas identiques à la ressource consommatrice. 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. Par exemple, voici deux solutions proposées pour les boucles infinies avec les ressources S3 et DynamoDB :

Généralités : 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 peuvent gérer les erreurs de service et les délais d'attente. 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 Lambda ou d'exceptions si la réponse d'erreur du service n'est pas traitée dans le code de 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 appropriée et une logique de nouvelle tentative. 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 devient indisponible, votre fonction Lambda peut enregistrer ces informations. Vous pouvez ensuite configurer des CloudWatch alarmes pour envoyer des notifications relatives à ces erreurs.

Comme Lambda peut évoluer rapidement, les services en aval non sans serveur peuvent avoir du mal à gérer les pics de trafic. Il existe trois approches courantes pour gérer ce problème :

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 :

Pour utiliser une version plus récente du AWS SDK ou pour verrouiller vos fonctions sur une version spécifique, vous pouvez regrouper la bibliothèque avec votre code de fonction ou créer une couche Lambda. Pour plus d’informations sur la création d’un package de déploiement avec des dépendances, consultez les rubriques suivantes :

Python : les bibliothèques se chargent de manière incorrecte

Problème : (Python) certaines bibliothèques ne se chargent pas correctement à partir du package de déploiement

Les bibliothèques avec des modules d’extension écrits en C ou C++ doivent être compilées dans un environnement avec la même architecture de processeur que Lambda (Amazon Linux). Pour de plus amples informations, veuillez consulter Travailler avec des archives de fichiers .zip pour les fonctions Lambda Python.

Java : votre fonction met plus de temps à traiter les événements après la mise à jour de Java 11 vers Java 17

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.