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 を有効にするには、次の手順に従います。
CFK 値ファイル で、以下を設定します。
telemetry: enabled: true
次のコマンドで変更を適用します。
helm upgrade --install confluent-operator \ confluentinc/confluent-for-kubernetes \ --values <path-to-values-file> \ --namespace <namespace>
Telemetry Reporter の設定を、すべての Confluent Platform コンポーネントに対してグローバルに構成するには、次の手順に従います。
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 は起動に失敗します。
Telemetry の設定、参照先のシークレット、または
telemetry.txtファイルに変更を適用するには、CFK と Confluent Platform を手動で再起動します。CFK を再起動します。
kubectl rollout restart deployment/confluent-operator
Confluent Platform のコンポーネントを再起動します。
kubectl rollout restart sts/<name>
コンポーネントの
<name>の検索については、「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]
tls:
enabled: --- [4]
- [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]
- [1] Kafka クラスターの名前に設定します。
- [2] Kafka のブートストラップエンドポイントに設定します。
ksqlDB クラスターと Connect クラスターをモニタリングするための Control Center の構成¶
ksqlDB クラスターと Connect クラスターの詳細のモニタリングビューを提供するよう Control Center を構成することができます。
複数の ksqlDB クラスターと Connect クラスターをモニタリングするよう Confluent Control Center を構成する例については、「Connect Control Center to Multiple Connect and ksqlDB Clusters」を参照してください。