モニタリング

手順

1. cluster-monitoring-config ConfigMap オブジェクトが存在するかどうかを確認します。

   $ oc -n openshift-monitoring get configmap cluster-monitoring-config

2. ConfigMap オブジェクトが存在しない場合:

   1. 以下の YAML マニフェストを作成します。以下の例では、このファイルは cluster-monitoring-config.yaml という名前です。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: cluster-monitoring-config
        namespace: openshift-monitoring
      data:
        config.yaml: |

   2. 設定を適用して ConfigMap を作成します。

      $ oc apply -f cluster-monitoring-config.yaml

手順

1. user-workload-monitoring-config ConfigMap オブジェクトが存在するかどうかを確認します。

   $ oc -n openshift-user-workload-monitoring get configmap user-workload-monitoring-config

2. user-workload-monitoring-config ConfigMap オブジェクトが存在しない場合:

   1. 以下の YAML マニフェストを作成します。以下の例では、このファイルは user-workload-monitoring-config.yaml という名前です。

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: user-workload-monitoring-config
        namespace: openshift-user-workload-monitoring
      data:
        config.yaml: |

   2. 設定を適用して ConfigMap を作成します。

      $ oc apply -f user-workload-monitoring-config.yaml

      注記

      user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

手順

1. まだの場合は、モニタリングコンポーネントを実行するノードにラベルを追加します。

   $ oc label nodes <node-name> <node-label>

2. ConfigMap オブジェクトを編集します。

   • OpenShift Container Platform のコアプロジェクトをモニターするコンポーネントを移行するには、以下を実行します。

     1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. data/config.yaml でコンポーネントの nodeSelector 制約のノードラベルを指定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              nodeSelector:
                <node-label-1> 2
                <node-label-2> 3
                <...>

        1

        <component> を適切なモニタリングスタックコンポーネント名に置き換えます。

        2

        <node-label-1> をノードに追加したラベルに置き換えます。

        3

        オプション: 追加のラベルを指定します。追加のラベルを指定すると、コンポーネントの Pod は、指定されたすべてのラベルを含むノード上でのみスケジュールされます。

        注記

        nodeSelector の制約を設定した後もモニタリングコンポーネントが Pending 状態のままになっている場合は、Pod イベントでテイントおよび容認に関連するエラーの有無を確認します。

   • ユーザー定義プロジェクトをモニターするコンポーネントを移動するには、以下を実行します。

     1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. data/config.yaml でコンポーネントの nodeSelector 制約のノードラベルを指定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              nodeSelector:
                <node-label-1> 2
                <node-label-2> 3
                <...>

        1

        <component> を適切なモニタリングスタックコンポーネント名に置き換えます。

        2

        <node-label-1> をノードに追加したラベルに置き換えます。

        3

        オプション: 追加のラベルを指定します。追加のラベルを指定すると、コンポーネントの Pod は、指定されたすべてのラベルを含むノード上でのみスケジュールされます。

        注記

        nodeSelector の制約を設定した後もモニタリングコンポーネントが Pending 状態のままになっている場合は、Pod イベントでテイントおよび容認に関連するエラーの有無を確認します。

3. 変更を適用するためにファイルを保存します。新しい設定で指定されたコンポーネントは、新しいノードに自動的に移動されます。

   注記

   user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

   警告

   monitoring config map への変更を保存すると、プロジェクトの Pod およびその他のリソースが再デプロイされる場合があります。そのプロジェクトで実行中のモニタリングプロセスも再起動する場合があります。

手順

1. openshift-monitoring namespace で cluster-monitoring-config ConfigMap オブジェクトを編集します。

   $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

2. 次のサンプルに示すように、enabled: true のキーと値のペアを追加します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       k8sPrometheusAdapter:
         dedicatedServiceMonitors:
           enabled: true 1

   1

   kubelet /metrics/resource エンドポイントを公開する専用サービスモニターをデプロイするには、enabled フィールドの値を true に設定します。

3. ファイルを保存して、変更を自動的に適用します。

   警告

   cluster-monitoring-config 設定マップへの変更を保存すると、openshift-monitoring プロジェクトの Pod およびその他のリソースが再デプロイされる場合があります。そのプロジェクトで実行中のモニタリングプロセスも再起動する場合があります。

手順

1. ConfigMap オブジェクトを編集します。

   • OpenShift Container Platform のコアプロジェクトをモニターするコンポーネントの PVC を設定するには、以下を実行します。

     1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. コンポーネントの PVC 設定を data/config.yaml の下に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>:
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class>
                  resources:
                    requests:
                      storage: <amount_of_storage>

        volumeClaimTemplate の指定方法については、PersistentVolumeClaims についての Kubernetes ドキュメント を参照してください。

        以下の例では、OpenShift Container Platform のコアコンポーネントをモニターする Prometheus インスタンスのローカル永続ストレージを要求する PVC を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 40Gi

        上記の例では、ローカルストレージ Operator によって作成されるストレージクラスは local-storage と呼ばれます。

        以下の例では、Alertmanager のローカル永続ストレージを要求する PVC を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 10Gi

   • ユーザー定義プロジェクトをモニターするコンポーネントの PVC を設定するには、以下を実行します。

     1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. コンポーネントの PVC 設定を data/config.yaml の下に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class>
                  resources:
                    requests:
                      storage: <amount_of_storage>

        volumeClaimTemplate の指定方法については、PersistentVolumeClaims についての Kubernetes ドキュメント を参照してください。

        以下の例では、ユーザー定義プロジェクトをモニターする Prometheus インスタンスのローカル永続ストレージを要求する PVC を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 40Gi

        上記の例では、ローカルストレージ Operator によって作成されるストレージクラスは local-storage と呼ばれます。

        以下の例では、Thanos Ruler のローカル永続ストレージを要求する PVC を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 10Gi

        注記

        thanosRuler コンポーネントのストレージ要件は、評価されルールの数や、各ルールが生成するサンプル数により異なります。

2. 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動され、新規ストレージ設定が適用されます。

   注記

   user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

   警告

   変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

手順

1. ConfigMap オブジェクトを編集します。

   • OpenShift Container Platform のコアプロジェクトをモニターするコンポーネントの PVC サイズを変更するには、以下を実行します。

     1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. data/config.yaml の下に、コンポーネントの PVC 設定用の新しいストレージサイズを追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class> 2
                  resources:
                    requests:
                      storage: <amount_of_storage> 3

        1

        コア監視コンポーネントを指定します。

        2

        ストレージクラスを作成します。

        3

        ストレージボリュームの新しいサイズを指定します。

        以下の例では、コア OpenShift Container Platform コンポーネントをモニターする Prometheus インスタンスのローカル永続ストレージを 100 ギガバイトに設定する PVC を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 100Gi

        次の例では、Alertmanager のローカル永続ストレージを 40 ギガバイトに設定する PVC を設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 40Gi

   • ユーザー定義プロジェクトを監視するコンポーネントの PVC のサイズを変更するには:

     注記

     ユーザー定義のプロジェクトを監視する Thanos Ruler および Prometheus インスタンスのボリュームサイズを変更できます。

     1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. data/config.yaml 下の監視コンポーネントの PVC 設定を更新します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              volumeClaimTemplate:
                spec:
                  storageClassName: <storage_class> 2
                  resources:
                    requests:
                      storage: <amount_of_storage> 3

        1

        コア監視コンポーネントを指定します。

        2

        ストレージクラスを作成します。

        3

        ストレージボリュームの新しいサイズを指定します。

        次の例では、ユーザー定義のプロジェクトを監視する Prometheus インスタンスの PVC サイズを 100 ギガバイトに設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 100Gi

        次の例では、Thanos Ruler の PVC サイズを 20 ギガバイトに設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              volumeClaimTemplate:
                spec:
                  storageClassName: local-storage
                  resources:
                    requests:
                      storage: 20Gi

        注記

        thanosRuler コンポーネントのストレージ要件は、評価されルールの数や、各ルールが生成するサンプル数により異なります。

2. 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動します。

   警告

   monitoring config map への変更を保存すると、関連プロジェクトの Pod およびその他のリソースが再デプロイされる場合があります。そのプロジェクトで実行している監視プロセスも再開される可能性があります。

3. 更新されたストレージ要求を使用して、すべての PVC に手動でパッチを適用します。以下の例では、openshift-monitoring namespace の Prometheus コンポーネントのストレージサイズを 100Gi に変更します。

   $ for p in $(oc -n openshift-monitoring get pvc -l app.kubernetes.io/name=prometheus -o jsonpath='{range .items[*]}{.metadata.name} {end}'); do \
     oc -n openshift-monitoring patch pvc/${p} --patch '{"spec": {"resources": {"requests": {"storage":"100Gi"}}}}'; \
     done

4. --cascade=orphan パラメーターを使用して、基になる StatefulSet を削除します。

   $ oc delete statefulset -l app.kubernetes.io/name=prometheus --cascade=orphan

手順

1. ConfigMap オブジェクトを編集します。

   • OpenShift Container Platform のコアプロジェクトをモニターする Prometheus インスタンスの保持時間を変更するには、以下を実行します。

     1. openshift-monitoring プロジェクトで cluster-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-monitoring edit configmap cluster-monitoring-config

     2. 保持期間の設定を data/config.yaml に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: <time_specification>

        <time_specification> を、ms (ミリ秒)、s (秒)、m (分)、h (時間)、d (日)、w (週)、または y (年) が直後に続く数字に置き換えます。

        以下の例では、OpenShift Container Platform のコアコンポーネントをモニターする Prometheus インスタンスの保持期間を 24 時間に設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              retention: 24h

   • ユーザー定義のプロジェクトをモニターする Prometheus インスタンスの保持時間を変更するには、以下を実行します。

     1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

        $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

     2. 保持期間の設定を data/config.yaml に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: <time_specification>

        <time_specification> を、ms (ミリ秒)、s (秒)、m (分)、h (時間)、d (日)、w (週)、または y (年) が直後に続く数字に置き換えます。

        以下の例では、ユーザー定義プロジェクトをモニターする Prometheus インスタンスの保持期間を 24 時間に設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              retention: 24h

2. 変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動されます。

   注記

   user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

   警告

   変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

手順

1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. 保持期間の設定を data/config.yaml に追加します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         retention: <time_specification> 1

   1

   保持時間 は、ms (ミリ秒)、s (秒)、m (分)、h (時)、d (日)、w (週)、y (年) が直後に続く数字で指定します。1h30m15s などの特定の時間に時間値を組み合わせることもできます。デフォルトは 24h です。

   以下の例では、Thanos Ruler データの保持期間を 10 日間に設定します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       thanosRuler:
         retention: 10d

3. 変更を適用するためにファイルを保存します。新規設定が加えられた Pod は自動的に再起動します。

手順

1. openshift-user-workload-monitoring プロジェクトで user-workload-monitoring-config ConfigMap オブジェクトを編集します。

   $ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config

2. enforcedSampleLimit 設定を data/config.yaml に追加し、ユーザー定義プロジェクトのターゲットの収集ごとに受け入れ可能なサンプルの数を制限できます。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         enforcedSampleLimit: 50000 1

   1

   このパラメーターが指定されている場合は、値が必要です。この enforcedSampleLimit の例では、ユーザー定義プロジェクトのターゲット収集ごとに受け入れ可能なサンプル数を 50,000 に制限します。

3. 変更を適用するためにファイルを保存します。制限は自動的に適用されます。

   注記

   user-workload-monitoring-config ConfigMap オブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。

   警告

   変更が user-workload-monitoring-config ConfigMap オブジェクトに保存されると、openshift-user-workload-monitoring プロジェクトの Pod および他のリソースは再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。

手順

1. ターゲットがダウンし、実行されたサンプル制限に近づく際に通知するアラートを指定して YAML ファイルを作成します。この例のファイルは monitoring-stack-alerts.yaml という名前です。

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     labels:
       prometheus: k8s
       role: alert-rules
     name: monitoring-stack-alerts 1
     namespace: ns1 2
   spec:
     groups:
     - name: general.rules
       rules:
       - alert: TargetDown 3
         annotations:
           message: '{{ printf "%.4g" $value }}% of the {{ $labels.job }}/{{ $labels.service
             }} targets in {{ $labels.namespace }} namespace are down.' 4
         expr: 100 * (count(up == 0) BY (job, namespace, service) / count(up) BY (job,
           namespace, service)) > 10
         for: 10m 5
         labels:
           severity: warning 6
       - alert: ApproachingEnforcedSamplesLimit 7
         annotations:
           message: '{{ $labels.container }} container of the {{ $labels.pod }} pod in the {{ $labels.namespace }} namespace consumes {{ $value | humanizePercentage }} of the samples limit budget.' 8
         expr: scrape_samples_scraped/50000 > 0.8 9
         for: 10m 10
         labels:
           severity: warning 11

   1

   アラートルールの名前を定義します。

   2

   アラートルールをデプロイするユーザー定義のプロジェクトを指定します。

   3

   TargetDown アラートは、 for の期間にターゲットを収集できないか、利用できない場合に実行されます。

   4

   TargetDown アラートが実行される場合に出力されるメッセージ。

   5

   アラートが実行される前に、TargetDown アラートの条件がこの期間中 true である必要があります。

   6

   TargetDown アラートの重大度を定義します。

   7

   ApproachingEnforcedSamplesLimit アラートは、指定された for の期間に定義された収集サンプルのしきい値に達するか、この値を上回る場合に実行されます。

   8

   ApproachingEnforcedSamplesLimit アラートの実行時に出力されるメッセージ。

   9

   ApproachingEnforcedSamplesLimit アラートのしきい値。この例では、ターゲット収集ごとのサンプル数が実行されたサンプル制限 50000 の 80% を超えるとアラートが実行されます。アラートが実行される前に、for の期間も経過している必要があります。式 scrape_samples_scraped/<number> > <threshold> の <number> は user-workload-monitoring-config ConfigMap オブジェクトで定義される enforcedSampleLimit 値に一致する必要があります。

   10

   アラートが実行される前に、ApproachingEnforcedSamplesLimit アラートの条件がこの期間中 true である必要があります。

   11

   ApproachingEnforcedSamplesLimit アラートの重大度を定義します。

2. 設定をユーザー定義プロジェクトに適用します。

   $ oc apply -f monitoring-stack-alerts.yaml

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、User Management → Role Bindings → Create Binding に移動します。
2. Binding Typeで、Namespace Role Binding タイプを選択します。
3. Name フィールドに、ロールバインディングの名前を入力します。

4. Namespace フィールドで、アクセスを付与するユーザー定義プロジェクトを選択します。

   重要

   モニタリングロールは、Namespace フィールドで適用するプロジェクトにバインドされます。この手順を使用してユーザーに付与するパーミッションは、選択されたプロジェクトにのみ適用されます。

5. Role Name 一覧で、monitoring-rules-view、 monitoring-rules-edit、または monitoring-edit を選択します。
6. Subject セクションで、User を選択します。
7. Subject Name フィールドにユーザーの名前を入力します。
8. Create を選択して、ロールバインディングを適用します。

手順

1. サービス設定の YAML ファイルを作成します。この例では、prometheus-example-app.yaml という名前です。

2. 以下のデプロイメントおよびサービス設定の詳細をファイルに追加します。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: ns1
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: prometheus-example-app
     name: prometheus-example-app
     namespace: ns1
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: prometheus-example-app
     template:
       metadata:
         labels:
           app: prometheus-example-app
       spec:
         containers:
         - image: ghcr.io/rhobs/prometheus-example-app:0.4.1
           imagePullPolicy: IfNotPresent
           name: prometheus-example-app
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: prometheus-example-app
     name: prometheus-example-app
     namespace: ns1
   spec:
     ports:
     - port: 8080
       protocol: TCP
       targetPort: 8080
       name: web
     selector:
       app: prometheus-example-app
     type: ClusterIP

   この設定は、prometheus-example-app という名前のサービスをユーザー定義の ns1 プロジェクトにデプロイします。このサービスは、カスタム version メトリクスを公開します。

3. 設定をクラスターに適用します。

   $ oc apply -f prometheus-example-app.yaml

   サービスをデプロイするには多少時間がかかります。

4. Pod が実行中であることを確認できます。

   $ oc -n ns1 get pod

   出力例

   NAME                                      READY     STATUS    RESTARTS   AGE
   prometheus-example-app-7857545cb7-sbgwq   1/1       Running   0          81m

手順

1. ServiceMonitor リソース設定の YAML ファイルを作成します。この例では、ファイルは example-app-service-monitor.yaml という名前です。

2. 以下の ServiceMonitor リソース設定の詳細を追加します。

   apiVersion: monitoring.coreos.com/v1
   kind: ServiceMonitor
   metadata:
     labels:
       k8s-app: prometheus-example-monitor
     name: prometheus-example-monitor
     namespace: ns1
   spec:
     endpoints:
     - interval: 30s
       port: web
       scheme: http
     selector:
       matchLabels:
         app: prometheus-example-app

   これは、prometheus-example-app サンプルサービスによって公開されるメトリクスを収集する ServiceMonitor リソースを定義します。これには version メトリクスが含まれます。

   注記

   ユーザー定義の namespace の ServiceMonitor リソースは、同じ namespace のサービスのみを検出できます。つまり、ServiceMonitor リソースの namespaceSelector フィールドは常に無視されます。

3. 設定をクラスターに適用します。

   $ oc apply -f example-app-service-monitor.yaml

   ServiceMonitor をデプロイするのに多少時間がかかります。

4. ServiceMonitor リソースが実行中であることを確認できます。

   $ oc -n ns1 get servicemonitor

   出力例

   NAME                         AGE
   prometheus-example-monitor   81m

手順

1. OpenShift Container Platform Web コンソール内の Administrator パースペクティブで、Observe → Metrics を選択します。
2. Insert Metric at Cursor を選択し、事前に定義されたクエリーの一覧を表示します。
3. カスタムクエリーを作成するには、Prometheus クエリー言語 (PromQL) のクエリーを Expression フィールドに追加します。
4. 複数のクエリーを追加するには、Add Query を選択します。
5. クエリーを削除するには、クエリーの横にある を選択してから Delete query を選択します。
6. クエリーの実行を無効にするには、クエリーの横にある を選択してから Disable query を選択します。

7. Run Queries を選択し、作成したクエリーを実行します。クエリーからのメトリクスはプロットで可視化されます。クエリーが無効な場合は、UI にエラーメッセージが表示されます。

   注記

   大量のデータで動作するクエリーは、時系列グラフの描画時にタイムアウトするか、ブラウザーをオーバーロードする可能性があります。これを回避するには、Hide graph を選択し、メトリックテーブルのみを使用してクエリーを調整します。次に、使用できるクエリーを確認した後に、グラフを描画できるようにプロットを有効にします。

8. オプション: ページ URL には、実行したクエリーが含まれます。このクエリーのセットを再度使用できるようにするには、この URL を保存します。

手順

1. OpenShift Container Platform Web コンソールの Developer パースペクティブから、Observe → Metrics を選択します。
2. Project: 一覧でメトリックで表示するプロジェクトを選択します。

3. Select Query 一覧からクエリーを選択するか、Show PromQL を選択してカスタム PromQL クエリーを実行します。

   注記

   Developer パースペクティブでは、1 度に 1 つのクエリーのみを実行できます。

1. 最初に、有効な全クエリーの全メトリクスがプロットに表示されます。表示されるメトリクスを選択できます。

   注記

   デフォルトでは、クエリーテーブルに、すべてのメトリクスとその現在の値を一覧表示する拡張ビューが表示されます。˅ を選択すると、クエリーの拡張ビューを最小にすることができます。

   • クエリーからすべてのメトリクスを非表示にするには、クエリーの をクリックし、Hide all series をクリックします。
   • 特定のメトリクスを非表示にするには、クエリーテーブルに移動し、メトリクス名の横にある色の付いた四角をクリックします。

2. プロットをズームアップし、時間範囲を変更するには、以下のいずれかを行います。

   • プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。
   • 左上隅のメニューを使用して、時間範囲を選択します。
3. 時間の範囲をリセットするには、Reset Zoom を選択します。
4. 特定の時点のすべてのクエリーの出力を表示するには、その時点のプロットにてマウスのカーソルを保持します。クエリーの出力はポップアップに表示されます。
5. プロットを非表示にするには、Hide Graph を選択します。

1. プロットをズームアップし、時間範囲を変更するには、以下のいずれかを行います。

   • プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。
   • 左上隅のメニューを使用して、時間範囲を選択します。
2. 時間の範囲をリセットするには、Reset Zoom を選択します。
3. 特定の時点のすべてのクエリーの出力を表示するには、その時点のプロットにてマウスのカーソルを保持します。クエリーの出力はポップアップに表示されます。

手順

1. アラートルールの YAML ファイルを作成します。この例では、example-app-alerting-rule.yaml という名前です。

2. アラートルール設定を YAML ファイルに追加します。以下に例を示します。

   注記

   アラートルールの作成時に、同じ名前のルールが別のプロジェクトにある場合に、プロジェクトのラベルがこのアラートルールに対して適用されます。

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     name: example-alert
     namespace: ns1
   spec:
     groups:
     - name: example
       rules:
       - alert: VersionAlert
         expr: version{job="prometheus-example-app"} == 0

   この設定により、example-alert という名前のアラートルールが作成されます。アラートルールは、サンプルサービスによって公開される version メトリクスが 0 になるとアラートを実行します。

   重要

   ユーザー定義のアラートルールには、独自のプロジェクトおよびクラスターメトリクスのメトリクスを含めることができます。別のユーザー定義プロジェクトのメトリクスを含めることはできません。

   たとえば、ユーザー定義プロジェクト ns1 のアラートルールには、ns1 からのメトリックと、CPU やメモリーのメトリックなどのクラスターメトリックを含めることができます。ただし、ルールには ns2 からのメトリクスを含めることはできません。

   さらに、openshift-* コア OpenShift Container Platform プロジェクトのアラートルールは作成できません。デフォルトで OpenShift Container Platform モニタリングはこれらのプロジェクトのアラートルールのセットを提供します。

3. 設定ファイルをクラスターに適用します。

   $ oc apply -f example-app-alerting-rule.yaml

   アラートルールの作成には多少時間がかかります。

手順

1. アラートルールの YAML ファイルを作成します。この例では、example-app-alerting-rule.yaml という名前です。

2. キーが openshift.io/prometheus-rule-evaluation-scope で、値が leaf-prometheus のラベルが含まれる YAML ファイルにアラートルール設定を追加します。以下に例を示します。

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     name: example-alert
     namespace: ns1
     labels:
       openshift.io/prometheus-rule-evaluation-scope: leaf-prometheus
   spec:
     groups:
     - name: example
       rules:
       - alert: VersionAlert
         expr: version{job="prometheus-example-app"} == 0

1. 設定ファイルをクラスターに適用します。

   $ oc apply -f example-app-alerting-rule.yaml

   アラートルールの作成には多少時間がかかります。

手順

1. <project> でアラートルールを一覧表示できます。

   $ oc -n <project> get prometheusrule

2. アラートルールの設定を一覧表示するには、以下を実行します。

   $ oc -n <project> get prometheusrule <rule> -o yaml

手順

1. Administrator パースペクティブで、Observe → Alerting → Alerting Rules に移動します。

2. Filter ドロップダウンメニューで、Platform および User ソースを選択します。

   注記

   Platform ソースはデフォルトで選択されます。

1. OpenShift Container Platform Web コンソールの Observe → Alerting → Silences ページに移動します。
2. Create Silence を選択します。
3. Create Silence フォームで、アラートのスケジュール、期間、およびラベルの詳細を設定します。また、サイレンスのコメントを追加する必要もあります。
4. 直前の手順で入力したラベルセクターに一致するアラートのサイレンスを作成するには、Silence を選択します。

1. Observe → Alerting → Silences ページに移動します。

2. 変更するサイレンスに対して、最後の列の を選択し、Edit silence を選択します。

   または、サイレンスに対して Silence Details ページで Actions → Edit Silence を選択できます。

3. Edit Silence ページで変更を入力し、Silence を選択します。これにより、既存のサイレンスが期限切れとなり、選択された設定でサイレンスが作成されます。

1. Observe → <project_name> → Alerts ページに移動します。
2. アラート名の左側にある > を選択して、アラートの詳細を展開します。拡張されたビューでアラートの名前を選択し、アラートの Alert Details ページを開きます。
3. そのページの Silenced By セクションでサイレンスの名前を選択し、サイレンスの Silence Details ページに移動します。
4. Silence Details ページに移動するサイレンスの名前を選択します。
5. サイレンスについて、Silence Details ページで Actions → Edit Silence を選択します。
6. Edit Silence ページで変更を入力し、Silence を選択します。これにより、既存のサイレンスが期限切れとなり、選択された設定でサイレンスが作成されます。

1. Observe → Alerting → Silences ページに移動します。

2. 変更するサイレンスについて、最後の列の を選択し、Expire silence を選択します。

   または、サイレンスの Silence Details ページで Actions → Expire Silence を選択できます。

1. Observe → <project_name> → Alerts ページに移動します。
2. アラート名の左側にある > を選択して、アラートの詳細を展開します。拡張されたビューでアラートの名前を選択し、アラートの Alert Details ページを開きます。
3. そのページの Silenced By セクションでサイレンスの名前を選択し、サイレンスの Silence Details ページに移動します。
4. Silence Details ページに移動するサイレンスの名前を選択します。
5. サイレンスの Silence Details ページで Actions → Expire Silence を選択します。

手順

1. Administrator パースペクティブで、Administration → Cluster Settings → Configuration → Alertmanager に移動します。

   注記

   または、通知ドロワーで同じページに移動することもできます。OpenShift Container Platform Web コンソールの右上にあるベルのアイコンを選択し、AlertmanagerReceiverNotConfigured アラートで Configure を選択します。

2. ページの Receivers セクションで Create Receiver を選択します。
3. Create Receiver フォームで、Receiver Name を追加し、一覧から Receiver Type を選択します。

4. レシーバー設定を編集します。

   • PagerDuty receiver の場合:

     1. 統合のタイプを選択し、PagerDuty 統合キーを追加します。
     2. PagerDuty インストールの URL を追加します。
     3. クライアントおよびインシデントの詳細または重大度の指定を編集する場合は、Show advanced configuration を選択します。

   • Webhook receiver の場合:

     1. HTTP POST リクエストを送信するエンドポイントを追加します。
     2. デフォルトオプションを編集して解決したアラートを receiver に送信する場合は、Show advanced configuration を選択します。

   • メール receiver の場合:

     1. 通知を送信するメールアドレスを追加します。
     2. SMTP 設定の詳細を追加します。これには、通知の送信先のアドレス、メールの送信に使用する smarthost およびポート番号、SMTP サーバーのホスト名、および認証情報を含む詳細情報が含まれます。
     3. TLS が必要であるかどうかについて選択します。
     4. デフォルトオプションを編集して解決済みのアラートが receiver に送信されないようにしたり、メール通知設定の本体を編集する必要がある場合は、Show advanced configuration を選択します。

   • Slack receiver の場合:

     1. Slack Webhook の URL を追加します。
     2. 通知を送信する Slack チャネルまたはユーザー名を追加します。
     3. デフォルトオプションを編集して解決済みのアラートが receiver に送信されないようにしたり、アイコンおよびユーザー設定を編集する必要がある場合は、Show advanced configuration を選択します。チャネル名とユーザー名を検索し、これらをリンクするかどうかについて選択することもできます。

5. デフォルトでは、実行されるすべてのセレクターに一致するラベルを持つアラートは receiver に送信されます。実行されるアラートのラベルの値を、それらが receiver に送信される前の状態に完全に一致させる必要がある場合は、以下を実行します。

   1. ルーティングラベル名と値をフォームの Routing Labels セクションに追加します。
   2. 正規表現を使用する場合は Regular Expression を選択します。
   3. Add Label を選択して、さらにルーティングラベルを追加します。
6. Create を選択して receiver を作成します。

手順

1. アラートルーティングの YAML ファイルを作成します。この手順の例では、example-app-alert-routing.yaml という名前のファイルを使用します。

2. AlertmanagerConfig YAML 定義をファイルに追加します。以下に例を示します。

   apiVersion: monitoring.coreos.com/v1alpha1
   kind: AlertmanagerConfig
   metadata:
     name: example-routing
     namespace: ns1
   spec:
     route:
       receiver: default
       groupBy: [job]
     receivers:
     - name: default
       webhookConfigs:
       - url: https://example.org/post

   注記

   ユーザー定義のアラートルールの場合、ユーザー定義のルーティングはリソースが定義される namespace に対してスコープ指定されます。たとえば、namespace ns1 の AlertmanagerConfig オブジェクトで定義されるルーティング設定は、同じ namespace の PrometheusRules リソースにのみ適用されます。

3. ファイルを保存します。

4. リソースをクラスターに適用します。

   $ oc apply -f example-app-alert-routing.yaml

   この設定は Alertmanager Pod に自動的に適用されます。

手順

1. Bare Metal Event Relay の namespace を作成します。

   1. 以下の YAML を bare-metal-events-namespace.yaml ファイルに保存します。

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-bare-metal-events
        labels:
          name: openshift-bare-metal-events
          openshift.io/cluster-monitoring: "true"

   2. namespace CR を作成します。

      $ oc create -f bare-metal-events-namespace.yaml

2. Bare Metal Event Relay Operator の Operator グループを作成します。

   1. 以下の YAML を bare-metal-events-operatorgroup.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: bare-metal-event-relay-group
        namespace: openshift-bare-metal-events
      spec:
        targetNamespaces:
        - openshift-bare-metal-events

   2. OperatorGroup CR を作成します。

      $ oc create -f bare-metal-events-operatorgroup.yaml

3. Bare Metal Event Relay にサブスクライブします。

   1. 以下の YAML を bare-metal-events-sub.yaml ファイルに保存します。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bare-metal-event-relay-subscription
        namespace: openshift-bare-metal-events
      spec:
        channel: "stable"
        name: bare-metal-event-relay
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. Subscription CR を作成します。

      $ oc create -f bare-metal-events-sub.yaml

手順

1. OpenShift Container Platform Web コンソールを使用して Bare Metal Event Relay をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
   2. 利用可能な Operator の一覧から Bare Metal Event Relay を選択し、Install をクリックします。
   3. Install Operatorページで、Namespace を選択または作成し、openshift-bare-metal-events を選択して、Install をクリックします。

1. Operators → Installed Operators ページに切り替えます。

2. Status が InstallSucceeded の状態で、Bare Metal Event Relay がプロジェクトに一覧表示されていることを確認します。

   注記

   インストール時に、 Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

手順

1. 以下の curl コマンドを実行して、ノードのハードウェアで Redfish EventService が有効になっていることを確認します。

   curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"

   ここでは、以下のようになります。

   bmc_ip_address

   Redfish イベントが生成される BMC の IP アドレスです。

   出力例

   {
      "@odata.context": "/redfish/v1/$metadata#EventService.EventService",
      "@odata.id": "/redfish/v1/EventService",
      "@odata.type": "#EventService.v1_0_2.EventService",
      "Actions": {
         "#EventService.SubmitTestEvent": {
            "EventType@Redfish.AllowableValues": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
            "target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent"
         }
      },
      "DeliveryRetryAttempts": 3,
      "DeliveryRetryIntervalSeconds": 30,
      "Description": "Event Service represents the properties for the service",
      "EventTypesForSubscription": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
      "EventTypesForSubscription@odata.count": 5,
      "Id": "EventService",
      "Name": "Event Service",
      "ServiceEnabled": true,
      "Status": {
         "Health": "OK",
         "HealthRollup": "OK",
         "State": "Enabled"
      },
      "Subscriptions": {
         "@odata.id": "/redfish/v1/EventService/Subscriptions"
      }
   }

2. 以下のコマンドを実行して、クラスターの Bare Metal Event Relay サービスのルートを取得します。

   $ oc get route -n openshift-bare-metal-events

   出力例

   NAME             HOST/PORT                                                                                           PATH   SERVICES                 PORT   TERMINATION   WILDCARD
   hw-event-proxy   hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com          hw-event-proxy-service   9087   edge          None

3. BMCEventSubscription リソースを作成し、Redfish イベントにサブスクライブします。

   1. 以下の YAML を bmc_sub.yaml ファイルに保存します。

      apiVersion: metal3.io/v1alpha1
      kind: BMCEventSubscription
      metadata:
        name: sub-01
        namespace: openshift-machine-api
      spec:
         hostName: <hostname> 1
         destination: <proxy_service_url> 2
         context: ''

      1

      Redfish イベントが生成されるワーカーノードの名前または UUID を指定します。

      2

      ベアメタルイベントプロキシーサービスを指定します (例: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook)。

   2. BMCEventSubscription CR を作成します。

      $ oc create -f bmc_sub.yaml

4. オプション: BMC イベントサブスクリプションを削除するには、以下のコマンドを実行します。

   $ oc delete -f bmc_sub.yaml

5. オプション:BMCEventSubscription CR を作成せずに Redfish イベントサブスクリプションを手動で作成するには、BMC のユーザー名およびパスワードを指定して以下の curl コマンドを実行します。

   $ curl -i -k -X POST -H "Content-Type: application/json"  -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –v

   ここでは、以下のようになります。

   proxy_service_url

   ベアメタルイベントプロキシーサービスです (例: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook)。

   bmc_ip_address

   Redfish イベントが生成される BMC の IP アドレスです。

   出力例

   HTTP/1.1 201 Created
   Server: AMI MegaRAC Redfish Service
   Location: /redfish/v1/EventService/Subscriptions/1
   Allow: GET, POST
   Access-Control-Allow-Origin: *
   Access-Control-Expose-Headers: X-Auth-Token
   Access-Control-Allow-Headers: X-Auth-Token
   Access-Control-Allow-Credentials: true
   Cache-Control: no-cache, must-revalidate
   Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>; rel=describedby
   Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>
   Link: </redfish/v1/EventService/Subscriptions>; path=
   ETag: "1651135676"
   Content-Type: application/json; charset=UTF-8
   OData-Version: 4.0
   Content-Length: 614
   Date: Thu, 28 Apr 2022 08:47:57 GMT

手順

1. 以下の curl コマンドを実行して、BMC の現在のサブスクリプションを確認します。

   $ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions

   ここでは、以下のようになります。

   bmc_ip_address

   Redfish イベントが生成される BMC の IP アドレスです。

   出力例

   % Total % Received % Xferd Average Speed Time Time Time Current
   Dload Upload Total Spent Left Speed
   100 435 100 435 0 0 399 0 0:00:01 0:00:01 --:--:-- 399
   {
     "@odata.context": "/redfish/v1/$metadata#EventDestinationCollection.EventDestinationCollection",
     "@odata.etag": ""
     1651137375 "",
     "@odata.id": "/redfish/v1/EventService/Subscriptions",
     "@odata.type": "#EventDestinationCollection.EventDestinationCollection",
     "Description": "Collection for Event Subscriptions",
     "Members": [
     {
       "@odata.id": "/redfish/v1/EventService/Subscriptions/1"
     }],
     "Members@odata.count": 1,
     "Name": "Event Subscriptions Collection"
   }

   この例では、サブスクリプションが 1 つ設定されています (/redfish/v1/EventService/Subscriptions/1)。

2. オプション: curl で /redfish/v1/EventService/Subscriptions/1 サブスクリプションを削除するには、BMC のユーザー名およびパスワードを指定して以下のコマンドを実行します。

   $ curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1

   ここでは、以下のようになります。

   bmc_ip_address

   Redfish イベントが生成される BMC の IP アドレスです。

手順

1. HardwareEvent カスタムリソース (CR) を作成します。

   1. 以下の YAML を hw-event.yaml ファイルに保存します。

      apiVersion: "event.redhat-cne.org/v1alpha1"
      kind: "HardwareEvent"
      metadata:
        name: "hardware-event"
      spec:
        nodeSelector:
          node-role.kubernetes.io/hw-event: "" 1
        transportHost: "amqp://amq-router-service-name.amq-namespace.svc.cluster.local" 2
        logLevel: "debug" 3
        msgParserTimeout: "10" 4

      1

      必須。nodeSelector フィールドを使用して、指定されたラベルを持つノードをターゲットにします (例: node-role.kubernetes.io/hw-event: ""。

      2

      必須。AMQP プロトコルを使用してトランスポート層でイベントを提供する AMQP ホスト。

      3

      オプション:デフォルト値は debug です。hw-event-proxy ログでログレベルを設定します。fatal、error、warning、info、debug、trace のログレベルを利用できます。

      4

      オプション: Message Parser のタイムアウト値をミリ秒単位で設定します。メッセージ解析要求がタイムアウト期間内に応答しない場合には、元のハードウェアイベントメッセージはクラウドネイティブイベントフレームワークに渡されます。デフォルト値は 10 です。

   2. HardwareEvent CR を作成します。

      $ oc create -f hardware-event.yaml

2. BMC ユーザー名およびパスワード Secret CR を作成します。これにより、ハードウェアイベントプロキシーがベアメタルホストの Redfish メッセージレジストリーにアクセスできるようになります。

   1. 以下の YAML を hw-event-bmc-secret.yaml ファイルに保存します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: redfish-basic-auth
      type: Opaque
      stringData: 1
        username: <bmc_username>
        password: <bmc_password>
        # BMC host DNS or IP address
        hostaddr: <bmc_host_ip_address>

      1

      stringData の下に、さまざまな項目のプレーンテキスト値を入力します。

   2. Secret CR を作成します。

      $ oc create -f hw-event-bmc-secret.yaml