Kafka クライアント アプリケーションをモニタリングする

このドキュメントでは、Managed Service for Apache Kafka クラスタでデータを生成または使用するクライアントの状態をモニタリングする方法について説明します。

全体的な信頼性戦略の一環として、クライアント アプリケーションをモニタリングすることが重要です。スループット、エラー率、コンシューマーの遅延などの指標は、クライアント アプリケーションで信頼性の問題が発生しているかどうかを示します。問題の原因は、クライアント構成、パーティション間のキーの不均等な分布、特定のパーティションにのみ影響するクラスタの問題である可能性があります。

サーバーサイドの指標

クライアントの動作を直接モニタリングすることは有用ですが、サーバーサイドの指標では追加のインストゥルメンテーションは必要ありません。また、信頼性に影響するクライアントサイドの問題を検出するのに役立ちます。

サーバーサイドの指標は、ブローカー間のロード バランスの不均衡（ホットブローカー）や、レイテンシの急増などの通常のオペレーションからの逸脱を検出するのに特に役立ちます。

スループット

次のスループット指標をモニタリングし、想定されるスループットと比較します。

  • ブローカーごと、トピックごとのメッセージ レート。
  • ブローカーごと、トピックごとのバイトレート。
  • リクエスト率。クライアントが誤って構成されていると、ブローカーに大量の小さなリクエスト（リクエストあたり 0 ～ 1,000 バイト）が送信され、スループットが低下する可能性があります。
  • リクエストのレイテンシ。プロデューサー リクエストのレイテンシの急増は、ロードの不均衡またはクライアント構成の問題を示している可能性があります。

Kafka は、トピックごととクラスタごとのスループット指標を提供します。これらの指標は、すべてのトピックで集計した場合に常に同じ値になるとは限りません。高レベルのモニタリングとアラートには集計指標を使用し、スループットの問題のトラブルシューティングを行う場合はトピックごとの指標を確認します。問題を特定のブローカーに分離します。

リクエスト エラー率

topic_error_count 指標は、サーバーサイドで失敗したフェッチ リクエストと生成リクエストの数を追跡します。ただし、一部のエラークラスはこの指標に反映されません。次に例を示します。

  • 認証設定が正しく構成されていないと、この指標にエラーが表示されずに、クライアントがトピックに生成できなくなることがあります。

  • クラスタ障害が発生すると、ブローカーがリクエストにまったく応答できなくなる可能性があります。

そのため、リクエスト タイムアウト エラーなど、クライアントサイドのエラーもモニタリングする必要があります。

コンシューマー ラグ

コンシューマー ラグは、コンシューマー クライアントが特定のオフセットからどの程度遅れているかを測定します。この指標をトピック、パーティション、ブローカー別に集計すると、ラグが特定のブローカーまたはパーティションによるものかどうかを判断するのに役立ちます。

ワークロードにとって重要なトピックのサブセット全体で最大遅延に基づいてアラートを作成することを検討してください。

カスタム ダッシュボードのクエリ

これらのシグナルをモニタリングするには、カスタム ダッシュボードとアラートを作成することをおすすめします。次の表に、クライアントの健全性をモニタリングするために使用できる Prometheus Query Language（PromQL）クエリを示します。

シグナルPromQL クエリ
スループット: ブローカーあたりのメッセージ レート 
sum by (resource_container, location, cluster_id, broker_index) (
  rate(
    {
      "managedkafka.googleapis.com/message_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
スループット: ブローカーあたりのトピックあたりのメッセージ レート（上位 5 つのトピック） 
topk(5,
  sum by (resource_container, location, cluster_id, broker_index, topic_id) (
    rate(
      {
        "managedkafka.googleapis.com/message_in_count",
        monitored_resource="managedkafka.googleapis.com/Topic"
      }[${__interval}]
    )
  )
)
スループット: トピックとブローカーあたりの帯域幅 
sum by (resource_container, location, cluster_id, broker_index, topic_id) (
  rate(
    {
      "managedkafka.googleapis.com/byte_in_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
リクエスト レート 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/request_count",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "request"="Produce"
    }[${__interval}]
  )
)
リクエスト率、クラスタの合計 
sum by (resource_container, location, cluster_id, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_request_count",
      monitored_resource="managedkafka.googleapis.com/Topic",
      "request"="Produce"
    }[${__interval}]
  )
)
リクエストのレイテンシ 
sum by (resource_container, location, cluster_id, broker_index, request) (
  avg_over_time(
    {
      "managedkafka.googleapis.com/request_latencies",
      monitored_resource="managedkafka.googleapis.com/Cluster",
      "percentile"="95",
      "request"="Produce"
    }[${__interval}]
  )
)
リクエスト エラー数 
sum by (resource_container, location, cluster_id, broker_index, request) (
  rate(
    {
      "managedkafka.googleapis.com/topic_error_count",
      monitored_resource="managedkafka.googleapis.com/Topic"
    }[${__interval}]
  )
)
コンシューマー ラグ: コンシューマー ラグ別の上位 5 つのパーティション 
topk(5,
  max by (resource_container, location, cluster_id, broker_index, topic_id) (
    max_over_time(
      {
        "managedkafka.googleapis.com/consumer_lag",
        monitored_resource="managedkafka.googleapis.com/TopicPartition"
      }[${__interval}]
    )
  )
)

クライアントサイドの指標

クライアントの問題がサーバー指標に表示されないことがあります。次に例を示します。

  • 認証またはネットワーキングが正しく構成されていない場合、メッセージがクライアントの内部キューに蓄積される可能性があります。リクエストがタイムアウトすると、メッセージは再キューに追加され、再試行されます。

  • フロー制御が正しく構成されていない場合、クライアントは割り当てられたスレッド数で送信できるメッセージよりも多くのメッセージを生成する可能性があります。スループットは一定でも、リクエストのバックログが増加し、送信前に期限切れになることがあります。

クライアントが Compute Engine、Google Kubernetes Engine、Cloud Run で実行されている場合は、Cloud Monitoring のログベースの指標を使用して、ログのエラー率が高いことを検出できます。ただし、ログレベルを高く構成しない限り、一部の Kafka クライアントは、再試行の延長につながる例外を非表示にします。したがって、リクエスト レイテンシの増加もモニタリングする必要があります。

Java クライアントは、Java Management Extensions（JMX）を介して多くの指標を公開します。詳細については、Apache Kafka のドキュメントの Monitoring をご覧ください。可能であれば、次の指標をレポートするようにクライアントを計測することを優先します。

  • リクエスト エラー率（kafka.producer:type=producer-metrics,client-id="{client-id}"）
  • リクエストの平均レイテンシ（kafka.producer:type=producer-metrics,client-id="{client-id}"）

可能であれば、これらの指標をモニタリング ソリューションに送信します。クライアント インスタンスを実行するマシンの JMX ポートに接続できる場合は、これらの指標をインタラクティブに読み取ることもできます。

緩和策

クライアント アプリケーションで問題が発生した場合は、次の軽減策を検討してください。

  • ブローカー間の負荷の不均衡（ホットブローカー）を探します。クラスタで自動再調整が有効になっていることを確認します。

  • リクエスト率が異常に高いと思われる場合は、クライアントが多数の小さなリクエストを送信しているかどうかを確認します。プロデューサーの max.request.size 構成と batch.size 構成を確認します。

  • 認証、ネットワーキング、フロー制御のクライアント構成を確認します。

  • クラスタ内のすべてのトピックまたはパーティションで過剰な遅延が発生している場合は、クラスタが過負荷になっている可能性があるため、スケールアップする必要があります。

  • ブローカー内のすべてのトピックまたはパーティションで過剰な遅延が発生している場合は、ブローカーが過負荷になっている可能性があります。キーの配布を改善するか、別のブローカーにパーティションを再割り当てしてみてください。

次のステップ