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
    Copy

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

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

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

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

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

    • [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>
      Copy

      参照された 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>
      Copy

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

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

    • CFK を再起動します。

      kubectl rollout restart deployment/confluent-operator
      Copy

    • Confluent Platform のコンポーネントを再起動します。

      kubectl rollout restart sts/<name>
      Copy

      コンポーネントの <name> の検索については、「Confluent Platform クラスターの再起動」を参照してください。

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

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

telemetry:
  global: false
Copy

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]
Copy

  • [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
    Copy

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

    その例を次に示します。

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

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

    その例を次に示します。

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

  • [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]
  tls:
    enabled:                 --- [4]
Copy
  • [1] `` true`` または false に設定して、メトリクスのレポートを有効または無効にします。
  • [2] Kafka に使用する認証タイプに設定します。詳細については、「Kafka にアクセスするための認証の構成」を参照してください。
  • [3] Kafka に対する認証用の Kubernetes シークレット名に設定します。
  • [4] Kafka クラスターの TLS ネットワーク暗号化が有効になっている場合は true に設定します。

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

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

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

spec:
  monitoringKafkaClusters:
  - name:                    --- [1]
    bootstrapEndpoint:       --- [2]
Copy
  • [1] Kafka クラスターの名前に設定します。
  • [2] Kafka のブートストラップエンドポイントに設定します。

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
Copy

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