Kafka クライアント・メトリックの概要

Kafkaでは、モニターには通常、トピック、パーティション、ブローカー、およびコンシューマー・グループに関連するさまざまなメトリックが含まれます。 標準の Kafka メトリックには、スループット、待ち時間、複製、およびディスク使用量に関する情報が含まれます。 ご使用のバージョンの Kafka で使用可能な具体的なメトリックと、それらを効果的に解釈する方法については、 Kafka の資料 および関連するモニター・ツールを参照してください。

Kafka クライアントをモニターすることが重要なのはなぜですか?

データ・パイプラインの最適な機能と全体的な正常性を確保するには、 Event Streams インスタンスをモニターすることが重要です。 Kafka クライアントをモニターすると、リソース使用量の増加、消費者の遅れ、ボトルネックなど、アプリケーション障害の早期の兆候を識別するのに役立ちます。 これらの警告サインを早期に特定することで、ダウン時間を最小限に抑え、ビジネス・オペレーションの中断を防止する潜在的な問題に事前対応することができます。

Kafka クライアント (プロデューサーとコンシューマー) には、パフォーマンスと正常性をモニターするための独自のメトリック・セットがあります。 さらに、 Event Streams サービスは、サーバーによって生成される豊富なメトリック・セットをサポートします。 詳しくは、 Monitoring Event Streams service metrics by using IBM Cloud Monitoring を参照してください。

モニターするクライアント・メトリック

プロデューサー・メトリック

生産者メトリクス
メトリック 説明
レコード・エラー率 このメトリックは、エラーになった送信レコードの 1 秒当たりの平均数を測定します。 record-error-rate が高い場合、または record-error-rate が増加している場合は、データまたはデータが予期したとおりに処理されていないことを示している可能性があります。 これらの影響はすべて、 Kafkaで処理および保管するデータの整合性を損なう可能性があります。 このメトリックをモニターすると、プロデューサーによって送信されるデータが正確かつ確実に Kafka トピックに記録されるようにすることができます。
要求待ち時間の平均 これは、各作成要求の平均待ち時間 (ミリ秒) です。 待ち時間の増加はパフォーマンスに影響し、問題をシグナル通知する可能性があります。 request-latency-avg メトリックを測定すると、インスタンス内のボトルネックを識別するのに役立ちます。 多くのアプリケーションでは、高品質のユーザー・エクスペリエンスを確保するために待ち時間を短くすることが重要です。また、 request-latency-avg のスパイクは、プロビジョンされたインスタンスの制限に到達していることを示している可能性があります。 この問題を修正するには、プロデューサー設定を変更します。例えば、計画をバッチ処理またはスケーリングしてパフォーマンスを最適化します。
バイト・レート トピックの 1 秒当たりの平均送信バイト数は、スループットの指標です。 データを定期的にストリーミングする場合、スループットの低下は、 Kafka インスタンスでの異常を示している可能性があります。 Event Streams エンタープライズ・プランは、入口と出口の間で 1 対 1 で分割された 150 MB/ 秒から開始されます。実効キャパシティー・プランニングのためにどれだけの量を消費しているかを知ることが重要です。 内部更新や障害モード (アベイラビリティー・ゾーンの損失など) などの操作アクションによって生じる可能性のある影響を考慮して、最大スループットの 3 分の 2 を超えないようにしてください。

コンシューマー・メトリック

消費者指標
メトリック 説明
fetch-rate fetch-size-avg (フェッチ速度フェッチ・サイズの平均) 1 秒当たりのフェッチ要求数 (fetch-rate) および 1 要求当たりの平均フェッチ・バイト数 (fetch-size-avg) は、 Kafka コンシューマーのパフォーマンスがどの程度良好かを示す重要な指標です。 fetch-rate を大きくすると、特に少数のメッセージに対して非効率の信号が出される可能性があります。これは、データが不十分であるか、データが毎回受信されていない可能性があることを意味します。 fetch-rate および fetch-size-avg は、 fetch.min.bytes、 fetch.max.bytes、および fetch.max.wait.ms の 3 つの設定の影響を受けます。 これらの設定を調整して、必要な全体の待ち時間を達成すると同時に、フェッチ要求の数を最小限に抑え、場合によってはブローカー CPU への負荷を最小限に抑えます。 両方のメトリックをモニターおよび最適化することにより、現在および将来のワークロードのためにデータを効率的に処理することができます。
コミット待ち時間の平均 このメトリックは、コミットされたレコードが送信されてからコミット応答が受信されるまでの平均時間を測定します。 プロデューサー・メトリックとしての request-latency-avg と同様に、安定した commit-latency-avg は、オフセット・コミットがタイムリーに行われることを意味します。 コミット待ち時間が長い場合は、コンシューマーが迅速にオフセットをコミットできない問題を示している可能性があります。これは、データ処理の信頼性に直接影響します。 コンシューマーが以前にコミットされていないオフセットからのメッセージを再始動して再処理する必要がある場合、メッセージの処理が重複する可能性があります。 また、コミット待ち時間が長いということは、実際のメッセージ処理よりも管理操作に多くの時間を費やすことを意味します。 この問題により、特に大容量環境では、処理を待機しているメッセージのバックログが発生する可能性があります。
消費バイト率 これは、1 秒当たりに消費された平均バイト数を測定するコンシューマー・フェッチ・メトリックです。 プロデューサー・メトリックとしての byte-rate と同様に、これは安定した期待されるメトリックでなければなりません。 bytes-consumed-rate の予期される傾向の突然の変化は、アプリケーションに問題があることを示している可能性があります。 低い速度は、データ・フェッチまたはオーバー・プロビジョニング・リソースでの効率のシグナルである可能性があります。 レートを高くすると、消費者の処理能力が圧倒される可能性があるため、スケーリングが必要になり、負荷のバランスを取るために消費者をさらに作成したり、フェッチ・サイズなどの消費者構成を変更したりすることが必要になります。
rebalance-rate-per-hour 1 時間当たりに参加したグループ・リバランスの数。 再平衡化は、新しいコンシューマーが存在するたびに、またはコンシューマーがグループから離脱して処理が遅延するたびに行われます。 これが発生するのは、区画が再割り当てされるためです。これにより、1 時間当たりの再バランスの回数が多い場合、 Kafka コンシューマーの効率が低下します。 1 時間当たりのリバランス率が高くなるのは、消費者の行動が不安定になるような構成の誤りが原因である可能性があります。 このリバランス・アクションにより、待ち時間が長くなり、アプリケーションが異常終了する可能性があります。 低および安定した rebalance-rate-per-hour を追跡して、コンシューマー・グループが安定していることを確認します。