Amazon Kinesis Data Firehose のトラブルシューティング - Amazon Kinesis Data Firehose

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon Kinesis Data Firehose のトラブルシューティング

Kinesis Data Firehose は、データの配信中や処理中にエラーが発生すると、設定された再試行期間が終了するまで再試行を続けます。データが正常に配信される前に再試行期間が終了すると、Kinesis Data Firehose は設定された S3 バックアップバケットにデータをバックアップします。送信先が Amazon S3 で配信が失敗するか、バックアップ S3 バケットへの配信が失敗すると、Kinesis Data Firehose は保持期間が終了するまで再試行を続けます。を使用する場合DirectPut配信ストリーム、Kinesis Data Firehose はレコードを 24 時間保持します。データソースが Kinesis データストリームの配信ストリームの場合、「データ保持期間の変更」の説明に従って、保持期間を変更できます。

データソースが Kinesis データストリームである場合、Kinesis Data Firehose は、以下のオペレーションを無期限に再試行します。DescribeStream,GetRecords, およびGetShardIterator

配信ストリームで DirectPut が使用されている場合は、IncomingBytes メトリクスと IncomingRecords メトリクスをチェックして、着信トラフィックの有無を確認します。PutRecord または PutRecordBatch を使用している場合は、例外をキャッチして再試行してください。ジッターと複数の再試行を使用するエクスポネンシャルバックオフによる再試行ポリシーをお勧めします。また、PutRecordBatch API を使用する場合は、API コールが成功した場合でも、レスポンスの FailedPutCount の値をコードによって確認してください。

配信ストリームがそのソースとして Kinesis データストリームを使用する場合は、ソースデータストリームの IncomingBytes メトリクスと IncomingRecords メトリクスを確認します。さらに、配信ストリームに関して DataReadFromKinesisStream.Bytes メトリクスと DataReadFromKinesisStream.Records メトリクスが生成されていることを確認します。

CloudWatch を使用した配信エラーの追跡については、「」を参照してください。CloudWatch Logs を使用した Kinesis Data Firehose のモニタリング

データを Amazon S3 に配信しない

Amazon Simple Storage Service (Amazon S3) バケットにデータが配信されない場合は、以下を確認してください。

データを Amazon Redshift に配信しない

Amazon Redshift クラスターにデータが配信されない場合は、以下の点を確認してください。

データは、Amazon Redshift にロードされる前に S3 バケットに配信されます。データが S3 バケットに配信されなかった場合は、「データを Amazon S3 に配信しない」を参照してください。

  • Kinesis Data Firehose の確認DeliveryToRedshift.Successメトリクスを使用して、Kinesis Data Firehose が S3 バケットから Amazon Redshift クラスターにデータをコピーしようとしたことを確認します。詳細については、「CloudWatch メトリクスを使用した Kinesis Data Firehose のモニタリング」を参照してください。

  • すでに有効になっていない場合はエラーログ記録を有効にし、配信の失敗のエラーログを確認します。詳細については、「CloudWatch Logs を使用した Kinesis Data Firehose のモニタリング」を参照してください。

  • Amazon Redshift をチェックするSTL_CONNECTION_LOGテーブルを使用して、Kinesis Data Firehose が正常に接続できるかどうかを確認することができます。このテーブルには、ユーザー名に基づく接続と接続ステータスが表示されます。詳細については、「」を参照してください。STL_CONNECTION_LOGAmazon Redshift データベース開発者ガイド

  • 前のチェックで、接続が確立されていることを確認したら、Amazon Redshift を確認してください。STL_LOAD_ERRORSの表で、COPY の失敗の理由を確認します。詳細については、「」を参照してください。STL_LOAD_ERRORSAmazon Redshift データベース開発者ガイド

  • Kinesis Data Firehose 配信ストリームの Amazon Redshift 設定が正確で有効であることを確認します。

  • Kinesis Data Firehose 配信ストリームで指定した IAM ロールに、Amazon Redshift によるデータのコピー元となる S3 バケットに対するアクセス権限と、データ変換用の Lambda 関数に対するアクセス権限 (データ変換が有効な場合) があることを確認します。詳細については、「Amazon S3 の送信先へのアクセス権を Kinesis Data Firehose に付与する」を参照してください。

  • Amazon Redshift クラスターが Virtual Private Cloud (VPC) にある場合は、クラスターで Kinesis Data Firehose の IP アドレスからのアクセスが許可されていることを確認します。詳細については、「Amazon Redshift へのアクセス権を Kinesis Data Firehose に付与する 」を参照してください。

  • Amazon Redshift クラスターがパブリックにアクセス可能であることを確認します。

  • データ変換を使用している場合は、Lambda 関数が、6 MB を超えるペイロードサイズのレスポンスを返さないようにします。詳細については、「Amazon Kinesis Data Firehose のデータ変換」を参照してください。

Amazon OpenSearch Service に配信されないデータ

OpenSearch Service ドメインにデータが配信されない場合は、以下の点を確認してください。

データは、Amazon S3 バケットに同時にバックアップできます。S3 バケットにデータが配信されなかった場合は、「データを Amazon S3 に配信しない」を参照してください。

データが Splunk に配信されない

Splunk エンドポイントにデータが配信されない場合は、以下の点を確認してください。

  • Splunk プラットフォームが VPC にある場合は、Kinesis Data Firehose がアクセスできることを確認します。詳細については、「VPC の Splunk へのアクセス」を参照してください。

  • ... を使用した場合AWSロードバランサー、Classic Load Balancer であることを確認します。Kinesis Data Firehose では、アプリケーションロードバランサーやネットワークロードバランサーはサポートされていません。また、Cookie の失効を無効化した期間ベースのスティッキーセッションを有効にしてください。これを行う方法については、「期間ベースのセッション維持」を参照してください。

  • Splunk プラットフォームの要件を確認します。Splunk Add-on for Kinesis Data Firehose 用の Splunk アドオンには、Splunk プラットフォームバージョン 6.X 以降が必要になります。詳細については、「Splunk Add-on for Amazon Kinesis Firehose」を参照してください。

  • Kinesis Data Firehose と HTTP Event Collector (HEC) ノードの間にプロキシ (Elastic Load Balancing など) がある場合は、スティッキーセッションを有効にして HEC 送達確認 (ACK) をサポートします。

  • 有効な HEC トークンを使用していることを確認します。

  • HEC トークンが有効であることを確認します。Enable and disable Event Collector tokens を参照してください。

  • Splunk に送信しているデータの形式が正しいかどうかを確認します。詳細については、「Format events for HTTP Event Collector」を参照してください。

  • 有効なインデックスを使用して HEC トークンと入力イベントが設定されていることを確認します。

  • HEC ノードのサーバーエラーのため Splunk へのアップロードが失敗すると、リクエストは自動的に再試行されます。すべての再試行が失敗すると、データは Amazon S3 にバックアップされます。Amazon S3 にデータが記載されているかどうかを確認します。Amazon S3 にデータが記載されているかどうかを確認します。Amazon S3 では、このような障害が発生したことを示します。

  • HEC トークンでインデクサの送達確認が有効であることを確認します。詳細については、「Enable indexer acknowledgement」を参照してください。

  • の値を大きくするHECAcknowledgmentTimeoutInSecondsで Splunk 送信先設定で、Kinesis Data Firehose 配信ストリームの。

  • の値を大きくするDurationInSeconds[]RetryOptionsで Splunk 送信先設定で、Kinesis Data Firehose 配信ストリームの。

  • HEC のヘルスを確認します。

  • データ変換を使用している場合は、Lambda 関数が、6 MB を超えるペイロードサイズのレスポンスを返さないようにします。詳細については、「Amazon Kinesis Data Firehose のデータ変換」を参照してください。

  • ackIdleCleanup と言う名前の Splunk パラメータが、true に設定されていることを確認します。これはデフォルトでは false です。このパラメータを true に設定するには、次のことを行います。

    • マネージド型の Splunk Cloud デプロイの場合は、Splunk サポートポータルを使用してケースを送信します。その場合は、HTTP イベントコレクターを有効にし、ackIdleCleanuptrueinputs.conf に設定して、このアドオンを使用するようにロードバランサーを作成または変更することを Splunk サポートに依頼します。

    • 分散された Splunk Enterprise デプロイの場合は、inputs.conf ファイルで ackIdleCleanup パラメータを true に設定します。*nix ユーザーの場合、このファイルは $SPLUNK_HOME/etc/apps/splunk_httpinput/local/ にあります。​ Windows ユーザーの場合、%SPLUNK_HOME%\etc\apps\splunk_httpinput\local\ にあります。​

    • シングルインスタンスの Splunk Enterprise デプロイの場合は、inputs.conf ファイルで ackIdleCleanup パラメータを true に設定します。*nix ユーザーの場合、このファイルは $SPLUNK_HOME/etc/apps/splunk_httpinput/local/ にあります。​ Windows ユーザーの場合、%SPLUNK_HOME%\etc\apps\splunk_httpinput\local\ にあります。​

  • 詳細については、Troubleshoot the Splunk Add-on for Amazon Kinesis Firehose を参照してください。

CloudWatch Logs、CloudWatch イベント、または CloudWatch イベントのターゲットとして使用できない配信ストリームAWS IoTアクション

ある程度AWSサービスは、同じ Kinesis Data Firehose 配信ストリームにメッセージおよびイベントのみ送信できます。AWSリージョン。Kinesis Data Firehose 配信ストリームが他のサービスと同じリージョンにあることを確認します。

データの鮮度メトリクスの増加または未発行

データの鮮度は、配信ストリーム内のデータがどの程度最新であるかを示す指標です。配信ストリーム内の最も古いデータレコードの経過時間であり、Kinesis Data Firehose がデータを取り込んだ時点から現在時刻までの時間で測定されます。Kinesis Data Firehose は、データの鮮度を監視するために使用できるメトリクスを提供します。特定の配信先に関するデータの鮮度メトリクスを確認するには、「CloudWatch メトリクスを使用した Kinesis Data Firehose のモニタリング」を参照してください。

すべてのイベントまたはすべてのドキュメントのバックアップを有効にする場合は、メイン配信先用とバックアップ用に 2 つのデータの鮮度メトリクスを別個にモニタリングします。

データの鮮度メトリクスが生成されていない場合は、配信ストリームにアクティブな配信がないことを意味します。これは、データ配信が完全にブロックされているか、着信データがない場合に発生します。

データの鮮度メトリクスが増え続けている場合は、データ配信が遅れていることを意味します。これは、次のいずれかの理由で発生します。

  • 配信先が配信率に対応できない。トラフィックが多いためにKinesis Data Firehose で一時的なエラーが発生すると、配信が遅れる場合があります。これは、Amazon S3 以外の送信先で発生することがあります (OpenSearch Service、Amazon Redshift、または Splunk で発生することがあります)。配信先に、着信トラフィックを処理するための十分な容量があることを確認します。

  • 配信先が遅い。Kinesis Data Firehose で高レイテンシーが発生すると、データ配信が遅れることがあります。配信先のレイテンシーメトリクスをモニタリングします。

  • Lambda 関数が遅い。これにより、データ配信レートが配信ストリームのデータ取り込みレートよりも低くなる場合があります。可能であれば、Lambda 関数の効率を向上させます。たとえば、関数がネットワーク IO を実行する場合は、複数のスレッドまたは非同期 IO を使用して並列処理を増やします。また、Lambda 関数のメモリサイズを大きくすることで CPU 割り当てを相応に増やします。これにより、Lambda 呼び出しが高速化される場合があります。Lambda 関数の設定の詳細については、「」を参照してください。の設定AWSLambda 関数

  • データ配信中に障害が発生した。Amazon CloudWatch Logs を使用してエラーをモニタリングする方法については、「」を参照してください。CloudWatch Logs を使用した Kinesis Data Firehose のモニタリング

  • 配信ストリームのデータソースが Kinesis データストリームである場合、スロットリングが発生している可能性があります。ThrottledGetRecords メトリクス、ThrottledGetShardIterator メトリクス、および ThrottledDescribeStream メトリクスを確認します。Kinesis データストリームに複数のコンシューマがアタッチされている場合は、以下を考慮してください。

    • ThrottledGetRecords メトリクスと ThrottledGetShardIterator メトリクスが高い場合は、データストリーム用にプロビジョニングするシャードの数を増やすことをお勧めします。

    • そのファイルにThrottledDescribeStream高いのは、追加することをお勧めしますkinesis:listshardsで設定されたロールに対するアクセス許可KinesisStreamSourceConfiguration

  • 配信先のバッファリングヒントが低い。これにより、Kinesis Data Firehose が送信先に対して行う必要があるラウンドトリップの数が増える場合があります。そのため、配信が遅れる場合があります。バッファリングヒントの値を大きくすることを検討します。詳細については、「BufferingHints」を参照してください。

  • 再試行期間が長くなると、エラーの発生数が増えたときに配信が遅れる場合があります。再試行期間を短縮することを検討してください。また、エラーをモニタリングし、エラーを減らしてください。Amazon CloudWatch Logs を使用してエラーをモニタリングする方法については、「」を参照してください。CloudWatch Logs を使用した Kinesis Data Firehose のモニタリング

  • 配信先が Splunk である場合、DeliveryToSplunk.DataFreshness が高くても DeliveryToSplunk.Success が適切であると思われるときは、Splunk クラスターがビジー状態である可能性があります。可能であれば Splunk クラスターを解放します。または、問い合わせ中AWSSplunk クラスターとの通信に Kinesis Data Firehose が使用しているチャネルの数の増加Support およびリクエストします。

Apache Parquet へのレコード形式変換が失敗する

これは、を含む DynamoDB データを取得した場合に発生します。Set入力し、Lambda を介して配信ストリームにストリーミングし、AWS Glue Data Catalogレコード形式を Apache Parquet に変換します。

次のときAWS Glueクローラは DynamoDB セットのデータ型のインデックスを作成します (StringSet,NumberSet, およびBinarySet) の場合、データカタログに次のように格納されます。SET<STRING>,SET<BIGINT>, およびSET<BINARY>など、それぞれ記載されている。ただし、Kinesis Data Firehose がデータレコードを Apache Parquet 形式に変換するには、Apache Hive データ型が必要です。セット型は有効な Apache Hive データ型ではないため、変換は失敗します。変換を機能させるには、Apache Hive データ型でデータカタログを更新します。そのためには、データカタログの setarray に変更します。

AWS Glue データカタログで 1 つ以上のデータ型を set から array に変更するには

  1. AWS Management Console にサインインし、AWS Glue コンソール (https://console.aws.amazon.com/glue/) を開きます。

  2. 左側のペインの [データカタログ] 見出しにある [テーブル] を選択します。

  3. テーブルのリストで、1 つ以上のデータ型を変更する必要があるテーブルの名前を選択します。そのテーブルの詳細ページが表示されます。

  4. [スキーマの編集ボタンは、詳細ページの右上隅にあります。

  5. [データ型] 列で、最初のデータ型 set を選択します。

  6. [Column type] ドロップダウンリストで、set から array に型を変更します。

  7. [ArraySchema] に、array<string>array<int>、または array<binary> と入力します。これは、シナリオの適切なデータ型によって異なります。

  8. [更新] を選択します。

  9. 他の set 型を array 型に変換するには、前のステップを繰り返します。

  10. [Save] を選択します。

メトリクスが正常であるにもかかわらず、配信先にデータがない

データ取り込みの問題がなく、配信ストリームに関して生成されるメトリクスが正常と思われる場合でも、配信先にデータが表示されないときは、リーダーロジックを確認します。リーダーがすべてのデータを正しく解析していることを確認してください。