永続的なクエリのモニタリング¶

Confluent Cloud Console と Metrics API を使用して、永続的なクエリの正常性のモニタリングと問題のトラブルシューティングが行えます。

正常性のインジケーター¶

正常性についての以下のインジケーターをモニタリングできます。

ストレージ使用率¶

ストレージ使用率は、集約や結合といったステートフルクエリのステートを保管するために ksqlDB が使用したストレージ容量の割合を、パーセントで表したメトリックです。この値が 100%（1.0）に達した場合、ステートを保持するために使用できるストレージ空き容量がないため、ksqlDB はレコードの処理を継続できなくなります。

ksqlDB Web インターフェイスの Performance タブで、現在および過去のストレージ使用率を確認できます。また、Confluent Cloud Metrics API を使用して、ストレージ使用率に対してクエリを実行することもできます。

コンシューマーグループラグ¶

コンシューマーグループラグは、クエリが消費する各ソーストピックのパーティションについて、現在の処理オフセットと前回のオフセットの差を表します。この値にはスパイクが発生することもありますが、コンシューマーラグが持続的に増加する場合は、クエリが消費するレコードがトピックに追加されるにつれて、ksqlDB によるレコード処理が間に合わなくなる可能性があります。

コンシューマーグループラグをモニタリングするには、クエリのコンシューマーグループを取得してから、それらのグループのラグをモニタリングする必要があります。

クエリのコンシューマーグループラグを取得するには、ksqlDB の EXPLAIN ステートメントを使用します。

EXPLAIN <QUERY ID>;

これにより、次のような応答が返されます。

{
  "queryDescription": {
    "consumerGroupId": "<consumer group id>"
  }
}

コンシューマーグループ ID を取得したら、コンシューマーラグのモニタリングに対して管理用の API または UI を使用できます。

以下のセクションでは、これらのインジケーターのいずれかによって問題が示された場合のトラブルシューティング方法について説明します。

クエリ飽和¶

クエリ飽和は、クエリ処理のスレッドが、シリアル化または非シリアル化、式の評価、集約と結合のステートの読み取りまたは書き込みなどのレコード処理にかかる時間をパーセントで表します。クエリを処理するスレッドが何も処理していないときは、処理する新しいレコードが渡されるのを待機しているため、クエリ処理スレッドがほぼ常時処理を実行している場合は、ソーストピックのパーティションに追いつけない可能性があります。このメトリックは、ksqlDB クラスターのすべてのクエリでの最大値を返します。コンシューマーグループのラグが増大している場合は、このメトリックを確認してください。

ksqlDB Web インターフェイスの Performance タブで、このメトリックの現在および過去の値が確認できます。また、Metrics API を使用して、現在および過去の飽和に対してクエリを実行することもできます。

トラブルシューティング¶

ストレージ使用率が高い¶

クラスターの空きストレージ容量がない場合には、2 つの選択肢があります。

The simplest option is to provision a cluster with more CSUs. Each CSU gets you 125 GB of storage space, but for 8 and 12 CSUs, ksqlDB automatically maintains replicas of your data. For more information, see CSUs and storage.

Before provisioning a cluster with more CSUs, you may want to make sure that your storage usage is not skewed such that the storage cannot be distributed across the cluster. To check this, use the Metrics API to query the storage usage broken down by task.

Each CSU adds 125GB of storage, and each task can only be run on 1 CSU. If you have a small number of tasks that store 125GB of data or more, adding CSUs won't help, because the storage from these tasks can't be distributed across the cluster.

If your storage usage is skewed, or you want to try to optimize your storage usage, you can find the queries that use lots of storage, and either drop or change the query or data to prevent skew or reduce footprint. Use the Metrics API to query current and historical state usage by query.

Ultimately, the feasibility of preventing skew or reducing footprint depends on your workload.

You may find that the source topic for a table has just one partition, and therefore a query that materializes the table runs only a single stateful task. You can mitigate this situation by repartitioning your source topic to increase the number of partitions.
You may find that one or a few partitions of your source topic contain all or most of its data. In this scenario, consider changing the partitioning scheme.

コンシューマーラグの増加¶

コンシューマーラグの増加をトラブルシューティングするには、まず現在コミットされているオフセットを確認し、実際にクエリがデータを処理しているかどうかを判定します。この値が絶えず増加している場合、レコードは処理されています。そうでない場合、クエリにエラーが発生している可能性があります。クエリステータスのページを参照して、原因を確認する必要があります。

クエリの処理が進んでいない場合は、外部サービス（Apache Kafka® など）または ksqlDB リソースがボトルネックになっている可能性があります。クエリのボトルネックが ksqlDB リソースにある場合は、より多くの CSU を構成した別の ksqlDB クラスターをプロビジョニングする必要があります。

ksqlDB でのボトルネックが限られたリソースによって発生しているのかどうかを確認するには、クエリ飽和メトリックを参照します。このメトリック値が 80%（0.80）を継続的に超えている場合、ksqlDB はソーストピックでの追加速度にほとんど追随できないため、CSU の追加を試みる必要があります。

クエリ飽和が高い場合であっても、より多くの CSU をクラスターにプロビジョニングしても効果がないことがあります。この場合、クエリへの負荷が少数のタスクに偏っていて、他の CSU に配分されないことが考えられます。クエリまたはタスクレベルでの使用率に対するクエリは現在はサポートされていないため、当面は CSU の追加を試してみる必要があります。