Metrics

Offline partitions

クラスタでリーダーがいないパーティション数。

メッセージの欠損やProducerのバックプレッシャーが起きたり、Producer側に影響出るので、0以外であれば確認する。

Under replicated partitions

レプリケーションが不足しているパーティションの数

単一のbrokerによるものか、クラスタ全体に関するものかを判断する。

• ホストレベルの問題
  • kafka-topics.shコマンドでunder-replicatedオプションをつけて共通のbroker idを確認する
  • ハードウェア障害、別のプロセスとの競合、ローカル設定の違い など
• クラスタの問題
  • 値が変動している場合はクラスタのパフォーマンス問題の可能性
  • 原因
    • アンバランスな負荷
      • パーティションやリーダーシップがアンバランス
      • Broker間で偏りがないか、Brokerのパーティションやメッセージのin/outを調べる
    • リソースの枯渇
      • CPU、ディスクIO、ネットワークなどを調べる

Purgatory Size

Producerでpartitionリーダーがフォロワーからレスポンスがあるまでこのキューに入る。Fetch requestも。

キューサイズが大きくなっていないか、増え続けていないかをチェックする

Request handler idle ratio

ネットワークスレッドとリクエストハンドラ(IOスレッド)の2つのスレッドプールがあり、これらのパフォーマンスをチェックする

• ネットワークスレッドは、ネットワーク経由のクライアントとのデータの読み書きをする。これが枯渇する心配はあまりない。
• リクエストハンドラ(IOスレッド)はクライアントリクエスト自体の処理を担当し、ディスクへの読み書きをする。

リクエストハンドラのアイドル率が小さいと、Brokerの負荷が大きい。

20%未満だと潜在的に問題ありそう、10%未満だとパフォーマンスに影響。

原因

• スレッドプールに十分なスレッドがない
  • スレッド数はプロセッサ数と同じに設定すべき
• スレッドがリクエストのたびに不必要な作業を行なっている
  • Producer, Broker, Consumerのバージョン違いによるメッセージの変換など

All topics bytes-in, bytes-out, message-in

正しく送受信しているか、偏りがないか

Request metrics

平均、99パーセンタイル、99.9パーセンタイルを見る。大きな変化がないか見る。正常の状態のときはこれらのメトリクスに大きな変動はない。問題があったときに詳細を見る

• Total time
  • Brokerがリクエストを受信してからリクエスト元にレスポンスを返すまでの時間
  • queue+local+remote+response
• Request queue time
  • リクエストを受信してから処理を開始するまでの時間
• Local time
  • パーティションのリーダーがリクエストを処理するのに費やした時間
• Remote time
  • リクエスト処理の完了前に、フォロワーを待つのに費やした時間
• Throttle time
  • クォータを満たすようにリクエストをスローダウンさせるためにレスポンスを保持した時間
• Response queue time
  • レスポンスをリクエスト元に送信するまで、リクエストがキューにある時間
• Response send time
  • レスポンスを送信するのに費やした時間