クライアントのモニタリング¶

Confluent Cloud で Apache Kafka® アプリケーションを開発する場合は、最適なパフォーマンスを維持するためにデプロイの正常性をモニタリングすることが重要です。パフォーマンスのモニタリングを行うと、各 Kafka コンポーネントまたは Confluent コンポーネントの正常性が定量的に計算されるので、役に立ちます。

本稼働環境は動的です。つまり、データプロファイルが変わったり、新しいクライアントを追加したり、新しい機能を有効にしたりすることがあります。そのため、パフォーマンスのモニタリングは必要不可欠です。継続的モニタリングとは、本稼働環境が変更されても常にサービス目標を満たすようにすることであると同時に、潜在的な障害を検出して対応することでもあります。本稼働環境に移行する前に、プロデューサー、コンシューマー、トピック、および使用するその他の Kafka コンポーネントや Confluent コンポーネントをすべて監視する堅牢なモニタリングシステムを構築する必要があります。

このページの情報は、Confluent Cloud を使用する場合に堅牢なパフォーマンスモニタリングシステムを構成するのに役立ちます。

Metrics API¶

Confluent Cloud のメトリクスは、Confluent Cloud デプロイのための実用的なメトリクスにプログラムでアクセスできるようにするものです。このようなメトリクスには、Confluent 管理のサービスに関するサーバー側のメトリクスなどがあります。一方、クライアント側のメトリクスは、Metrics API では取得できません。クライアント側のメトリクスを取得するには、「プロデューサー」および「コンシューマー」を参照してください。

Metrics API はデフォルトで有効になっており、トピックレベルとクラスターレベルでメトリクスを集約します。許可されたユーザーは、メトリクスにアクセスして全体的な使用量とパフォーマンスをモニタリングすることができます。Metrics API の利用を開始するには、「Confluent Cloud のメトリクス」ドキュメントを参照してください。

Metrics API を使用して、次の単位でメトリクスに対してクエリを実行できます（必要に応じて別の単位も使用できます）。

トピック別に集計された 1 分あたりの生成バイト数
トピック別に集計された 1 分あたりの消費バイト数
特定のトピックについて 2 時間以上保持された最大バイト数/時間
特定のクラスターについて 2 時間以上保持された最大バイト数/時間

これらのメトリクスを HTTPS を使用してインターネットから簡単に取得できます。一定間隔で取り込むことで時系列データを作成し、クラスターのパフォーマンスのオペレーションビューを利用することができます。これらのメトリクスを、Azure Monitor、Google Cloud オペレーションスイート（旧 Stackdriver）、Amazon CloudWatch などのクラウドプロバイダーモニタリングツールや、Prometheus、Datadog などの既存のモニタリングシステムに統合して時系列グラフとしてプロットすると、使用量の経時変化を調べることができます。Metrics API を使用するアプリケーションを独自に作成する場合は、API の詳しい仕様を参照して高度な機能を利用してください。

クライアントの JMX メトリクス¶

Kafka アプリケーションは、一部の内部 Java Management Extensions（JMX）メトリクスを公開しており、多くのユーザーが、JMX エクスポーターを実行してメトリクスを各自のモニタリングシステムに取り込んでいます。JMX_PORT 環境変数を構成して Kafka クライアントを開始すれば、ユーザー管理のクライアントアプリケーションやサービスに関する JMX メトリクスを取得できます（Confluent 管理のサービスに関するメトリクスではありません。これらはユーザーには直接公開されません）。JMX で公開される Kafka 内部メトリクスは多数あるので、アプリケーションのパフォーマンスに関する洞察を引き出すことができます。

プロデューサー¶

スロットリング¶

Confluent Cloud サービスプランによっては、生成（書き込み）のスループット速度に一定の制限が適用される場合があります。クライアントアプリケーションが生成速度を超えると、ブローカーのクォータによって検知され、ブローカーがクライアントアプリケーションのリクエストにスロットルを適用します。想定される量を超えるリソースをアプリケーションで消費しないようにすることが重要です。ブローカーがクライアントアプリケーションのリクエストにスロットリングを適用した場合には、次の 2 つの方法について検討してください。

スループットを最適化するように、アプリケーションに変更を加える。スループットを最適化する方法について詳しくは、「スループットのための最適化」を参照してください。
上限を引き上げたクラスター構成にアップグレードする。Confluent Cloud では、標準クラスターまたは専用クラスターを選択できます（上限を引き上げるようにカスタマイズ可能）。Metrics API から、サーバー側のスループットについて示す情報を得ることができます。しかし、クライアント側のスループットメトリクスを得ることはできません。

プロデューサー別のスロットリングメトリクスを取得するには、次のクライアント JMX メトリクスをモニタリングしてください。

メトリック	説明
`kafka.producer:type=producer-metrics,client-id=([-.w]+),name=produce-throttle-time-avg`	リクエストがブローカーによってスロットリングされた平均時間（ミリ秒）
`kafka.producer:type=producer-metrics,client-id=([-.w]+),name=produce-throttle-time-max`	リクエストがブローカーによってスロットリングされた最長時間（ミリ秒）

ユーザー処理¶

プロデューサーにメッセージの送信をブロックするコードが存在しなければ、プロデューサーのパフォーマンスをさらにチューニングするために、ユーザー処理に費やされたプロデューサー時間をモニタリングしてください。次の io-ratio メトリクスと io-wait-ratio メトリクスを使用します。両方のメトリクスで費やされた時間を除く時間が、ユーザーの処理時間に相当します。これらのメトリクスの時間が短ければ、ユーザー処理時間が長く、単一プロデューサーの I/O スレッドのビジー状態が続いていることになります。たとえば、プロデューサーがコールバックを使用しているかどうかを確認できます（コールバックは、メッセージの受領応答が返されると呼び出され、I/O スレッドで実行されます）。

メトリック	説明
`kafka.producer:type=producer-metrics,client-id=([-.w]+),name=io-ratio`	I/O スレッドで I/O 処理に費やされた時間
`kafka.producer:type=producer-metrics,client-id=([-.w]+),name=io-wait-ratio`	I/O スレッドで待機に費やされた時間

コンシューマー¶

スロットリング¶

前にプロデューサーについての説明で触れたように、Confluent Cloud サービスプランによっては、消費（読み取り）のスループット速度に一定の制限がかかる場合があります。クライアントアプリケーションがこれらの消費速度を超えた場合は、前述の 2 つの方法について検討してください。

コンシューマー別のスロットリングメトリクスを取得するには、次のクライアント JMX メトリクスをモニタリングしてください。

メトリック	説明
`kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.w]+),name=fetch-throttle-time-avg`	ブローカーがフェッチリクエストのスロットリングに費やした平均時間（ミリ秒）
`kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.w]+),name=fetch-throttle-time-max`	ブローカーがフェッチリクエストのスロットリングに費やした最長時間（ミリ秒）

コンシューマーラグ¶

アプリケーションの コンシューマーラグ もモニタリングする必要があります。コンシューマーラグとは、コンシューマーがログに消費することが遅れているパーティションのレコード件数です。コンシューマーができる限り低いレイテンシで最新のメッセージを処理しなければならないリアルタイムのコンシューマーアプリケーションにとっては、このメトリックが特に重要です。コンシューマーラグをモニタリングすると、十分な速度でコンシューマーがブローカーからレコードをフェッチできているかどうかがわかります。オフセットがコミットされる方法についても検討する必要があります。たとえば、EOS（「厳密に 1 回」のセマンティクス）は、コンシューマーラグを増加させる可能性がありますが、よりしっかりとした保証を提供します。コンシューマーラグは Confluent Cloud ユーザーインターフェイスからモニタリングできます（「コンシューマーラグのモニタリング」のドキュメントを参照）。JMX メトリクスを取り込む場合は、records-lag-max をモニタリングできます。

メトリック	説明
`kafka.consumer:type=consumer-fetch-manager-metrics,client-id=([-.w]+),records-lag-max`	この時間枠でのパーティションのラグ（レコード件数）の最大値。この値が時間の経過とともに増加する場合は、そのコンシューマーグループがプロデューサーから後れを取っていることを表しています。

その他のリソース¶

Apache Kafka® クライアントアプリケーションおよび Confluent Cloud メトリクスをモニタリングする方法のサンプル、およびさまざまな失敗のシナリオに対応してメトリクスの結果を表示する手順については、Confluent Cloud に接続する Apache Kafka® クライアント用の Observability のデモを参照してください。