Confluent Control Center

Confluent Control Center は、Apache Kafka® を管理およびモニタリングするための ウェブベースのツールです。Control Center のユーザーインターフェイスを使用することで、開発者やオペレーターは、クラスターの正常性の概要をすばやく把握したり、メッセージ、トピック、Schema Registry を調査および制御したりすることができます。また、ksqlDB クエリの開発や実行を行うこともできます。

Control Center のページ

Control Center には以下のページがあります。これらのページでは、詳細なデータを表示したり、Apache Kafka® 環境内の機能を構成したりすることができます。

Clusters overview
正常なクラスターおよび問題のあるクラスターが即座にわかる一覧を表示し、Control Center によって管理されているクラスターを検索できます。このクラスターのクリティカルメトリクスや接続されているサービスについてより詳しい情報を表示するには、クラスタータイルをクリックします。
Brokers overview
クラスター内のブローカーの重要な Kafka メトリクスを表示します。
Topics
トピックの追加と編集、トピックの生成メトリクスと消費メトリクスの表示を行います。また、メッセージの閲覧、作成、ダウンロードを実行したり、トピックの Schema Registry を管理したりすることもできます。
Connect
外部システムを Kafka に接続するためのツールキット Kafka Connect を使用してコネクターの管理、モニタリング、構成を行います。
ksqlDB
Kafka 用のストリーミング SQL エンジンである ksqlDB を利用するアプリケーションを開発します。Control Center の ksqlDB ページを使用して、SQL クエリーの実行、表示、終了を行ったり、クエリ結果からのメッセージの閲覧やダウンロードを行ったりすることができます。また、ストリームやテーブルの追加、定義、削除、およびひとつのクラスター内にある使用可能なストリームやテーブルのスキーマの表示を行うこともできます。
Consumers
選択した Kafka クラスターに関連付けられているコンシューマーグループを表示します。これには、グループあたりのコンシューマーの数、消費されているトピックの数、すべての関連トピック全体でのコンシューマーラグが含まれます。コンシューマー機能には、再設計されたストリームモニタリングページも含まれています。
Replicators
レプリケートされたトピックのモニタリングと構成を行い、送信元クラスター内にトピック構成を保持するレプリカトピックを作成します。
Cluster Settings
クラスターのプロパティおよびブローカーの構成を表示および編集します。
Alerts
Alerts を使用して、データモニタリングの間に発生する異常イベントのトリガー基準を定義し、定義したイベントが発生した場合にアラートをトリガーします。すべての Control Center クラスターを対象としてトリガーやアクションを設定し、アラート履歴を表示します。

アーキテクチャ

Control Center は、以下の部分で構成されています。

  • クライアント(プロデューサーおよびコンシューマー)のメトリックデータを収集するメトリクスインターセプター。
  • メトリックデータを移動させる Kafka。
  • ストリームメトリクスを分析するための Control Center アプリケーションサーバー。

以下に示す一般的な Kafka 環境では、Kafka を使用して、一連のプロデューサーから別々のデータセンターにある一連のコンシューマーにメッセージを転送し、Replicator を使用してクラスター間でデータをコピーします。

../_images/kafka_example.ja.png

Kafka を使用したシステムの一例

Confluent Control Center は、遅延、重複、メッセージの紛失など、データ移動時のあらゆる問題の検出に役立ちます。ストリームモニタリングでは、軽量なコードをクライアントに追加することにより、ストリーミングアプリケーション内で送受信されるすべてのメッセージをカウントできます。Kafka を使用してメトリクス情報を送信すると、ストリームモニタリングメトリクスは Control Center アプリケーションに迅速、確実に送信されます。

../_images/kafka_example_CC.ja.png

Control Center でモニタリングされている、Kafka を使用したシステムの一例

時間ウィンドウおよびメトリクス

ストリームモニタリングは、送受信される一連のメッセージを効率的に監査する目的で設計されています。これを行うために、Control Center では、一連の手法を使用してデリバリーを測定および検証します。

インターセプター は各クライアント上で生成または消費されるメッセージに関するメトリクスを収集し、分析とレポートのために Control Center に送信します。インターセプターでは、Kafka のメッセージタイムスタンプを使用してメッセージをグループ化します。具体的には、このタイムスタンプに基づいて、この 1 分間の時間ウィンドウの間のメトリクスが収集されます。この時間ウィンドウは floor(messageTimestamp / 60) * 60 などの関数を使用して計算できます。メトリクスは、プロデューサー、コンシューマーグループ、コンシューマー、トピック、パーティションの各組み合わせについて収集されます。現在、メトリクスには、プロデューサーおよびコンシューマーのメッセージ数と累積チェックサム、そしてコンシューマーからのレイテンシ情報が含まれます。

レイテンシおよびシステムクロックの意味

レイテンシは、コンシューマー上のシステムクロック時刻とメッセージ内のタイムスタンプの差異を計算して測定されます。分散環境では、クロックの同期を維持することは困難です。コンシューマー上のクロックがプロデューサー上のクロックよりも進んでいる場合、Control Center では実際の値よりも大きいレイテンシ値が表示されます。コンシューマー上のクロックがプロデューサー上のクロックよりも遅れている場合、Control Center では実際の値よりも小さいレイテンシ値(最悪の場合、マイナスの値)が表示されます。

クロックが同期されていない場合は、Confluent Control Center に想定外の結果がいくつか示されることがあります。Confluent では、NTP などのメカニズムを使用して本稼働マシン間で時刻を同期することをお勧めします。これにより、パブリックインターネット経由では 20 ミリ秒以内、同じローカルネットワーク上のサーバーでは 1 ミリ秒以内でクロックを同期できます。

ちなみに

NTP の実例: メッセージの生成から消費まで 1 秒以上かかる環境で、NTP を使用してマシン間でクロックを同期している場合、レイテンシ情報の誤差は 2% 以内です。