Comment résoudre l'échec de la diffusion de données entre Kinesis Data Firehose et Amazon S3 ?

Dernière mise à jour : 20/06/2022

J'essaie d'envoyer des données depuis Amazon Kinesis Data Firehose vers mon compartiment Amazon Simple Storage Service (Amazon S3), mais l'envoi échoue. Comment puis-je résoudre ce problème ?

Brève description

Pour vous assurer que Kinesis Data Firehose tente d'ajouter des données à votre compartiment Amazon S3, vérifiez la métrique DeliveryToS3.Success. Si la valeur de la métrique DeliveryToS3.Success est constamment égale à zéro, vérifiez les points suivants :

  • Disponibilité des ressources
  • Enregistrements des données entrantes
  • Journaux Kinesis Data Firehose
  • Autorisations du rôle de la gestion des identités et des accès AWS (AWS IAM)
  • Chiffrement côté serveur de Kinesis Data Firehose
  • Compartiment Amazon S3 chiffré par AWS KMS
  • Appel AWS Lambda

Solution

Disponibilité des ressources

Vérifiez la disponibilité du compartiment S3 spécifié dans votre flux de diffusion Kinesis Data Firehose. Si vous utilisez la fonction de transformation des données, assurez-vous que la fonction Lambda spécifiée existe.

Enregistrements des données entrantes

Vérifiez les métriques IncomingRecords et IncomingBytes afin de vous assurer que Kinesis Data Firehose reçoit bien des données entrantes. Une valeur de métrique égale à zéro pour IncomingRecords ou IncomingBytes indique que Kinesis Data Firehose ne reçoit aucun enregistrement. Si le flux de diffusion utilise un flux de données Amazon Kinesis comme source, vérifiez alors la source du flux en examinant les métriques IncomingBytes et IncomingRecords. Vérifiez également si les métriques DataReadFromKinesisStream.Bytes et DataReadFromKinesisStream.Records sont émises à partir du flux de diffusion. Pour en savoir plus sur ces métriques, consultez la section Métriques CloudWatch de diffusion de données.

Si aucune donnée n'atteint Kinesis Data Firehose, le problème peut résider en amont. Pour une opération PUT directe, vérifiez que les API PutRecord et PutRecordBatch utilisées pour envoyer des enregistrements à Kinesis Data Firehose sont correctement appelées.

Journaux Kinesis Data Firehose

Vérifiez que la journalisation est activée pour Kinesis Data Firehose. Si la journalisation n'est pas activée, vérifiez les journaux d'erreurs pour déterminer la cause de l'échec de diffusion. Les journaux d'erreurs fournissent des raisons spécifiques d'échec de diffusion et vous permettent de résoudre ces problèmes. Le format du nom du groupe de journaux est /aws/kinesisfirehose/delivery-stream-name.

Utilisez alors les autorisations suivantes pour votre rôle :

"Action": [
               "logs:PutLogEvents"
           ],
           "Resource": [
               "arn:aws:logs:region:account-id:log-group:log-group-name:log-stream:log-stream-name"
           ]

Autorisations du rôle IAM

Assurez-vous que le rôle IAM spécifié dans votre flux de diffusion Kinesis Data Firehose dispose des autorisations appropriées. En fonction des paramètres activés sur le flux, un certain nombre d'autorisations sont requises. Pour en savoir plus, consultez la section Accorder à Kinesis Data Firehose l'accès à une destination Amazon S3.

Pour l'accès à Amazon S3, mettez à jour votre stratégie IAM comme suit :

"Action": [
                "s3:AbortMultipartUpload",
                "s3:GetBucketLocation",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:ListBucketMultipartUploads",
                "s3:PutObject"
            ],     
            "Resource": [       
                "arn:aws:s3:::bucket-name",
                "arn:aws:s3:::bucket-name/*"                         
            ]

Pour autoriser la transformation des données de votre fonction Lambda, mettez à jour votre stratégie comme suit :

"Action": [
               "lambda:InvokeFunction",
               "lambda:GetFunctionConfiguration"
           ],
           "Resource": [
               "arn:aws:lambda:region:account-id:function:function-name:function-version"
           ]

Pour un flux de données Kinesis répertorié comme source, mettez à jour votre politique comme suit :

"Action": [
                "kinesis:DescribeStream",
                "kinesis:GetShardIterator",
                "kinesis:GetRecords",
                "kinesis:ListShards"
            ],
            "Resource": "arn:aws:kinesis:region:account-id:stream/stream-name"

Chiffrement côté serveur de Kinesis Data Firehose

Kinesis Data Firehose prend en charge le chiffrement côté serveur Amazon S3 avec AWS Key Management Service (AWS KMS) pour chiffrer les données envoyées à Amazon S3. Pour autoriser le chiffrement côté serveur, mettez à jour la politique de votre rôle IAM en procédant comme suit :

"Action": [
               "kms:Decrypt",
               "kms:GenerateDataKey"
           ],
           "Resource": [
               "arn:aws:kms:region:account-id:key/key-id"          
           ],
           "Condition": {
               "StringEquals": {
                   "kms:ViaService": "s3.region.amazonaws.com"
               },
               "StringLike": {
                   "kms:EncryptionContext:aws:s3:arn": "arn:aws:s3:::bucket-name/prefix*"
               }
           }

Compartiment S3 chiffré par AWS KMS

Confirmez que le rôle IAM pour le flux de diffusion Kinesis Data Firehose dispose des autorisations appropriées. Pour diffuser des données vers un compartiment Amazon S3 chiffré par AWS KMS, le rôle IAM de Kinesis Data Firehose doit être autorisé dans la politique de clé. Pour plus d'informations, consultez Comment résoudre l'erreur « Access Denied »(Accès refusé) qui se produit dans Kinesis Data Firehose lorsque j'écris dans un compartiment Amazon S3 ?

Appel Lambda

Vérifiez la disponibilité de la fonction Lambda spécifiée dans votre flux de diffusion. Si la fonction Lambda est manquante ou a été supprimée, créez-en une nouvelle pour l'appeler.

Vérifiez les métriques Kinesis Data Firehose ExecuteProcessingSuccess et Errors pour vous assurer que Data Firehose a essayé d'appeler votre fonction Lambda. Si l'appel échoue, vérifiez l'emplacement </aws/lambda/functionname> dans le groupe de journaux Amazon CloudWatch afin de déterminer pourquoi Lambda n'effectue pas l'appel. En cas de transformation Lambda et si la fonction Lambda est appelée, vérifiez la durée de l'appel. Si la durée dépasse le paramètre d'expiration, votre appel échouera. Pour plus d'informations sur les métriques d'appel, consultez Utilisation des métriques d'appel.

Si la transformation des données échoue, les enregistrements ayant échoué sont transmis à votre compartiment S3 dans le dossier processing-failed. Le format des enregistrements dans Amazon S3 contient également le message d'erreur. Pour plus d'informations sur les échecs de transformation des données, consultez Gestion des échecs de transformation de données.

Remarque : votre stratégie de compartiment S3 peut également rencontrer un refus explicite, comme aws:SourceIp ou aws:SourceVpce. Pour vérifier si votre stratégie de compartiment S3 est explicitement refusée, recherchez le code d'erreur S3.AccessDenied dans CloudWatch Logs.


Cet article vous a-t-il été utile ?


Avez-vous besoin d'aide pour une question technique ou de facturation ?