Gestion des erreurs et tentatives automatiques dans AWS Lambda - AWS Lambda

Gestion des erreurs et tentatives automatiques dans AWS Lambda

Lorsque vous appelez une fonction, deux types d'erreur peuvent se produire. Les erreurs d'invocation surviennent lorsque la demande d'invocation est rejetée avant sa réception par votre fonction. Les erreurs de fonction se produisent lorsque le code de votre fonction ou l'exécution renvoie une erreur. En fonction du type d'erreur, du type d'appel et du client ou du service qui appelle la fonction, le comportement de tentative et la stratégie de gestion des erreurs varient.

Des problèmes avec la demande, l'appelant ou le compte peuvent entraîner des erreurs d'appel. Les erreurs d'appel incluent un type d'erreur et un code d'état dans la réponse qui indiquent la cause de l'erreur.

Erreurs d'appel courantes

  • Demande – L'événement de demande est trop volumineux ou n'est pas un JSON valable, la fonction n'existe pas ou une valeur de paramètre est de type incorrect.

  • Appelant – L'utilisateur ou le service ne sont pas autorisés à appeler la fonction.

  • Compte – Le nombre maximum d'instances de fonctions sont déjà en cours d'exécution, ou les demandes sont réalisées trop rapidement.

Les clients comme AWS CLI et le kit AWS SDK effectuent de nouvelles tentatives selon les délais d'expiration du client, les erreurs de limitation (429) et d'autres erreurs qui ne sont pas causées par une demande erronée. Pour obtenir la liste complète des erreurs d'appel, consultez Appeler.

Les erreurs de fonction se produisent lorsque le code de votre fonction ou l'exécution qu'elle utilise renvoie une erreur.

Erreurs de fonction courantes

  • Fonction – Le code de votre fonction lève une exception ou renvoie un objet erreur.

  • Runtime – Le runtime a résilié votre fonction parce que celle-ci arrivait à expiration, parce qu'il a détecté une erreur de syntaxe, ou parce qu'il n'a pas réussi pu recueillir l'objet réponse dans JSON. La fonction est sortie avec un code d'erreur.

Contrairement aux erreurs d'appel, les erreurs de fonction ne conduisent pas Lambda à renvoyer un code d'état des séries 400 ou 500. Si la fonction renvoie une erreur, Lambda l'indique en incluant un en-tête nommé X-Amz-Function-Error, et une réponse au format JSON avec le message d'erreur et d'autres détails. Pour obtenir des exemples d’erreurs de fonction dans chaque langage, consultez les rubriques suivantes.

Lorsque vous invoquez une fonction directement, vous déterminez la stratégie de gestion des erreurs liées au code de votre fonction. Lambda ne réessaie pas automatiquement ce type d'erreur en votre nom. Pour réessayer, vous pouvez manuellement invoquer à nouveau votre fonction, envoyer l'événement échoué à une file d'attente pour le débogage, ou ignorer l'erreur. Le code de votre fonction peut s'exécuter entièrement, partiellement ou pas du tout. Si vous recommencez, assurez-vous que le code de votre fonction peut gérer le même événement plusieurs fois, sans provoquer des transactions en double ou d’autres effets secondaires.

Lorsque vous appelez une fonction indirectement, vous devez connaître le comportement de la nouvelle tentative de l’appelant et tout service que la demande rencontre sur le chemin. Cela inclut les scénarios suivants.

  • Appel asynchrone – Lambda réessaie deux fois les erreurs de fonction. Si la fonction ne dispose pas de la capacité suffisante pour gérer toutes les demandes entrantes, des événements peuvent attendre dans la file d'attente pendant des heures ou des jours avant d'être envoyés à la fonction. Vous pouvez configurer une file d'attente de lettres mortes sur la fonction pour capturer les événements qui n'ont pas été traitées avec succès. Pour de plus amples informations, veuillez consulter Appel asynchrone.

  • Mappages de source d'événement – Les mappages de source d'événement qui lisent à partir de flux réessaient la totalité du lot d'événements. Les erreurs répétées bloquent le traitement de la partition concernée jusqu'à la résolution de l'erreur ou l'expiration des éléments. Pour détecter des partitions bloquées, vous pouvez surveiller la métrique Âge de l'itérateur.

    Pour les mappages de source d'événement qui lisent à partir d'une file d'attente, vous devez déterminer l'intervalle entre les nouvelles tentatives et la destination pour les événements ayant échoué, en configurant le délai de visibilité et la stratégie de redirection dans la file d'attente source. Pour plus d'informations, consultez Mappage de source d’événement Lambda ainsi que les rubriques spécifiques du service dans Utilisation de AWS Lambda avec d'autres services.

  • Services AWS – Des services AWS peuvent appeler votre fonction de manière synchrone ou asynchrone. Dans le cas des appels synchrones, le service décide s'il convient d'effectuer une nouvelle tentative. Par exemple, les opérations par lot Amazon S3 retentent l'opération si la fonction Lambda renvoie un code de réponse TemporaryFailure. Les services avec requêtes proxy d'un utilisateur ou client en amont, peuvent également avoir une stratégie de nouvelle tentative ou relayer la réponse d'erreur au demandeur. Par exemple, API Gateway transmet toujours la réponse d'erreur au demandeur.

    Pour un appel asynchrone, le comportement est le même que lors de l'appel de la fonction de façon synchrone. Pour plus d'informations, consultez les rubriques spécifiques du service dans Utilisation de AWS Lambda avec d'autres services, ainsi que la documentation concernant le service appelant.

  • Autres comptes et clients – Lorsque vous accordez l'accès à d'autres comptes, vous pouvez utiliser des stratégies basées sur une ressource afin de restreindre les services ou ressources qu'ils peuvent configurer pour appeler votre fonction. Pour protéger votre fonction de toute surcharge, envisagez de placer une couche d'API devant votre fonction avec Amazon API Gateway.

Pour vous aider à gérer les erreurs dans les applications Lambda, Lambda s'intègre avec des services tels que Amazon CloudWatch et AWS X-Ray. Vous pouvez utiliser une combinaison de journaux, de mesures, d'alarmes et de suivi, pour détecter rapidement et d'identifier les problèmes dans le code de votre fonction, de l'API ou d'autres ressources qui prennent en charge votre application. Pour de plus amples informations, veuillez consulter Surveillance et dépannage des fonctions Lambda.

Pour un exemple d'application utilisant un abonnement CloudWatch Logs, un suivi X-Ray et une fonction Lambda pour détecter et traiter les erreurs, consultez Exemple d'application du processeur d'erreurs pour AWS Lambda.