Pourquoi est-ce que je rencontre un échec de livraison de données avec Kinesis Data Firehose ?

Date de la dernière mise à jour : 16/06/2020

J'essaie d'envoyer des données depuis Amazon Kinesis Data Firehose vers mon domaine Amazon Elasticsearch Service (Amazon ES). Pourquoi est-ce que je rencontre un échec de livraison de données ?

Brève description

Un échec de livraison entre Kinesis Data Firehose et Amazon ES peut être causé par les raisons suivantes :

  • Destination de livraison non valide
  • Aucune donnée entrante
  • Journaux Kinesis Data Firehose désactivés
  • Absence d'autorisations appropriées
  • Problèmes d'appel de la fonction AWS Lambda
  • Problèmes de santé du domaine Amazon ES

Solution

Destination de livraison non valide

Vérifiez que vous avez spécifié une destination de livraison Kinesis Data Firehose valide et que vous utilisez l'ARN correct. Vous pouvez vérifier si votre livraison a réussi en consultant la métrique DeliveryToElasticsearch.Success dans Amazon CloudWatch. Une valeur de métrique DeliveryToElasticsearch.Success égale à zéro correspond à la confirmation que les livraisons ont échoué. Pour plus d'informations sur la métrique DeliveryToElasticsearch.Success, consultez Delivery to Amazon ES dans Data delivery CloudWatch metrics.

Aucune donnée entrante

Vérifiez qu'il existe des données entrantes pour Kinesis Data Firehose en surveillant les métriques IncomingRecords et IncomingBytes. Une valeur de zéro pour ces métriques signifie qu'aucun enregistrement n'atteint Kinesis Data Firehose. Pour plus d'informations sur les métriques IncomingRecords et IncomingBytes, consultez Ingestion de données via PUT direct dans Métriques d'ingestion de données.

Si le flux de diffusion utilise Amazon Kinesis Data Streams comme source, vérifiez les métriques IncomingRecords et IncomingBytes du flux de données Kinesis. Ces deux métriques indiquent qu'il existe des données entrantes. La valeur zéro confirme qu'aucun enregistrement n'atteint les services de streaming.

Si des données atteignent Kinesis Data Streams, les métriques DataReadFromKinesisStream.Bytes et DataReadFromKinesisStream.Records indiquent si les données proviennent de Kinesis Data Streams vers Kinesis Data Firehose. Pour plus d'informations sur les métriques de données, consultez Intégration de données via Kinesis Data Streams. Une valeur de zéro peut indiquer un échec de livraison à Amazon ES plutôt qu'un échec entre Kinesis Data Streams et Kinesis Data Firehose.

Vous pouvez également vérifier si les appels d'API PutRecord et PutRecordBatch pour Kinesis Data Firehose sont appelés correctement. Si vous ne voyez pas de métriques de flux de données entrantes, vérifiez le producteur qui exécute les opérations PUT. Pour plus d'informations sur la résolution des problèmes liés aux applications producteur, consultez Résolution des problèmes liés aux producteurs Amazon Kinesis Data Streams.

Journaux Kinesis Data Firehose désactivés

Assurez-vous que la journalisation est activée pour Kinesis Data Firehose. Sinon, les journaux d'erreurs entraînent un échec de livraison. Ensuite, vérifiez le nom du groupe de journaux /aws/kinesisfirehose/delivery-stream-name dans CloudWatch Logs.

Dans le rôle Kinesis Data Firehose, les autorisations suivantes sont requises :

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

Vérifiez que vous avez accordé à Kinesis Data Firehose l'accès à une destination Amazon ES publique. Si vous utilisez la fonction de transformation de données, vous devez également accorder l'accès à AWS Lambda.

Absence d'autorisations appropriées

Plusieurs autorisations sont requises en fonction de la configuration de Kinesis Data Firehose.

Pour livrer des enregistrements à un compartiment Amazon Simple Storage Service (Amazon S3), les autorisations suivantes sont requises :

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

Remarque : pour utiliser cette stratégie, la ressource de compartiment Amazon S3 doit être présente.

Si votre Kinesis Data Firehose est chiffré au repos, les autorisations suivantes sont requises :

{
           "Effect": "Allow",
           "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*"
               }
           }
        }

Pour accorder des autorisations pour l'accès à Amazon ES, vous pouvez mettre à jour votre stratégie comme dans l'exemple suivant :

 {
           "Effect": "Allow",
           "Action": [
               "es:DescribeElasticsearchDomain",
               "es:DescribeElasticsearchDomains",
               "es:DescribeElasticsearchDomainConfig",
               "es:ESHttpPost",
               "es:ESHttpPut"
           ],
          "Resource": [
              "arn:aws:es:region:account-id:domain/domain-name",
              "arn:aws:es:region:account-id:domain/domain-name/*"
          ]
       },
       {
          "Effect": "Allow",
          "Action": [
              "es:ESHttpGet"
          ],
          "Resource": [
              "arn:aws:es:region:account-id:domain/domain-name/_all/_settings",
              "arn:aws:es:region:account-id:domain/domain-name/_cluster/stats",
              "arn:aws:es:region:account-id:domain/domain-name/index-name*/_mapping/type-name",
              "arn:aws:es:region:account-id:domain/domain-name/_nodes",
              "arn:aws:es:region:account-id:domain/domain-name/_nodes/stats",
              "arn:aws:es:region:account-id:domain/domain-name/_nodes/*/stats",
              "arn:aws:es:region:account-id:domain/domain-name/_stats",
              "arn:aws:es:region:account-id:domain/domain-name/index-name*/_stats"
          ]
       }

Si vous utilisez Kinesis Data Streams comme source, mettez à jour vos autorisations comme dans l'exemple suivant :

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

Pour configurer Kinesis Data Firehose pour la transformation de données, vous pouvez mettre à jour votre stratégie comme suit :

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

Problèmes d'appel de la fonction AWS Lambda

Vérifiez les métriques Kinesis Data Firehose ExecuteProcessing.Success et Errors pour vous assurer que Kinesis Data Firehose a appelé votre fonction. Si Kinesis Data Firehose n'a pas essayé d'appeler votre fonction Lambda, vérifiez le délai d'appel pour voir s'il dépasse le paramètre de délai d'attente. Votre fonction Lambda peut nécessiter une valeur de délai d'attente supérieure ou avoir besoin de plus de mémoire pour se terminer dans le temps. Pour plus d'informations sur les métriques d'appel, consultez Utilisation des métriques d'appel.

Pour identifier les raisons pour lesquelles Kinesis Data Firehose n'appelle pas la fonction Lambda, recherchez /aws/lambda/lamdba-function-name dans le groupe Amazon CloudWatch Logs. Si la transformation de données échoue, les enregistrements ayant échoué sont transmis au compartiment S3 en tant que sauvegarde dans le dossier processing-failed. Les enregistrements de votre compartiment S3 contiennent également le message d'erreur relatif à l'échec de l'appel. Pour plus d'informations sur la résolution des échecs d'appel Lambda, consultez Gestion des échecs de transformation de données.

Problèmes de santé du domaine Amazon ES

Vérifiez les métriques suivantes pour confirmer qu'Amazon ES est en bonne santé :

  • Utilisation de l'UC : si cette métrique est constamment élevée, le nœud de données peut ne pas être en mesure de répondre aux demandes ou aux données entrantes. Vous devrez peut-être mettre à l'échelle votre cluster.
  • Pression de mémoire JVM : si la pression de mémoire JVM est constamment supérieure à 80 %, le cluster peut déclencher des exceptions de disjoncteur de mémoire. Ces exceptions peuvent empêcher l'indexation des données.
  • ClusterWriteBlockException : il s'agit d'un bloc d'indexation qui se produit si le domaine est soumis à une pression de mémoire JVM élevée ou si plus d'espace de stockage est nécessaire. Si un nœud de données n'a pas d'espace, aucune nouvelle donnée ne peut être indexée. Pour plus d'informations sur la résolution des problèmes liés à Amazon ES, consultez Résolution des problèmes liés à Amazon Elasticsearch Service.

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

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


Vous avez besoin d'aide ?