6.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-config
ConfigMap が存在する必要があります。詳しい情報は、以下の資料を参照してください。- 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 のモニタリングを設定するには、以下の手順を順番に行います。
6.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-PROJECT
Prometheus ルールのサンプルを同じプロジェクトにデプロイします。
oc apply -f prometheus-rules.yaml -n MY-PROJECT
その他のリソース
- OpenShift Container Platform 4.6 の『モニタリング』ガイド。
- 「アラートルールの例」