Streams for Apache Kafka Console の使用
Streams for Apache Kafka Console による Streams for Apache Kafka のデプロイメントのサポート
概要
はじめに
Red Hat ドキュメントへのフィードバック (英語のみ)
Red Hat ドキュメントに関するご意見やご感想をお寄せください。
改善を提案するには、Jira 課題を作成し、変更案についてご説明ください。ご要望に迅速に対応できるよう、できるだけ詳細にご記入ください。
前提条件
-
Red Hat カスタマーポータルのアカウントがある。このアカウントを使用すると、Red Hat Jira Software インスタンスにログインできます。
アカウントをお持ちでない場合は、アカウントを作成するように求められます。
手順
- 以下の Create issue をクリックします。
- Summary テキストボックスに、問題の簡単な説明を入力します。
Description テキストボックスに、次の情報を入力します。
- 問題が見つかったページの URL
-
問題の詳細情報
他のフィールドの情報はデフォルト値のままにすることができます。
- レポーター名を追加します。
- Create をクリックして、Jira 課題をドキュメントチームに送信します。
フィードバックをご提供いただきありがとうございました。
テクノロジープレビュー
Streams for Apache Kafka Console はテクノロジープレビューです。
テクノロジープレビュー機能は、Red Hat の実稼働環境のサービスレベルアグリーメント (SLA) ではサポートされません。また、機能的に完全ではない可能性があるため、Red Hat はテクノロジープレビュー機能を実稼働環境に実装することは推奨しません。テクノロジープレビューの機能は、最新の技術をいち早く提供して、開発段階で機能のテストやフィードバックの収集を可能にするために提供されます。サポート範囲の詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
第1章 Streams for Apache Kafka Console を使用した Kafka クラスターの管理
Streams for Apache Kafka Console は、Kafka クラスターの管理を容易にするユーザーインターフェイスを提供し、ユーザーインターフェイスから各クラスターを監視、管理、最適化するためのリアルタイムの分析情報を提供します。
第2章 Streams for Apache Kafka Console の Kafka クラスターへの接続
Streams for Apache Kafka Console を、Streams for Apache Kafka によって管理される Kafka クラスターと同じ OpenShift クラスターにデプロイします。Streams for Apache Kafka Console に付属のインストールファイルを使用します。
各 Kafka クラスターでは、クラスターのインストールに使用される Kafka
リソースの設定に以下が必要です。
- コンソールがクラスターに接続するための十分な権限。
- Prometheus が有効になっており、クラスターからメトリクスを取得できます。
-
Prometheus に適した形式でメトリクスをエクスポートするためのメトリクス設定 (
ConfigMap
経由)。
Streams for Apache Kafka Console では、KafkaUser
カスタムリソースとして設定された Kafka ユーザーが必要です。これは、コンソールが認証および認可されたユーザーとしてクラスターにアクセスするために必要です。
KafkaUser
認証および認可メカニズムを設定する場合、必ず同等の Kafka
設定と一致するようにしてください。
-
KafkaUser.spec.authentication
はKafka.spec.kafka.listeners[*].authentication
と一致します。 -
KafkaUser.spec.authorization
はKafka.spec.kafka.authorization
と一致します。
Kubernetes および Kafka クラスターからメトリクスをスクレイピングし、コンソールにメトリクスグラフを入力するには、Prometheus をインストールして設定する必要があります。
前提条件
-
インストール用に
system:admin
などのcluster-admin
ロールを持つ OpenShift ユーザーを用意する。 - OpenShift 4.12 - 4.15 クラスター。
- OpenShift クラスター上で実行されている Streams for Apache Kafka によって管理される Kafka クラスター。
- Prometheus Operator。これは、OpenShift モニタリング用にデプロイされた Operator とは別の Operator である必要があります。
-
oc
コマンドラインツールがインストールされ、OpenShift クラスターに接続するように設定されている。 コンソール内のセッション管理と認証のためのシークレットの値。
次のように OpenSSL TLS 管理ツールを使用して値を生成できます。
SESSION_SECRET=$(LC_CTYPE=C openssl rand -base64 32) echo "Generated SESSION_SECRET: $SESSION_SECRET" NEXTAUTH_SECRET=$(LC_CTYPE=C openssl rand -base64 32) echo "Generated NEXTAUTH_SECRET: $NEXTAUTH_SECRET"
使用されるオプションのコマンドラインの説明は、
openssl help
を使用してください。
コンソールをインストールするためのファイルに加えて、Streams for Apache Kafka Operator、Prometheus Operator、Prometheus インスタンス、および Kafka クラスターをインストールするための事前設定済みファイルも、Streams for Apache Kafka Console のインストールアーティファクトに含まれています。この手順では、Operator がインストールされていることを前提としています。インストールファイルを使用すると、最も簡単にコンソールをセットアップして試すことができます。ただし、Streams for Apache Kafka と Prometheus の独自のデプロイメントを使用することもできます。
手順
Streams for Apache Kafka Console インストールアーティファクトをダウンロードして展開します。
アーティファクトは、Streams for Apache Kafka ソフトウェアダウンロードページ から入手できるインストールおよびサンプルファイルに含まれています。
ファイルには、コンソール、Kafka クラスター、および Prometheus に必要なデプロイメント設定が含まれています。
この Kafka 設定の例では、コンソールが Kafka クラスターに接続するために使用するルートリスナーを作成します。コンソールと Kafka クラスターは同じ OpenShift クラスターにデプロイされるため、ルートの代わりに Kafka クラスターの内部ブートストラップアドレスを使用できます。
Prometheus インストールファイルを適用して、コンソールに必要な設定を持つ Prometheus インスタンスを作成します。
console-prometheus-server.clusterrolebinding.yaml
ファイルの${NAMESPACE}
を編集して、Prometheus インスタンスがインストールされる namespace を使用します。sed -i 's/${NAMESPACE}/'"my-project"'/g' <resource_path>/console-prometheus-server.clusterrolebinding.yaml
たとえば、この手順では、
my-project
namespace にインストールします。この設定では、Prometheus のロールとそのサービスアカウントをバインドします。次の順序でインストールファイルを適用して、Prometheus インスタンスを作成します。
# Prometheus security resources oc apply -n my-project -f <resource_path>/prometheus/console-prometheus-server.clusterrole.yaml oc apply -n my-project -f <resource_path>/prometheus/console-prometheus-server.serviceaccount.yaml oc apply -n my-project -f <resource_path>/prometheus/console-prometheus-server.clusterrolebinding.yaml # Prometheus PodMonitor and Kubernetes scrape configurations oc apply -n my-project -f <resource_path>/prometheus/kafka-resources.podmonitor.yaml oc apply -n my-project -f <resource_path>/prometheus/kubernetes-scrape-configs.secret.yaml # Prometheus instance oc apply -n my-project -f <resource_path>/prometheus/console-prometheus.prometheus.yaml
インスタンスの名前は
console-prometheus
で、コンソールに接続するためのサービスの URL はhttp://prometheus-operated.my-project.svc.cluster.local:9090
です (my-project
は namespace 名から取得されます)。注記console-prometheus
インスタンスは OpenShift クラスターの外部からアクセスする必要がないため、ルートはデプロイされません。
Kafka クラスターを作成してデプロイします。
KRaft モードで動作している Kafka クラスターでコンソールを使用している場合は、
console-kafka-metrics.configmap.yaml
ファイルでクラスターのメトリクス設定を更新します。- KRaft 関連のメトリクス設定のコメントを解除します。
- ZooKeeper 関連のメトリクスをコメントアウトします。
このファイルには、コンソールに必要なメトリクス設定が含まれています。
console-kafka-user1.kafkauser.yaml
ファイル内のKafkaUser
カスタムリソースを編集し、ACL タイプを追加して、コンソールから Kafka クラスターへの承認済みアクセスを付与します。少なくとも、Kafka ユーザーには次の ACL ルールが必要です。
-
cluster
リソースのDescribe
、DescribeConfigs
権限 -
すべての
topic
リソースに対するRead
、Describe
、DescribeConfigs
権限 すべての
group
リソースに対するRead
、Describe
権限ユーザー認証設定の例
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaUser metadata: name: console-kafka-user1 labels: strimzi.io/cluster: console-kafka spec: authentication: type: scram-sha-512 authorization: type: simple acls: - resource: type: cluster name: "" patternType: literal operations: - Describe - DescribeConfigs - resource: type: topic name: "*" patternType: literal operations: - Read - Describe - DescribeConfigs - resource: type: group name: "*" patternType: literal operations: - Read - Describe
-
console-kafka.kafka.yaml
ファイルを編集して、プレースホルダーを置き換えます。sed -i 's/type: ${LISTENER_TYPE}/type: route/g' console-kafka.kafka.yaml sed -i 's/\${CLUSTER_DOMAIN}/'"<my_router_base_domain>"'/g' console-kafka.kafka.yaml
このファイルには、Kafka クラスターを作成するための
Kafka
カスタムリソース設定が含まれています。これらのコマンドは次のことを実行します。
-
type: ${LISTENER_TYPE}
をtype: route
に置き換えます。この例ではroute
タイプを使用していますが、${LISTENER_TYPE}
をデプロイメントの有効なリスナータイプに置き換えることもできます。 -
${CLUSTER_DOMAIN}
を、ブートストラップおよび各ブローカーのサービスで使用されるルートリスナーホストを指定するために必要なベースドメインの値に置き換えます。デフォルトでは、route
リスナーのホストは OpenShift によって自動的に割り当てられます。ただし、ホストを指定して、割り当てられたルートをオーバーライドすることができます。
あるいは、サンプル設定を独自の Kafka デプロイメントにコピーする こともできます。
-
次の順序でインストールファイルを適用して、Kafka クラスターを作成します。
# Metrics configuration oc apply -n my-project -f <resource_path>/console-kafka-metrics.configmap.yaml # Create the cluster oc apply -n my-project -f <resource_path>/console-kafka.kafka.yaml # Create a user for the cluster oc apply -n my-project -f <resource_path>/console-kafka-user1.kafkauser.yaml
独自の Kafka クラスターを使用している場合は、
console-kafka.kafka.yaml
の代わりに更新されたKafka
リソース設定を適用します。インストールファイルは、Kafka クラスターと、クラスターに接続するためにコンソールで必要な Kafka ユーザーおよびメトリクス設定を作成します。コンソールから監視する Kafka クラスターごとに、Kafka ユーザーとメトリクス設定が必要です。各 Kafka ユーザーには一意の名前が必要です。
Kafka クラスターが Prometheus インスタンスとは異なる namespace にある場合は、
kafka-resources.podmonitor.yaml
ファイルを変更してnamespaceSelector
を含めます。apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: kafka-resources labels: app: console-kafka-monitor spec: namespaceSelector: matchNames: - <kafka_namespace> # ...
これにより、Prometheus が Kafka Pod を監視できるようになります。
<kafka_namespace>
は、Kafka クラスターがデプロイされている実際の namespace に置き換えます。
デプロイメントのステータスを確認します。
oc get pods -n <my_console_namespace>
出力には Operator とクラスターの準備状況が表示されます
NAME READY STATUS RESTARTS strimzi-cluster-operator 1/1 Running 0 console-kafka-kafka-0 1/1 Running 0 console-kafka-kafka-1 1/1 Running 0 console-kafka-kafka-2 1/1 Running 0 prometheus-operator-... 1/1 Running 0 prometheus-console-prometheus 1/1 Running 0
ここで、
console-kafka
はクラスターの名前です。Pod ID は作成された Pod を識別します。
デフォルトのデプロイメントでは、3 つの Pod をインストールします。
READY は、ready/expected 状態のレプリカ数を表示します。STATUS が Running と表示されれば、デプロイメントは成功です。
Streams for Apache Kafka Console をインストールします。
コンソールインスタンスがインストールされる namespace を使用するように
console-server.clusterrolebinding.yaml
ファイルを編集します。sed -i 's/${NAMESPACE}/'"my-project"'/g' /<resource_path>console-server.clusterrolebinding.yaml
設定により、コンソールのロールとそのサービスアカウントがバインドされます。
次の順序でインストールファイルを適用して、コンソールユーザーインターフェイスをインストールし、インターフェイスにルートします。
# Console security resources oc apply -n my-project -f <resource_path>/console-server.clusterrole.yaml oc apply -n my-project -f <resource_path>/console-server.serviceaccount.yaml oc apply -n my-project -f <resource_path>/console-server.clusterrolebinding.yaml # Console user interface service oc apply -n my-project -f <resource_path>/console-ui.service.yaml # Console route oc apply -n my-project -f <resource_path>/console-ui.route.yaml
インストールにより、コンソールユーザーインターフェイスを実行するために必要なロール、ロールバインディング、サービスアカウント、サービス、およびルートが作成されます。
コンソール内でのセッション管理と認証のための 2 つのシークレット値 (前提条件で説明) を含む
console-ui-secrets
というSecret
を作成します。oc create secret generic console-ui-secrets -n my-project \ --from-literal=SESSION_SECRET="<session_secret_value>" \ --from-literal=NEXTAUTH_SECRET="<next_secret_value>"
コンソールがデプロイされると、シークレットは環境変数としてマウントされます。
コンソールユーザーインターフェイス用に作成されたルートのホスト名を取得します。
oc get route console-ui-route -n my-project -o jsonpath='{.spec.host}'
コンソールユーザーインターフェイスにアクセスするには、ホスト名が必要です。
console.deployment.yaml
ファイルを編集してプレースホルダーを置き換えます。sed -i 's/${CONSOLE_HOSTNAME}/'"<route_hostname>"'/g' console.deployment.yaml sed -i 's/${NAMESPACE}/'"my-project"'/g' console.deployment.yaml
これらのコマンドは次のことを実行します。
-
https://${CONSOLE_HOSTNAME}
を、コンソールユーザーインターフェイスにアクセスするために使用されるルートであるhttps://<route_hostname>
に置き換えます。 -
コンソールが使用する Prometheus インスタンスの URL である
http://prometheus-operated.${NAMESPACE}.svc.cluster.local:9090
内の${NAMESPACE}
をmy-project
namespace に置き換えます。
独自の Kafka クラスターを使用している場合は、正しいクラスター名が使用され、他の環境変数が 正しい値で設定されている ことを確認してください。これらの値により、コンソールはクラスターに接続してメトリクスを取得できるようになります。
-
コンソールをインストールします。
oc apply -n my-project -f <resource_path>/console.deployment.yaml
出力はコンソールの準備状況を示します
NAME READY STATUS RESTARTS strimzi-cluster-operator 1/1 Running 0 console-kafka-kafka-0 1/1 Running 0 console-kafka-kafka-0 1/1 Running 0 console-kafka-kafka-0 1/1 Running 0 prometheus-operator-... 1/1 Running 0 prometheus-console-prometheus 1/1 Running 0 console-... 2/2 Running 0
独自の Kafka クラスターにサンプル設定を追加する
Kafka クラスターがすでにインストールされている場合は、必要な設定で Kafka
リソースを更新できます。クラスター設定ファイルを適用するときは、Streams for Apache Kafka Console インストールファイルに付属する Kafka
リソースではなく、更新した Kafka
リソースを使用します。
Kafka
リソースには次の設定が必要です。
-
コンソール接続用にクラスターを公開する
route
リスナー - クラスター上のメトリクスを取得するために Prometheus メトリクスが有効になっています。メタデータ管理に ZooKeeper を使用している場合は、ZooKeeper に同じ設定を追加します。
-
クラスター名がコンソールデプロイメントファイル (
console- kafka
) で使用されているクラスター名と一致しない場合は、console-kafka-user1.kafkauser.yaml
などの Kafka クラスターの名前を参照するデプロイメントファイルを更新します。
Prometheus メトリクス設定は、コンソールに必要なメトリクス設定を提供する ConfigMap
を参照する必要があります。メトリクス設定は、console-cluster-metrics.configmap.yaml
リソース設定ファイルで提供されます。
コンソール接続用の Kafka クラスター設定の例
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: console-kafka namespace: my-project spec: entityOperator: topicOperator: {} userOperator: {} kafka: authorization: type: simple config: allow.everyone.if.no.acl.found: 'true' default.replication.factor: 3 inter.broker.protocol.version: '3.6' min.insync.replicas: 2 offsets.topic.replication.factor: 3 transaction.state.log.min.isr: 2 transaction.state.log.replication.factor: 3 listeners: 1 - name: route1 port: 9094 tls: true type: route authentication: type: scram-sha-512 replicas: 3 storage: type: jbod volumes: - id: 0 type: persistent-claim size: 10Gi deleteClaim: false metricsConfig: 2 type: jmxPrometheusExporter valueFrom: configMapKeyRef: name: console-cluster-metrics key: kafka-metrics-config.yml version: 3.6.0 zookeeper: replicas: 3 storage: deleteClaim: false size: 10Gi type: persistent-claim metricsConfig: 3 type: jmxPrometheusExporter valueFrom: configMapKeyRef: name: console-cluster-metrics key: zookeeper-metrics-config.yml
コンソールのデプロイメント環境変数を確認する
独自の Kafka クラスターを使用している場合は、コンソールのデプロイメント設定に必要な環境変数が含まれていることを確認してください。
次の接頭辞は環境変数値のスコープを決定します。
-
KAFKA
は、すべての Kafka クラスターの設定を表します。 -
CONSOLE_KAFKA_<UNIQUE_NAME_ID_FOR_CLUSTER>
は、特定のクラスターごとの設定を表します。
コンソールデプロイメント設定の例
apiVersion: apps/v1 kind: Deployment metadata: name: console spec: replicas: 1 # ... template: metadata: labels: app: console spec: # ... containers: - name: console-api # ... env: - name: KAFKA_SECURITY_PROTOCOL 1 value: SASL_SSL - name: KAFKA_SASL_MECHANISM 2 value: SCRAM-SHA-512 - name: CONSOLE_KAFKA_CLUSTER1 3 value: my-project/console-kafka - name: CONSOLE_KAFKA_CLUSTER1_BOOTSTRAP_SERVERS 4 value: console-kafka-route1-bootstrap-my-project.router.com:443 - name: CONSOLE_KAFKA_CLUSTER1_SASL_JAAS_CONFIG 5 valueFrom: secretKeyRef: name: console-kafka-user1 key: sasl.jaas.config - name: console-ui # ... env: - name: NEXTAUTH_SECRET 6 valueFrom: secretKeyRef: name: console-ui-secrets key: NEXTAUTH_SECRET - name: SESSION_SECRET 7 valueFrom: secretKeyRef: name: console-ui-secrets key: SESSION_SECRET - name: NEXTAUTH_URL 8 value: 'https://console-ui-route-my-project.router.com' - name: BACKEND_URL 9 value: 'http://127.0.0.1:8080' - name: CONSOLE_METRICS_PROMETHEUS_URL 10 value: 'http://prometheus-operated.my-project.svc.cluster.local:9090'
- 1
- Kafka ブローカーとの通信に使用されるセキュリティープロトコル。
- 2
- Kafka ブローカーへのコンソール (クライアント) 認証用の SASL メカニズム。
- 3
Kafka
リソース設定でクラスターに指定された namespace および名前と一致するようにする必要があります。- 4
- Kafka クラスターのすべてのブローカーを検出し、接続するブートストラップブローカーアドレスのホストとポートのペア。この例では、ルートリスナーアドレスが使用されています。リスナーは
Kafka
リソースで設定されました。 - 5
Secret
としてマウントされたコンソールを表す Kafka ユーザーの認証情報。対応するユーザーが作成されると、console-kafka-user1
シークレットが自動的に作成されます。シークレット内のsasl.jaas.config
プロパティーには、SASL 認証用の JAAS 設定が含まれています。- 6
- コンソール内での認証用のシークレット。
- 7
- コンソール内のセッション管理のシークレット
- 8
- Streams for Apache Kafka ユーザーインターフェイスに接続し、ユーザーがコンソールにアクセスするための URL。
- 9
- コンソールユーザーインターフェイスがデータ取得のために通信するバックエンドサーバー。
- 10
Kafka
リソースの namespace (my-project
) を含む Prometheus インスタンスに接続するための URL。
第4章 HOME: 接続されているクラスターの確認
ホームページでは、接続された Kafka クラスターのスナップショットが提供され、ブローカーのステータスおよび関連するコンシューマーグループの数が表示されます。トピックを探索すると、ホームページに最近のトピック表示に関する詳細が表示されるので便利です。
詳細情報を見つける方法は以下のとおりです。
- クラスター名をクリックすると、Cluster overview ページでクラスターメトリクスが表示されます。
- 最近表示したトピックをクリックすると、その特定のトピックに関する詳細が表示されます。
第5章 Cluster overview ページ
Cluster overview ページには、Kafka クラスターのステータスが表示されます。ここでは、Kafka ブローカーの準備状況の評価や、クラスターエラーや警告の特定、クラスターの健全性に関する重要な洞察の取得が可能です。このページでは、クラスター内のトピックおよびパーティションの数と、それらのレプリケーションステータスに関する情報を一目で確認できます。使用済みディスク容量、CPU 使用率、メモリー使用量を表示するグラフで、クラスターメトリクスを確認してください。さらに、トピックメトリクスは、Kafka クラスターの全トピックの受信および送信バイトレートの合計に関する包括的なビューを提供します。
5.1. クライアントアクセスのためのクラスター接続に関する詳細へのアクセス
クライアントを Kafka クラスターに接続するときは、次の手順に従って、Cluster overview ページから接続に関する必要な詳細情報を取得します。
手順
- Streams for Apache Kafka Console から、接続する Kafka クラスターの名前をクリックし、Cluster overview と Cluster connection details をクリックします。
- ブートストラップアドレスと接続プロパティーをコピーして Kafka クライアント設定に追加し、Kafka クラスターとの接続を確立します。
クライアントが使用する認証タイプが、Kafka クラスターに設定された認証タイプと一致することを確認してください。
第6章 Topics ページ
Topics ページには、Kafka クラスター用に作成したすべてのトピックが表示されます。トピックスに関する情報を確認するにはこのページを使用してください。
Topics ページには、トピックのパーティションの全体的なレプリケーションステータスや、トピックのパーティション数および関連するコンシューマーグループの数が表示されます。トピックが使用する全体的なストレージも表示されます。
内部トピックは変更しないでください。Topics ページで返されるトピックのリストで内部トピックを非表示にすることもできます。
トピック名をクリックすると、追加のトピック情報が一連のタブに表示されます。
- Messages
- Messages にはトピックのメッセージログが表示されます。
- Partitions
- Partitions には、トピック内の各パーティションのレプリケーションステータスが表示されます。
- Consumer groups
- Consumer groups には、トピックに接続されているコンシューマーグループとグループメンバーの名前とステータスがリスト表示されます。
- Configuration
- Configuration にはトピックの設定が表示されます。
トピックが Managed として表示されている場合、そのトピックは Streams for Apache Kafka Topic Operator を使用して管理されており、Kafka クラスターで直接作成されていません。
タブに表示される情報を使用して、トピックの設定を確認および変更します。
6.1. トピックメッセージの確認
Messages タブから特定のトピックのメッセージフローを追跡します。Messages タブには、トピックのメッセージの時系列リストが表示されます。
手順
- Streams for Apache Kafka Console から、Kafka クラスターの名前をクリックし、Topics をクリックします。
- 確認したいトピックの名前をクリックします。
Messages タブの情報を確認してください。
各メッセージについて、タイムスタンプ (UTC 内)、オフセット、キー、値を確認できます。
メッセージをクリックすると、メッセージの詳細全体が表示されます。
表示する情報を選択するには、Manage columns アイコン (2 つの列として表示されます) をクリックします。
検索ドロップダウンをクリックし、詳細検索オプションを選択して検索を絞り込みます。
最新のメッセージを表示するか、指定した時間またはオフセットからのメッセージを表示するかを選択します。すべてのパーティションまたは指定したパーティションのメッセージを表示できます。
完了したら、CSV アイコン (CSV ファイルとして表されます) をクリックして、返されたメッセージの情報をダウンロードできます。
検索を絞り込む
この例では、検索用語とメッセージ、取得、パーティションのオプションが組み合わされています。
-
messages=timestamp:2024-03-01T00:00:00Z retrieve=50 partition=1 Error on page load where=value
このフィルターは、2024 年 3 月 1 日以降のパーティション 1 内のテキスト "Error on page load" をメッセージ値として検索し、最大 50 件のメッセージを取得します。
- 検索用語
特定の一致を検索するには、検索用語をテキスト (単語を含む) として入力し、メッセージ内の where で検索する用語を定義します。メッセージ内の任意の場所を検索したり、キー、ヘッダー、または値に検索範囲を絞り込むことができます。
以下に例を示します。
-
messages=latest retrieve=100 642-26-1594 where=key
この例では、メッセージキー
642-26-1594
の最新の 100 件のメッセージを検索します。-
- メッセージオプション
メッセージを返す開始点を設定します。
最新のメッセージから開始するには、Latest を選択します。
-
messages=latest
-
ISO 8601 形式の正確な日時から開始する タイムスタンプ。
-
messages=timestamp:2024-03-14T00:00:00Z
-
パーティション内のオフセットから開始する オフセット。場合によっては、パーティションなしでオフセットを指定する必要があることがあります。ただし、最も一般的なシナリオは、特定のパーティション内のオフセットで検索することです。
-
messages=offset:5600253 partition=0
-
Unix 形式の時刻と日付から開始する Unix タイムスタンプ。
-
messages=epoch:1
-
- 検索オプション
取得オプションを設定します。
指定した数のメッセージを返す メッセージ数。
-
messages=latest retrieve=50
-
最新のメッセージをリアルタイムで 継続的 に返します。更新を一時停止するには、一時停止ボタン (2 本の縦線で表されます) をクリックします。更新を続行するには一時停止を解除してください。
-
retrieve=continuously
-
- Partition オプション
- すべてのパーティションに対して検索を実行するか、特定のパーティションに対して検索を実行するかを選択します。
6.2. トピックパーティションの確認
Partitions タブから特定のトピックのパーティションを確認します。Partitions タブには、トピックに属するパーティションのリストが表示されます。
手順
- Streams for Apache Kafka Console から、Kafka クラスターの名前をクリックし、Topics をクリックします。
- Topics ページで、確認したいトピックの名前をクリックします。
- Partitions タブの情報を確認します。
パーティションごとに、そのレプリケーションステータスのほか、指定されたパーティションリーダー、レプリカブローカー、およびパーティションに保存されているデータ量に関する情報を確認できます。
レプリケーションステータスごとにパーティションを表示できます。
- In-sync
-
トピック内のすべてのパーティションが完全にレプリケートされます。パーティションは、そのレプリカ (フォロワー) が指定されたパーティションリーダーと 'in-sync' の場合、完全にレプリケートされます。レプリカは、許容ラグタイム内でリーダーパーティションのログ末尾のオフセットまでレコードを取得している場合に、'in-sync' となります。許容ラグタイムは、
replica.lag.time.max.ms
で決定されます。 - Under-replicated
- 一部のレプリカ (フォロワー) が同期していない場合、パーティションはレプリケーションが不十分です。under-replicated ステータスは、データレプリケーションでの潜在的な問題を示します。
- オフライン
- トピックの一部またはすべてのパーティションが現在使用できません。これはブローカーの障害やネットワークの問題などが原因である可能性があり、調査と対処が必要です。
パーティションリーダーとして指定されたブローカー、およびレプリカを含むブローカーに関する情報を確認することもできます。
- Leader
- リーダーはすべてのプロデュースリクエストを処理します。他のブローカーのフォロワーは、リーダーのデータをレプリケートします。フォロワーは、リーダーの最新のコミットメッセージに追いついた場合、同期しているとみなされます。
- Preferred leader
- 新しいトピックを作成するとき、Kafka のリーダー選択アルゴリズムは、各パーティションのレプリカのリストからリーダーを割り当てます。このアルゴリズムは、リーダーシップの割り当てをバランスよく分散することを目的としています。値が "Yes" の場合、現在のリーダーが優先リーダーであることを示し、リーダーシップがバランスよく分散していることを示します。値が "No" の場合は、リーダーシップの割り当ての不均衡を示唆している可能性があり、さらなる調査が必要です。パーティションのリーダーシップ割り当てのバランスが取れていない場合、サイズの不一致が生じる可能性があります。バランスのとれた Kafka クラスターでは、リーダーの役割がブローカー間で均等に分散します。
- Replicas
- リーダーのデータをレプリケートするフォロワーです。レプリカは、フォールトトレランスとデータの可用性を提供します。
ブローカー間のデータ分散に不一致がある場合、Kafka クラスターでバランスの問題が生じている可能性があります。特定のブローカーが一貫して大量のデータを処理している場合は、パーティションがブローカー間で均等に分散されていない可能性があります。これにより、リソースの使用率が不均一になり、ブローカーのパフォーマンスに影響を与えるおそれがあります。
6.3. トピックのコンシューマーグループの確認
Consumer groups タブから特定のトピックのコンシューマーグループを確認します。Consumer groups タブには、トピックに関連付けられたコンシューマーグループのリストが表示されます。
手順
- Streams for Apache Kafka Console から、Kafka クラスターの名前をクリックし、Topics をクリックします。
- Topics ページで、確認したいトピックの名前をクリックします。
- Consumer groups タブの情報を確認します。
- コンシューマーグループのメンバーを確認するには、コンシューマーグループ名をクリックします。
コンシューマーグループごとに、そのステータス、全パーティションにわたる全体的なコンシューマーラグ、およびメンバーの数を確認できます。コンシューマーグループの確認に関する詳細は、8章Consumer groups ページ を参照してください。
グループメンバーごとに、コンシューマーグループ内のコンシューマーに割り当てられた一意の (コンシューマー) クライアント ID、全体的なコンシューマーラグ、および割り当てられたパーティションの数が表示されます。コンシューマーグループメンバーの確認に関する詳細は、「コンシューマーグループのメンバーの確認」 を参照してください。
コンシューマーグループの動作を監視することは、コンシューマー間のメッセージ分散を最適化するために不可欠です。
6.4. トピック設定の確認
Configuration タブから特定のトピックの設定を確認します。Configuration タブには、トピックの設定値のリストが表示されます。
手順
- Streams for Apache Kafka Console から、Kafka クラスターの名前をクリックし、Topics をクリックします。
- Topics ページで、確認したいトピックの名前をクリックします。
- Configuration タブの情報を確認します。
データソース別に選択するなど、確認するプロパティーをフィルタリングできます。
- DEFAULT_CONFIG プロパティーには、事前定義されたデフォルト値があります。この値は、このプロパティーにユーザー定義の値がない場合に使用されます。
- STATIC_BROKER_CONFIG プロパティーには、ブローカー全体、さらにはそのブローカーが管理するすべてのトピックに適用される事前定義された値があります。この値は、このプロパティーにユーザー定義の値がない場合に使用されます。
- DYNAMIC_TOPIC_CONFIG プロパティーの値は特定のトピックに対して設定されており、デフォルトの設定値をオーバーライドします。
Streams for Apache Kafka Topic Operator は、KafkaTopic
リソースを使用して Kafka トピックを作成および管理するプロセスを簡素化します。
第7章 Brokers ページ
Brokers ページには、Kafka クラスター用に作成したすべてのブローカーが表示されます。ブローカーごとに、そのステータスのほか、パーティションリーダーとレプリカの数を含む、ブローカー全体のパーティションの分散を確認できます。
ブローカーのステータスは次のいずれかとして表示されます。
- Stable
- 安定したブローカーは、重大な問題なく正常に動作しています。
- Unstable
- 不安定なブローカーでは、高いリソース使用率やネットワークの問題などが発生している可能性があります。
ブローカーにラック ID がある場合、これはブローカーが存在するラックまたはデータセンターの ID です。
ブローカー名の横にある右矢印 (>) をクリックすると、ホスト名やディスク使用状況など、ブローカーに関する詳細情報が表示されます。
リソースを効率的に利用するために、分散が不均一な場合はリバランスを検討してください。
第8章 Consumer groups ページ
Consumer Groups ページには、Kafka クラスターに関連付けられたすべてのコンシューマーグループが表示されます。コンシューマーグループごとに、そのステータス、全パーティションにわたる全体的なコンシューマーラグ、およびメンバーの数を確認できます。関連するトピックをクリックすると、Topics ページのタブ から入手できるトピック情報が表示されます。
コンシューマーグループのステータスは次のいずれかになります。
- Stable は、正常に機能していることを示します。
- Rebalancing は、コンシューマーグループのメンバーに対する調整が進行中であることを示します。
- Empty は、アクティブなメンバーが存在しないことを示します。Empty 状態の場合は、グループにメンバーを追加することを検討してください。
コンシューマーグループ名をクリックしてグループメンバーを確認します。コンシューマーグループメンバーの確認に関する詳細は、「コンシューマーグループのメンバーの確認」 を参照してください。
8.1. コンシューマーグループのメンバーの確認
Consumer groups ページから、特定のコンシューマーグループのメンバーを確認します。
手順
- Streams for Apache Kafka Console から、Kafka クラスターの名前をクリックし、Consumer groups をクリックします。
- Consumer groups ページから、確認するコンシューマーグループの名前をクリックします。
- メンバー ID の横にある右矢印 (>) をクリックして、メンバーが関連付けられているトピックパーティション、および想定されるコンシューマーラグを表示します。
グループメンバーごとに、コンシューマーグループ内のコンシューマーに割り当てられた一意の (コンシューマー) クライアント ID、全体的なコンシューマーラグ、および割り当てられたパーティションの数が表示されます。
特定のトピックパーティションのコンシューマーラグは、コンシューマーが取得した最後のメッセージ (コミットされたオフセット位置) と、プロデューサーが書き込んだ最新のメッセージ (末尾のオフセット位置) との間のギャップを反映します。
付録A サブスクリプションの使用
Streams for Apache Kafka は、ソフトウェアサブスクリプションを通じて提供されます。サブスクリプションを管理するには、Red Hat カスタマーポータルでアカウントにアクセスします。
アカウントへのアクセス
- access.redhat.com に移動します。
- アカウントがない場合は作成します。
- アカウントにログインします。
サブスクリプションのアクティベート
- access.redhat.com に移動します。
- My Subscriptions に移動します。
- Activate a subscription に移動し、16 桁のアクティベーション番号を入力します。
Zip および Tar ファイルのダウンロード
zip または tar ファイルにアクセスするには、カスタマーポータルを使用して、ダウンロードする関連ファイルを検索します。RPM パッケージを使用している場合、この手順は必要ありません。
- ブラウザーを開き、access.redhat.com/downloads で Red Hat カスタマーポータルの Product Downloads ページにログインします。
- INTEGRATION AND AUTOMATION カテゴリーで、Streams for Apache Kafka エントリーを見つけます。
- 必要な Streams for Apache Kafka 製品を選択します。Software Downloads ページが開きます。
- コンポーネントの Download リンクをクリックします。
DNF を使用したパッケージのインストール
パッケージとすべてのパッケージ依存関係をインストールするには、以下を使用します。
dnf install <package_name>
ローカルディレクトリーからダウンロード済みのパッケージをインストールするには、以下を使用します。
dnf install <path_to_download_package>
改訂日時: 2024-07-19