Confluent Operator のトラブルシューティング

以降のセクションでは、Confluent Platform デプロイのトラブルシューティングについて説明します。

ログ

ログはポッドごとに STDOUT へ直接送られます。ポッドのログを表示するには、以下のコマンドを使用します。

kubectl logs <pod-name> -n <namespace>
Copy

メトリクス

  • JMX メトリクスは、各ポッドのポート 7203 で使用できます。
  • Jolokia(JMX メトリクス用の REST インターフェイス)は、各ポッドのポート 7777 で使用できます。

デバッグ

Operator の使用中に起こりうる問題には以下の 2 種類があります。

  • インフラストラクチャレベルに存在する問題。Kubernetes レイヤーで何か問題が発生したという意味です。
  • アプリケーションレベルに存在する問題。インフラストラクチャに問題はないが、Confluent Platform そのものに問題が発生したという意味です。通常は構成が原因です。

まず、Kubernetes の障害 を探してください。

以下のコマンドを入力して、Kubernetes エラーの可能性を確認します。

kubectl get events -n <namespace>
Copy

次に、以下のコマンドを入力して(リソースタイプの例として "pods" を使用)、特定のリソースの問題を確認します。

kubectl describe pods <podname> -n <namespace>
Copy

上記のコマンドを実行したが何も問題がなさそうだった場合は、以下のコマンドを使用してポッドごとにログをチェックします。

kubectl logs <pod name> -n <namespace>
Copy

Confluent Platform コンテナーは、アプリケーションログが直接 STDOUT に出力されるように構成されています。ログは、以下のコマンドで直接読むことができます。無効な構成など、アプリケーションレベルで何か問題があった場合は、ログではっきりわかります。

注釈

クラッシュを理由にポッドが置き換えられている状態で、以前のポッドのログを確認するには、上記のコマンドの末尾に --previous を追加します。

仮想マシン(VM)のファイアウォールルールや DNS の構成など、データセンターインフラストラクチャに起因する問題については、インフラストラクチャのシステム管理者にトラブルシューティングを依頼してください。

デプロイのテスト

以下のセクションの説明に従って、デプロイをテストおよび検証します。

内部アクセスの検証

内部通信を検証するには、以下の手順に従います。

  1. ローカルマシンで以下のコマンドを入力して、クラスターの名前空間情報を表示します(例として名前空間 operator を使用)。この情報には、内部通信の検証に必要なブートストラップエンドポイントが含まれています。

    kubectl get kafka -n operator -oyaml
    
    Copy

    ブートストラップエンドポイントは bootstrap.servers の行に示されます。

    ... omitted
    
       internalClient: |-
          bootstrap.servers=kafka:9071
    
    Copy
  2. ローカルマシンで kubectl exec を使用して、クラスター内のポッドのいずれかで bash セッションを開始します。この例では、デフォルト名 kafka-0 のポッドを、デフォルト名 kafka の Kafka クラスターで使用します。

    kubectl -n operator exec -it kafka-0 bash
    
    Copy
  3. ポッドで、kafka.properties という名前のファイルを作成し、内容を入力します。コンテナーにはテキストエディターがインストールされていないので、このファイルの作成には以下の例に示すように cat コマンドを使用します。ファイルを保存するには、Ctrl + D キーを押します。

    注釈

    この例には、デフォルトの SASL/PLAIN セキュリティパラメーターが示されています。本稼働環境では、追加のセキュリティが必要です。詳細については、「Confluent Operator でのセキュリティの構成」を参照してください。

    cat << EOF > kafka.properties
    bootstrap.servers=kafka:9071
    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="test" password="test123";
    sasl.mechanism=PLAIN
    security.protocol=SASL_PLAINTEXT
    EOF
    
    Copy
  4. ポッドで、以下のコマンドを使用してブートストラップサーバーへのクエリを実行します。

    kafka-broker-api-versions --command-config kafka.properties --bootstrap-server kafka:9071
    
    Copy

    3 つの Kafka ブローカーそれぞれにつき、以下のような出力が表示されます。

    kafka-1.kafka.operator.svc.cluster.local:9071 (id: 1 rack: 0) -> (
       Produce(0): 0 to 7 [usable: 7],
       Fetch(1): 0 to 10 [usable: 10],
       ListOffsets(2): 0 to 4 [usable: 4],
       Metadata(3): 0 to 7 [usable: 7],
       LeaderAndIsr(4): 0 to 1 [usable: 1],
       StopReplica(5): 0 [usable: 0],
       UpdateMetadata(6): 0 to 4 [usable: 4],
       ControlledShutdown(7): 0 to 1 [usable: 1],
       OffsetCommit(8): 0 to 6 [usable: 6],
       OffsetFetch(9): 0 to 5 [usable: 5],
       FindCoordinator(10): 0 to 2 [usable: 2],
       JoinGroup(11): 0 to 3 [usable: 3],
       Heartbeat(12): 0 to 2 [usable: 2],
    
    ... omitted
    
    Copy

    この出力をもって、クラスター内での内部通信の検証となります。

外部アクセスの検証

Kafka への外部アクセス」の説明に従って、Kafka への外部アクセスと追加した DNS エントリを有効にしたら、外部通信を検証するために以下の手順に従います。

注釈

この例では、デフォルトの Confluent Platform コンポーネント名とデフォルトの Kafka ブートストラッププレフィックス kafka が使用されます。

  1. ローカルマシンで、 Confluent Platform をダウンロード します。Confluent CLI は、ダウンロードして PATH と必要な環境変数を設定するだけで使用できます。ローカルマシンで Confluent Platform を起動する必要はありません。

    外部通信の検証には、ローカルマシンで実行されている Confluent CLI を使用します。Confluent CLI は Confluent Platform に含まれています。

  2. ローカルマシンで、外部クライアント用のブートストラップサーバーエンドポイントを取得するためのコマンドを実行します。

    kubectl get kafka -n operator -oyaml
    
    Copy

    以下の出力例で、ブートストラップサーバーエンドポイントは kafka.mydomain:9092 です。

    ... omitted
    
    externalClient: |-
       bootstrap.servers=kafka.mydomain:9092
       sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="test" password="test123";
       sasl.mechanism=PLAIN
       security.protocol=SASL_PLAINTEXT
    
    Copy
  3. Confluent Platform がローカル実行されているローカルマシンで、kafka.properties という名前のファイルを作成し、以下の内容を入力します。上記の手順で取得した外部エンドポイントを bootstrap.servers に割り当てます。

    bootstrap.servers=<kafka bootstrap endpoint>
    sasl.jaas.config=org.apache.kafka.common.security.plain.PlainLoginModule required username="test" password="test123";
    sasl.mechanism=PLAIN
    security.protocol=SASL_PLAINTEXT
    
    Copy

    注釈

    この例には、デフォルトの SASL/PLAIN セキュリティパラメーターが示されています。本稼働環境では、追加のセキュリティが必要です。詳細については、「Confluent Operator でのセキュリティの構成」を参照してください。

  4. ローカルマシンで、ブートストラップエンドポイント <kafka bootstrap endpoint> を使用してトピックを作成します。以下の例では、パーティションが 1 つ、レプリカが 3 つのトピックが作成されます。

    kafka-topics --bootstrap-server <kafka bootstrap endpoint> \
    --command-config kafka.properties \
    --create --replication-factor 3 \
    --partitions 1 --topic example
    
    Copy
  5. ローカルマシンで、ブートストラップエンドポイント <kafka bootstrap endpoint> を使用して新しいトピックを生成します。これ 1 つですべての Kafka ブローカーにゲートウェイアクセスが提供されることから、ブートストラップサーバーエンドポイントは必要な唯一の Kafka ブローカーエンドポイントであることにご注意ください。

    seq 10000 | kafka-console-producer \
    --topic example --broker-list <kafka bootstrap endpoint> \
    --producer.config kafka.properties
    
    Copy
  6. ローカルマシンの 別のターミナル で、kafka.properties を作成したディレクトリから、Confluent CLI コマンドを発行して新しいトピックを消費します。

    kafka-console-consumer --from-beginning \
    --topic example --bootstrap-server <kafka bootstrap endpoint> \
    --consumer.config kafka.properties
    
    Copy

これらの手順が正常に完了したことをもって、クラスターとの外部通信の検証となります。