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

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

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

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

ストレージ使用率¶

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

You can view the current and historical storage utilization in the Performance tab in the ksqlDB Web インターフェイス. You can also query storage utilization using the Confluent Cloud Metrics API.

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

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

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

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

EXPLAIN <QUERY ID>;

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

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

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

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

Query Saturation¶

Query saturation measures the percentage of time a query-processing thread spends processing records, for example serializing/deserializing, evaluating expressions, and reading/writing state for aggregations and joins. When a query processing thread is not doing work, it's waiting for new records to process, so if a query-processing thread is almost always busy, it likely can't keep up with its source topic partitions. This metric returns the maximum value across all queries in a ksqlDB cluster. Check this metric when consumer group lag is growing.

You can inspect current and historical values of this metric in the Performance tab in the ksqlDB Web インターフェイス. You can also use the Metrics API to query the current and historical saturation.

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

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

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

最も簡単な選択肢は、より多くの CSU をクラスターにプロビジョニングすることです。各 CSU には 125 GB のストレージ容量があります。ただし、8 および 12 CSU の場合の注意点として、ksqlDB は自動的にデータのレプリカを保持するため、4 CSU を超えてストレージを拡張する場合は、12 CSU まで拡張する必要があります。

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, you can 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. So if you have a small number of tasks that store 125GB of data or more, then adding CSUs will not help because the storage from these tasks cannot be distributed across the cluster.

In the case that 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.

結局のところ、偏りの防止や使用量の削減が実現できるかどうかは、ワークロードに依存します。つまり、ここには共通した問題が存在します。* テーブルのソーストピックに 1 つのパーティションしかない場合、そのテーブルを具現化するクエリは 1 つのステートフルタスクしか実行しないということです。これを軽減するには、ソーストピックを再パーティション化し、パーティション数を増やします。* ソーストピックのいくつかのパーティションがそのデータのすべてまたはほとんどを保持している場合があります。このような場合は、パーティション化スキーマの変更を検討してください。

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

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

If the query isn't making progress, it may be bottlenecked on an external service (like Apache Kafka®), or on ksqlDB resources. If the query is bottlenecked on ksqlDB resources, you must provision another ksqlDB cluster with more CSUs.

To determine if ksqlDB is bottlenecked on limited resources, look at the query saturation metric. If this metric's value is consistently higher than 80 percent (.80), ksqlDB is likely not able to keep up with the append rate at its source topics, and you should try adding CSUs.

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