カフカのこの「千里眼」について知っておく必要があります! ！ ！

[[413084]]

Kafka クラスターの担当者としては、メッセージのバックログや繰り返しの再バランス調整などの問題がコンシューマー側で発生したときに、パフォーマンスのボトルネックを迅速に特定することが重要です。

この記事では、アーキテクトが提案するパフォーマンス最適化ソリューションにデータサポートを提供するために、コンシューマー側の監視指標について詳しく紹介します。

Kafka の設計者はすでにこの点を考慮しており、さまざまな監視指標を提供しています。

1. 消費者指標

Kafka の監視インジケーターは MBean を通じて保存され、jconsole を通じて表示できます。スクリーンショットは次のとおりです。

主に以下の4つの次元に分かれます。

• 消費者コーディネーターメトリクス

消費者団体コーディネーターに関連する指標の監視。

• コンシューマー フェッチ マネージャー メトリック

消費者グループのメッセージプルに関連する監視指標

• コンシューマーノードメトリクス

ブローカー ノードに基づく統計情報、複数のブローカー ノードからメッセージをプルするコンシューマーなどの監視指標。

• Kafka メトリクス カウント

次に、各指標について詳しく説明し、各指標の意味を詳しく説明するとともに、実践的なガイダンスを提供します。

1.1 消費者グループコーディネーターの監視指標

グループコーディネーターに関連する監視指標の詳細な説明は次のとおりです。

詳細な手順は次のとおりです。

• 参加時間最大

消費者が消費者グループに再参加できる最大時間

• 参加時間平均

消費者が消費者グループに再加入するまでにかかる平均時間

• 参加率

消費者グループに参加する消費者のTPS

実用的なガイダンス: この値は 0 であることが正常です。値が大きいほど問題が多くなり、コンシューマーが頻繁にコンシューマーに参加しており、コンシューマーに参加するプロセス中にメッセージを消費しないことを示します。

• 参加時間平均

消費者が消費者グループに参加するまでにかかる平均時間

• 合計を結合

消費者が消費者グループに再加入した回数（リバランスが発生した回数）

実践的なガイダンス: この値を収集します。値が大きすぎる場合は、再バランスの回数が多すぎることを意味し、再バランス中にコンシューマーはメッセージの消費に参加しません。

• コミットレイテンシ平均

サイトを送信する平均時間

• コミットレート

サイトのTPSを送信する

• コミットレイテンシ最大値

サイト送信時の最大遅延

• コミット合計

消費者が開始してからのサイト送信の総数

• 同期時間平均

同期を送信するコンシューマーの平均応答時間。

知識ポイント: コンシューマーがグループに参加した後、コンシューマーのリーダーがキューの割り当てを担当し、割り当て計画をグループ コーディネーターに送信します。各スレーブ ノードは、グループ コーディネータから割り当てられたキューを取得します。

• 同期レート

コンシューマが同期tpsを送信する

• 同期合計

コンシューマーが送信した同期リクエストの総数

• 同期時間最大

コンシューマー同期要求応答の最大応答時間

• 割り当てられたパーティション

現在割り当てられているパーティションの数

• 心拍数合計

ハートビート要求の総数

• ハートビート応答時間最大

ハートビート要求の最大応答時間

• 最後のハートビート秒前

最後のハートビートパケットが送信された時刻

• 心拍数

ハートビートパケット送信のTPS

監視指標から、消費者側コーディネーターの責任を知ることができます。

• 消費者が消費者グループに参加できるよう調整する
• キューの負荷を分散するために消費者リーダーを調整する
• セッションを維持するためにハートビートを送信する
• サイトを送信

1.2 コンシューマーメッセージプル監視指標

コンシューマーとメッセージのプルに関連する監視インジケーターを次の図に示します。

消費者グループによって取得される指標の構成は、消費者グループと、消費者グループによってサブスクライブされる複数のトピックの 2 つの次元に分かれています。

次に、上記の指標を詳細に分析します。

• 消費バイト数

消費者がビジネスに送信する 1 秒あたりの tps。

• 消費バイト数合計

現在コンシューマーによって消費されているバイトの合計数。

• フェッチレイテンシ最大値

API.FETCH リクエスト (つまり、ブローカーにメッセージを送信して取得する) にかかる最大時間。

• リクエストあたりの平均レコード数

フェッチ要求ごとに取得されたメッセージの数 (現在のインジケーターの平均値)。

• フェッチレート

クライアントから送信された Fetch 要求の tps。

• フェッチ合計

クライアントによって開始されたフェッチ要求の合計数

• フェッチスロットル時間最大

メッセージのプル (フェッチ要求) には、サーバー (ブローカー) のフロー制限により、最大フロー制限期間があります。ブローカー側のフロー制限メカニズムについては、後で詳しく説明します。

• フェッチスロットル時間平均

メッセージ取得要求の平均フロー制限期間。

• フェッチサイズ最大

一度に 1 つのパーティションから取得できる最大バイト数。

実用的なガイダンス: 消費者のメッセージ取得能力を評価するには、この値を収集して監視することが非常に重要です。設定した期待値に近い値が継続している場合でも、消費者の TPS が需要を満たしていない場合は、値を適宜増やすことができます。

• フェッチ待ち時間平均

メッセージの取得に費やされた平均時間。

• フェッチサイズ平均

メッセージごとに取得される平均バイト数

• 消費されたレコードの合計

消費者側の合計バイト数

• レコードリード分

現在の消費位置とログ終了時の最小位置の差。

• レコードラグ最大

コンシューマーに割り当てられたパーティション内の最大メッセージ バックログ。

実用的なガイダンス: この値に基づいてアラームを発行できます。

コンシューマーは、トピック パーティション レベルで消費の進行状況に関連するメトリックも収集します。関連するメトリックは次のように説明されます。

• 記録の遅れ
• レコード遅延平均
• レコードラグ最大
• 記録リード
• 記録リード平均
• レコードリード分

上記の指標については、主に2つの基本的な意味を説明し、他の指標は集計計算（最大、平均）となります。

• 記録の遅れ

消費バックログとは、現在のパーティション内の消費サイトと最大サイト間のギャップを指します。値が大きいほど、消費者側の処理速度が遅くなります。これには特別な注意が必要であり、通常はプロジェクト関係者にタイムリーに通知するためにアラームにアクセスする必要があります。

• 記録リード

現在のパーティションの消費サイトと最小サイト間のギャップ。この値の具体的な用途はまだわかりません。興味のある読者の方は、ぜひ私までご連絡ください。

1.3 消費者ネットワーク関連の監視指標

上記の指標は、主にコンシューマー側コーディネーターとコンシューマー側フェッチ（メッセージのプル）という 2 つの重要な側面に焦点を当てています。次に、メッセージ送信者の観点から、基盤となるネットワーク IO やその他の側面に関連する指標に注目してみましょう。関連するインジケーターのコレクション エントリは、Kafka の org.apache.kafka.common.network.Selector です。具体的な指標は次の図のとおりです。

実際、これらの指標は、次のように生産者の指標と基本的に同じです。

• リクエストレート

tps の送信を要求します。

• リクエストサイズ最大

送信要求の最大バイト数

• リクエストサイズ平均

リクエストの平均サイズ

• リクエスト合計

リクエストの総数

• 選択率

イベントセレクター tps。

• 選択合計

イベントセレクタがイベント選択を実行した合計回数

• 回答合計

応答リクエストの総数

• 応答率

レスポンスTPS

• 送信バイトレート

1秒あたりの送信バイト数

• 送信バイト合計

送信された合計バイト数

• 受信バイトレート

1秒あたりの受信バイト数

• 受信バイト合計

受信したバイト数の合計

• io比率

IOスレッドがIOの読み取りと書き込みを処理する合計時間

• io-time-ns-平均

各イベントセレクタがIO操作を呼び出す平均時間（ナノ秒単位）

• io-待機時間合計

IO スレッドが読み取り/書き込みの準備ができるまで待機する平均時間 (ナノ秒単位)

• iotime合計

合計 IO 処理時間。

• io 待機比率

IO待機時間と総IO処理時間の比率

• io 待機時間 (ns) 平均

IO スレッドの平均待機時間 (ナノ秒)

実践的なガイダンス: ネットワーク関連の監視指標については、IO スレッドに関連するパフォーマンスに重点を置くことができます。

1.4 ブローカーノードによる監視データの収集

クライアントは、リクエスト tps や平均応答時間など、ブローカーのディメンションに従ってリクエスト関連の指標を収集することにも重点を置きます。

実践ガイダンス: モニタリング指標の意味については上記で説明しました。これらの指標、特に request-latency-max と request-latency-avg は、ブローカーにボトルネックがあるかどうかを確認するのに役立つため、収集する価値が最も高くなります。

2. モニタリング指標の収集

Kafka には多くの組み込み監視インジケーターがありますが、これらのインジケーターはデフォルトではメモリに保存されます。監視データはメモリに保存されるため、監視データが際限なく増加してメモリ オーバーフローが発生するのを防ぐため、監視データの保存は通常、スライディング ウィンドウに基づいて行われます。つまり、ローリング カバレッジでは、最新の期間の監視データのみが保存されます。

したがって、これらの指標をより直感的に表示するには、これらの情報を定期的に収集し、他のデータベースやその他の永続ストレージに均一に保存する必要があるため、履歴データに基づいて曲線を描くことができます。望ましい効果は次の図に示されています。

ここに画像の説明を挿入

基本的な監視および取得システムのアーキテクチャ設計を下図に示します。

mq-collect はプロデューサー SDK に配置する必要があります。収集された情報は、mq-collect ライブラリを通じて、時系列データベース InfluxDB に非同期かつ定期的にアップロードできます。次に、mq-portal ポータル表示ページを使用して各運用クライアントの指標を視覚化し、監視データの視覚化を実現して、パフォーマンス最適化の基礎を提供します。

この記事はWeChatの公開アカウント「Middleware Interest Circle」から転載したものです。以下のQRコードからフォローできます。この記事を転載する場合は、Middleware Interest Circle の公開アカウントにお問い合わせください。