Pourquoi mon déclencheur Kinesis Data Streams ne parvient-il pas à invoquer ma fonction Lambda ?

Brève description

Les causes courantes des erreurs liées à la fonction Lambda sont les suivantes :

• autorisations insuffisantes dans le rôle d’exécution de la fonction Lambda ;
• absence de donnée entrantes dans le flux de données Kinesis ;
• mappage des sources d’événements inactif causé par la recréation d’un flux de données Kinesis, d’une fonction Lambda ou d’un rôle d’exécution Lambda ;
• présence d’une fonction Lambda qui dépasse la durée d’exécution maximale et entraîne une erreur de dépassement de délai d’exécution dans la fonction Lambda.
• Lambda dépasse ses limites d’exécutions simultanées

En cas d’erreur de la fonction Lambda, celle-ci n’est pas invoquée. La fonction ne traite également plus les enregistrements issus du lot. Une erreur peut amener Lambda à réessayer le lot d’enregistrements jusqu’à ce que le processus réussisse ou que le lot expire. Pour plus d’informations sur la fonction Lambda et les erreurs liées à Kinesis, consultez Utilisation d’AWS Lambda avec Amazon Kinesis.

Résolution

Résoudre les problèmes liés à votre fonction Lambda

Pour savoir pourquoi votre fonction Lambda n’est pas invoquée, suivez les étapes ci-dessous :

1. Vérifiez la métrique Invocations dans Amazon CloudWatch avec les statistiques définies comme Somme pour la fonction Lambda. La métrique Invocations peut vous aider à vérifier si la fonction Lambda est invoquée.

2. Vérifiez la métrique IteratorAge pour connaître la date du dernier enregistrement du lot ou la date d’achèvement du processus. Lorsque votre consommateur Lambda n’est pas en mesure d’invoquer, l’âge de l’itérateur de votre flux augmente.

3. Consultez les journaux CloudWatch de la fonction Lambda. Ces journaux utilisent le format .../aws/lambda/function_name pour leurs noms. Recherchez les entrées correspondantes par rapport à l’erreur de fonction. Par exemple, si l’erreur se produit en raison des autorisations de rôle de la gestion des identités et des accès AWS (AWS IAM) de Lambda, modifiez la politique de rôle IAM.

4. Vérifiez que votre rôle IAM dispose bien des autorisations appropriées pour accéder à CloudWatch :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "logs:CreateLogGroup",
           "logs:CreateLogStream",
           "logs:PutLogEvents"
         ],
         "Resource": "*"
       }
     ]
   }

5. (Facultatif) En cas d’erreur d’autorisation, mettez à jour votre politique de fonction Lambda et accordez-lui l’accès à Kinesis Data Streams :

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "kinesis:DescribeStream",
           "kinesis:DescribeStreamSummary",
           "kinesis:GetRecords",
           "kinesis:GetShardIterator",
           "kinesis:ListShards",
           "kinesis:ListStreams",
           "kinesis:SubscribeToShard",
           "logs:CreateLogGroup",
           "logs:CreateLogStream",
           "logs:PutLogEvents"
         ],
         "Resource": "*"
       }
     ]
   }

   Remarque : la politique AWSLambdaKinesisExecutionRole comprend ces autorisations.

Résolution de problèmes supplémentaires

Pour résoudre les problèmes supplémentaires, effectuez les tâches suivantes :

Expiration du délai d’exécution de Lambda

Si l’erreur est liée à l’expiration du délai d’exécution d’une fonction Lambda, augmentez la valeur du délai pour accélérer le traitement.

Flux de données chiffré AWS KMS

Si vous utilisez AWS Key Management Service (AWS KMS) pour chiffrer votre flux de données Kinesis, le consommateur et le producteur doivent disposer d’un accès approprié. Le flux de données Kinesis doit pouvoir accéder aux clés AWS KMS utilisées pour le chiffrement et le déchiffrement. Le rôle d’exécution de la fonction Lambda doit également disposer d’un accès en lecture à la clé KMS pour lire correctement les données du flux de données Kinesis.

Erreur interne de la fonction Lambda

Si l’erreur est causée par une erreur interne de la fonction Lambda, alors le traitement du flux pose problème. Pour éviter toute limitation de l’API du plan de contrôle, limitez chaque flux à 4 ou 5 mappages des sources d’événements. Ces restrictions permettent d’éviter un trop grand nombre de mappages des sources d’événements avec le même flux de données. Les mappages des sources d’événements multiples avec le même flux peuvent entraîner une violation des limites du plan de contrôle de Kinesis et d’Amazon DynamoDB.

Erreur d’expiration du délai de connexion

Si vous obtenez une erreur d’expiration du délai de connexion, ajoutez d’abord des instructions de journalisation avant et après les appels d’API effectués dans votre code. Ensuite, identifiez la ligne de code exacte correspondant au début de l’échec de la fonction.

Partitions lentes ou bloquées

En cas de lenteur ou de blocage de vos partitions, configurez le mappage des sources d’événements afin de réessayer avec une taille de lot plus petite. Vous pouvez également limiter le nombre de tentatives ou supprimer les anciens enregistrements.

Erreur « Memory used »

Si un message d’erreur « Memory used » s’affiche dans vos journaux CloudWatch, augmentez la mémoire de votre fonction Lambda.

Délai d’expiration maximal dépassé

Si vous avez dépassé le délai d’expiration maximal de votre fonction Lambda, modifiez la bibliothèque cliente et les délais d’expiration du client. Pour modifier la session du délai d’expiration en fonction du temps d’exécution restant dans le conteneur Lambda, utilisez la fonction context.GetRemainingTimeInMillis. La fonction context.GetRemainingTimeInMillis renvoie le temps restant dans le conteneur Lambda avant son expiration.

Erreur de code de fonction Lambda

Si vous recevez des messages d’erreurs provenant du code de la fonction Lambda, il est possible que votre fonction Lambda soit bloquée après l’essai du même enregistrement. Utilisez un bloc de type « try-catch » pour récupérer les données qui n’ont pas été enregistrées. Utilisez ensuite une file d’attente Amazon Simple Queue Service (Amazon SQS) ou une rubrique Amazon Simple Notification Service (Amazon SNS) pour enregistrer ces données. Vous pouvez en outre ajouter un déclencheur Lambda à la file d’attente Amazon SQS en utilisant la logique de traitement pour réessayer de soumettre séparément les demandes échouées.

SQS DLQ

Configurez une file d’attente de lettres mortes Amazon SQS (DLQ) pour invoquer manuellement la fonction Lambda. Configurez la propriété DeadLetterConfig lorsque vous créez ou mettez à jour votre fonction Lambda. Vous pouvez fournir une file d’attente Amazon SQS ou une rubrique Amazon SNS comme TargetArn pour votre DLQ. Lambda écrit ensuite l’objet d’événement et invoque la fonction Lambda au point de terminaison spécifié une fois que la politique de nouvelle tentative standard est épuisée.

Lambda avec X-Ray

Utilisez Lambda avec AWS X-Ray pour détecter, analyser et optimiser les problèmes de performance des applications Lambda. X-Ray collecte les métadonnées du service Lambda et génère des graphiques qui décrivent les problèmes qui affectent les performances de l’application Lambda. Par exemple, si un appel prend beaucoup de temps à s’exécuter, vous pouvez utiliser AWS X-Ray pour confirmer le problème.