第7章 AMQ Streams のメトリクスおよびダッシュボードの設定
ダッシュボードでキーメトリクスを表示し、特定の条件下でトリガーされるアラートを設定すると、AMQ Streams デプロイメントを監視できます。メトリクスは、Kafka、ZooKeeper、および AMQ Streams の他のコンポーネントで利用できます。
AMQ Streams は、メトリクス情報を提供するために、Prometheus ルールと Grafana ダッシュボードを使用します。
Prometheus に AMQ Streams の各コンポーネントのルールセットが設定されている場合、Prometheus はクラスターで稼働している Pod からキーメトリクスを使用します。次に、Grafana はこれらのメトリクスをダッシュボードで可視化します。AMQ Streams には、デプロイメントに合わせてカスタマイズできる Grafana ダッシュボードのサンプルが含まれています。
OpenShift Container Platform 4.x では、AMQ Streams は ユーザー定義プロジェクトのモニタリング (OpenShift の機能) を使用し、Prometheus の設定プロセスを容易にします。
OpenShift Container Platform 3.11 では、Prometheus および Alertmanager コンポーネントを別々にクラスターにデプロイする必要があります。
OpenShift Container Platform のバージョンに関係なく、AMQ Streams に Prometheus メトリクス設定をデプロイ して開始する必要があります。
次に、OpenShift Container Platform のバージョンに適した手順に従います。
Prometheus および Grafana が設定されると、Grafana ダッシュボードおよびアラートルールのサンプルを使用して Kafka クラスターを監視できます。
追加の監視オプション
Kafka Exporter は、コンシューマーラグに関連する追加の監視を提供する任意のコンポーネントです。AMQ Streams で Kafka Exporter を使用する場合は、「Kafka クラスターと Kafka Exporter をデプロイするように Kafka リソースを設定」を参照してください。
さらに、分散トレーシングを設定してメッセージをエンドツーエンドで追跡するように、デプロイメントを設定することもできます。詳細は、『AMQ Streams on OpenShift の使用』の「分散トレーシング」を参照してください。
その他のリソース
- Prometheus ドキュメント
- Grafana ドキュメント
- Kafka ドキュメントの Apache Kafka Monitoring では、Apache Kafka により公開される JMX メトリクスについて解説しています。
- ZooKeeper ドキュメントの ZooKeeper JMX では、Apache Zookeeper により公開される JMX メトリックについて解説しています。
7.1. メトリクスファイルの例
Grafana ダッシュボードおよびその他のメトリクス設定のサンプルファイルは、examples/metrics ディレクトリー にあります。以下のリストが示すように、一部のファイルは OpenShift Container Platform 3.11 のみで使用され、OpenShift Container Platform 4.x では使用されません。
AMQ Streams で提供されるサンプルメトリクスファイル
metrics ├── grafana-dashboards 1 │ ├── strimzi-cruise-control.json │ ├── strimzi-kafka-bridge.json │ ├── strimzi-kafka-connect.json │ ├── strimzi-kafka-exporter.json │ ├── strimzi-kafka-mirror-maker-2.json │ ├── strimzi-kafka.json │ ├── strimzi-operators.json │ └── strimzi-zookeeper.json ├── grafana-install │ └── grafana.yaml 2 ├── prometheus-additional-properties │ └── prometheus-additional.yaml - OPENSHIFT 3.11 ONLY 3 ├── prometheus-alertmanager-config │ └── alert-manager-config.yaml 4 ├── prometheus-install │ ├── alert-manager.yaml - OPENSHIFT 3.11 ONLY 5 │ ├── prometheus-rules.yaml 6 │ ├── prometheus.yaml - OPENSHIFT 3.11 ONLY 7 │ ├── strimzi-pod-monitor.yaml 8 ├── kafka-bridge-metrics.yaml 9 ├── kafka-connect-metrics.yaml 10 ├── kafka-cruise-control-metrics.yaml 11 ├── kafka-metrics.yaml 12 └── kafka-mirror-maker-2-metrics.yaml 13
- 1
- Grafana ダッシュボードのサンプル
- 2
- Grafana イメージのインストールファイル。
- 3
- OPENSHIFT 3.11 のみ該当: CPU、メモリー、およびディスクボリュームの使用状況についてのメトリクスをスクレープする追加の Prometheus 設定。これらのメトリクスは、ノード上の OpenShift cAdvisor エージェントおよび kubelet から直接提供されます。
- 4
- Alertmanager による通知送信のためのフック定義。
- 5
- OPENSHIFT 3.11 のみ該当: Alertmanager をデプロイおよび設定するためのリソース。
- 6
- Prometheus Alertmanager と使用するアラートルールの例。
- 7
- OPENSHIFT 3.11 のみ該当: Prometheus イメージのインストールリソースファイル。
- 8
- Prometheus Operator によって Prometheus サーバーのジョブに変換される PodMonitor の定義。これにより、Pod から直接メトリクスデータをスクレープできます。
- 9
- メトリクスが有効になっている Kafka Bridge リソース。
- 10
- Kafka Connect に対する Prometheus JMX Exporter の再ラベル付けルールを定義するメトリクス設定。
- 11
- Cruise Control に対する Prometheus JMX Exporter の再ラベル付けルールを定義するメトリクス設定。
- 12
- Kafka および ZooKeeper に対する Prometheus JMX Exporter の再ラベル付けルールを定義するメトリクス設定。
- 13
- Kafka Mirror Maker 2.0 に対する Prometheus JMX Exporter の再ラベル付けルールを定義するメトリクス設定。
7.1.1. Grafana ダッシュボードのサンプル
Grafana ダッシュボードのサンプルは、以下のリソースを監視するために提供されます。
- AMQ Streams Kafka
以下のメトリクスを表示します。
- オンラインのブローカーの数
- クラスター内のアクティブなコントローラーの数
- 非同期レプリカがリーダーに選択される割合
- オンラインのレプリカ
- 複製の数が最低数未満であるパーティションの数
- 最小の In-Sync レプリカ数にあるパーティション
- 最小の In-Sync レプリカ数未満のパーティション
- アクティブなリーダーを持たないため、書き込みや読み取りができないパーティション
- Kafka ブローカー Pod のメモリー使用量
- 集約された Kafka ブローカー Pod の CPU 使用率
- Kafka ブローカー Pod のディスク使用量
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- JVM ガベージコレクションの数
- 受信バイトレートの合計
- 送信バイトレートの合計
- 受信メッセージレート
- 生成要求レートの合計
- バイトレート
- 生成要求レート
- 取得要求レート
- ネットワークプロセッサーの平均時間アイドル率
- リクエストハンドラーの平均時間アイドル率
- ログサイズ
- AMQ Streams ZooKeeper
以下のメトリクスを表示します。
- ZooKeeper アンサンブルのクォーラムサイズ
- アクティブな 接続の数
- サーバーのキューに置かれたリクエストの数
- ウォッチャーの数
- ZooKeeper Pod のメモリー使用量
- 集約された ZooKeeper Pod の CPU 使用率
- ZooKeeper Pod のディスク使用量
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- JVM ガベージコレクションの数
- サーバーがクライアントリクエストに応答するまでの時間 (最大、最小、および平均)
- AMQ Streams Kafka Connect
以下のメトリクスを表示します。
- 受信バイトレートの合計
- 送信バイトレートの合計
- ディスク使用量
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- AMQ Streams Kafka MirrorMaker 2
以下のメトリクスを表示します。
- コネクターの数
- タスクの数
- 受信バイトレートの合計
- 送信バイトレートの合計
- ディスク使用量
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- AMQ Streams の Operator
以下のメトリクスを表示します。
- カスタムリソース
- 1 時間あたりの成功したカスタムリソース調整の数
- 1 時間あたりの失敗したカスタムリソース調整の数
- 1 時間あたりのロックなしの調整の数
- 1 時間あたりの開始された調整の数
- 1 時間あたりの定期的な調整の数
- 最大の調整時間
- 平均の調整時間
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- JVM ガベージコレクションの数
ダッシュボードは、AMQ Streams の Kafka Bridge および Cruise Control コンポーネントにも提供されます。
すべてのダッシュボードは、JVM メトリクスの他に、各コンポーネントに固有のメトリクスを提供します。たとえば、Operator ダッシュボードは、処理中の調整またはカスタムリソースの数に関する情報を提供します。
7.1.2. Prometheus メトリクス設定の例
AMQ Streams は、Prometheus JMX Exporter を使用して、Prometheus によってスクレープされる HTTP エンドポイントを使用して JMX メトリクスを公開します。
Grafana ダッシュボードが依存する Prometheus JMX Exporter の再ラベル付けルールは、カスタムリソース設定として AMQ Streams コンポーネントに対して定義されます。
ラベルは名前と値のペアです。再ラベル付けは、ラベルを動的に書き込むプロセスです。たとえば、ラベルの値は Kafka サーバーおよびクライアント ID の名前から派生されることがあります。
AMQ Streams では、再ラベル付けルールがすでに定義されたカスタムリソース設定 YAML ファイルのサンプルが提供されます。Prometheus メトリクス設定をデプロイする場合、カスタムリソースのサンプルをデプロイすることや、メトリクス設定を独自のカスタムリソース定義にコピーすることができます。
表7.1 メトリクス設定を含むカスタムリソースの例
| コンポーネント | カスタムリソース | サンプル YAML ファイル |
|---|---|---|
| Kafka および ZooKeeper |
|
|
| Kafka Connect |
|
|
| Kafka MirrorMaker 2.0 |
|
|
| Kafka Bridge |
|
|
| Cruise Control |
|
|
その他のリソース
- 「Prometheus メトリクス設定のデプロイ」
- 再ラベル付けの使用方法の詳細は、Prometheus ドキュメントの「Configuration」を参照してください。
7.2. Prometheus メトリクス設定のデプロイ
AMQ Streams では、再ラベル付けルールが含まれる カスタムリソース設定用の YAML ファイルのサンプル が提供されます。
再ラベル付けルールのメトリクス設定を適用するには、以下のいずれかを行います。
7.2.1. Prometheus メトリクス設定のカスタムリソースへのコピー
Grafana ダッシュボードを監視に使用するには、メトリクス設定サンプルをカスタムリソースにコピーします。
以下の手順では、Kafka リソースを更新しますが、モニタリングをサポートするすべてのコンポーネントについて手順は同じです。
手順
デプロイメントの Kafka リソースごとに以下の手順を実行します。
エディターで
Kafkaリソースを更新します。oc edit kafka KAFKA-CONFIG-FILE-
kafka-metrics.yamlの設定例を、ユーザーのKafkaリソース定義にコピーします。 - ファイルを保存し、更新したリソースが調整されるのを待ちます。
7.2.2. Prometheus メトリクス設定での Kafka クラスターのデプロイメント
Grafana ダッシュボードを監視に使用するには、メトリクス設定でサンプル Kafka クラスターをデプロイできます。
以下の手順では、Kafka リソース用に、kafka-metrics.yaml ファイルが使用されます。
手順
メトリクス設定サンプルで Kafka クラスターをデプロイします。
oc apply -f kafka-metrics.yaml
7.3. OpenShift 4 での Kafka メトリクスおよびダッシュボードの表示
AMQ Streams が OpenShift Container Platform 4.x にデプロイされると、ユーザー定義プロジェクトのモニタリング によりメトリクスが提供されます。この OpenShift 機能により、開発者は独自のプロジェクト (例: Kafka プロジェクト) を監視するために別の Prometheus インスタンスにアクセスできます。
ユーザー定義プロジェクトのモニタリングが有効である場合、openshift-user-workload-monitoring プロジェクトには以下のコンポーネントが含まれます。
- Prometheus Operator
- Prometheus インスタンス (Prometheus Operator によって自動的にデプロイされます)
- Thanos Ruler インスタンス
AMQ Streams は、これらのコンポーネントを使用してメトリクスを消費します。
クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にし、開発者およびその他のユーザーに独自のプロジェクト内のアプリケーションを監視するパーミッションを付与する必要があります。
Grafana のデプロイメント
Grafana インスタンスを、Kafka クラスターが含まれるプロジェクトにデプロイできます。その後、Grafana ダッシュボードのサンプルを使用して、AMQ Streams の Prometheus メトリクスを Grafana ユーザーインターフェースで可視化できます。
openshift-monitoring プロジェクトは、コアプラットフォームコンポーネントの監視を提供します。このプロジェクトの Prometheus および Grafana コンポーネントを使用して、OpenShift Container Platform 4.x 上の AMQ Streams の監視を設定しないでください。
Grafana バージョン 6.3 は、サポートされる最小バージョンです。
前提条件
- YAML ファイルのサンプルを使用して、Prometheus メトリクス設定がデプロイされている 必要があります。
ユーザー定義プロジェクトの監視が有効になっている必要があります。OpenShift Container Platform クラスターに、クラスター管理者が作成した
cluster-monitoring-configConfigMap が存在する必要があります。詳細は、以下のリソースを参照してください。- OpenShift Container Platform 4.6 の「ユーザー定義プロジェクトのモニタリングの有効化」。
- OpenShift Container Platform 4.5 の「独自のサービスのモニタリングの有効化」。
ユーザー定義のプロジェクトを監視するには、クラスター管理者がユーザーに
monitoring-rules-editまたはmonitoring-editロールを割り当て済みである必要があります。以下を参照してください。- OpenShift Container Platform 4.6 の「ユーザーに対するユーザー定義のプロジェクトをモニターするパーミッションの付与」。
- OpenShift Container Platform 4.5 の「WEB コンソールを使用したユーザーパーミッションの付与」
手順の概要
OpenShift Container Platform 4.x で AMQ Streams のモニタリングを設定するには、以下の手順を順番に行います。
7.3.1. Prometheus リソースのデプロイ
OpenShift Container Platform 4.x で AMQ Streams を実行している場合は、この手順を使用します。
Kafka メトリクスを使用するよう Prometheus を有効にするには、サンプルメトリクスファイルで PodMonitor リソースを設定およびデプロイします。PodMonitors は、Apache Kafka、ZooKeeper、Operator、Kafka Bridge、および Cruise Control から直接データをスクレープします。
次に、Alertmanager のアラートルールのサンプルをデプロイします。
前提条件
- 稼働中の Kafka クラスターが必要です。
- AMQ Streams で 提供されるアラートルールのサンプル を確認します。
手順
ユーザー定義プロジェクトのモニタリングが有効であることを確認します。
oc get pods -n openshift-user-workload-monitoring
有効であると、モニタリングコンポーネントの Pod が返されます。以下に例を示します。
NAME READY STATUS RESTARTS AGE prometheus-operator-5cc59f9bc6-kgcq8 1/1 Running 0 25s prometheus-user-workload-0 5/5 Running 1 14s prometheus-user-workload-1 5/5 Running 1 14s thanos-ruler-user-workload-0 3/3 Running 0 14s thanos-ruler-user-workload-1 3/3 Running 0 14s
Pod が返されなければ、ユーザー定義プロジェクトのモニタリングは無効になっています。「OpenShift 4 での Kafka メトリクスおよびダッシュボードの表示」 の前提条件を参照してください。
複数の
PodMonitorリソースがexamples/metrics/prometheus-install/strimzi-pod-monitor.yamlで定義されています。PodMonitorリソースごとに、spec.namespaceSelector.matchNamesプロパティーを編集します。apiVersion: monitoring.coreos.com/v1 kind: PodMonitor metadata: name: cluster-operator-metrics labels: app: strimzi spec: selector: matchLabels: strimzi.io/kind: cluster-operator namespaceSelector: matchNames: - PROJECT-NAME 1 podMetricsEndpoints: - path: /metrics port: http # ...- 1
- メトリクスをスクレープする Pod が実行されているプロジェクト (例:
Kafka)。
strimzi-pod-monitor.yamlファイルを、Kafka クラスターが稼働しているプロジェクトにデプロイします。oc apply -f strimzi-pod-monitor.yaml -n MY-PROJECTPrometheus ルールのサンプルを同じプロジェクトにデプロイします。
oc apply -f prometheus-rules.yaml -n MY-PROJECT
その他のリソース
- OpenShift Container Platform 4.6 の『モニタリング』ガイド。
- 「アラートルールの例」
7.3.2. Grafana のサービスアカウントの作成
OpenShift Container Platform 4.x で AMQ Streams を実行している場合は、この手順を使用します。
AMQ Streams の Grafana インスタンスは、cluster-monitoring-view ロールが割り当てられたサービスアカウントで実行する必要があります。
前提条件
手順
Grafana の
ServiceAccountを作成します。ここでは、リソースの名前はgrafana-serviceaccountです。apiVersion: v1 kind: ServiceAccount metadata: name: grafana-serviceaccount labels: app: strimziServiceAccountを Kafka クラスターが含まれるプロジェクトにデプロイします。oc apply -f GRAFANA-SERVICEACCOUNT -n MY-PROJECT
cluster-monitoring-viewロールを GrafanaServiceAccountに割り当てるClusterRoleBindingリソースを作成します。ここでは、リソースの名前はgrafana-cluster-monitoring-bindingです。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: grafana-cluster-monitoring-binding labels: app: strimzi subjects: - kind: ServiceAccount name: grafana-serviceaccount namespace: MY-PROJECT 1 roleRef: kind: ClusterRole name: cluster-monitoring-view apiGroup: rbac.authorization.k8s.io- 1
- プロジェクトの名前。
ClusterRoleBindingを Kafka クラスターが含まれるプロジェクトにデプロイします。oc apply -f GRAFANA-CLUSTER-MONITORING-BINDING -n MY-PROJECT
7.3.3. Prometheus データソースを使用した Grafana のデプロイ
OpenShift Container Platform 4.x で AMQ Streams を実行している場合は、この手順を使用します。
この手順では、OpenShift Container Platform 4.x モニタリングスタックに対して設定された Grafana アプリケーションをデプロイする方法を説明します。
OpenShift Container Platform 4.x には、openshift-monitoring プロジェクトに Thanos Querier インスタンスが含まれています。Thanos Querier は、プラットフォームメトリクスを集約するために使用されます。
必要なプラットフォームメトリクスを使用するには、Grafana インスタンスには Thanos Querier に接続できる Prometheus データソースが必要です。この接続を設定するには、トークンを使用し、Thanos Querier と並行して実行される oauth-proxy サイドカーに対して認証を行う Config Map を作成します。datasource.yaml ファイルは Config Map のソースとして使用されます。
最後に、Kafka クラスターが含まれるプロジェクトにボリュームとしてマウントされた Config Map で Grafana アプリケーションをデプロイします。
手順
Grafana
ServiceAccountのアクセストークンを取得します。oc serviceaccounts get-token grafana-serviceaccount -n MY-PROJECT次のステップで使用するアクセストークンをコピーします。
Grafana の Thanos Querier 設定が含まれる
datasource.yamlファイルを作成します。以下に示すように、アクセストークンを
httpHeaderValue1プロパティーに貼り付けます。apiVersion: 1 datasources: - name: Prometheus type: prometheus url: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 access: proxy basicAuth: false withCredentials: false isDefault: true jsonData: timeInterval: 5s tlsSkipVerify: true httpHeaderName1: "Authorization" secureJsonData: httpHeaderValue1: "Bearer ${GRAFANA-ACCESS-TOKEN}" 1 editable: true- 1
GRAFANA-ACCESS-TOKEN: GrafanaServiceAccountのアクセストークンの値
grafana-configファイルからdatasource.yamlという名前の Config Map を作成します。oc create configmap grafana-config --from-file=datasource.yaml -n MY-PROJECTDeploymentおよびServiceで構成される Grafana アプリケーションを作成します。grafana-configConfig Map はデータソース設定のボリュームとしてマウントされます。apiVersion: apps/v1 kind: Deployment metadata: name: grafana labels: app: strimzi spec: replicas: 1 selector: matchLabels: name: grafana template: metadata: labels: name: grafana spec: serviceAccountName: grafana-serviceaccount containers: - name: grafana image: grafana/grafana:6.3.0 ports: - name: grafana containerPort: 3000 protocol: TCP volumeMounts: - name: grafana-data mountPath: /var/lib/grafana - name: grafana-logs mountPath: /var/log/grafana - name: grafana-config mountPath: /etc/grafana/provisioning/datasources/datasource.yaml readOnly: true subPath: datasource.yaml readinessProbe: httpGet: path: /api/health port: 3000 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: httpGet: path: /api/health port: 3000 initialDelaySeconds: 15 periodSeconds: 20 volumes: - name: grafana-data emptyDir: {} - name: grafana-logs emptyDir: {} - name: grafana-config configMap: name: grafana-config --- apiVersion: v1 kind: Service metadata: name: grafana labels: app: strimzi spec: ports: - name: grafana port: 3000 targetPort: 3000 protocol: TCP selector: name: grafana type: ClusterIPGrafana アプリケーションを、Kafka クラスターが含まれるプロジェクトにデプロイします。
oc apply -f GRAFANA-APPLICATION -n MY-PROJECT
その他のリソース
- 「OpenShift 4 での Kafka メトリクスおよびダッシュボードの表示」
- OpenShift Container Platform 4.6 の『モニタリング』ガイド。
7.3.4. Grafana サービスへのルートの作成
OpenShift Container Platform 4.x で AMQ Streams を実行している場合は、この手順を使用します。
Grafana サービスを公開するルートを介して、Grafana ユーザーインターフェースにアクセスできます。
手順
grafanaサービスへの edge ルートを作成します。oc create route edge MY-GRAFANA-ROUTE --service=grafana --namespace=KAFKA-NAMESPACE
7.3.5. Grafana ダッシュボードサンプルのインポート
OpenShift Container Platform 4.x で AMQ Streams を実行している場合は、この手順を使用します。
Grafana ユーザーインターフェースを使用して Grafana ダッシュボードのサンプルをインポートします。
前提条件
手順
Grafana サービスへのルートの詳細を取得します。以下に例を示します。
oc get routes NAME HOST/PORT PATH SERVICES MY-GRAFANA-ROUTE MY-GRAFANA-ROUTE-amq-streams.net grafana
- Web ブラウザーで、Route ホストおよびポートの URL を使用して Grafana ログイン画面にアクセスします。
ユーザー名とパスワードを入力し、続いて Log In をクリックします。
デフォルトの Grafana ユーザー名およびパスワードは、どちらも
adminです。初回ログイン後に、パスワードを変更できます。- Configuration > Data Sources で、Prometheus データソースが作成済みであることを確認します。データソースは 「Prometheus データソースを使用した Grafana のデプロイ」 に作成されています。
- Dashboards > Manage をクリックしてから Import をクリックします。
-
examples/metrics/grafana-dashboardsで、インポートするダッシュボードの JSON をコピーします。 - JSON をテキストボックスに貼り付け、Load をクリックします。
- 他の Grafana ダッシュボードのサンプルに、ステップ 1 -7 を繰り返します。
インポートされた Grafana ダッシュボードは、Dashboards ホームページから表示できます。
7.4. OpenShift 3.11 での Kafka メトリクスおよびダッシュボードの表示
AMQ Streams が OpenShift Container Platform 3.11 にデプロイされた場合、Prometheus を使用して AMQ Streams で提供される Grafana ダッシュボードのサンプルのモニタリングデータを提供できます。Prometheus コンポーネントをクラスターに手動でデプロイする必要があります。
Grafana ダッシュボードのサンプルを実行するには、以下を行う必要があります。
このセクションで参照されるリソースは、まず監視を設定することを目的としており、これらはサンプルとしてのみ提供されます。実稼働環境で Prometheus または Grafana を設定、実行するためにサポートがさらに必要な場合は、それぞれのコミュニティーに連絡してください。
7.4.1. Prometheus のサポート
AMQ Streams が OpenShift Container Platform 3.11 にデプロイされた場合は、Prometheus サーバーはサポートされません。しかし、メトリクスを公開するために使用される Prometheus エンドポイントと Prometheus JMX Exporter はサポートされます。
Prometheus を使用して監視を行う場合に備え、詳細な手順とメトリクス設定ファイルのサンプルが提供されます。
7.4.2. Prometheus の設定
OpenShift Container Platform 3.11 で AMQ Streams を実行している場合は、以下の手順を使用します。
Prometheus では、システム監視とアラート通知のオープンソースのコンポーネントセットが提供されます。
ここでは、AMQ Streams が OpenShift Container Platform 3.11 にデプロイされている場合に、提供された Prometheus イメージと設定ファイルを使用して、Prometheus サーバーを実行および管理する方法を説明します。
前提条件
- 互換性のあるバージョンの Prometheus および Grafana を OpenShift Container Platform 3.11 クラスターにデプロイしている。
Prometheus サーバー Pod の実行に使用されるサービスアカウントが OpenShift API サーバーにアクセスできる。これにより、サービスアカウントはメトリクスの取得元となるクラスターにある Pod の一覧を取得できます。
詳細は、「Discovering services」を参照してください。
7.4.2.1. Prometheus の設定
AMQ Streams では、Prometheus サーバーの設定ファイルのサンプル が提供されます。
デプロイメント用に Prometheus イメージが提供されます。
-
prometheus.yaml
Prometheus 関連の追加設定も、以下のファイルに含まれています。
-
prometheus-additional.yaml -
prometheus-rules.yaml -
strimzi-pod-monitor.yaml
Prometheus が監視データを取得するには、互換性のあるバージョンの Prometheus を OpenShift Container Platform 3.11 クラスターにデプロイしている必要があります。
次に、設定ファイルを使用して Prometheus をデプロイ します。
7.4.2.2. Prometheus リソース
Prometheus 設定を適用すると、以下のリソースが OpenShift クラスターに作成され、Prometheus Operator によって管理されます。
-
ClusterRole。コンテナーメトリクスのために Kafka と ZooKeeper の Pod、cAdvisor および kubelet によって公開される health エンドポイントを読み取る権限を Prometheus に付与します。 -
ServiceAccount。これで Prometheus Pod が実行されます。 -
ClusterRoleBinding。ClusterRoleをServiceAccountにバインドします。 -
Deployment。Prometheus Operator Pod を管理します。 -
PodMonitor。Prometheus Pod の設定を管理します。 -
Prometheus。Prometheus Pod の設定を管理します。 -
PrometheusRule。Prometheus Pod のアラートルールを管理します。 -
Secret。Prometheus の追加設定を管理します。 -
Service。クラスターで稼働するアプリケーションが Prometheus に接続できるようにします (例: Prometheus をデータソースとして使用する Grafana)。
7.4.2.3. Prometheus のデプロイメント
Kafka クラスターの監視データを取得するには、独自の Prometheus デプロイメントを使用するか、Prometheus Docker イメージのインストールリソースサンプルファイルと Prometheus 関連リソースの YAML ファイル を適用して Prometheus をデプロイすることができます。
デプロイメントプロセスでは、ClusterRoleBinding が作成され、デプロイメントのために指定された namespace で Alertmanager インスタンスが検出されます。
前提条件
- 提供されるアラートルールのサンプルを確認します。
手順
Prometheus のインストール先となる namespace に従い、Prometheus インストールファイル (
prometheus.yaml) を変更します。Linux の場合は、以下を使用します。
sed -i 's/namespace: .*/namespace: my-namespace/' prometheus.yamlMacOS の場合は、以下を使用します。
sed -i '' 's/namespace: .*/namespace: my-namespace/' prometheus.yamlPodMonitorリソースをstrimzi-pod-monitor.yamlで編集し、Pod からメトリクスデータをスクレープする Prometheus ジョブを定義します。namespaceSelector.matchNamesプロパティーを、メトリクスのスクレープ元の Pod が実行されている namespace で更新します。PodMonitorは、Apache Kafka、ZooKeeper、Operator、Kafka Bridge、および Cruise Control 用 Pod から直接データをスクレープするのに使用されます。prometheus.yamlインストールファイルを編集し、ノードから直接メトリクスをスクレープするための追加設定を含めます。提供される Grafana ダッシュボードが表示する CPU、メモリー、およびディスクボリュームの使用状況についてのメトリクスは、ノード上の OpenShift cAdvisor エージェントおよび kubelet から直接提供されます。
設定ファイル (
examples/metrics/prometheus-additional-propertiesディレクトリーのprometheus-additional.yaml) からSecretリソースを作成します。oc apply -f prometheus-additional.yaml
-
prometheus.yamlファイルでadditionalScrapeConfigsプロパティーを編集し、Secretの名前およびprometheus-additional.yamlファイルを追加します。
Prometheus リソースをデプロイします。
oc apply -f strimzi-pod-monitor.yaml oc apply -f prometheus-rules.yaml oc apply -f prometheus.yaml
7.4.3. Prometheus Alertmanager の設定
Prometheus Alertmanager は、アラートを処理して通知サービスにルーティングするためのプラグインです。Alertmanager は、アラートルールを基にして潜在的な問題と見られる状態を通知し、監視で必要な条件に対応します。
7.4.3.1. Alertmanager の設定
AMQ Streams には、Prometheus Alertmanager の設定ファイルのサンプルが含まれます。
設定ファイルは、Alertmanager をデプロイするためのリソースを定義します。
-
alert-manager.yaml
追加の設定ファイルには、Kafka クラスターから通知を送信するためのフック定義が含まれます。
-
alert-manager-config.yaml
Alertmanger で Prometheus アラートの処理を可能にするには、設定ファイルを使用して以下を行います。
7.4.3.2. アラートルール
アラートルールによって、メトリクスで監視される特定条件についての通知が提供されます。ルールは Prometheus サーバーで宣言されますが、アラート通知は Prometheus Alertmanager で対応します。
Prometheus アラートルールでは、継続的に評価される PromQL 表現を使用して条件が記述されます。
アラート表現が true になると、条件が満たされ、Prometheus サーバーからアラートデータが Alertmanager に送信されます。次に Alertmanager は、そのデプロイメントに設定された通信方法を使用して通知を送信します。
Alertmanager は、電子メール、チャットメッセージなどの通知方法を使用するように設定できます。
その他のリソース
アラートルールの設定についての詳細は、Prometheus ドキュメントの「Configuration」を参照してください。
7.4.3.3. アラートルールの例
Kafka および ZooKeeper メトリクスのアラートルールのサンプルは AMQ Streams に含まれており、Prometheus デプロイメントで使用できます。
アラートルールの定義に関する一般的な留意点:
-
forプロパティーはルールと併用され、アラートがトリガーされる前に条件が維持されなければならない期間を決定します。 -
ティック (tick) は ZooKeeper の基本的な時間単位です。ミリ秒単位で測定され、
Kafka.spec.zookeeper.configのtickTimeパラメーターを使用して設定されます。たとえば、ZooKeeper でtickTime=3000の場合、3 ティック (3 x 3000) は 9000 ミリ秒と等しくなります。 -
ZookeeperRunningOutOfSpaceメトリクスおよびアラートを利用できるかどうかは、使用される OpenShift 設定およびストレージ実装によります。特定のプラットフォームのストレージ実装では、メトリクスによるアラートの提供に必要な利用可能な領域について情報が提供されない場合があります。
Kafka アラートルール
UnderReplicatedPartitions-
現在のブローカーがリードレプリカでありながら、パーティションのトピックに設定された
min.insync.replicasよりも複製数が少ないパーティションの数が示されます。このメトリクスにより、フォロワーレプリカをホストするブローカーの詳細が提供されます。リーダーからこれらのフォロワーへの複製が追い付いていません。その理由として、現在または過去にオフライン状態になっていたり、過剰なスロットリングが適用されたブローカー間の複製であることが考えられます。この値がゼロより大きい場合にアラートが発生し、複製の数が最低数未満であるパーティションの情報がブローカー別に通知されます。 AbnormalControllerState- 現在のブローカーがクラスターのコントローラーであるかどうかを示します。メトリクスは 0 または 1 です。クラスターのライフサイクルでは、1 つのブローカーのみかコントローラーとなるはずで、クラスターには常にアクティブなコントローラーが存在する必要があります。複数のブローカーがコントローラーであることが示される場合は問題になります。そのような状態が続くと、すべてのブローカーのこのメトリクスの合計値が 1 でない場合にアラートが発生します。合計値が 0 であればアクティブなコントローラーがなく、合計値が 1 を超えればコントローラーが複数あることを意味します。
UnderMinIsrPartitionCount-
書き込み操作の完了を通知しなければならないリード Kafka ブローカーの ISR (In-Sync レプリカ) が最小数 (
min.insync.replicasを使用して指定) に達していないことを示します。このメトリクスでは、ブローカーがリードし、In-Sync レプリカの数が最小数に達していない、パーティションの数が定義されます。この値がゼロより大きい場合にアラートが発生し、完了通知 (ack) が最少数未満であった各ブローカーのパーティション数に関する情報が提供されます。 OfflineLogDirectoryCount- ハードウェア障害などの理由によりオフライン状態であるログディレクトリーの数を示します。そのため、ブローカーは受信メッセージを保存できません。この値がゼロより大きい場合にアラートが発生し、各ブローカーのオフライン状態であるログディレクトリーの数に関する情報が提供されます。
KafkaRunningOutOfSpace-
データの書き込みに使用できる残りのディスク容量を示します。この値が 5GiB 未満になるとアラートが発生し、永続ボリューム要求 (Persistent Volume Claim、PVC) ごとに容量不足のディスクに関する情報が提供されます。しきい値は
prometheus-rules.yamlで変更できます。
ZooKeeper アラートルール
AvgRequestLatency- サーバーがクライアントリクエストに応答するまでの時間を示します。この値が 10 (tick) を超えるとアラートが発生し、各サーバーの平均リクエストレイテンシーの実際の値が通知されます。
OutstandingRequests- サーバーでキューに置かれたリクエストの数を示します。この値は、サーバーが処理能力を超えるリクエストを受信すると上昇します。この値が 10 よりも大きい場合にアラートが発生し、各サーバーの未処理のリクエスト数が通知されます。
ZookeeperRunningOutOfSpace- このメトリクスは、ZooKeeper へのデータ書き込みに使用できる残りのディスク容量を示します。この値が 5GiB 未満になるとアラートが発生し、永続ボリューム要求 (Persistent Volume Claim、PVC) ごとに容量不足のディスクに関する情報が提供されます。
7.4.3.4. Alertmanager のデプロイメント
Alertmanager をデプロイするには、設定ファイルのサンプルを適用します。
AMQ Streams に含まれる設定サンプルでは、Slack チャネルに通知を送信するように Alertmanager を設定します。
デプロイメントで以下のリソースが定義されます。
-
Alertmanager。Alertmanager Pod を管理します。 -
Secret。Alertmanager の設定を管理します。 -
Service。参照しやすいホスト名を提供し、他のサービスが Alertmanager に接続できるようにします (Prometheus など)。
手順
Alertmanager 設定ファイル (
examples/metrics/prometheus-alertmanager-configディレクトリーのalert-manager-config.yaml) からSecretリソースを作成します。oc apply -f alert-manager-config.yaml
alert-manager-config.yamlファイルを更新し、以下を行います。-
slack_api_urlプロパティーを、Slack ワークスペースのアプリケーションに関連する Slack API URL の実際の値に置き換えます。 -
channelプロパティーを、通知が送信される実際の Slack チャネルに置き換えます。
-
Alertmanager をデプロイします。
oc apply -f alert-manager.yaml
7.4.4. Grafana の設定
Grafana では、Prometheus メトリクスを視覚化できます。
AMQ Streams で提供される Grafana ダッシュボードサンプルをデプロイして有効化できます。
7.4.4.1. Grafana のデプロイメント
Prometheus メトリクスを視覚化するには、独自の Grafana インストールを使用するか、examples/metrics ディレクトリーにある grafana.yaml ファイルを適用して Grafana をデプロイすることができます。
前提条件
手順
Grafana をデプロイします。
oc apply -f grafana.yaml
- Grafana ダッシュボードを有効にします。
7.4.4.2. Grafana ダッシュボードサンプルの有効化
AMQ Streams には、Grafana のダッシュボード設定ファイルのサンプル が含まれています。ダッシュボードのサンプルは、examples/metrics/grafana-dashboards ディレクトリーの以下の JSON ファイルで提供されます。
-
strimzi-kafka.json -
strimzi-zookeeper.json -
strimzi-operators.json -
strimzi-kafka-connect.json -
strimzi-kafka-mirror-maker-2.json -
strimzi-kafka-bridge.json -
strimzi-cruise-control.json -
strimzi-kafka-exporter.json
ダッシュボードのサンプルは、主なメトリクスの監視を開始するための雛形として使用できますが、使用できるすべてのメトリックスを対象としていません。使用するインフラストラクチャーに応じて、ダッシュボードのサンプルの編集や、他のメトリクスの追加を行うことができます。
Prometheus および Grafana の設定後に、Grafana ダッシュボードで AMQ Streams データを可視化できます。
アラート通知ルールは定義されていません。
ダッシュボードにアクセスする場合、port-forward コマンドを使用して Grafana Pod からホストにトラフィックを転送できます。
Grafana Pod の名前はユーザーごとに異なります。
手順
Grafana サービスの詳細を取得します。
oc get service grafana
以下に例を示します。
NAME TYPE CLUSTER-IP PORT(S) grafana
ClusterIP
172.30.123.40
3000/TCP
ポート転送用のポート番号を書き留めておきます。
port-forwardを使用して、Grafana ユーザーインターフェースをlocalhost:3000にリダイレクトします。oc port-forward svc/grafana 3000:3000
Web ブラウザーで
http://localhost:3000を指定します。Grafana のログインページが表示されます。
ユーザー名とパスワードを入力し、続いて Log In をクリックします。
デフォルトの Grafana ユーザー名およびパスワードは、どちらも
adminです。初回ログイン後に、パスワードを変更できます。Prometheus を データソース として追加します。
- 名前を指定します。
- Prometheus をタイプとして追加します。
Prometheus サーバーの URL (http://prometheus-operated:9090) を指定します。
詳細を追加したら、保存して接続をテストします。

- Dashboards → Import から、ダッシュボードのサンプルをアップロードするか、JSON を直接貼り付けます。
上部のヘッダーでダッシュボードのドロップダウンメニューをクリックし、表示するダッシュボードを選択します。
Prometheus サーバーが AMQ Streams クラスターのメトリクスを収集すると、それがダッシュボードに反映されます。
図7.1 ダッシュボードの選択オプション

- AMQ Streams Kafka
以下のメトリクスを表示します。
- オンラインのブローカーの数
- クラスター内のアクティブなコントローラーの数
- 非同期レプリカがリーダーに選択される割合
- オンラインのレプリカ
- 複製の数が最低数未満であるパーティションの数
- 最小の In-Sync レプリカ数にあるパーティション
- 最小の In-Sync レプリカ数未満のパーティション
- アクティブなリーダーを持たないため、書き込みや読み取りができないパーティション
- Kafka ブローカー Pod のメモリー使用量
- 集約された Kafka ブローカー Pod の CPU 使用率
- Kafka ブローカー Pod のディスク使用量
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- JVM ガベージコレクションの数
- 受信バイトレートの合計
- 送信バイトレートの合計
- 受信メッセージレート
- 生成要求レートの合計
- バイトレート
- 生成要求レート
- 取得要求レート
- ネットワークプロセッサーの平均時間アイドル率
- リクエストハンドラーの平均時間アイドル率
ログサイズ
図7.2 AMQ Streams Kafka ダッシュボード

- AMQ Streams ZooKeeper
以下のメトリクスを表示します。
- ZooKeeper アンサンブルのクォーラムサイズ
- アクティブな 接続の数
- サーバーのキューに置かれたリクエストの数
- ウォッチャーの数
- ZooKeeper Pod のメモリー使用量
- 集約された ZooKeeper Pod の CPU 使用率
- ZooKeeper Pod のディスク使用量
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- JVM ガベージコレクションの数
- サーバーがクライアントリクエストに応答するまでの時間 (最大、最小、および平均)
- AMQ Streams の Operator
以下のメトリクスを表示します。
- カスタムリソース
- 1 時間あたりの成功したカスタムリソース調整の数
- 1 時間あたりの失敗したカスタムリソース調整の数
- 1 時間あたりのロックなしの調整の数
- 1 時間あたりの開始された調整の数
- 1 時間あたりの定期的な調整の数
- 最大の調整時間
- 平均の調整時間
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- JVM ガベージコレクションの数
- AMQ Streams Kafka Connect
以下のメトリクスを表示します。
- 受信バイトレートの合計
- 送信バイトレートの合計
- ディスク使用量
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- AMQ Streams Kafka MirrorMaker 2
以下のメトリクスを表示します。
- コネクターの数
- タスクの数
- 受信バイトレートの合計
- 送信バイトレートの合計
- ディスク使用量
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- AMQ Streams Kafka Bridge
- 「Kafka Bridge の監視」 を参照してください。
- AMQ Streams Cruise Control
- 「Cruise Control の監視」 を参照してください。
- AMQ Streams Kafka Exporter
- 「Kafka Exporter Grafana ダッシュボードの有効化」 を参照してください。
7.5. Kafka Exporter の追加
Kafka Exporter は、Apache Kafka ブローカーおよびクライアントの監視を強化するオープンソースプロジェクトです。Kafka Exporter は、Kafka クラスターとのデプロイメントを実現するために AMQ Streams で提供され、オフセット、コンシューマーグループ、コンシューマーラグ、およびトピックに関連する Kafka ブローカーから追加のメトリクスデータを抽出します。
一例として、メトリクスデータを使用すると、低速なコンシューマーの識別に役立ちます。
ラグデータは Prometheus メトリクスとして公開され、解析のために Grafana で使用できます。
ビルトイン Kafka メトリクスの監視のために Prometheus および Grafana をすでに使用している場合、Kafka Exporter Prometheus エンドポイントをスクレープするように Prometheus を設定することもできます。
AMQ Streams の examples/metrics/grafana-dashboards/strimzi-kafka-exporter.json には、Kafka Exporter ダッシュボードのサンプルが含まれています。
7.5.1. コンシューマーラグの監視
コンシューマーラグは、メッセージの生成と消費の差を示しています。具体的には、指定のコンシューマーグループのコンシューマーラグは、パーティションの最後のメッセージと、そのコンシューマーが現在ピックアップしているメッセージとの時間差を示しています。
ラグには、パーティションログの最後を基準とする、コンシューマーオフセットの相対的な位置が反映されます。
プロデューサーおよびコンシューマーオフセット間のコンシューマーラグ
この差は、Kafka ブローカートピックパーティションの読み取りと書き込みの場所である、プロデューサーオフセットとコンシューマーオフセットの間の デルタ とも呼ばれます。
あるトピックで毎秒 100 個のメッセージがストリーミングされる場合を考えてみましょう。プロデューサーオフセット (トピックパーティションの先頭) と、コンシューマーが読み取った最後のオフセットとの間のラグが 1000 個のメッセージであれば、10 秒の遅延があることを意味します。
コンシューマーラグ監視の重要性
可能な限りリアルタイムのデータの処理に依存するアプリケーションでは、コンシューマーラグを監視して、ラグが過度に大きくならないようにチェックする必要があります。ラグが大きくなるほど、リアルタイム処理の達成から遠ざかります。
たとえば、パージされていない古いデータの大量消費や、予定外のシャットダウンが、コンシューマーラグの原因となることがあります。
コンシューマーラグの削減
通常、ラグを削減するには以下を行います。
- 新規コンシューマーを追加してコンシューマーグループをスケールアップします。
- メッセージがトピックに留まる保持時間を延長します。
- ディスク容量を追加してメッセージバッファーを増強します。
コンシューマーラグを減らす方法は、基礎となるインフラストラクチャーや、AMQ Streams によりサポートされるユースケースによって異なります。たとえば、ラグが生じているコンシューマーの場合、ディスクキャッシュからフェッチリクエストに対応できるブローカーを活用できる可能性は低いでしょう。場合によっては、コンシューマーの状態が改善されるまで、自動的にメッセージをドロップすることが許容されることがあります。
7.5.2. Kafka Exporter アラートルールの例
メトリクスをデプロイメントに導入するステップが実行済みである場合、Kafka Exporter をサポートするアラート通知ルールを使用するよう Kafka クラスターがすでに設定された状態になっています。
Kafka Exporter のルールは prometheus-rules.yaml に定義されており、Prometheus でデプロイされます。詳細は、「Prometheus」を参照してください。
Kafka Exporter に固有のサンプルのアラート通知ルールには以下があります。
UnderReplicatedPartition- トピックで複製の数が最低数未満であり、ブローカーがパーティションで十分な複製を作成していないことを警告するアラートです。デフォルトの設定では、トピックに複製の数が最低数未満のパーティションが 1 つ以上ある場合のアラートになります。このアラートは、Kafka インスタンスがダウンしているか Kafka クラスターがオーバーロードの状態であることを示す場合があります。レプリケーションプロセスを再起動するには、Kafka ブローカーの計画的な再起動が必要な場合があります。
TooLargeConsumerGroupLag- 特定のトピックパーティションでコンシューマーグループのラグが大きすぎることを警告するアラートです。デフォルト設定は 1000 レコードです。ラグが大きい場合、コンシューマーが遅すぎてプロデューサーの処理に追い付いてない可能性があります。
NoMessageForTooLong- トピックが一定期間にわたりメッセージを受信していないことを警告するアラートです。この期間のデフォルト設定は 10 分です。この遅れは、設定の問題により、プロデューサーがトピックにメッセージを公開できないことが原因である可能性があります。
これらのルールのデフォルト設定は、特定のニーズに合わせて調整してください。
7.5.3. Kafka Exporter メトリクスの公開
ラグ情報は、Grafana で示す Prometheus メトリクスとして Kafka Exporter によって公開されます。
Kafka Exporter は、ブローカー、トピック、およびコンシューマーグループのメトリクスデータを公開します。これらのメトリクスは、strimzi-kafka-exporter ダッシュボードのサンプルに表示されます。
抽出されるデータを以下に示します。
表7.2 ブローカーメトリクスの出力
| 名前 | 詳細 |
|---|---|
|
| Kafka クラスターに含まれるブローカーの数 |
表7.3 トピックメトリクスの出力
| 名前 | 詳細 |
|---|---|
|
| トピックのパーティション数 |
|
| ブローカーの現在のトピックパーティションオフセット |
|
| ブローカーの最も古いトピックパーティションオフセット |
|
| トピックパーティションの In-Sync レプリカ数 |
|
| トピックパーティションのリーダーブローカー ID |
|
|
トピックパーティションが優先ブローカーを使用している場合は、 |
|
| このトピックパーティションのレプリカ数 |
|
|
トピックパーティションの複製の数が最低数未満である場合に |
表7.4 コンシューマーグループメトリクスの出力
| 名前 | 詳細 |
|---|---|
|
| コンシューマーグループの現在のトピックパーティションオフセット |
|
| トピックパーティションのコンシューマーグループの現在のラグ (概算値) |
1 つ以上のコンシューマーグループにゼロよりも大きいラグがある場合、コンシューマーグループメトリクスは Kafka Exporter ダッシュボードのみに表示されます。
7.5.4. Kafka Exporter の設定
この手順では、KafkaExporter プロパティーから Kafka リソースの Kafka Exporter を設定する方法を説明します。
Kafka リソースの設定に関する詳細は、『AMQ Streams on OpenShift の使用』の「Kafka クラスターの設定」を参照してください。
この手順では、Kafka Exporter 設定に関連するプロパティーを取り上げます。
これらのプロパティーは、Kafka クラスターのデプロイメントまたは再デプロイメントの一部として設定できます。
前提条件
- OpenShift クラスター。
- 稼働中の Cluster Operator。
手順
KafkaリソースのKafkaExporterプロパティーを編集します。設定可能なプロパティーは以下の例のとおりです。
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: # ... kafkaExporter: image: my-registry.io/my-org/my-exporter-cluster:latest 1 groupRegex: ".*" 2 topicRegex: ".*" 3 resources: 4 requests: cpu: 200m memory: 64Mi limits: cpu: 500m memory: 128Mi logging: debug 5 enableSaramaLogging: true 6 template: 7 pod: metadata: labels: label1: value1 imagePullSecrets: - name: my-docker-credentials securityContext: runAsUser: 1000001 fsGroup: 0 terminationGracePeriodSeconds: 120 readinessProbe: 8 initialDelaySeconds: 15 timeoutSeconds: 5 livenessProbe: 9 initialDelaySeconds: 15 timeoutSeconds: 5 # ...リソースを作成または更新します。
oc apply -f kafka.yaml
次のステップ
Kafka Exporter の設定およびデプロイ後に、Grafana を有効にして Kafka Exporter ダッシュボードを表示できます。
その他のリソース
7.5.5. Kafka Exporter Grafana ダッシュボードの有効化
AMQ Streams には、Grafana のダッシュボード設定ファイルのサンプル が含まれています。Kafka Exporter ダッシュボードは、JSON ファイルとして提供され、examples/metrics ディレクトリーに含まれています。
-
strimzi-kafka-exporter.json
Kafka Exporter を Kafka クラスターでデプロイした場合、公開されるメトリクスデータを Grafana ダッシュボードで可視化できます。
前提条件
この手順では、Grafana ユーザーインターフェースにアクセスでき、Prometheus がデータソースとして追加されていることを前提とします。ユーザーインターフェースに初めてアクセスする場合は、「Grafana」を参照してください。
手順
- Grafana ユーザーインターフェースにアクセスします。
Strimzi Kafka Exporter ダッシュボードを選択します。
メトリクスデータが収集されると、Kafka Exporter のチャートにデータが反映されます。
- AMQ Streams Kafka Exporter
以下のメトリクスを表示します。
- トピックの数
- パーティションの数
- レプリカの数
- In-Sync レプリカの数
- 複製の数が最低数未満であるパーティションの数
- 最小の In-Sync レプリカ数にあるパーティション
- 最小の In-Sync レプリカ数未満のパーティション
- 優先ノードにないパーティション
- 毎秒のトピックからのメッセージ
- 毎秒消費されるトピックからのメッセージ
- コンシューマーグループごとに毎分消費されるメッセージ
- コンシューマーグループごとのラグ
- パーティションの数
- 最新のオフセット
- 最も古いオフセット
Grafana のチャートを使用して、ラグを分析し、ラグ削減の方法が対象のコンシューマーグループに影響しているかどうかを確認します。たとえば、ラグを減らすように Kafka ブローカーを調整すると、ダッシュボードには コンシューマーグループごとのラグ のチャートが下降し 毎分のメッセージ消費 のチャートが上昇する状況が示されます。
7.6. Kafka Bridge の監視
ビルトイン Kafka メトリクスの監視のために Prometheus および Grafana をすでに使用している場合、Kafka Bridge Prometheus エンドポイントをスクレープするように Prometheus を設定することもできます。
Kafka Bridge の Grafana ダッシュボードのサンプルは以下を提供します。
- さまざまなエンドポイントへの HTTP 接続および関連リクエストに関する情報
- ブリッジによって使用される Kafka コンシューマーおよびプロデューサーに関する情報
- ブリッジ自体からの JVM メトリクス
7.6.1. Kafka Bridge の設定
KafkaBridge リソースの enableMetrics プロパティーを使用して、Kafka Bridge メトリクスを有効にできます。
このプロパティーは、Kafka Bridge のデプロイメントまたは再デプロイメントの一部として設定できます。
以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaBridge
metadata:
name: my-bridge
spec:
# ...
bootstrapServers: my-cluster-kafka:9092
http:
# ...
enableMetrics: true
# ...7.6.2. Kafka Bridge Grafana ダッシュボードの有効化
Kafka Bridge を Kafka クラスターでデプロイした場合、Grafana により公開されるメトリクスデータを表示するように Grafana を有効化できます。
Kafka Bridge ダッシュボードは、JSON ファイルとして提供され、examples/metrics ディレクトリーに含まれています。
-
strimzi-kafka-bridge.json
メトリクスデータが収集されると、Kafka Bridge のチャートにデータが反映されます。
- Kafka Bridge
以下のメトリクスを表示します。
- Kafka Bridge への HTTP 接続の数
- 処理中の HTTP リクエストの数
- HTTP メソッドごとに 1 秒あたり処理されるリクエスト
- レスポンスコード (2XX、4XX、5XX) ごとの要求レートの合計
- 1 秒あたりの受信および送信バイト数
- Kafka Bridge エンドポイントごとのリクエスト
- Kafka Bridge 自体によって使用される Kafka コンシューマー、プロデューサー、および関連するオープン接続の数
Kafka プロデューサー:
- 1 秒あたり送信される平均のレコード数 (トピックごとにグループ化)
- 1 秒あたりすべてのブローカーに送信される発信バイト数 (トピックごとにグループ化)
- エラーとなったレコードの 1 秒あたりの平均数 (トピックごとにグループ化)
Kafka コンシューマー:
- 1 秒あたり消費される平均のレコード数 (clientId-topic ごとにグループ化)
- 1 秒あたり消費される平均のバイト数 (clientId-topic ごとにグループ化)
- 割り当てられるパーティション (clientId ごとにグループ化)
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- JVM ガベージコレクションの数
7.7. Cruise Control の監視
ビルトイン Kafka メトリクスの監視のために Prometheus および Grafana をすでに使用している場合、Cruise Control Prometheus エンドポイントをスクレープするように Prometheus を設定することもできます。
Cruise Control の Grafana ダッシュボードのサンプルは以下を提供します。
- 最適化プロポーザルの計算、ゴールの逸脱、クラスターのバランス状況などに関する情報
- リバランスプロポーザルおよび実際のリバランス操作の REST API コールに関する情報
- Cruise Control 自体からの JVM メトリクス
7.7.1. Cruise Control の設定
Kafka リソースの cruiseControl.metricsConfig プロパティーを使用して Cruise Control メトリクスを有効にし、公開するメトリクスの JMX エクスポーター設定が含まれる ConfigMap への参照を提供します。
以下に例を示します。
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
name: my-cluster
spec:
# ...
kafka:
# ...
zookeeper:
# ...
cruiseControl:
metricsConfig:
type: jmxPrometheusExporter
valueFrom:
configMapKeyRef:
name: my-config-map
key: my-key7.7.2. Cruise Control Grafana ダッシュボードの有効化
メトリクスを有効にして Cruise Control を Kafka クラスターでデプロイした場合、Grafana により公開されるメトリクスデータを表示するように Grafana を有効化できます。
Cruise Control ダッシュボードは、JSON ファイルとして提供され、examples/metrics ディレクトリーに含まれています。
-
strimzi-cruise-control.json
メトリクスデータが収集されると、Cruise Control のチャートにデータが反映されます。
- Cruise Control
以下のメトリクスを表示します。
- Cruise Control によって監視されるスナップショットウィンドウの数
- 最適化プロポーザルを計算するのに十分なサンプルが含まれるため、有効とみなされる時間枠の数
- プロポーザルまたはリバランスのために実施中の実行の数
- Cruise Control の異常検出コンポーネントによって計算された (デフォルトでは 5 分ごと) Kafka クラスターの現在のバランス状態スコア
- 監視されるパーティションの割合
- 異常検出によって報告された (デフォルトでは 5 分ごと) ゴール逸脱の数
- ブローカーでディスクの読み取り障害が発生する頻度
- メトリクスサンプルの取得に失敗する割合
- 最適化プロポーザルの計算に必要な時間
- クラスターモデルの作成に必要な時間
- Cruise Control の REST API 経由でプロポーザルリクエストまたは実際のリバランスリクエストが実行される頻度
- Cruise Control の REST API 経由でクラスター全体の状態およびユーザータスクの状態が要求される頻度
- 使用されている JVM メモリー
- JVM ガベージコレクションの時間
- JVM ガベージコレクションの数