このドキュメントでは、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, topic_id, partition_index) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
| コンシューマー ラグ: オフセットラグ別の上位 5 つのコンシューマー グループ | topk(5, max by (resource_container, location, cluster_id, consumer_group_id) ( max_over_time( { "managedkafka.googleapis.com/offset_lag", monitored_resource="managedkafka.googleapis.com/TopicPartitionConsumerGroup" }[${__interval}] ) ) ) |
クライアントサイドの指標
クライアントの問題がサーバーの指標に表示されないことがあります。次に例を示します。
認証またはネットワーキングが正しく構成されていない場合、メッセージがクライアントの内部キューに蓄積される可能性があります。リクエストがタイムアウトすると、メッセージは再度キューに入れられ、再試行されます。
フロー制御が誤って構成されていると、クライアントは、割り当てられたスレッド数で送信できる数よりも多くのメッセージを生成する可能性があります。スループットは一定である可能性がありますが、リクエストのバックログが増加すると、送信される前に期限切れになります。
クライアントが Compute Engine、Google Kubernetes Engine、または Cloud Run で実行されている場合は、Cloud Monitoring のログベースの指標を使用して、ログ内の高いエラー率を検出できます。ただし、一部の Kafka クライアントでは、より高いログレベルを構成しない限り、再試行が長引く原因となる例外が非表示になります。そのため、リクエスト レイテンシの増加もモニタリングする必要があります。
Java クライアントは、Java Management Extensions（JMX）を介して多くの指標を公開します。詳細については、Apache Kafka ドキュメントのモニタリングをご覧ください。可能であれば、次の指標を報告するようにクライアントを優先的に計測します。
- リクエスト エラー率（
kafka.producer:type=producer-metrics,client-id="{client-id}"） - リクエストの平均レイテンシ（
kafka.producer:type=producer-metrics,client-id="{client-id}"）
可能であれば、これらの指標をモニタリング ソリューションに送信します。クライアント インスタンスを実行するマシンの JMX ポートに接続できる場合は、これらの指標をインタラクティブに読み取ることもできます。
緩和策
クライアント アプリケーションで問題が発生した場合は、次の緩和策を検討してください。
ブローカー間の負荷の不均衡（ホット ブローカー）を探します。クラスタで自動リバランスが有効になっていることを確認します。
リクエスト率が異常に高いと思われる場合は、クライアントが多数の小さなリクエストを送信しているかどうかを確認します。プロデューサーの
max.request.sizeとbatch.sizeの構成を確認します。認証、ネットワーキング、フロー制御のクライアント構成を確認します。
クラスタ内のすべてのトピックまたはパーティションで過剰なラグが発生している場合は、クラスタが過負荷状態であり、スケールアップが必要であることを示している可能性があります。
ブローカー内のすべてのトピックまたはパーティションで過剰なラグが発生している場合は、ブローカーが過負荷になっている可能性があります。キーの分散を改善するか、別のブローカーにパーティションを再割り当てしてみてください。