モニタリング

手順

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

   • OpenShift Container Platform のコアモニタリングコンポーネントを設定するには、以下を実行します。

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

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

     2. 設定を、data/config.yaml の下に値とキーのペア <component_name>: <component_configuration> として追加します。

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

        <component> および <configuration_for_the_component> を随時置き換えます。

        以下の ConfigMap オブジェクトの例は、Prometheus の永続ボリューム要求 (PVC) を設定します。これは、OpenShift Container Platform のコアコンポーネントのみをモニターする Prometheus インスタンスに関連します。

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

        1

        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 の下に値とキーのペア <component_name>: <component_configuration> として追加します。

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

        <component> および <configuration_for_the_component> を随時置き換えます。

        以下の ConfigMap オブジェクトの例は、Prometheus のデータ保持期間および最小コンテナーリソース要求を設定します。これは、ユーザー定義のプロジェクトのみをモニターする Prometheus インスタンスに関連します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus: 1
              retention: 24h 2
              resources:
                requests:
                  cpu: 200m 3
                  memory: 2Gi 4

        1

        Prometheus コンポーネントを定義し、後続の行はその設定を定義します。

        2

        ユーザー定義プロジェクトをモニターする Prometheus インスタンスについて 24 時間のデータ保持期間を設定します。

        3

        Prometheus コンテナーの 200 ミリコアの最小リソース要求を定義します。

        4

        Prometheus コンテナーのメモリーの 2 GiB の最小 Pod リソース要求を定義します。

        注記

        Prometheus 設定マップコンポーネントは、 cluster-monitoring-config ConfigMap オブジェクトで prometheusK8s と呼ばれ、 user-workload-monitoring-config ConfigMap オブジェクトで prometheus と呼ばれます。

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

   注記

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

   警告

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

手順

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

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

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

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

     2. コンポーネントの tolerations を指定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>:
              tolerations:
                <toleration_specification>

        <component> および <toleration_specification> を随時置き換えます。

        たとえば、oc adm taint nodes node1 key1=value1:NoSchedule は、キーが key1 で、値が value1 の node1 にテイントを追加します。これにより、モニタリングコンポーネントが node1 に Pod をデプロイするのを防ぎます。ただし、そのテイントに対して許容値が設定されている場合を除きます。以下の例は、サンプルのテイントを容認するように alertmanagerMain コンポーネントを設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            alertmanagerMain:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"

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

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

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

     2. コンポーネントの tolerations を指定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>:
              tolerations:
                <toleration_specification>

        <component> および <toleration_specification> を随時置き換えます。

        たとえば、oc adm taint nodes node1 key1=value1:NoSchedule は、キーが key1 で、値が value1 の node1 にテイントを追加します。これにより、モニタリングコンポーネントが node1 に Pod をデプロイするのを防ぎます。ただし、そのテイントに対して許容値が設定されている場合を除きます。以下の例では、サンプルのテイントを容認するように thanosRuler コンポーネントを設定します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            thanosRuler:
              tolerations:
              - key: "key1"
                operator: "Equal"
                value: "value1"
                effect: "NoSchedule"

2. 変更を適用するためにファイルを保存します。新しいコンポーネントの配置設定が自動的に適用されます。

   注記

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

   警告

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

手順

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

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

2. enforcedBodySizeLimit の値を data/config.yaml/prometheusK8s に追加して、ターゲットスクレイプごとに受け入れられるボディサイズを制限します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |-
       prometheusK8s:
         enforcedBodySizeLimit: 40MB 1

   1

   スクレイピングされたメトリックターゲットの最大ボディサイズを指定します。この enforcedBodySizeLimit の例では、ターゲットスクレイプごとの非圧縮サイズを 40 メガバイトに制限しています。有効な数値は、B (バイト)、KB (キロバイト)、MB (メガバイト)、GB (ギガバイト)、TB (テラバイト)、PB (ペタバイト)、および EB (エクサバイト) の Prometheus データサイズ形式を使用します。デフォルト値は 0 で、制限なしを指定します。値を automatic に設定して、クラスターの容量に基づいて制限を自動的に計算することもできます。

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

   警告

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

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

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

2. data/config.yaml/prometheusK8s に remoteWrite: セクションを追加します。

3. このセクションにエンドポイント URL および認証情報を追加します。

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

   1

   リモート書き込みエンドポイントの URL。

   2

   エンドポイントの認証方法およびクレデンシャル。現在サポートされている認証方法は、AWS 署名バージョン 4、Authorization リクエストヘッダーでの HTTP を使用した認証、基本認証、OAuth 2.0、および TLS クライアントです。サポートされている認証方法のサンプル設定については、サポートされているリモート書き込み認証設定 を参照してください。

4. 認証クレデンシャルの後に、書き込みの再ラベル設定値を追加します。

   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>
           <write_relabel_configs> 1

   1

   書き込みの再ラベル設定。

   <write_relabel_configs> は、リモートエンドポイントに送信する必要のあるメトリクスの書き込みラベル一覧に置き換えます。

   以下の例では、my_metric という単一のメトリックを転送する方法を紹介します。

   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: [__name__]
             regex: 'my_metric'
             action: keep

   書き込み再ラベル設定オプションについては、Prometheus relabel_config documentation を参照してください。

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

   注記

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

   警告

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

手順

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:
              externalLabels:
                <key>: <value> 1

        1

        <key>: <value> をキーと値のペアのマップに置き換えます。ここで、<key> は新規ラベルの一意の名前で、<value> はその値になります。

        警告

        prometheus または prometheus_replica は予約され、上書きされるため、これらをキー名として使用しないでください。

        たとえば、リージョンおよび環境に関するメタデータをすべての時系列およびアラートに追加するには、以下を使用します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusK8s:
              externalLabels:
                region: eu
                environment: prod

   • カスタムラベルを、ユーザー定義のプロジェクトをモニターする 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:
              externalLabels:
                <key>: <value> 1

        1

        <key>: <value> をキーと値のペアのマップに置き換えます。ここで、<key> は新規ラベルの一意の名前で、<value> はその値になります。

        警告

        prometheus または prometheus_replica は予約され、上書きされるため、これらをキー名として使用しないでください。

        注記

        openshift-user-workload-monitoring プロジェクトでは、Prometheus はメトリックを処理し、Thanos Ruler はアラートおよび記録ルールを処理します。user-workload-monitoring-config ConfigMap オブジェクトで prometheus の externalLabels を設定すると、すべてのルールではなく、メトリックの外部ラベルのみが設定されます。

        たとえば、リージョンおよび環境に関するメタデータをすべての時系列およびユーザー定義プロジェクトに関連するアラートに追加するには、以下を使用します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheus:
              externalLabels:
                region: eu
                environment: prod

2. 変更を適用するためにファイルを保存します。新しい設定は自動的に適用されます。

   注記

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

   警告

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

手順

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

   • openshift-monitoring プロジェクトのコンポーネントのログレベルを設定するには、以下を実行します。

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

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

     2. コンポーネントの logLevel: <log_level> を data/config.yaml の下に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            <component>: 1
              logLevel: <log_level> 2

        1

        ログレベルを設定するモニタリングスタックコンポーネント。デフォルトのプラットフォームモニタリングの場合、使用可能なコンポーネント値は prometheusK8s、alertmanagerMain、prometheusOperator、および thanosQuerier です。

        2

        コンポーネントに設定するログレベル。使用可能な値は、error、warn、info、および debug です。デフォルト値は info です。

   • openshift-user-workload-monitoring プロジェクトのコンポーネントのログレベルを設定するには、以下を実行します。

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

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

     2. コンポーネントの logLevel: <log_level> を data/config.yaml の下に追加します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            <component>: 1
              logLevel: <log_level> 2

        1

        ログレベルを設定する監視スタックコンポーネント。ユーザーワークロードの監視の場合、使用可能なコンポーネントの値は、prometheus、prometheusOperator、および thanosRuler です。

        2

        コンポーネントに設定するログレベル。使用可能な値は、error、warn、info、および debug です。デフォルト値は info です。

2. 変更を適用するためにファイルを保存します。ログレベルの変更を適用する際に、コンポーネントの Pod は自動的に再起動します。

   注記

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

   警告

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

3. 関連するプロジェクトでデプロイメントまたは Pod 設定を確認し、ログレベルが適用されていることを確認します。以下の例では、openshift-user-workload-monitoring プロジェクトの prometheus-operator デプロイメントでログレベルを確認します。

   $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

   出力例

           - --log-level=debug

4. コンポーネントの Pod が実行中であることを確認します。以下の例は、openshift-user-workload-monitoring プロジェクトの Pod のステータスをリスト表示します。

   $ oc -n openshift-user-workload-monitoring get pods

   注記

   認識されない loglevel 値が ConfigMap オブジェクトに含まれる場合は、コンポーネントの Pod が正常に再起動しない可能性があります。

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

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

2. 以下の例のように thanosQuerier セクションを data/config.yaml に追加し、値を追加します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       thanosQuerier:
         enableRequestLogging: <value> 1
         logLevel: <value> 2

   1

   ロギングを有効にするには、値を true に設定し、ロギングを無効にするには false を設定します。デフォルト値は false です。

   2

   この値は debug、info、warn、または error に設定します。logLevel に値が存在しない場合、ログレベルはデフォルトで error に設定されます。

3. 変更を適用するためにファイルを保存します。

   警告

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

検証

1. Thanos Querier Pod が実行されていることを確認します。次のコマンドの例は、openshift-monitoringプロジェクトの Pod のステータスを一覧表示します。

   $ oc -n openshift-monitoring get pods

2. 以下のサンプルコマンドをモデルとして使用して、テストクエリーを実行します。

   $ token=`oc create token prometheus-k8s -n openshift-monitoring`
   $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -k -H "Authorization: Bearer $token" 'https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query?query=cluster_version'

3. 以下のコマンドを実行してクエリーログを読み取ります。

   $ oc -n openshift-monitoring logs <thanos_querier_pod_name> -c thanos-query

   注記

   thanos-querier Pod は高可用性 (HA) Pod であるため、1 つの Pod でのみログを表示できる可能性があります。

4. ログに記録されたクエリー情報を確認したら、設定マップで enableRequestLogging の値を false に変更してクエリーロギングを無効にします。

手順

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

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

2. data/config.yaml の下に、alertmanagerMain コンポーネントの enabled: false を追加します。

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

3. 変更を適用するためにファイルを保存します。Alertmanager インスタンスは、この変更を適用すると自動的に無効にされます。

手順

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

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

2. enableUserWorkload: true を data/config.yaml の下に追加します。

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

   1

   true に設定すると、enableUserWorkload パラメーターはクラスター内のユーザー定義プロジェクトのモニタリングを有効にします。

3. 変更を適用するためにファイルを保存します。ユーザー定義プロジェクトのモニタリングは自動的に有効になります。

   警告

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

4. prometheus-operator、 prometheus-user-workload および thanos-ruler-user-workload Pod が openshift-user-workload-monitoring プロジェクトで実行中であることを確認します。Pod が起動するまでに少し時間がかかる場合があります。

   $ oc -n openshift-user-workload-monitoring get pod

   出力例

   NAME                                   READY   STATUS        RESTARTS   AGE
   prometheus-operator-6f7b748d5b-t7nbg   2/2     Running       0          3h
   prometheus-user-workload-0             4/4     Running       1          3h
   prometheus-user-workload-1             4/4     Running       1          3h
   thanos-ruler-user-workload-0           3/3     Running       0          3h
   thanos-ruler-user-workload-1           3/3     Running       0          3h

手順

1. トークンをデプロイメントして Prometheus に接続します。

   $ SECRET=`oc get secret -n openshift-user-workload-monitoring | grep  prometheus-user-workload-token | head -n 1 | awk '{print $1 }'`

   $ TOKEN=`echo $(oc get secret $SECRET -n openshift-user-workload-monitoring -o json | jq -r '.data.token') | base64 -d`

2. ルートホストをデプロイメントします。

   $ THANOS_QUERIER_HOST=`oc get route thanos-querier -n openshift-monitoring -o json | jq -r '.spec.host'`

3. コマンドラインで独自のサービスのメトリックをクエリーします。以下に例を示します。

   $ NAMESPACE=ns1

   $ curl -X GET -kG "https://$THANOS_QUERIER_HOST/api/v1/query?" --data-urlencode "query=up{namespace='$NAMESPACE'}" -H "Authorization: Bearer $TOKEN"

   出力には、アプリケーション Pod が起動していた期間が表示されます。

   出力例

   {"status":"success","data":{"resultType":"vector","result":[{"metric":{"__name__":"up","endpoint":"web","instance":"10.129.0.46:8080","job":"prometheus-example-app","namespace":"ns1","pod":"prometheus-example-app-68d47c4fb6-jztp2","service":"prometheus-example-app"},"value":[1591881154.748,"1"]}]}}

手順

1. ラベルをプロジェクト namespace に追加します。

   $ oc label namespace my-project 'openshift.io/user-monitoring=false'

2. モニタリングを再度有効にするには、namespace からラベルを削除します。

   $ oc label namespace my-project 'openshift.io/user-monitoring-'

   注記

   プロジェクトにアクティブなモニタリングターゲットがあった場合、ラベルを追加した後、Prometheus がそれらのスクレイピングを停止するまでに数分かかる場合があります。

手順

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

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

   1. data/config.yaml で enableUserWorkload: を false に設定します。

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

2. 変更を適用するためにファイルを保存します。ユーザー定義プロジェクトのモニタリングは自動的に無効になります。

3. prometheus-operator、 prometheus-user-workload および thanos-ruler-user-workload Pod が openshift-user-workload-monitoring プロジェクトで終了していることを確認します。これには少し時間がかかる場合があります。

   $ oc -n openshift-user-workload-monitoring get pod

   出力例

   No resources found in openshift-user-workload-monitoring project.

手順

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

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

2. alertmanagerMain セクションに enableUserAlertmanagerConfig: true を data/config.yaml の下に追加します。

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

   1

   enableUserAlertmanagerConfig 値を true に設定して、ユーザーが Alertmanager のメインプラットフォームインスタンスを使用するユーザー定義のアラートルーティング設定を作成できるようにします。

3. 変更を適用するためにファイルを保存します。

手順

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

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

2. data/config.yaml の下にある alertmanager セクションに enabled: true および enableAlertmanagerConfig: true を追加します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: user-workload-monitoring-config
     namespace: openshift-user-workload-monitoring
   data:
     config.yaml: |
       alertmanager:
         enabled: true 1
         enableAlertmanagerConfig: true 2

   1

   enabled の値を true に設定して、クラスター内のユーザー定義プロジェクトの Alertmanager の専用インスタンスを有効にします。値を false に設定するか、キーを完全に省略してユーザー定義プロジェクトの Alertmanager を無効にします。この値を false に設定した場合や、キーを省略すると、ユーザー定義のアラートはデフォルトのプラットフォーム Alertmanager インスタンスにルーティングされます。

   2

   enableAlertmanagerConfig 値を true に設定して、ユーザーが AlertmanagerConfig オブジェクトで独自のアラートルーティング設定を定義できるようにします。

3. 変更を適用するためにファイルを保存します。ユーザー定義プロジェクトの Alertmanager の専用インスタンスが自動的に起動します。

1. OpenShift Container Platform Web コンソールを開き、Observe → Targets に移動します。
2. オプション: Filter リストでフィルターを選択して、ステータスとソースでターゲットをフィルターします。
3. オプション: 検索ボックスの横にある Text または Label フィールドを使用して、名前またはラベルでターゲットを検索します。
4. オプション: 1 つ以上の Endpoint、Status、Namespace、Last Scrape、および Scrape Duration 列ヘッダーをクリックして、ターゲットを並べ替えます。

5. ターゲットの Endpoint 列の URL をクリックし、Target details ページに移動します。このページには、以下を含むターゲットに関する情報が含まれます。

   • メトリックのためにスクレイピングされているエンドポイント URL
   • 現在のターゲットのステータス (Up または Down)
   • namespace へのリンク
   • ServiceMonitor の詳細へのリンク
   • ターゲットに割り当てられたラベル
   • ターゲットがメトリック用にスクレイピングされた直近の時間

1. OpenShift Container Platform Web コンソールを開き、Observe → Alerting → Alerts ページに移動します。
2. オプション: 検索一覧で Name フィールドを使用し、アラートを名前で検索します。
3. オプション: Filter リストでフィルターを選択し、アラートを状態、重大度およびソースでフィルターします。
4. オプション: 1 つ以上の Name、Severity、State、および Source 列ヘッダーをクリックし、アラートを並べ替えます。

5. Alert Details ページに移動するためにアラートの名前を選択します。このページには、アラートの時系列データを示すグラフが含まれます。また、以下を含むアラートについての情報も含まれます。

   • アラートの説明
   • アラートに関連付けられたメッセージ
   • アラートに割り当てられるラベル
   • アラートを規定するアラートルールへのリンク
   • アラートが存在する場合のアラートのサイレンス

1. Observe → Alerting → Silences ページに移動します。
2. オプション: Search by name フィールドを使用し、サイレンスを名前でフィルターします。
3. オプション: Filter リストでフィルターを選択し、サイレンスをフィルターします。デフォルトでは、Active および Pending フィルターが適用されます。
4. オプション: 1 つ以上の Name、Firing Alerts、および State 列ヘッダーをクリックしてサイレンスを並べ替えます。

5. Silence Details ページに移動するサイレンスの名前を選択します。このページには、以下の詳細が含まれます。

   • アラート仕様
   • 開始時間
   • 終了時間
   • サイレンス状態
   • 発生するアラートの数およびリスト

1. Observe → Alerting → Alerting Rules ページに移動します。
2. オプション: Filter 一覧でフィルターを選択し、アラートルールを状態、重大度およびソースでフィルターします。
3. オプション: 1 つ以上の Name、Severity、Alert State、および Source 列ヘッダーをクリックし、アラートルールを並べ替えます。

4. アラートルールの名前を選択し、Alerting Rule Details ページに移動します。このページには、アラートルールに関する以下の情報が含まれます。

   • アラートルール名、重大度、および説明
   • アラートを発生させるための条件を定義する式
   • アラートを発生させるための条件が true である期間
   • アラートルールに規定される各アラートのグラフ。アラートを発生させる際に使用する値が表示されます。
   • アラートルールで規定されるすべてのアラートについての表

1. Observe → <project_name> → Alerts ページに移動します。

2. アラート、サイレンス、またはアラートルールの詳細を表示します。

   • Alert Details を表示するには、アラート名の左側で > を選択し、リストでアラートを選択します。

   • Silence Details を表示するには、Alert Details ページの Silenced By セクションでサイレンスを選択します。Silence Details ページには、以下の情報が含まれます。

     • アラート仕様
     • 開始時間
     • 終了時間
     • サイレンス状態
     • 発生するアラートの数およびリスト
   • Alerting Rule Details を表示するには、Alerts ページのアラートの右側にある メニューの View Alerting Rule を選択します。

1. 現在アクティブな Alertmanager 設定をファイル alertmanager.yaml に出力します。

   $ oc -n openshift-monitoring get secret alertmanager-main --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. alertmanager.yaml で設定を編集します。

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s 1
     group_interval: 5m 2
     repeat_interval: 12h 3
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 2m
       receiver: watchdog
     - matchers:
       - "service=<your_service>" 4
       routes:
       - matchers:
         - <your_matching_rules> 5
         receiver: <receiver> 6
   receivers:
   - name: default
   - name: watchdog
   - name: <receiver>
   #  <receiver_configuration>

   1

   group_wait 値は、Alertmanager がアラートグループの初期通知を送信するまで待機する時間を指定します。この値は、Alertmanager が通知を送信する前に、同じグループの初期アラートを収集するまで待機する時間を制御します。

   2

   group_interval 値は、最初の通知がすでに送信されているアラートグループに追加された新しいアラートに関する通知を Alertmanager が送信するまでの時間を指定します。

   3

   repeat_interval の値は、アラート通知が繰り返される前に経過する必要のある最小時間を指定します。各グループの間隔で通知を繰り返す場合は、repeat_interval の値を group_interval の値よりも小さく設定します。ただし、たとえば特定の Alertmanager Pod が再起動または再スケジュールされた場合などは、繰り返し通知が遅延する可能性があります。

   4

   service の値は、アラートを発行するサービスを指定します。

   5

   <your_matching_rules> 値は、ターゲットアラートを指定します。

   6

   receiver 値は、アラートに使用するレシーバーを指定します。

   注記

   matchers キー名を使用して、ノードの照合でアラートが満たす必要のあるマッチャーを指定します。match または match_re キー名は使用しないでください。どちらも非推奨であり、今後のリリースで削除される予定です。

   さらに、禁止ルールを定義する場合は、target_matchers キー名を使用してターゲットマッチャーを示し、source_matchers キー 名を使用してソースマッチャーを示します。target_match、target_match_re、source_match、または source_match_re キー名は使用しないでください。これらは非推奨であり、今後のリリースで削除される予定です。

   以下の Alertmanager 設定例は、PagerDuty をアラートレシーバーとして設定します。

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: default
     routes:
     - matchers:
       - "alertname=Watchdog"
       repeat_interval: 2m
       receiver: watchdog
     - matchers:
       - "service=example-app"
       routes:
       - matchers:
         - "severity=critical"
         receiver: team-frontend-page*
   receivers:
   - name: default
   - name: watchdog
   - name: team-frontend-page
     pagerduty_configs:
     - service_key: "_your-key_"

   この設定では、example-app サービスで実行される重大度が critical のアラートは、team-frontend-page receiver を使用して送信されます。通常、これらのタイプのアラートは、個別または緊急対策チーム (Critical Response Team) に送信先が設定されます。

3. 新規設定をファイルで適用します。

   $ oc -n openshift-monitoring create secret generic alertmanager-main --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-monitoring replace secret --filename=-

1. Web コンソールの Administration → Cluster Settings → Configuration → Alertmanager → YAML ページに移動します。
2. YAML 設定ファイルを変更します。
3. Save を選択します。

手順

1. 現在アクティブな Alertmanager 設定をファイル alertmanager.yaml に出力します。

   $ oc -n openshift-user-workload-monitoring get secret alertmanager-user-workload --template='{{ index .data "alertmanager.yaml" }}' | base64 --decode > alertmanager.yaml

2. alertmanager.yaml で設定を編集します。

   route:
     receiver: Default
     group_by:
     - name: Default
     routes:
     - matchers:
       - "service = prometheus-example-monitor" 1
       receiver: <receiver> 2
   receivers:
   - name: Default
   - name: <receiver>
   #  <receiver_configuration>

   1

   ルートに一致するアラートを指定します。この例では、service="prometheus-example-monitor" ラベルの付いたすべてのアラートを示しています。

   2

   アラートグループに使用するレシーバーを指定します。

3. 新規設定をファイルで適用します。

   $ oc -n openshift-user-workload-monitoring create secret generic alertmanager-user-workload --from-file=alertmanager.yaml --dry-run=client -o=yaml |  oc -n openshift-user-workload-monitoring replace secret --filename=-

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Observe → Dashboards に移動します。
2. Dashboard 一覧でダッシュボードを選択します。etcd や Prometheus ダッシュボードなどの一部のダッシュボードは、選択時に追加のサブメニューを生成します。

3. 必要に応じて、Time Range 一覧でグラフの時間範囲を選択します。

   • 事前定義済みの期間を選択します。

   • 時間範囲 リストで カスタムの時間範囲 を選択して、カスタムの時間範囲を設定します。

     1. From および To の日付と時間を入力または選択します。
     2. Save をクリックして、カスタムの時間範囲を保存します。
4. オプション: Refresh Interval を選択します。
5. 特定の項目についての詳細情報を表示するには、ダッシュボードの各グラフにカーソルを合わせます。

手順

1. OpenShift Container Platform Web コンソールの Developer パースペクティブで、Observe → Dashboard に移動します。
2. Project: ドロップダウンリストからプロジェクトを選択します。

3. Dashboard ドロップダウンリストからダッシュボードを選択し、フィルターされたメトリックを表示します。

   注記

   すべてのダッシュボードは、Kubernetes / Compute Resources / Namespace(Pod) を除く、選択時に追加のサブメニューを生成します。

4. 必要に応じて、Time Range 一覧でグラフの時間範囲を選択します。

   • 事前定義済みの期間を選択します。

   • 時間範囲 リストで カスタムの時間範囲 を選択して、カスタムの時間範囲を設定します。

     1. From および To の日付と時間を入力または選択します。
     2. Save をクリックして、カスタムの時間範囲を保存します。
5. オプション: Refresh Interval を選択します。
6. 特定の項目についての詳細情報を表示するには、ダッシュボードの各グラフにカーソルを合わせます。

1. Helm リポジトリーを追加します。

   $ helm repo add rh-ecosystem-edge https://rh-ecosystem-edge.github.io/console-plugin-nvidia-gpu

   $ helm repo update

2. デフォルトの NVIDIA GPU Operator namespace に Helm チャートをインストールします。

   $ helm install -n nvidia-gpu-operator console-plugin-nvidia-gpu rh-ecosystem-edge/console-plugin-nvidia-gpu

   出力例

   NAME: console-plugin-nvidia-gpu
   LAST DEPLOYED: Tue Aug 23 15:37:35 2022
   NAMESPACE: nvidia-gpu-operator
   STATUS: deployed
   REVISION: 1
   NOTES:
   View the Console Plugin NVIDIA GPU deployed resources by running the following command:
   
   $ oc -n {{ .Release.Namespace }} get all -l app.kubernetes.io/name=console-plugin-nvidia-gpu
   
   Enable the plugin by running the following command:
   
   # Check if a plugins field is specified
   $ oc get consoles.operator.openshift.io cluster --output=jsonpath="{.spec.plugins}"
   
   # if not, then run the following command to enable the plugin
   $ oc patch consoles.operator.openshift.io cluster --patch '{ "spec": { "plugins": ["console-plugin-nvidia-gpu"] } }' --type=merge
   
   # if yes, then run the following command to enable the plugin
   $ oc patch consoles.operator.openshift.io cluster --patch '[{"op": "add", "path": "/spec/plugins/-", "value": "console-plugin-nvidia-gpu" }]' --type=json
   
   # add the required DCGM Exporter metrics ConfigMap to the existing NVIDIA operator ClusterPolicy CR:
   oc patch clusterpolicies.nvidia.com gpu-cluster-policy --patch '{ "spec": { "dcgmExporter": { "config": { "name": "console-plugin-nvidia-gpu" } } } }' --type=merge

   ダッシュボードは、主に NVIDIA DCGM Exporter によって公開された Prometheus メトリックに依存していますが、デフォルトの公開されたメトリックは、ダッシュボードが必要なゲージをレンダリングするには不十分です。したがって、DGCM エクスポーターは、以下に示すように、カスタムのメトリクスセットを公開するように設定されます。

   apiVersion: v1
   data:
     dcgm-metrics.csv: |
       DCGM_FI_PROF_GR_ENGINE_ACTIVE, gauge, gpu utilization.
       DCGM_FI_DEV_MEM_COPY_UTIL, gauge, mem utilization.
       DCGM_FI_DEV_ENC_UTIL, gauge, enc utilization.
       DCGM_FI_DEV_DEC_UTIL, gauge, dec utilization.
       DCGM_FI_DEV_POWER_USAGE, gauge, power usage.
       DCGM_FI_DEV_POWER_MGMT_LIMIT_MAX, gauge, power mgmt limit.
       DCGM_FI_DEV_GPU_TEMP, gauge, gpu temp.
       DCGM_FI_DEV_SM_CLOCK, gauge, sm clock.
       DCGM_FI_DEV_MAX_SM_CLOCK, gauge, max sm clock.
       DCGM_FI_DEV_MEM_CLOCK, gauge, mem clock.
       DCGM_FI_DEV_MAX_MEM_CLOCK, gauge, max mem clock.
   kind: ConfigMap
   metadata:
     annotations:
       meta.helm.sh/release-name: console-plugin-nvidia-gpu
       meta.helm.sh/release-namespace: nvidia-gpu-operator
     creationTimestamp: "2022-10-26T19:46:41Z"
     labels:
       app.kubernetes.io/component: console-plugin-nvidia-gpu
       app.kubernetes.io/instance: console-plugin-nvidia-gpu
       app.kubernetes.io/managed-by: Helm
       app.kubernetes.io/name: console-plugin-nvidia-gpu
       app.kubernetes.io/part-of: console-plugin-nvidia-gpu
       app.kubernetes.io/version: latest
       helm.sh/chart: console-plugin-nvidia-gpu-0.2.3
     name: console-plugin-nvidia-gpu
     namespace: nvidia-gpu-operator
     resourceVersion: "19096623"
     uid: 96cdf700-dd27-437b-897d-5cbb1c255068

   ConfigMap をインストールし、NVIDIA Operator ClusterPolicy CR を編集して、その ConfigMap を DCGM エクスポーター設定に追加します。ConfigMap のインストールは、新しいバージョンの Console Plugin NVIDIA GPU Helm Chart で実行されますが、ClusterPolicy CR の編集はユーザーが行います。

3. デプロイされたリソースを表示します。

   $ oc -n nvidia-gpu-operator get all -l app.kubernetes.io/name=console-plugin-nvidia-gpu

   出力例

   NAME                                             READY   STATUS    RESTARTS   AGE
   pod/console-plugin-nvidia-gpu-7dc9cfb5df-ztksx   1/1     Running   0          2m6s
   
   NAME                                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
   service/console-plugin-nvidia-gpu   ClusterIP   172.30.240.138   <none>        9443/TCP   2m6s
   
   NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/console-plugin-nvidia-gpu   1/1     1            1           2m6s
   
   NAME                                                   DESIRED   CURRENT   READY   AGE
   replicaset.apps/console-plugin-nvidia-gpu-7dc9cfb5df   1         1         1       2m6s

手順

1. ベアラートークンを取得します。

   $ token=`oc whoami -t`

2. /federate ルートからメトリックをクエリーします。以下の例では、メトリックのクエリー up します。

   $ curl -G -s -k -H "Authorization: Bearer $token" \
       'https:/<federation_host>/federate' \ 1
       --data-urlencode 'match[]=up'

   1

   <federation_host> については、フェデレーションルートのホスト URL を置き換えます。

   出力例

   # TYPE up untyped
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.143.148:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035322214
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.148.166:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035338597
   up{apiserver="kube-apiserver",endpoint="https",instance="10.0.173.16:6443",job="apiserver",namespace="default",service="kubernetes",prometheus="openshift-monitoring/k8s",prometheus_replica="prometheus-k8s-0"} 1 1657035343834
   ...

手順

1. サービスおよび ServiceMonitor リソース設定で、対応するラベルの一致を確認 します。

   1. サービスに定義されたラベルを取得します。以下の例では、ns1 プロジェクトの prometheus-example-app サービスをクエリーします。

      $ oc -n ns1 get service prometheus-example-app -o yaml

      出力例

        labels:
          app: prometheus-example-app

   2. ServiceMonitor リソース設定の matchLabels app ラベルが直前のステップのラベルの出力と一致することを確認します。

      $ oc -n ns1 get servicemonitor prometheus-example-monitor -o yaml

      出力例

      apiVersion: v1
      kind: Service
      # ...
      spec:
        endpoints:
        - interval: 30s
          port: web
          scheme: http
        selector:
          matchLabels:
            app: prometheus-example-app
      # ...

      注記

      プロジェクトの表示パーミッションを持つ開発者として、サービスおよび ServiceMonitor リソースラベルを確認できます。

2. openshift-user-workload-monitoring プロジェクトの Prometheus Operator のログを検査します。

   1. openshift-user-workload-monitoring プロジェクトの Pod をリスト表示します。

      $ oc -n openshift-user-workload-monitoring get pods

      出力例

      NAME                                   READY   STATUS    RESTARTS   AGE
      prometheus-operator-776fcbbd56-2nbfm   2/2     Running   0          132m
      prometheus-user-workload-0             5/5     Running   1          132m
      prometheus-user-workload-1             5/5     Running   1          132m
      thanos-ruler-user-workload-0           3/3     Running   0          132m
      thanos-ruler-user-workload-1           3/3     Running   0          132m

   2. prometheus-operator Pod の prometheus-operator コンテナーからログを取得します。以下の例では、Pod は prometheus-operator-776fcbbd56-2nbfm になります。

      $ oc -n openshift-user-workload-monitoring logs prometheus-operator-776fcbbd56-2nbfm -c prometheus-operator

      サービスモニターに問題がある場合、ログには以下のようなエラーが含まれる可能性があります。

      level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload

3. OpenShift Container Platform Web コンソール UI の Metrics targets ページで、エンドポイントのターゲットステータスを確認 します。

   1. OpenShift Container Platform の Web コンソールにログインし、管理者 パースペクティブの Observe → Targets に移動します。
   2. リストでメトリックのエンドポイントを探し、Status 列でターゲットのステータスを確認します。
   3. Status が Down の場合、エンドポイントの URL をクリックすると、そのメトリックターゲットの Target Details ページで詳細情報を見ることができます。

4. openshift-user-workload-monitoring プロジェクトで Prometheus Operator のデバッグレベルのロギングを設定 します。

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

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

   2. prometheusOperator の logLevel: debug を data/config.yaml に追加し、ログレベルを debug に設定します。

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

   3. 変更を適用するためにファイルを保存します。

      注記

      openshift-user-workload-monitoring プロジェクトの prometheus-operator は、ログレベルの変更時に自動的に再起動します。

   4. debug ログレベルが openshift-user-workload-monitoring プロジェクトの prometheus-operator デプロイメントに適用されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get deploy prometheus-operator -o yaml |  grep "log-level"

      出力例

              - --log-level=debug

      debug レベルのロギングにより、Prometheus Operator によって行われるすべての呼び出しが表示されます。

   5. prometheus-operator Pod が実行されていることを確認します。

      $ oc -n openshift-user-workload-monitoring get pods

      注記

      認識されない Prometheus Operator の loglevel 値が設定マップに含まれる場合、prometheus-operator Pod が正常に再起動されない可能性があります。

   6. デバッグログを確認し、Prometheus Operator が ServiceMonitor リソースを使用しているかどうかを確認します。ログで他の関連するエラーの有無を確認します。

手順

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

2. Expression フィールドで、以下の Prometheus Query Language (PromQL) クエリーを実行します。これにより、収集サンプルの数が最も多い 10 メトリックが返されます。

   topk(10,count by (job)({__name__=~".+"}))

3. 予想されるよりも多くの収集サンプルを持つメトリックに割り当てられたバインドされていないラベル値の数を調査します。

   • メトリックがユーザー定義のプロジェクトに関連する場合、ワークロードに割り当てられたメトリックのキーと値のペアを確認します。これらのライブラリーは、アプリケーションレベルで Prometheus クライアントライブラリーを使用して実装されます。ラベルで参照されるバインドされていない属性の数の制限を試行します。
   • メトリクスが OpenShift Container Platform のコアプロジェクトに関連する場合、Red Hat サポートケースを Red Hat カスタマーポータル で作成してください。

4. クラスター管理者として以下のコマンドを実行して、Prometheus HTTP API を使用して TSDB ステータスを確認します。

   $ oc login -u <username> -p <password>

   $ host=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})

   $ token=$(oc whoami -t)

   $ curl -H "Authorization: Bearer $token" -k "https://$host/api/v1/status/tsdb"

   出力例

   "status": "success",