Control Center のトラブルシューティング¶
共通の問題¶
インストールとセットアップ¶
インストールとセットアップの際に問題が発生した場合は、以下の解決策をお試しください。
不適切なセキュリティ構成¶
すべてのブローカー、Metrics Reporter、クライアントインターセプター、Control Center のセキュリティ構成をチェックします(「構成チェックのデバッグ」を参照)。たとえば、構成は SASL_SSL、SASL_PLAINTEXT、SSL になっていますか。
以下のようなエラーが考えられます。
ERROR SASL authentication failed using login context 'Client'. (org.apache.zookeeper.client.ZooKeeperSaslClient)
Caused by: org.apache.kafka.common.KafkaException: java.lang.IllegalArgumentException: No serviceName defined in either JAAS or Kafka configuration
org.apache.kafka.common.errors.IllegalSaslStateException: Unexpected handshake request with client mechanism GSSAPI, enabled mechanisms are [GSSAPI]
正しい Java Authentication and Authorization Service(JAAS)構成が検出されたことを確認します。
ACL が有効な場合は、ACL をチェックします。
クラスターと通信できることを検証するには、同じセキュリティ設定により、
console-*
を使用して生成および消費してみます。
InvalidStateStoreException¶
- このエラーは、一般に、構成されている
confluent.controlcenter.data.dir
内のデータが破損していることを示します。たとえば、正常にシャットダウンされなかった結果として発生します。修正するには、confluent.controlcenter.id
を変更することにより Control Center に新しい ID を付与して再起動します。 - 構成されている
confluent.controlcenter.data.dir
に対するアクセス許可を付与します。
ブローカーが不足¶
ログを調べて関連エラー not enough brokers
をチェックします。トピックのレプリケーション係数 が正しく設定されていることおよび使用可能なブローカーが十分に存在することを確認します。
ローカル保管のアクセス許可¶
Control Center ステートディレクトリのローカルアクセス許可をチェックします。これらの設定は、control-center.properties
内の構成 confluent.controlcenter.data.dir
で定義されているとおりです。このディレクトリには、Control Center の起動に使用されたユーザー ID でアクセスできます。
Control Center の複数インスタンスの ID が同一¶
Docker 内のインスタンスを含め、各 Control Center インスタンスの ID は一意である必要があります。ID の重複はサポートされておらず、問題が発生します。
ライセンスの期限切れ¶
次のようなメッセージが表示される場合、
[2017-08-21 14:12:33,812] WARN checking license failure. please contact `support@confluent.io <mailto:support@confluent.io>`_ for a license key: Unable to process JOSE object (cause: org.jose4j.lang.JoseException: Invalid JOSE….
confluent.license=<your key>
に指定されているユーザーのライセンスが有効であることを確認する必要があります。キーまたはライセンスファイルのパスのいずれかです。詳細については、 Control Center の構成のドキュメント を参照してください。Control Center ウェブインターフェイスでのライセンスの管理については、「Confluent Platform ライセンスの管理」を参照してください。
メッセージ値用のスキーマの 1 つがこのトピック用に設定されていない¶
このエラーメッセージが表示された場合は、Schema Registry listeners=http://0.0.0.0:8081
構成が Control Center の confluent.controlcenter.schema.registry.url=http://localhost:8081
構成と一致していることを確認する必要があります。詳細については、「ログ記録」を参照してください。
Control Center が Confluent Cloud に接続できない¶
「Control Center の Confluent Cloud への接続」の手順に従って Confluent Cloud クラスターを Control Center に接続しようとすると、以下のようなメッセージが表示されます。
[2019-07-31 20:40:28,023] ERROR [main] attempt=failed to create topic=TopicInfo{name=_confluent-metrics, partitions=12, replication=3} (io.confluent.controlcenter.KafkaHelper)
org.apache.kafka.common.errors.PolicyViolationException: Config property 'max.message.bytes' with value '10485760' exceeded max limit of 8388608.
エラーメッセージ max.message.bytes
は Confluent Cloud のいくつかのデフォルト設定が適用されているために表示されます。
このエラーを解決するには、Control Center プロパティファイルに以下の構成を追加し、Control Center を再起動します。
...
confluent.metrics.topic.max.message.bytes=8388608
...
Control Center と Confluent Cloud のデフォルト値が一致していないこの件は既知の問題であり、MMA-3564 で追跡されています。
Safari および認証を使用してトピックメッセージをブラウズできない¶
Safari での WebKit のバグ が原因で、認証を使用して トピックメッセージをブラウズ しようとしているときに、以下の不明なエラーが表示されます。
Safari ブラウザーでは、認証されたリクエストを WebSocket プロトコル経由で送信できません。
暫定的な回避策として、Safari ではなく Chrome または Firefox ブラウザーを使用することをお勧めします。
システム正常性¶
ウェブインターフェイスが空白または読み込み中に停止¶
ウェブインターフェイスが空白または読み込み中に停止する場合は、ドロップダウンからクラスターを選択し、以下の情報を参照してトラブルシューティングを行うことができます。
ログにエラーまたは警告 が出力されていますか。ログを見つける方法の詳細については、この ドキュメント を参照してください。
モニタリング対象は何ですか 。プロビジョニング不足 ですか。
Control Center にラグ はありますか。特に
MetricsAggregateStore
パーティションにラグがありますか。ブラウザーデバッグツールを使用して REST 呼び出しをチェックし、リクエストが正常に行われ、有効な応答があることを、特に以下のリクエストについて確認します。
ちなみに
一般的なウェブブラウザーツール( Chrome デベロッパーツール など)を使用してこれらの呼び出しを表示できます。
/2.0/metrics/<cluster-id>/maxtime
エンドポイントは Control Center がメトリクスデータに対して保持している最新のタイムスタンプを返すはずです。バックエンドからデータが返されない場合は、入力トピック上のデータを取得していることを確認し、ログを調べて問題を確認します。
Control Center が起動準備中¶
Control Center の起動または再起動後にこのメッセージがウェブインターフェイスに表示される場合は、Try again をクリックします。
Control Center が起動しない場合は、以下の推奨事項を試してトラブルシューティングを行います。
- 通常、このメッセージは、Apache Kafka® にメトリクスデータがないことを意味しますが、500 Internal Server Error の発生を示すこともあります。500 エラーが発生した場合は、Control Center のログでエラーを確認します。
- ブラウザーデバッグツールを使用して応答をチェックします。
/2.0/metrics/<cluster-id>/maxtime
エンドポイントからの応答が空({ }
)の場合は、Kafka がメトリクスデータを受信していないことを意味します。 - Control Center ログの出力を調べて WARN メッセージ
broker=<x> is not instrumented with ConfluentMetricsReporter
をチェックします。この警告がある場合は、metric.reporters=io.confluent.metrics.reporter.ConfluentMetricsReporter
を使って Kafka サーバーを構成する 手順 を確実に実装してください。Kafka ブローカーを再起動して、この構成変更を適用します。 - Metrics Reporter が適切にセットアップされていることを確認します。
_confluent-metrics
入力トピックをダンプして、生成されたメッセージがあるかどうかを確認します。
クラスターが見つからない¶
Control Center の起動後にウェブインターフェイスにこのメッセージが表示される場合は、適切な control.center.properties
ファイルにあるご使用の 構成 をチェックします。
一時的なディレクトリアクセス許可が原因で Control Center を起動できない¶
問題 : noexec
を使用してマウントされた /tmp
に関するエラーが発生:
java.lang.UnsatisfiedLinkError: /tmp/librocksdbjni3375578050467151433.so:
/tmp/librocksdbjni3375578050467151433.so: failed to map segment from shared object:
Operation not permitted when /tmp is mounted with noexec
解決策: /tmp
ディレクトリが noexec
に設定されていて書き込みアクセス権限がない場合は、書き込みアクセス権限がある rocksdbtmp
のディレクトリパスを渡して Control Center を起動します。
CONTROL_CENTER_OPTS="-Djava.io.tmpdir=/my/dir/for/rocksdbtmp" control-center-start /path/to/control-center.properties
メトリクス(_confluent-metrics
)トピックで何も生成されない¶
- セキュリティを構成した Metrics Reporter が適切にセットアップされている ことを確認します。
- Kafka ブローカーの複数のログを調べて、タイムアウトまたはその他のエラー( RecordTooLargeException など)を探します。
Control Center が Kafka から遅れている¶
Control Center で最新データがレポートされておらず、チャートが遅れている場合は、以下の情報を参照してトラブルシューティングを行うことができます。
- この現象は、Control Center がパワー不足であるか、未処理データの負荷を処理している場合に発生します。
- オフセットラグ をチェックします。ラグが大きく、時間の経過に従って拡大している場合は、Control Center でモニタリングの負荷を処理できない可能性があります。クラスター および システム に対する以下の追加のチェックを試してください。
- Confluent Platform 3.3.x 以降では、未処理データモニタリングのスキップ設定の
confluent.monitoring.interceptor.topic.skip.backlog.minutes
およびconfluent.metrics.topic.skip.backlog.minutes
に短い時間を設定できます。たとえば、最新オフセットから処理する場合は、0
に設定できます。Control Center では、入力トピックに関して、指定された時間よりも古いすべてのデータを無視することになります。この機能は、Control Center が迅速に追いつく必要のある場合に有用です。詳細については、 Control Center の構成のドキュメント を参照してください。
RecordTooLargeException¶
ブローカーログにこのエラーが出力される場合は、以下の情報を使用してトラブルシューティングを行うことができます。
ブローカーの
server.properties
ファイルでconfluent.metrics.reporter.max.request.size=10485760
を設定します。これが 3.3.x 以降のデフォルトです。大きいメッセージを受け入れるように
_confluent-metrics
のトピック構成を変更します。これが 3.3.x 以降のデフォルトです。詳細については、 Metrics Reporter のメッセージサイズのドキュメント を参照してください。bin/kafka-configs --bootstrap-server <host:port> --alter --add-config max.message.bytes=10485760 --entity-type topics --entity-name _confluent-metrics
ブローカーまたはトピックテーブルの一部の値が空白¶
これは、Control Center の遅れが取り戻されるまでの一過性の状態と思われる既知の問題です。以下の原因により発生します。
- リストア時に異なるストリームトポロジーが異なるレートで処理しています。
- Control Center が、リソース不足によって遅れているか追いつけない状態になっています。
ストリームモニタリング¶
チャートが空白¶
空白のチャートが表示される場合は、以下の情報を使用してトラブルシューティングを行うことができます。
- Confluent Monitoring Interceptor が、必要なすべてのセキュリティ構成設定を含め、クライアント上で適切に構成されていることを確認します。
- 選択した時間範囲について、_confluent-monitoring トピック に到着している新しいデータがあるかどうかをチェックします。
- Confluent では想定される消費量を認識していないため、消費されていないメッセージが Control Center で表示されないことは正常です。したがって、このトピックから読み取っているコンシューマーがあるかどうかを確認してください。
想定されないヘリンボーンパターン¶
想定されないヘリンボーンパターンが表示される場合は、以下の情報を使用してトラブルシューティングを行うことができます。
- クライアントが適切にシャットダウンされていることを確認します。
- 以下のエラーをクライアントのログで探します。
Failed to shutdown metrics reporting thread...
Failed to publish all cached metrics on termination for...
ERROR Terminating publishing and collecting monitoring metrics for
Failed to close monitoring interceptor for…
コンシューマーまたはコンシューマーグループが欠落¶
コンシューマーまたはコンシューマーグループが欠落している場合は、以下の情報を使用してトラブルシューティングを行うことができます。
- 欠落しているクライアントのログでエラーまたは警告を探します。
- 入力トピックが、欠落しているクライアントのインターセプターデータを受信しているかどうかを確認します。
デバッグ¶
ログのチェック¶
次の Control Center ログタイプがあります。
c3.log
- Control Center、HTTP アクティビティ、ストリームに関連しないあらゆるもの、REST API 呼び出しc3-streams.log
- Streamsc3-kafka.log
- クライアント、ZooKeeper、および Kafka
ログ内で探す必要のある内容を次に示します。
ERROR
shutdown
Exceptions
- ブローカーに接続できることを確認WARN
Healthcheck
エラーおよび警告
何もはっきりしない場合は、 DEBUG ログをオン にして、Control Center を再起動します。
デバッグおよびトレースログ記録の有効化¶
<path-to-confluent>/etc/confluent-control-center/log4j.properties
ファイルを開きます。このファイルはCONTROL_CENTER_LOG4J_OPTS
環境変数によって参照されます。次の例のような内容を
CONTROL_CENTER_LOG4J_OPTS
環境変数に設定してエクスポートします。export CONTROL_CENTER_LOG4J_OPTS='-Dlog4j.configuration=file:/apps/kafka/config/confluent-control-center/log4j.properties'
デバッグオプションを設定します。
デバッグログ記録を有効にするには、ルートレベルでログレベルを
DEBUG
に変更します。log4j.rootLogger=DEBUG, stdout
トレースログ記録を有効にするには、ルートレベルでルートロガーを
TRACE
に変更します。log4j.rootLogger=TRACE, stdout
特に Confluent サポートのリクエストによって追加のストリームログ記録を有効にするには、以下の例に従います。
log4j.rootLogger=DEBUG, stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.EnhancedPatternLayout log4j.appender.stdout.layout.ConversionPattern=[%d] %p [%t] %m (%c)%n log4j.appender.streams=org.apache.log4j.ConsoleAppender log4j.appender.streams.layout=org.apache.log4j.EnhancedPatternLayout log4j.appender.streams.layout.ConversionPattern=[%d] %p [%t] %m (%c)%n log4j.appender.streams.filter.1=io.confluent.Log4jRateFilter # Allows everything that is greater than or equal to specified level log4j.appender.streams.filter.1.level=TRACE # Allows rate/second logs at less than specified level #log4j.appender.streams.filter.1.rate=25 log4j.logger.org.apache.kafka.streams=INFO, streams log4j.additivity.org.apache.kafka.streams=false log4j.logger.io.confluent.controlcenter.streams=INFO, streams log4j.additivity.io.confluent.controlcenter.streams=false log4j.logger.kafka=ERROR, stdout log4j.logger.org.apache.kafka=ERROR, stdout log4j.logger.org.apache.kafka.clients.consumer=INFO, stdout log4j.logger.org.apache.zookeeper=ERROR, stdout log4j.logger.org.I0Itec.zkclient=ERROR, stdout
Control Center を 再起動 します。詳細については、「Control Center のプロパティファイル」を参照してください。
./bin/control-center-stop ./bin/control-center-start ../etc/confluent-control-center/control-center.properties
デバッグおよびトレースを完了した後で、ログレベルをデフォルトに戻し、Control Center を再起動します。
log4j.rootLogger=INFO, stdout log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.EnhancedPatternLayout log4j.appender.stdout.layout.ConversionPattern=[%d] %p [%t] %m (%c)%n log4j.appender.streams=org.apache.log4j.ConsoleAppender log4j.appender.streams.layout=org.apache.log4j.EnhancedPatternLayout log4j.appender.streams.layout.ConversionPattern=[%d] %p [%t] %m (%c)%n log4j.appender.streams.filter.1=io.confluent.Log4jRateFilter # will allow everything that is >=level log4j.appender.streams.filter.1.level=WARN # will only allow rate/second logs at <level log4j.appender.streams.filter.1.rate=25 log4j.logger.org.apache.kafka.streams=INFO, streams log4j.additivity.org.apache.kafka.streams=false log4j.logger.io.confluent.controlcenter.streams=INFO, streams log4j.additivity.io.confluent.controlcenter.streams=false log4j.logger.kafka=INFO, stdout log4j.logger.org.apache.kafka=INFO, stdout log4j.logger.org.apache.kafka.clients.consumer=INFO, stdout log4j.logger.org.apache.zookeeper=WARN, stdout log4j.logger.org.I0Itec.zkclient=WARN, stdout
構成のチェック¶
セキュリティは有効にされていますか。ブローカー、クライアント、および Control Center 上の セキュリティ構成設定 をチェックします。
プレフィックスが正しいことを確認します。
Metrics Reporter およびインターセプターは正しくインストールおよび構成されていますか。
すべての Control Center トピックのトピック構成(レプリケーション係数、タイムスタンプの種類、最小 ISR、保持)を確認します。ZooKeeper ホストおよびポート(
<host:port>
)を指定した次のコマンドを使用できます。各プロセスによって正しい構成が選択されていることを確認します。./bin/kafka-topics --bootstrap-server <host:port> --describe
入力トピックのレビュー¶
_confluent-monitoring
および_confluent-metrics
が Control Center データのエントリーポイント入力トピックが作成されており、ホストとポート(
<host:port>
)、およびトピック(<input_topic>
)が指定されていることを確認します。bin/kafka-topics.sh --bootstrap-server <host:port> --topic <input_topic>
データが入力トピック内で生成されていることを確認します。これが機能するためには、コンシューマー内でセキュリティ設定が適切に構成されている必要があります。これを行うには、次のコマンドで Control Center の起動に使用されたプロパティファイル(
control-center.properties
など)を指定し、<input_topic>
に読み取るトピックを設定します。bin/control-center-console-consumer config/control-center.properties --topic <input_topic> {"clientType":"PRODUCER","clientId":"rock-client-producer-4","group... {"clientType":"CONSUMER","clientId":"rock-client-consumer-2","group...
クラスターのサイズ¶
ご使用の環境のサイズ設定の例については、 Control Center デプロイ例 を参照してください。
システムチェック¶
Control Center が実行されているシステムレベルのメトリクスをチェックします。これには、CPU、メモリー、ディスクおよび JVM の設定が含まれます。設定は 推奨値 の範囲内にありますか。
フロントエンドのリクエストおよび応答¶
ご使用のブラウザーのウェブ開発者ツールを使用して Network 設定を表示し、リクエストおよび応答に正しいデータが示されていることを確認します。
Confluent サポートと連携してブラウザーの問題をデバッグしている場合は、サポートでレビューするための HAR ファイルをキャプチャするよう依頼されることがあります。HAR ファイルにはブラウザーとサーバーの間のすべてのリクエストおよび応答が保管されます。
たとえば、Google Chrome を使用して HAR ファイルを生成するには、以下の手順に従います。
- Google Chrome を開き、問題が発生しているページを閲覧します。
- Chrome のメニューバーで 表示、開発/管理 、デベロッパーツール の順に選択します。
- デベロッパーツールパネルで、Network タブを選択します。
- タブの左上隅にある赤くて丸い Record ボタンを見つけ、赤くなっている(アクティブである)ことを確認します。灰色の場合は 1 回クリックしてレコーディングを開始します。
- Preserve log チェックボックスをオンにして、複数ページをまたがってキャプチャが保存されるようにします。
- ページを操作して、ブラウザー内で問題を再現します。
- ネットワークリクエストのグリッド上の任意の場所を右クリックし、Save as HAR with content を選択してファイルを保存します。
HAR ファイルはご使用の Confluent サポートチケットにアップロードできます(独自にトラブルシューティングを行う場合は、ファイルの内容をレビューすることもできます)。
ちなみに
デベロッパーツールパネル内の任意の行を右クリックし、Copy > を選択してネットワークログの内容を HAR ファイルまたは cURL ファイルとしてコピーすることもできます。
REST API¶
バックエンド REST API 呼び出しは c3.log
にログ記録されます。
コンシューマーのオフセットラグ¶
Control Center トピックのオフセットラグに、時間経過に伴って大きくなっているものがないことを確認します。MetricsAggregateStore
トピックおよび aggregate-rekey
トピックはボトルネックであることが多いため、これらをレビューします。トレンドを観察するには、Control Center のバージョン( <version>
)および ID(control-center-id
)を指定して、このコマンドを複数回実行することが必要になります。
./bin/kafka-consumer-groups --bootstrap-server <host:port> --describe --group _confluent-controlcenter-<version>-<control-center-id>
GC ログ記録の有効化¶
GC ログを有効にし、ディレクトリ(<dir>
)を指定した次の設定を使用して Control Center を再起動します。
CONTROL_CENTER_JVM_PERFORMANCE_OPTS="-server -verbose:gc -Xloggc:<dir>/gc.log -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSScavengeBeforeRemark -XX:+DisableExplicitGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCCause -Djava.awt.headless=true"
スレッドダンプ¶
スレッドダンプを作成するには、以下のコマンドを実行します。
jstack -l $(jcmd | grep -i 'controlcenter\.ControlCenter' | awk '{print $1}') > jstack.out
データディレクトリ¶
Control Center のローカルステートは confluent.controlcenter.data.dir
に保管されます。
このコマンドを使用して、データディレクトリ(<data.dir>
)のサイズを判別できます。
du -h <data.dir>