2
votes

Comment savoir quel Lambda a envoyé un message à la file d'attente des lettres mortes?

J'utilise une rubrique SNS comme file d'attente de lettres mortes pour gérer les erreurs générées par plusieurs Lambdas. Dans les messages d'erreur, il y a les attributs suivants:

RequestID ,
ErrorCode,
ErrorMessage ,

Cependant, je ne parviens pas à trouver facilement quel Lambda a généré l'erreur, car rien de lié n'apparaît dans le message (par exemple: ARN, nom de la fonction ...)

Bien que ce soit possible de rechercher l'ID de requête sur CloudWatch ou de créer plusieurs sujets, il devrait y avoir un moyen beaucoup plus simple de trouver quel Lambda a généré l'erreur. Voici la structure du message reçu:

{
    "Records": [
        {
            "EventSource": "aws:sns",
            "EventVersion": "1.0",
            "EventSubscriptionArn": "",
            "Sns": {
                "Type": "Notification",
                "MessageId": "",
                "TopicArn": "",
                "Subject": null,
                "Message": "",
                "Timestamp": "",
                "SignatureVersion": "",
                "Signature": "",
                "SigningCertUrl": "",
                "UnsubscribeUrl": "",
                "MessageAttributes": {
                    "RequestID": {
                        "Type": "String",
                        "Value": ""
                    },
                    "ErrorCode": {
                        "Type": "String",
                        "Value": "200"
                    },
                    "ErrorMessage": {
                        "Type": "String",
                        "Value": "test"
                    }
                }
            }
        }
    ]
}

Existe-t-il un moyen d'ajouter des informations, telles que l'ARN, sur le Lambda qui a déclenché ce message d'erreur?

aws-lambda amazon-sns

0 commentaires

3 Réponses :

0
votes

Vous pouvez utiliser AWS CloudTrail pour identifier le Lambda exécuté:

https://docs.aws.amazon .com / lambda / latest / dg / logging-using-cloudtrail.html

1 commentaires

Merci d'avoir répondu! J'ai jeté un œil au fonctionnement de cloudtrail. À mon humble avis, il est assez limité: - Il stocke chaque appel (je n'ai besoin que d'erreurs) - J'ai besoin de récupérer des fichiers dans S3 et de faire une recherche sur demande ID C'est assez surprenant qu'il n'existe pas de moyen plus immédiat de trouver lequel lambda a jeté l'erreur?

0
votes

Vous devriez avoir un DLQ par fonction Lambda. Cela vous permettra de savoir d'où vient la lettre morte.

1 commentaires

Cela nécessiterait de créer un sujet par lambda, ce que je préfère ne pas faire pour des raisons d'évolutivité.

0
votes

J'ai fini par configurer:

Un thème SNS unique pour chaque DLQ lambda.
Un lambda écoutant la rubrique ci-dessus et stockant l'ID de requête dans S3
Un suivi sur CloudTrail enregistrant chaque appel lambda
Un lambda correspondant à l'ID de demande ayant échoué dans S3 et aux journaux cloudtrail. Ces derniers fournissent le nom du lambda défaillant.

Cette infrastructure peut sembler un peu compliquée mais elle fonctionne très bien. Il ne permet d'ajouter qu'une seule ligne de code onError: ... dans chaque fichier de configuration lambda.

0 commentaires