Linuxマシン上でAmazon Kinesis エージェントの問題をトラブルシューティングするにはどうすればよいですか?

最終更新日: 2022 年 5 月 5 日

Linux マシンで Amazon Kinesis エージェントを使用しようとしています。しかし、問題が発生しています。これを解決するにはどうすればよいですか?

簡単な説明

この記事では、次の問題について説明します:

  • Kinesis エージェントが重複するイベントを送信しています。
  • Kinesis エージェントが原因で、Amazon Kinesis ストリーミングに書き込みスロットルと障害レコードが発生しています。
  • Kinesis エージェントはログファイルを読み取ったりストリーミングしたりできません。
  • Java ヒープサイズが不足しているため、Amazon Elastic Computing (Amazon EC2)サーバーの障害が続いています。
  • Amazon EC2 の CPU 使用率が非常に高いです。

解決策

Kinesis エージェントが重複するイベントを送信しています

Kinesis エージェントからログを送信するたびに重複を受信する場合は、一致パターンが正しく修飾されていない場所でファイルローテーションが行われている可能性があります。ログを送信するたびに、Kinesis エージェントはファイルパターンに一致する各ファイルの latestUpdateTimestamp をチェックします。デフォルトでは、Kinesis エージェントは、ローテーションパターンに一致するアクティブなファイルを識別し、最も最近更新されたファイルを選択します。複数のファイルが同時に更新された場合、Kinesis エージェントは追跡するアクティブなファイルを判別できません。したがって、Kinesis エージェントは更新されたファイルを最初からテールし始め、いくつかの重複を引き起こします。

この問題を回避するには、個々のファイルごとに異なるファイルフローを作成し、代わりにファイルパターンがローテーションを追跡するようにします。

注: ローテーションを追跡している場合は、copytruncate の代わりに、ログローテーション設定の 作成 または 名前変更 を使用することをお勧めします。

例えば、次のようなファイルフローを使用できます:

"flows": [
        {
            "filePattern": "/tmp/app1.log*",
            "kinesisStream": "yourkinesisstream1"
        },
        {
            "filePattern": "/tmp/app2.log*",
            "kinesisStream": "yourkinesisstream2"
        }
    ]

また、Kinesis エージェントは、断続的なネットワークの問題が発生した場合、返送に失敗したレコードを再試行します。Kinesis エージェントがサーバー側の確認応答を受信できない場合、Kinesis エージェントは再度試行し、重複を作成します。この例では、ダウンストリームアプリケーションの重複を排除する必要があります。

チェックポイントファイルが調節されたり、削除された場合にも、重複が発生する可能性があります。チェックポイントファイルが /var/ run / aws-kinesis-agent に保存されている場合、再インストールまたはインスタンスの再起動中にファイルがクリーンアップされる可能性があります。Kinesis エージェントを再度実行すると、ファイルを読み取ると同時にアプリケーションに障害が起こり、重複が発生します。したがって、チェックポイントをメインのエージェントディレクトリに保持し、Kinesis エージェントの設定を新しい場所で更新します。

たとえば、次のようになります:

"checkpointFile": "/aws-kinesis-agent-checkpoints/checkpoints"

Kinesis エージェントが原因で、Amazon Kinesis データストリーミングに書き込みスロットルと障害レコードが発生

デフォルトでは、Kinesis エージェントはログファイルをできるだけ早く送信しようとするため、Kinesisのスループットしきい値を突破してしまいます。ただし、障害レコードは再キューされ、データの損失を防ぐために継続的に再試行されます。キューがいっぱいになると、Kinesis エージェントは ファイルのテーリング を停止します。これにより、アプリケーションが遅延する可能性があります。

例えば、キューがいっぱいの場合、ログは次のようになります:

com.amazon.kinesis.streaming.agent.Agent [WARN] Agent: Tailing is 745.005859 MB (781195567 bytes) behind.

注: キューサイズは PublishQueueCapacity パラメータによって決定されます (デフォルト値は「100」に設定されています)。

Kinesis データストリームで障害レコードやパフォーマンスの問題を調査するには、次のことを試してください:

  • Amazon CloudWatch で recordSenderErors のメトリクスをモニタリングします。
  • Kinesis エージェントのログを確認して、ラグが発生していないかどうかを確認します。ProvidedThroughputExceededException エントリは、DEBUG ログレベルでのみ表示されます。この間、CPU の大部分がデータの解析と変換に使用されている場合、Kinesis エージェントのレコード送信速度が遅くなることがあります。
  • Kinesis エージェントが遅れている場合は、Amazon Kinesis 配信ストリームの規模を拡大することを検討してください。

Kinesis エージェントがログファイルを読み取ったりストリーミングしたりできません

Kinesis エージェントが実行されている Amazon EC2 インスタンスに、宛先の Kinesis 配信ストリームにアクセスするための適切なアクセス許可を持っていることを確認してください。Kinesisエージェントがログファイルを読み取れない場合、Kinesisエージェントにそのファイルの読み取り権限があるかどうかを確認します。このパターンに一致するすべてのファイルについて、読み取り権限を aws-kinesis-agent-user に付与する必要があります。ファイルを含むディレクトリの場合、読み取りと実行権限とを aws-kinesis-agent-user に付与する必要があります。そうしないと、アクセス拒否エラーまたは Java ランタイム例外が発生します。

Java ヒープサイズが不十分なため、Amazon EC2 サーバーの障害が続く

Java ヒープサイズが不十分なためにAmazonEC2 サーバーに障害が発生し続ける場合は、Amazon Kinesis エージェントに割り当てられているヒープサイズを増やしてください。Kinesis エージェントで使用できるメモリ量を設定するには、「start-aws-kinesis-agent」ファイルを更新してください。以下のパラメータの設定値を増やしてください:

  • AVA_START_HEAP
  • JAVA_MAX_HEAP

注: Linuxでは、「start-aws-kinesis-agent」のファイルパスは「/ usr / bin/start-aws-kinesis-agent」です。

Amazon EC2 の CPU 使用率が非常に高い

Kinesis エージェントが最適化されていない正規表現パターンマッチングとログ変換を実行している場合、CPU 使用率が急上昇する可能性があります。すでに Kinesis エージェントを設定している場合は、すべての正規表現 (regex) パターンの一致と変換を削除してみてください。次に、CPU の問題がまだ発生しているかどうかを確認します。

それでも CPU の問題が発生する場合は、メモリにバッファリングされているスレッドとレコードを調整することを検討してください。または、/etc/aws-kinesis/agent.json 構成設定ファイルのデフォルトパラメータの一部を更新してください。Kinesis エージェント構成ファイルでもいくつかのパラメータを下げることができます。

下げることができる一般的な構成パラメーターは次のとおりです:

  • sendThreadsMaxQueueSize: データを宛先に送信するための threadPool の workQueue サイズ。デフォルト値は 100 です。
  • maxSendingThreads: データを宛先に送信するためのスレッドの数。最小値は 2 です。デフォルト値は、マシンのコア数の 12 倍です。
  • maxSendingThreadsPerCore: データを宛先に送信する際のコアあたりのスレッド数。デフォルト値は 12 です。
下げることができるフロー構成パラメータは次のとおりです:
  • publishQueueCapacity: 宛先に送信される前にキューに入れることができるレコードのバッファーの最大数。デフォルト値は 100 です。
  • minTimeBetweenFilePollsMillis: 追跡されたファイルがポーリングされて新しいデータの解析が開始される時間間隔。デフォルト値は 100 です。

この記事はお役に立ちましたか?


請求に関するサポートまたは技術サポートが必要ですか?