手順

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

手順

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> 1
              retentionSize: <size_specification> 2

        1

        保持時間: ms (ミリ秒)、s (秒)、m (分)、h (時)、d (日)、w (週)、y (年) が直接続く数値。1h30m15s などの特定の時間に時間値を組み合わせることもできます。

        2

        保持サイズ: B (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)、TB (テラバイト)、PB (ペタバイト)、EB (エクサバイト) が直接続く数値。

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

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

   • ユーザー定義プロジェクトをモニターする 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> 1
              retentionSize: <size_specification> 2

        1

        保持時間: ms (ミリ秒)、s (秒)、m (分)、h (時)、d (日)、w (週)、y (年) が直接続く数値。1h30m15s などの特定の時間に時間値を組み合わせることもできます。

        2

        保持サイズ: B (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)、TB (テラバイト)、PB (ペタバイト)、EB (エクサバイト) が直接続く数値。

        次の例では、ユーザー定義プロジェクトを監視する Prometheus インスタンスについて、保持時間を 24 時間に、保持サイズを 10 ギガバイトに設定しています。

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

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

   警告

   変更がモニタリング設定マップに保存されると、関連するプロジェクトの 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 は自動的に再起動します。

   警告

   監視設定マップの変更を保存すると、監視プロセスが再起動し、関連プロジェクトの Pod やその他のリソースが再デプロイされる場合があります。そのプロジェクトで実行中のモニタリングプロセスも再起動する場合があります。

手順

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

   • コア OpenShift Container Platform メトリクスのクラスター ID ラベルを作成するには、次の手順を実行します。

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

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

     2. data/config.yaml/prometheusK8s/remoteWrite の下にある writeRelabelConfigs: セクションで、クラスター ID の再ラベル付け設定値を追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                <endpoint_authentication_credentials>
                writeRelabelConfigs: 1
                  - <relabel_config> 2

        1

        リモートエンドポイントに送信するメトリクスの書き込み再ラベル付け設定の一覧を追加します。

        2

        リモート書き込みエンドポイントに送信されるメトリクスのラベル設定を置き換えます。

        以下の例は、デフォルトのプラットフォームモニタリングでクラスター ID ラベル cluster_id を持つメトリクスを転送する方法を示しています。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                writeRelabelConfigs:
                - sourceLabels:
                  - __tmp_openshift_cluster_id__ 1
                  targetLabel: cluster_id 2
                  action: replace 3

        1

        システムは最初に __tmp_openshift_cluster_id__ という名前の一時的なクラスター ID ソースラベルを適用します。この一時的なラベルは、指定するクラスター ID ラベル名に置き換えられます。

        2

        リモート書き込みストレージに送信されるメトリクスのクラスター ID ラベルの名前を指定します。メトリクスにすでに存在するラベル名を使用する場合、その値はこのクラスター ID ラベルの名前で上書きされます。ラベル名には __tmp_openshift_cluster_id__ は使用しないでください。最後の再ラベル手順では、この名前を使用するラベルを削除します。

        3

        replace 置き換えラベルの再設定アクションは、一時ラベルを送信メトリクスのターゲットラベルに置き換えます。このアクションはデフォルトであり、アクションが指定されていない場合に適用されます。

   • ユーザー定義のプロジェクトメトリックのクラスター ID ラベルを作成するには、次の手順を実行します。

     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/prometheus/remoteWrite の下にある writeRelabelConfigs: セクションで、クラスター ID の再ラベル付け設定値を追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                <endpoint_authentication_credentials>
                writeRelabelConfigs: 1
                  - <relabel_config> 2

        1

        リモートエンドポイントに送信するメトリクスの書き込み再ラベル付け設定の一覧を追加します。

        2

        リモート書き込みエンドポイントに送信されるメトリクスのラベル設定を置き換えます。

        次のサンプルは、ユーザーワークロードのモニタリングでクラスター ID ラベル cluster_id を持つメトリックを転送する方法を示しています。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              remoteWrite:
              - url: "https://remote-write-endpoint.example.com"
                writeRelabelConfigs:
                - sourceLabels:
                  - __tmp_openshift_cluster_id__ 1
                  targetLabel: cluster_id 2
                  action: replace 3

        1

        システムは最初に __tmp_openshift_cluster_id__ という名前の一時的なクラスター ID ソースラベルを適用します。この一時的なラベルは、指定するクラスター ID ラベル名に置き換えられます。

        2

        リモート書き込みストレージに送信されるメトリクスのクラスター ID ラベルの名前を指定します。メトリクスにすでに存在するラベル名を使用する場合、その値はこのクラスター ID ラベルの名前で上書きされます。ラベル名には __tmp_openshift_cluster_id__ は使用しないでください。最後の再ラベル手順では、この名前を使用するラベルを削除します。

        3

        replace 置き換えラベルの再設定アクションは、一時ラベルを送信メトリクスのターゲットラベルに置き換えます。このアクションはデフォルトであり、アクションが指定されていない場合に適用されます。

2. ファイルを保存して、変更を ConfigMap オブジェクトに適用します。更新された設定の影響を受ける Pod は自動的に再起動します。

   警告

   モニタリング ConfigMap オブジェクトへの変更を保存すると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。また、変更を保存すると、そのプロジェクトで実行中のモニタリングプロセスも再起動する可能性があります。

手順

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

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

2. data/config.yaml/prometheusK8s の下にメトリック収集プロファイル設定を追加します。

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

   1

   メトリック収集プロファイルの名前。使用可能な値は full または minimum です。値を指定しない場合、または collectionProfile キー名が config map に存在しない場合は、デフォルト設定の full が使用されます。

   次の例では、Prometheus のコアプラットフォームインスタンスのメトリックコレクションプロファイルを minimal に設定します。

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

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. enforcedLabelLimit、enforcedLabelNameLengthLimit、および enforcedLabelValueLengthLimit 設定を data/config.yaml に追加し、収集されるラベルの数、ラベル名の長さ、およびユーザー定義プロジェクトでのラベル値の長さを制限します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       prometheus:
         enforcedLabelLimit: 500 1
         enforcedLabelNameLengthLimit: 50 2
         enforcedLabelValueLengthLimit: 600 3

   1

   収集ごとのラベルの最大数を指定します。デフォルト値は 0 で、制限なしを指定します。

   2

   ラベル名の最大長を指定します。デフォルト値は 0 で、制限なしを指定します。

   3

   ラベル値の最大長を指定します。デフォルト値は 0 で、制限なしを指定します。

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

   注記

   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 → RoleBindings → 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. 1 つ以上のクエリーを追加するには、次のいずれかを実行します。

   オプション	説明
   カスタムクエリーを作成します。	Prometheus Query Language (PromQL) クエリーを Expression フィールドに追加します。 PromQL 式を入力すると、オートコンプリートの提案がドロップダウンリストに表示されます。これらの提案には、関数、メトリック、ラベル、および時間トークンが含まれます。キーボードの矢印を使用して提案された項目のいずれかを選択し、Enter を押して項目を式に追加できます。また、マウスポインターを推奨項目の上に移動して、その項目の簡単な説明を表示することもできます。
   複数のクエリーを追加します。	クエリーの追加 を選択します。
   既存のクエリーを複製します。	オプションメニューを選択します クエリーの横にある Duplicate query を選択します。
   クエリーの実行を無効にします。	オプションメニューを選択します クエリーの横にある Disable query を選択します。

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

   注記

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

   注記

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

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

5. 視覚化されたメトリクスを調べます。最初に、有効な全クエリーの全メトリクスがプロットに表示されます。次のいずれかを実行して、表示するメトリクスを選択できます。

   オプション	説明
   クエリーからすべてのメトリクスを非表示にします。	オプションメニューをクリックします クエリーを選択し、Hide all series をクリックします。
   特定のメトリックを非表示にします。	クエリーテーブルに移動し、メトリック名の近くにある色付きの四角形をクリックします。
   プロットを拡大し、時間範囲を変更します。	次のいずれかになります。 プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。 左上隅のメニューを使用して、時間範囲を選択します。
   時間範囲をリセットします。	Reset zoom を選択します。
   特定の時点でのすべてのクエリーの出力を表示します。	その時点でプロット上にマウスカーソルを置きます。クエリーの出力はポップアップに表示されます。
   プロットを非表示にします。	Hide graph を選択します。

手順

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

3. Select query 一覧からクエリーを選択するか、または Show PromQL を選択して、選択したクエリーに基づいてカスタム PromQL クエリーを作成します。クエリーからのメトリックはプロットで可視化されます。

   注記

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

4. 次のいずれかを実行して、視覚化されたメトリクスを調べます。

   オプション	説明
   プロットを拡大し、時間範囲を変更します。	次のいずれかになります。 プロットを水平にクリックし、ドラッグして、時間範囲を視覚的に選択します。 左上隅のメニューを使用して、時間範囲を選択します。
   時間範囲をリセットします。	Reset zoom を選択します。
   特定の時点でのすべてのクエリーの出力を表示します。	その時点でプロット上にマウスカーソルを置きます。クエリーの出力はポップアップに表示されます。

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. アラートルールの 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

   そのラベルがある場合、アラートルールは openshift-user-workload-monitoring プロジェクトの Prometheus インスタンスにデプロイされます。ラベルが存在しない場合、アラートルールは Theanos Ruler にデプロイされます。

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

   $ 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-monitoring namespace に example-modified-alerting-rule.yaml という名前の新規 YAML 設定ファイルを作成します。

2. AlertRelabelConfig リソースを YAML ファイルに追加します。以下の例では、デフォルトのプラットフォーム watchdog アラートルールの severity 設定を critical に変更します。

   apiVersion: monitoring.openshift.io/v1alpha1
   kind: AlertRelabelConfig
   metadata:
     name: watchdog
     namespace: openshift-monitoring
   spec:
     configs:
     - sourceLabels: [alertname,severity] 1
       regex: "Watchdog;none" 2
       targetLabel: severity 3
       replacement: critical 4
       action: Replace 5

   1

   変更する値のソースラベル。

   2

   sourceLabels の値が一致する正規表現。

   3

   変更する値のターゲットラベル。

   4

   ターゲットラベルを置き換える新しい値。

   5

   正規表現の一致に基づいて古い値を置き換える再ラベルアクション。デフォルトのアクションは Replace です。その他に使用可能な値は、Keep、Drop 、HshMod、LabelMap、LabelDrop、および LabelKeep です。

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

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

手順

1. openshift-monitoring namespace に example-alerting-rule.yaml という名前の新規 YAML 設定ファイルを作成します。

2. AlertingRule リソースを YAML ファイルに追加します。以下の例では、デフォルトの watchdog アラートと同様に example という名前の新規アラートルールを作成します。

   apiVersion: monitoring.openshift.io/v1alpha1
   kind: AlertingRule
   metadata:
     name: example
     namespace: openshift-monitoring
   spec:
     groups:
     - name: example-rules
       rules:
       - alert: ExampleAlert 1
         expr: vector(1) 2

   1

   作成する必要のあるアラートルールの名前。

   2

   新規ルールを定義する PromQL クエリー式。

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

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

手順

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/v1beta1
   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) を作成します。

   注記

   複数の HardwareEvent リソースは許可されません。

   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
        logLevel: "debug" 2
        msgParserTimeout: "10" 3

      1

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

      注記

      OpenShift Container Platform 4.13 以降でベアメタルイベントに HTTP トランスポートを使用する場合、HardwareEvent リソースの spec.transportHost フィールドを設定する必要はありません。ベアメタルイベントに AMQP トランスポートを使用する場合にのみ transportHost を設定します。

      2

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

      3

      オプション: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