Comment remédier à l'échec de la diffusion de données entre Kinesis Data Firehose et Amazon S3 ?

Dernière mise à jour : 18/06/2020

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 AWS Identity and Access Management (IAM)
  • Chiffrement côté serveur
  • 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 à 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 stratégie 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

Kinesis Data Firehose prend en charge le chiffrement côté serveur S3 avec AWS Key Management Service (AWS KMS) pour chiffrer les données envoyées à S3. Pour autoriser le chiffrement côté serveur, mettez à jour la stratégie 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*"
               }
           }

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 une nouvelle fonction Lambda à 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 pour voir si elle dépasse le paramètre de délai d'attente. Pour en savoir plus sur les métriques d'appel, consultez la section 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 S3 contient également le message d'erreur. Pour en savoir plus sur les échecs de transformation des données, consultez la section 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 ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?