1. Home
  2. Confluent for Kubernetes

Confluent for Kubernetes を使用した Confluent Platform のモニタリング

Confluent for Kubernetes （CFK）環境のモニタリングには、次のツールとリソースを使用します。

  • Confluent Health+ と Telemetry
  • JMX メトリクスモニタリング統合
  • Confluent Control Center

Confluent Health+

Confluent Health+ は、Confluent Platform デプロイのパフォーマンスおよび構成データの継続的なリアルタイム解析を提供します。Health+ は、この解析に基づいて通知を送信することにより、問題が重大になる前に、環境の潜在的な問題についてユーザーに警告します。

詳細については、「Confluent Health+」を参照してください。

Telemetry Reporter

Confluent Telemetry Reporter は、サービスに関するメタデータを Confluent にプッシュするために各 Confluent Platform サービス内で動作するプラグインです。Telemetry Reporter により、メタデータに基づく製品機能（Health+ など）が有効になります。データは HTTP を介して送信され、暗号化された接続が使用されます。

CFK では、デフォルトで Telemetry が無効になっています。これは、CFK レベルでグローバルに有効にし、構成することができます。

Telemetry をグローバルに有効にするときに、特定の Confluent Platform コンポーネントに対して無効にすることができます。

各 Confluent Platform コンポーネントの CR には、Telemetry が有効かどうかを示すステータス条件が status.conditions として用意されています。

Telemetry Reporter の詳細およびサポートされる設定については、「Confluent Telemetry Reporter」を参照してください。

Health+ 用に収集されるメトリクスのリストについては、「Telemetry Reporter のメトリクス」を参照してください。

Telemetry のグローバル構成

すべての Confluent Platform コンポーネントに対してグローバルに Telemetry Reporter を有効にするには、次の手順に従います。

  1. CFK 値ファイル で、以下を設定します。

    telemetry:
  enabled: true

  2. 次のコマンドで変更を適用します。

    helm upgrade --install confluent-operator \
  confluentinc/confluent-for-kubernetes \
  --values <path-to-values-file> \
  --namespace <namespace>

Telemetry Reporter の設定を、すべての Confluent Platform コンポーネントに対してグローバルに構成するには、次の手順に従います。

  1. CFK 値ファイル で、以下を設定します。

    telemetry:
  secretRef:                 --- [1]
  directoryPathInContainer:  --- [2]

    • [1] [2] Helm を通じて Telemetry の構成を読み込む方法として、CFK は secretRef と directoryPathInContainer をサポートしています。

    • [1] 両方を構成した場合は、directoryPathInContainer よりも secretRef が優先されます。

      secretRef には、次の情報が含まれている必要があります。

      telemetry.txt : |-
 api.key=<cloud_key>
 api.secret=<cloud_secret>
 proxy.url=<proxy_url>
 proxy.username=<proxy_username>
 proxy.password=<proxy_password>

      参照された secretRef が読み取られない場合、または想定された形式のデータではない場合、CFK は起動に失敗します。

    • [2] telemetry.txt が置かれているディレクトリパスを指定します。telemetry.txt には次の情報が含まれています。

      api.key=<cloud_key>
api.secret=<cloud_secret>
proxy.url=<proxy_url>
proxy.username=<proxy_username>
proxy.password=<proxy_password>

      telemetry.txt が想定された形式になっていない場合、CFK は起動に失敗します。

    Vault を使用する際のキー/値と必要なアノテーションを提供する方法については、「Confluent Platform アプリケーションの CR へのシークレットの提供」を参照してください。

  2. Telemetry の設定、参照先のシークレット、または telemetry.txt ファイルに変更を適用するには、CFK と Confluent Platform を手動で再起動します。

    • CFK を再起動します。

      kubectl rollout restart deployment/confluent-operator

    • 「Confluent Platform の再起動」の説明に従って Confluent Platform コンポーネントを再起動します。

特定の Confluent Platform コンポーネントを対象とした Telemetry の無効化

特定の Confluent Platform コンポーネントを対象に Telemetry を無効にするには、コンポーネントの CR に次のように設定し、kubectl apply コマンドで変更を適用します。

telemetry:
  global: false

JMX メトリクス

CFK のデフォルトでは、すべての Confluent コンポーネントが、JMX メトリクスを有効にしてデプロイされます。すべてのポッドにおいて、これらの JMX メトリクスは次のエンドポイントで提供されます。

  • JMX メトリクスは、各ポッドのポート 7203 で使用できます。

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

  • JMX Prometheus Exporter はポート 7778 で使用できます。

    Prometheus Exporter では、認証と暗号化がサポートされていません。

JMX メトリクスのエンドポイントに対するセキュリティの構成

JMX/Prometheus メトリックのエンドポイントでは、認証、暗号化、外部アクセスがデフォルトでは提供されません。ただし必要であれば、コンポーネントの CR レベルで、JMX/Prometheus メトリックのエンドポイントに認証、TLS、外部アクセスを構成することができます。

spec:
  metrics:
    authentication:
      type:                    --- [1]
    prometheus:                --- [2]
      rules:                   --- [3]
        - attrNameSnakeCase:
          cache:
          help:
          labels:
          name:
          pattern:
          type:
          value:
          valueFactor:
      blackList:               --- [4]
      whiteList:               --- [5]
    tls:
      enabled:                 --- [6]

  • [1] mTLS 認証では mtls に設定します。

    mtls に設定した場合は、tls.enabled: true （[3]）を設定する必要があります。

  • [2] Prometheus の構成を指定して、デフォルトの設定をオーバーライドします。

    rules、blacklist、および whitelist プロパティの詳細については、Prometheus の説明 を参照してください。

  • [3] 適用されるルールのリスト。

    その例を次に示します。

    spec:
  metrics:
    prometheus:
      rules:
        - pattern: "org.apache.kafka.metrics<type=(\w+), name=(\w+)><>Value: (\d+)"
          name: "kafka_$1_$2"
          value: "$3"
          valueFactor: "0.000001"
          labels:
            "$1": "$4"
            "$2": "$3"
          help: "Kafka metric $1 $2"
          cache: false
          type: "GAUGE"
          attrNameSnakeCase: false

  • [4] クエリの対象にしないものを特定するためのパターン。

    その例を次に示します。

    spec:
  metrics:
    prometheus:
      blackist: "org.apache.kafka.metrics:*"

  • [5] クエリの対象にするものを特定するためのパターン。

    その例を次に示します。

    spec:
  metrics:
    prometheus:
      whitelist: "org.apache.kafka.metrics:type=ColumnFamily,*"

  • [6] true に設定した場合、「Confluent for Kubernetes でのネットワーク暗号化の構成」に示すとおりグローバルまたはコンポーネントの TLS を使用してメトリクスが構成されます。

Prometheus と Grafana の構成

JMX メトリクスを Confluent コンポーネントから取り込んで集計するように Prometheus を構成することができます。さらに Grafana を構成すれば、メトリクスをダッシュボードで可視化することができます。

構成シナリオの例については、Prometheus と Grafana を使用したモニタリング に関するページを参照してください。

Confluent Control Center

Confluent Control Center は、Confluent Platform を管理およびモニタリングするためのウェブベースのツールです。Control Center のユーザーインターフェイスを使用して、開発者やオペレーターは次のような作業を行うことができます。

  • クラスターの正常性の概要をすばやく把握する
  • メッセージ、トピック、Schema Registry を監視して制御する
  • ksqlDB のクエリを作成して実行する

モニタリングに使用できるメトリクスについては、Control Center で利用できるメトリクス のセクションを参照してください。

Kafka クラスターをモニタリングするための Control Center の構成

Confluent Metrics Reporter は、Apache Kafka® クラスターからさまざまなメトリクスを収集します。それらのメトリクスは、Kafka クラスターの詳細なモニタリングビューを提供するために Control Center によって使用されます。

Confluent Metrics Reporter はデフォルトで有効になっており、Kafka クラスターのメトリクスを、同じ Kafka クラスター上にある一連のトピックに送信するよう構成されています。

異なるクラスターにメトリクスを送信したり、特定の認証設定を構成したりするには、次のように Kafka のカスタムリソース（CR）を構成します。

metricReporter:
  enabled:                       --- [1]
  authentication:
    type:                        --- [2]
    jaasConfigPassThrough:
      secretRef:                 --- [3]
      directoryPathInContainer:  --- [4]
  tls:
    enabled:                     --- [5]

  • [1] `` true`` または false に設定して、メトリクスのレポートを有効または無効にします。

  • [2] Kafka に使用する認証タイプに設定します。詳細については、「Kafka にアクセスするための認証の構成」を参照してください。

  • [3] Kafka に対する認証用の Kubernetes シークレットの名前に設定します。

  • [4] Vault によって Kafka 認証情報が挿入される Kafka コンテナーのディレクトリパスに設定します。

    Vault を使用する際の認証情報と必要なアノテーションを提供する方法については、「Confluent Platform コンポーネントの CR へのシークレットの提供」を参照してください。

  • [5] Kafka クラスターの TLS ネットワーク暗号化が有効になっている場合は true に設定します。

Kafka クラスター用に Confluent Metrics Reporter をセットアップしたら、そのクラスターをモニタリングするよう Control Center を構成します。

Control Center は、使用している Kafka クラスターをモニタリングしてそれ自身の状態を格納するようデフォルトでセットアップされます。この Kafka クラスターは、Confluent Control Center の CR の spec.dependencies.kafka で定義されます。

モニタリング対象の Kafka クラスターが他にもあれば、Control Center の CR で次のようにして構成できます。

spec:
  monitoringKafkaClusters:
  - name:                         --- [1]
    bootstrapEndpoint:            --- [2]
    authentication:
      type:                       —-- [3]
      jaasConfig:                 —-- [4]
      jaasConfigPassThrough:      —-- [5]
      oauthbearer:                —-- [6]
        secretRef:                —-- [7]
        directoryPathInContainer: --- [8]
    tls:
      enabled:                    —-- [9]

  • [1] Kafka クラスターの名前に設定します。

  • [2] Kafka のブートストラップエンドポイントに設定します。

  • [3] Kafka のクライアント認証タイプに設定します。指定可能なオプションは、plain、oauthbearer、mtls です。oauthbearer は、RBAC が有効になっている場合のみ使用できます。

  • [4] [5] SASL/PLAIN を使用して Kafka クラスターへの認証を行う場合は、「Configure Confluent components to authenticate to Kafka using SASL/PLAIN」を参照してください。

  • [6] Confluent Control Center の認可タイプが RBAC（spec.authorization.type: rbac）に設定されており、認証タイプが [3] で oauthbearer に設定されている場合、OAuth メソッドを使用して Kafka クラスターへの認証を行うことができます。

  • [7] ユーザー名とパスワードは secretRef から読み込まれます。想定されるキーは bearer.txt で、キーの値は次のようになります。

    username=<username>
password=<password>

    このプロパティに使用するシークレットを作成するコマンドの例を以下に示します。

    kubectl create secret generic oauth-client \
  --from-file=bearer.txt=/some/path/bearer.txt \
  --namespace confluent

  • [8] Vault によって想定されるベアラー認証情報が挿入される Confluent Control Center コンテナーのディレクトリ。想定される形式については、前の説明（[7]）を参照してください。

    Vault を使用する際の認証情報と必要なアノテーションを提供する方法については、「Confluent Platform コンポーネントの CR へのシークレットの提供」を参照してください。

  • [9] mTLS を使用して Kafka クラスターへの認証を行う場合は、「Configure Confluent components to authenticate to Kafka using mTLS」を参照してください。

ksqlDB、Connect、Schema Registry クラスターをモニタリングするための Control Center の構成

ksqlDB、Connect、Schema Registry クラスターの詳細なモニタリングおよび管理ビューを提供するように Control Center を構成できます。

以下は、Control Center の CR の dependencies セクションの例です。この例では、2 つの Schema Registry クラスター、2 つの ksqlDB クラスター、2 つの Connect クラスターを Control Center に接続しています。

spec:
 dependencies:
   schemaRegistry:
     url: https://schemaregistry.confluent.svc.cluster.local:8081
     tls:
       enabled: true
     authentication:
       type: mtls
     clusters:
     - name: schemaregistry-dev
       url: https://schemaregistry-dev.confluent.svc.cluster.local:8081
       tls:
         enabled: true
       authentication:
        type: mtls
   ksqldb:
   - name: ksql-dev
     url: https://ksqldb.confluent.svc.cluster.local:8088
     tls:
       enabled: true
     authentication:
       type: mtls
   - name: ksql-dev1
     url: https://ksqldb-dev.confluent.svc.cluster.local:8088
     tls:
       enabled: true
     authentication:
       type: mtls
   connect:
   - name: connect-dev
     url: https://connect.confluent.svc.cluster.local:8083
     tls:
       enabled: true
     authentication:
       type: mtls
   - name: connect-dev2
     url: https://connect-dev.confluent.svc.cluster.local:8083
     tls:
       enabled: true
     authentication:
       type: mtls

複数の ksqlDB、Connect、Schema Registry クラスターをモニタリングするように Confluent Control Center を構成するシナリオ例については、「Connect Control Center to Multiple Connect and ksqlDB Clusters」を参照してください。