Pourquoi le déclencheur Kinesis Data Streams ne peut-il pas appeler ma fonction Lambda ?

Brève description

Les erreurs de fonction Lambda sont souvent causées par les éléments suivants :

• Autorisations insuffisantes dans le rôle d'exécution de la fonction Lambda.
• Aucune donnée entrante dans le flux de données Kinesis.
• Mappage de source d'événement 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.
• Fonction Lambda qui dépasse le temps limite d'exécution, ce qui entraîne une erreur de délai d'attente dans la fonction Lambda.
• Lambda dépasse ses limites d'exécutions simultanées. Pour plus d'informations sur Lambda dépassant ses limites, consultez Quotas AWS Lambda.

En cas d'erreur de fonction Lambda, votre fonction n'est pas invoquée et ne traite pas non plus les enregistrements du lot. Une erreur peut conduire Lambda à réessayer le lot d'enregistrements jusqu'à ce que le traitement aboutisse ou jusqu'à ce que le lot expire. Pour plus d'informations sur les erreurs de fonction Lambda et Kinesis, consultez Utilisation d'AWS Lambda avec Amazon Kinesis.

Résolution

Dépannage de votre fonction Lambda

Pour savoir pourquoi votre fonction Lambda n'est pas invoquée, effectuez les opérations suivantes :

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 l'âge du dernier enregistrement du lot ou la date du traitement. Lorsque votre consommateur Lambda n'est pas en mesure d'appeler, l'âge de l'itérateur de votre flux augmente.

3.    Vérifiez les journaux CloudWatch de la fonction Lambda. Ceux-ci sont nommés à l'aide de la fonction .../aws/lambda/nom_fonction. Recherchez les entrées correspondantes par rapport à l'erreur de fonction. Par exemple, si l'erreur se produit en raison des autorisations du rôle d'exécution de Lambda, modifiez la stratégie de rôle AWS Identity and Access Management (IAM).

4.    Vérifiez que votre rôle d'exécution IAM dispose 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) Si vous une erreur d'autorisation se produit, mettez à jour votre stratégie de fonction Lambda pour lui accorder 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 inclut ces autorisations.

Résolution des problèmes supplémentaires

• Si l'erreur est liée à un délai d'expiration de la fonction d'exécution Lambda, augmentez la valeur du délai d'expiration pour permettre un traitement plus rapide.
• Si votre flux de données Kinesis est chiffré à l'aide d'AWS Key Management Service (AWS KMS), le consommateur et le producteur doivent disposer d'un accès approprié. Le flux de données Kinesis doit être en mesure d'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.
• Si l'erreur est provoquée par une erreur de fonction Lambda interne, cette erreur indique un problème de traitement des flux. Pour éviter la limitation de l'API du plan de contrôle, limitez chaque flux à 4 ou 5 mappages de source d'événement.
• Si l'erreur est provoquée par une erreur de fonction Lambda interne, cette erreur indique un problème de traitement des flux. Limitez chaque flux à 4 ou 5 mappages de source d'événement pour éviter un trop grand nombre de mappages de source d'événement avec le même flux de données. Plusieurs mappages de source d'événement avec le même flux peuvent entraîner une violation des limites de plan de contrôle Kinesis et Amazon DynamoDB.
• Si vous obtenez une erreur de délai de connexion, ajoutez des instructions de journalisation avant et après les appels d'API effectués dans votre code. Vous pouvez ensuite identifier la ligne de code exacte où la fonction commence à échouer.
• Si vous rencontrez des partitions lentes ou bloquées, configurez le mappage de source d'événement pour réessayer avec une taille de lot plus petite. Vous pouvez également limiter le nombre de nouvelles tentatives ou ignorer les enregistrements anciens.
• Si vous voyez un message d'erreur « mémoire utilisée » dans vos journaux CloudWatch Logs, augmentez la mémoire de votre fonction Lambda.
• Si vous avez dépassé le délai maximum pour votre fonction Lambda, modifiez les délais d'attente de la bibliothèque client et du client. Pour modifier la session de délai d'expiration en fonction du temps 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.
• Si vous recevez des erreurs du code de la fonction Lambda, votre fonction Lambda peut se bloquer en essayant le même enregistrement. Utilisez un bloc try-catch pour intercepter les données ayant échoué, puis enregistrez-le à l'aide d'une file d'attente Amazon SQS ou d'une rubrique Amazon SNS. Vous pouvez également ajouter un déclencheur Lambda à la file d'attente Amazon SQS avec la logique de traitement pour réessayer séparément les demandes ayant échoué.
• Configurez une file d'attente de lettres mortes (DLQ) Amazon SQS pour appeler 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 Simple Queue Service (Amazon SQS) ou une rubrique Amazon Simple Notification Service (Amazon SNS) en tant que TargetArn pour votre DLQ. Lambda écrit ensuite l'objet d'événement en appelant la fonction Lambda sur le point de terminaison spécifié une fois que la politique de nouvelle tentative standard a été épuisée.
• Utilisez AWS Lambda avec AWS X-Ray pour détecter, analyser et optimiser les problèmes de performances avec les applications Lambda. AWS X-Ray collecte les métadonnées du service Lambda et génère des graphiques qui décrivent les problèmes affectant les performances de l'application Lambda. Par exemple, s'il existe un appel dont l'exécution dure longtemps, vous pouvez utiliser AWS X-Ray pour confirmer le problème.

</ul

---