第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 の使用』の「分散トレーシング」を参照してください。

その他のリソース

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

kafka-metrics.yaml

Kafka Connect

KafkaConnect および KafkaConnectS2I

kafka-connect-metrics.yaml

Kafka MirrorMaker 2.0

KafkaMirrorMaker2

kafka-mirror-maker-2-metrics.yaml

Kafka Bridge

KafkaBridge

kafka-bridge-metrics.yaml

Cruise Control

Kafka

kafka-cruise-control-metrics.yaml

その他のリソース

7.2. Prometheus メトリクス設定のデプロイ

AMQ Streams では、再ラベル付けルールが含まれる カスタムリソース設定用の YAML ファイルのサンプル が提供されます。

再ラベル付けルールのメトリクス設定を適用するには、以下のいずれかを行います。

7.2.1. Prometheus メトリクス設定のカスタムリソースへのコピー

Grafana ダッシュボードを監視に使用するには、メトリクス設定サンプルをカスタムリソースにコピーします。

以下の手順では、Kafka リソースを更新しますが、モニタリングをサポートするすべてのコンポーネントについて手順は同じです。

手順

デプロイメントの Kafka リソースごとに以下の手順を実行します。

  1. エディターで Kafka リソースを更新します。

    oc edit kafka KAFKA-CONFIG-FILE
  2. kafka-metrics.yaml の設定例を、ユーザーの Kafka リソース定義にコピーします。
  3. ファイルを保存し、更新したリソースが調整されるのを待ちます。

7.2.2. Prometheus メトリクス設定での Kafka クラスターのデプロイメント

Grafana ダッシュボードを監視に使用するには、メトリクス設定でサンプル Kafka クラスターをデプロイできます。

以下の手順では、Kafka リソース用に、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 は、サポートされる最小バージョンです。

前提条件

手順の概要

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 のアラートルールのサンプルをデプロイします。

前提条件

手順

  1. ユーザー定義プロジェクトのモニタリングが有効であることを確認します。

    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 メトリクスおよびダッシュボードの表示」 の前提条件を参照してください。

  2. 複数の 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)。
  3. strimzi-pod-monitor.yaml ファイルを、Kafka クラスターが稼働しているプロジェクトにデプロイします。

    oc apply -f strimzi-pod-monitor.yaml -n MY-PROJECT
  4. Prometheus ルールのサンプルを同じプロジェクトにデプロイします。

    oc apply -f prometheus-rules.yaml -n MY-PROJECT

その他のリソース

7.3.2. Grafana のサービスアカウントの作成

注記

OpenShift Container Platform 4.x で AMQ Streams を実行している場合は、この手順を使用します。

AMQ Streams の Grafana インスタンスは、cluster-monitoring-view ロールが割り当てられたサービスアカウントで実行する必要があります。

手順

  1. Grafana の ServiceAccount を作成します。ここでは、リソースの名前は grafana-serviceaccount です。

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: grafana-serviceaccount
      labels:
        app: strimzi
  2. ServiceAccount を Kafka クラスターが含まれるプロジェクトにデプロイします。

    oc apply -f GRAFANA-SERVICEACCOUNT -n MY-PROJECT
  3. cluster-monitoring-view ロールを Grafana ServiceAccount に割り当てる 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
    プロジェクトの名前。
  4. 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 アプリケーションをデプロイします。

手順

  1. Grafana ServiceAccount のアクセストークンを取得します。

    oc serviceaccounts get-token grafana-serviceaccount -n MY-PROJECT

    次のステップで使用するアクセストークンをコピーします。

  2. 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: Grafana ServiceAccount のアクセストークンの値
  3. grafana-config ファイルから datasource.yaml という名前の Config Map を作成します。

    oc create configmap grafana-config --from-file=datasource.yaml -n MY-PROJECT
  4. Deployment および Service で構成される Grafana アプリケーションを作成します。

    grafana-config Config 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: ClusterIP
  5. Grafana アプリケーションを、Kafka クラスターが含まれるプロジェクトにデプロイします。

    oc apply -f GRAFANA-APPLICATION -n MY-PROJECT

その他のリソース

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 ダッシュボードのサンプルをインポートします。

手順

  1. Grafana サービスへのルートの詳細を取得します。以下に例を示します。

    oc get routes
    
    NAME               HOST/PORT                         PATH  SERVICES
    MY-GRAFANA-ROUTE   MY-GRAFANA-ROUTE-amq-streams.net        grafana
  2. Web ブラウザーで、Route ホストおよびポートの URL を使用して Grafana ログイン画面にアクセスします。
  3. ユーザー名とパスワードを入力し、続いて Log In をクリックします。

    デフォルトの Grafana ユーザー名およびパスワードは、どちらも admin です。初回ログイン後に、パスワードを変更できます。

  4. Configuration > Data Sources で、Prometheus データソースが作成済みであることを確認します。データソースは 「Prometheus データソースを使用した Grafana のデプロイ」 に作成されています。
  5. Dashboards > Manage をクリックしてから Import をクリックします。
  6. examples/metrics/grafana-dashboards で、インポートするダッシュボードの JSON をコピーします。
  7. JSON をテキストボックスに貼り付け、Load をクリックします。
  8. 他の 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 が実行されます。
  • ClusterRoleBindingClusterRoleServiceAccount にバインドします。
  • 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 インスタンスが検出されます。

前提条件

手順

  1. Prometheus のインストール先となる namespace に従い、Prometheus インストールファイル (prometheus.yaml) を変更します。

    Linux の場合は、以下を使用します。

    sed -i 's/namespace: .*/namespace: my-namespace/' prometheus.yaml

    MacOS の場合は、以下を使用します。

    sed -i '' 's/namespace: .*/namespace: my-namespace/' prometheus.yaml
  2. PodMonitor リソースを strimzi-pod-monitor.yaml で編集し、Pod からメトリクスデータをスクレープする Prometheus ジョブを定義します。

    namespaceSelector.matchNames プロパティーを、メトリクスのスクレープ元の Pod が実行されている namespace で更新します。

    PodMonitor は、Apache Kafka、ZooKeeper、Operator、Kafka Bridge、および Cruise Control 用 Pod から直接データをスクレープするのに使用されます。

  3. prometheus.yaml インストールファイルを編集し、ノードから直接メトリクスをスクレープするための追加設定を含めます。

    提供される Grafana ダッシュボードが表示する CPU、メモリー、およびディスクボリュームの使用状況についてのメトリクスは、ノード上の OpenShift cAdvisor エージェントおよび kubelet から直接提供されます。

    1. 設定ファイル (examples/metrics/prometheus-additional-properties ディレクトリーの prometheus-additional.yaml) から Secret リソースを作成します。

      oc apply -f prometheus-additional.yaml
    2. prometheus.yaml ファイルで additionalScrapeConfigs プロパティーを編集し、Secret の名前および prometheus-additional.yaml ファイルを追加します。
  4. 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.configtickTime パラメーターを使用して設定されます。たとえば、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 など)。

手順

  1. Alertmanager 設定ファイル (examples/metrics/prometheus-alertmanager-config ディレクトリーの alert-manager-config.yaml) から Secret リソースを作成します。

    oc apply -f alert-manager-config.yaml
  2. alert-manager-config.yaml ファイルを更新し、以下を行います。

    • slack_api_url プロパティーを、Slack ワークスペースのアプリケーションに関連する Slack API URL の実際の値に置き換えます。
    • channel プロパティーを、通知が送信される実際の Slack チャネルに置き換えます。
  3. 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 をデプロイすることができます。

手順

  1. Grafana をデプロイします。

    oc apply -f grafana.yaml
  2. 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 の名前はユーザーごとに異なります。

手順

  1. Grafana サービスの詳細を取得します。

    oc get service grafana

    以下に例を示します。

    NAMETYPECLUSTER-IPPORT(S)

    grafana

    ClusterIP

    172.30.123.40

    3000/TCP

    ポート転送用のポート番号を書き留めておきます。

  2. port-forward を使用して、Grafana ユーザーインターフェースを localhost:3000 にリダイレクトします。

    oc port-forward svc/grafana 3000:3000
  3. Web ブラウザーで http://localhost:3000 を指定します。

    Grafana のログインページが表示されます。

  4. ユーザー名とパスワードを入力し、続いて Log In をクリックします。

    デフォルトの Grafana ユーザー名およびパスワードは、どちらも admin です。初回ログイン後に、パスワードを変更できます。

  5. Prometheus を データソース として追加します。

    • 名前を指定します。
    • Prometheus をタイプとして追加します。
    • Prometheus サーバーの URL (http://prometheus-operated:9090) を指定します。

      詳細を追加したら、保存して接続をテストします。

      Add Prometheus data source
  6. Dashboards Import から、ダッシュボードのサンプルをアップロードするか、JSON を直接貼り付けます。
  7. 上部のヘッダーでダッシュボードのドロップダウンメニューをクリックし、表示するダッシュボードを選択します。

    Prometheus サーバーが AMQ Streams クラスターのメトリクスを収集すると、それがダッシュボードに反映されます。

図7.1 ダッシュボードの選択オプション

AMQ Streams dashboard selection
AMQ Streams Kafka

以下のメトリクスを表示します。

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

    図7.2 AMQ Streams Kafka ダッシュボード

    Kafka dashboard
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. コンシューマーラグの監視

コンシューマーラグは、メッセージの生成と消費の差を示しています。具体的には、指定のコンシューマーグループのコンシューマーラグは、パーティションの最後のメッセージと、そのコンシューマーが現在ピックアップしているメッセージとの時間差を示しています。

ラグには、パーティションログの最後を基準とする、コンシューマーオフセットの相対的な位置が反映されます。

プロデューサーおよびコンシューマーオフセット間のコンシューマーラグ

Consumer lag

この差は、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_brokers

Kafka クラスターに含まれるブローカーの数

表7.3 トピックメトリクスの出力

名前詳細

kafka_topic_partitions

トピックのパーティション数

kafka_topic_partition_current_offset

ブローカーの現在のトピックパーティションオフセット

kafka_topic_partition_oldest_offset

ブローカーの最も古いトピックパーティションオフセット

kafka_topic_partition_in_sync_replica

トピックパーティションの In-Sync レプリカ数

kafka_topic_partition_leader

トピックパーティションのリーダーブローカー ID

kafka_topic_partition_leader_is_preferred

トピックパーティションが優先ブローカーを使用している場合は、1 が示されます。

kafka_topic_partition_replicas

このトピックパーティションのレプリカ数

kafka_topic_partition_under_replicated_partition

トピックパーティションの複製の数が最低数未満である場合に 1 が示されます。

表7.4 コンシューマーグループメトリクスの出力

名前詳細

kafka_consumergroup_current_offset

コンシューマーグループの現在のトピックパーティションオフセット

kafka_consumergroup_lag

トピックパーティションのコンシューマーグループの現在のラグ (概算値)

1 つ以上のコンシューマーグループにゼロよりも大きいラグがある場合、コンシューマーグループメトリクスは Kafka Exporter ダッシュボードのみに表示されます。

7.5.4. Kafka Exporter の設定

この手順では、KafkaExporter プロパティーから Kafka リソースの Kafka Exporter を設定する方法を説明します。

Kafka リソースの設定に関する詳細は、『AMQ Streams on OpenShift の使用』の「Kafka クラスターの設定」を参照してください。

この手順では、Kafka Exporter 設定に関連するプロパティーを取り上げます。

これらのプロパティーは、Kafka クラスターのデプロイメントまたは再デプロイメントの一部として設定できます。

前提条件

  • OpenShift クラスター。
  • 稼働中の Cluster Operator。

手順

  1. 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
    # ...
    1
    2
    メトリクスに含まれるコンシューマーグループを指定する正規表現。
    3
    メトリクスに含まれるトピックを指定する正規表現。
    4
    5
    指定の重大度 (debug、info、warn、error、fatal) 以上でメッセージをログに記録するためのログ設定。
    6
    Sarama ロギングを有効にするブール値 (Kafka Exporter によって使用される Go クライアントライブラリー)。
    7
    8
    9
  2. リソースを作成または更新します。

    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」を参照してください。

手順

  1. Grafana ユーザーインターフェースにアクセスします
  2. 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-key

7.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 ガベージコレクションの数