Problèmes courants - Amazon Data Firehose
Stream Firehose non disponibleAucune donnée à destinationMesure de fraîcheur des données croissante ou non émiseLa conversion du format d'enregistrement vers Apache Parquet échoueChamps manquants pour l'objet transformé pour Lambda

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Problèmes courants

Vous trouverez ci-dessous des conseils de dépannage qui vous aideront à résoudre les problèmes courants lorsque vous travaillez avec un stream Firehose.

Stream Firehose non disponible

Le flux Firehose n'est pas disponible en tant que cible pour les CloudWatch journaux, les CloudWatch événements ou les actions AWS IoT, car certains AWS services ne peuvent envoyer des messages et des événements qu'à un flux Firehose qui se trouve dans le même flux. Région AWS Vérifiez que votre stream Firehose se trouve dans la même région que vos autres services.

Aucune donnée à destination

S'il n'y a aucun problème d'ingestion de données et que les métriques émises pour le flux Firehose semblent correctes, mais que vous ne voyez pas les données à destination, vérifiez la logique du lecteur. Assurez-vous que le lecteur analyse correctement toutes les données.

Mesure de fraîcheur des données croissante ou non émise

La fraîcheur des données est une mesure de l'actualité de vos données dans votre flux Firehose. Il s'agit de l'âge du plus ancien enregistrement de données du flux Firehose, mesuré depuis le moment où Firehose a ingéré les données jusqu'à aujourd'hui. Firehose fournit des métriques que vous pouvez utiliser pour surveiller l'actualité des données. Pour identifier la métrique d'actualité des données pour une destination spécifique, consultez Surveillez Amazon Data Firehose à l'aide de métriques CloudWatch.

Si vous activez la sauvegarde pour tous les événements ou tous les documents, surveillez deux métriques d'actualité des données distinctes : l'une pour la destination principale et l'autre pour la sauvegarde.

Si la métrique de fraîcheur des données n'est pas émise, cela signifie qu'il n'y a pas de diffusion active pour le flux Firehose. Ce cas de figure se présente lorsque la livraison des données est complètement bloquée ou lorsqu'il n'y a pas de données entrantes.

Si la métrique d'actualité des données augmente constamment, cela signifie que la livraison des données prend du retard. Plusieurs raisons sont possibles.

  • La destination ne parvient pas à gérer le taux de livraison. Si Firehose rencontre des erreurs transitoires en raison d'un trafic élevé, il se peut que la livraison soit retardée. Cela peut se produire pour des destinations autres qu'Amazon S3 (cela peut se produire pour OpenSearch Service, Amazon Redshift ou Splunk). Assurez-vous que la destination dispose de suffisamment de capacité pour gérer le trafic entrant.

  • La destination est lente. La livraison des données peut prendre du retard si Firehose rencontre une latence élevée. Surveillez la métrique de latence de la destination.

  • La fonction Lambda est lente. Cela peut entraîner un taux de livraison de données inférieur au taux d'ingestion de données pour le flux Firehose. Si possible, améliorez l'efficacité de la fonction Lambda. Par exemple, si la fonction effectue des E/S réseau, utilisez plusieurs threads ou des E/S asynchrones pour accroître le parallélisme. Envisagez également d'augmenter la taille de la mémoire de la fonction Lambda afin que l'allocation du CPU puisse croître en conséquence. Ces modifications peuvent entraîner des invocations Lambda plus rapides. Pour plus d'informations sur la configuration des fonctions Lambda, consultez la section Configuration des fonctions Lambda AWS.

  • Des échecs affectent la livraison des données. Pour plus d'informations sur la façon de surveiller les erreurs à l'aide d'Amazon CloudWatch Logs, consultezSurveillez Amazon Data Firehose à l'aide des journaux CloudWatch.

  • Si la source de données du flux Firehose est un flux de données Kinesis, il est possible qu'une régulation se produise. Vérifiez les métriques ThrottledGetRecords, ThrottledGetShardIterator et ThrottledDescribeStream. Si plusieurs consommateurs sont associés au flux de données Kinesis, tenez compte des points suivants :

    • Si les métriques ThrottledGetRecords et ThrottledGetShardIterator sont élevées, nous vous recommandons d'augmenter le nombre de partitions provisionnées pour le flux de données.

    • Si la ThrottledDescribeStream valeur est élevée, nous vous recommandons d'ajouter l'kinesis:listshardsautorisation au rôle configuré dans KinesisStreamSourceConfiguration.

  • La mise en mémoire tampon est insuffisante pour la destination. Cela peut augmenter le nombre d'allers-retours que Firehose doit effectuer pour se rendre à destination, ce qui peut entraîner un retard de livraison. Pensez à augmenter la valeur des indicateurs de mise en mémoire tampon. Pour de plus amples informations, veuillez consulter BufferingHints.

  • Une durée élevée configurée pour les nouvelles tentatives peut entraîner un retard de livraison lorsque les erreurs sont fréquentes. Envisagez de réduire cette durée. En outre, surveillez les erreurs et essayez de les corriger. Pour plus d'informations sur la façon de surveiller les erreurs à l'aide d'Amazon CloudWatch Logs, consultezSurveillez Amazon Data Firehose à l'aide des journaux CloudWatch.

  • Si la destination est Splunk et que la métrique DeliveryToSplunk.DataFreshness est élevée, mais que DeliveryToSplunk.Success semble correct, le cluster Splunk est peut-être occupé. Libérez le cluster Splunk si possible. Vous pouvez également contacter le AWS Support et demander une augmentation du nombre de canaux utilisés par Firehose pour communiquer avec le cluster Splunk.

La conversion du format d'enregistrement vers Apache Parquet échoue

Cela se produit si vous prenez des données DynamoDB qui incluent Set le type, que vous les diffusez via Lambda vers un flux Firehose et que vous utilisez AWS Glue Data Catalog an pour convertir le format d'enregistrement en Apache Parquet.

Lorsque le AWS Glue robot d'exploration indexe les types de données de l'ensemble DynamoDB (StringSet,, etBinarySet)NumberSet, il les stocke dans le catalogue de données sous SET<STRING> les formes, et, respectivement. SET<BIGINT> SET<BINARY> Cependant, pour que Firehose puisse convertir les enregistrements de données au format Apache Parquet, les types de données Apache Hive sont nécessaires. Les types définis n’étant pas des types de données Apache Hive valides, la conversion échoue. Pour que la conversion fonctionne, mettez à jour le catalogue de données avec les types de données Apache Hive. Pour cela, remplacez set par array dans le catalogue de données.

Pour modifier un ou plusieurs types de données de set à array dans un catalogue AWS Glue de données

  1. Connectez-vous à la AWS Glue console AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/glue/.

  2. Dans le volet de gauche, sous l'en-tête Data catalog (Catalogue de données) choisissez Tables.

  3. Dans la liste des tables, choisissez le nom de la table dans laquelle vous devez modifier un ou plusieurs types de données. Vous accédez alors à la page des détails de la table.

  4. Choisissez le bouton Modifier le schéma dans le coin supérieur droit de la page des détails.

  5. Dans la colonne Data type (Type de données), choisissez le premier type de données set.

  6. Dans la liste déroulante Column type (Type de colonne) remplacez le type set par array.

  7. Dans le ArraySchemachamp, entrez array<string>array<int>, ouarray<binary>, selon le type de données approprié à votre scénario.

  8. Choisissez Mettre à jour.

  9. Répétez les étapes précédentes pour convertir d'autres types set en types array.

  10. Choisissez Enregistrer.

Champs manquants pour l'objet transformé pour Lambda

Lorsque vous utilisez la transformation de données Lambda pour transformer des données JSON en objet Parquet, certains champs peuvent être manquants après la transformation. Cela se produit si votre objet JSON comporte des majuscules et que la distinction majuscules et minuscules est définie surfalse, ce qui peut entraîner une incohérence dans les clés JSON après la transformation des données, entraînant des données manquantes dans l'objet Parquet obtenu dans le compartiment s3.

Pour résoudre ce problème, assurez-vous que la configuration du tuyau est deserializationOption: case.insensitive définie sur true afin que les clés JSON correspondent après la transformation.