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

Date de la dernière mise à jour : 23/07/2021

J'essaie d'envoyer des données depuis Amazon Kinesis Data Firehose vers mon domaine Amazon OpenSearch Service. 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 OpenSearch Service (successeur d'Amazon Elasticsearch Service) peut avoir pour origine l'une des 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 d'intégrité du domaine OpenSearch Service

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 en savoir plus sur la métrique DeliveryToElasticsearch.Success, consultez Diffusion vers OpenSearch Service dans Métriques CloudWatch de la diffusion de données.

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 en savoir plus 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.

Consultez les métriques DataReadFromKinesisStream.Bytes et DataReadFromKinesisStream.Records pour vérifier que les données proviennent de Kinesis Data Streams vers Kinesis Data Firehose. Pour en savoir plus sur les métriques de données, consultez Ingestion de données via Kinesis Data Streams. Une valeur de zéro peut indiquer un échec de livraison à OpenSearch Service 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 en savoir plus 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 OpenSearch Service 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 à OpenSearch Service, vous pouvez mettre à jour votre stratégie comme suit :

{
           "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 suit :

{
          "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 appelé 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 en savoir plus sur la résolution des échecs d'appel Lambda, consultez Gestion des échecs de transformation de données.

Problèmes d'intégrité du domaine OpenSearch Service

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

  • Utilisation du CPU : 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 : ce bloc d'indexation 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 assez d'espace, les nouvelles données ne peuvent pas être indexées. Pour en savoir plus sur la résolution des problèmes liés à OpenSearch Service, consultez Résolution des problèmes liés à Amazon OpenSearch Service.

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


Besoin d'aide pour une question technique ou de facturation ?