モニタリング

手順

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. コンポーネントの nodeSelector 制約を data/config.yaml に指定します。

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

        <component> を適宜置き換え、<node_key>: <node_value> を、宛先ノードのグループを指定するキーと値のペアのマップに置き換えます。通常は、単一のキーと値のペアのみが使用されます。

        コンポーネントは、指定されたキーと値のペアのそれぞれをラベルとして持つノードでのみ実行できます。ノードには追加のラベルを持たせることもできます。

        重要

        モニタリングコンポーネントの多くは、高可用性を維持するために、クラスターの異なるノード間で複数の Pod を使用してデプロイされます。モニタリングコンポーネントをラベル付きノードに移動する際には、コンポーネントの耐障害性を維持するために十分な数の一致するノードが利用可能であることを確認します。1 つのラベルのみが指定されている場合は、複数の別々のノードにコンポーネントに関連するすべての Pod を分散するために、十分な数のノードにそのラベルが含まれていることを確認します。または、複数のラベルを指定することもできます。その場合は、それぞれのラベルを個々のノードに関連付けます。

        注記

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

        たとえば、OpenShift Container Platform のコアプロジェクトのモニタリングコンポーネントを、 nodename: controlplane1、 nodename: worker1、nodename: worker2、および nodename: worker2 のラベルが付けられた特定のノードに移行するには、以下を使用します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: cluster-monitoring-config
          namespace: openshift-monitoring
        data:
          config.yaml: |
            prometheusOperator:
              nodeSelector:
                nodename: controlplane1
            prometheusK8s:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            alertmanagerMain:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            kubeStateMetrics:
              nodeSelector:
                nodename: worker1
            grafana:
              nodeSelector:
                nodename: worker1
            telemeterClient:
              nodeSelector:
                nodename: worker1
            k8sPrometheusAdapter:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            openshiftStateMetrics:
              nodeSelector:
                nodename: worker1
            thanosQuerier:
              nodeSelector:
                nodename: worker1
                nodename: worker2

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

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

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

     2. コンポーネントの nodeSelector 制約を data/config.yaml に指定します。

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

        <component> を適宜置き換え、<node_key>: <node_value> を、宛先ノードを指定するキーと値のペアのマップに置き換えます。通常は、単一のキーと値のペアのみが使用されます。

        コンポーネントは、指定されたキーと値のペアのそれぞれをラベルとして持つノードでのみ実行できます。ノードには追加のラベルを持たせることもできます。

        重要

        モニタリングコンポーネントの多くは、高可用性を維持するために、クラスターの異なるノード間で複数の Pod を使用してデプロイされます。モニタリングコンポーネントをラベル付きノードに移動する際には、コンポーネントの耐障害性を維持するために十分な数の一致するノードが利用可能であることを確認します。1 つのラベルのみが指定されている場合は、複数の別々のノードにコンポーネントに関連するすべての Pod を分散するために、十分な数のノードにそのラベルが含まれていることを確認します。または、複数のラベルを指定することもできます。その場合は、それぞれのラベルを個々のノードに関連付けます。

        注記

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

        たとえば、ユーザー定義プロジェクトのモニタリングコンポーネントを nodename: worker1、nodename: worker2、および nodename: worker2 のラベルが付けられた特定のワーカーノードに移行するには、以下を使用します。

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: user-workload-monitoring-config
          namespace: openshift-user-workload-monitoring
        data:
          config.yaml: |
            prometheusOperator:
              nodeSelector:
                nodename: worker1
            prometheus:
              nodeSelector:
                nodename: worker1
                nodename: worker2
            thanosRuler:
              nodeSelector:
                nodename: worker1
                nodename: worker2

2. 変更を適用するためにファイルを保存します。新しい設定の影響を受けるコンポーネントは新しいノードに自動的に移動します。

   注記

   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. 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

        ログレベルを適用するモニタリングコンポーネント。

        2

        コンポーネントに適用するログレベル。

   • 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

        ログレベルを適用するモニタリングコンポーネント。

        2

        コンポーネントに適用するログレベル。

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

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

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

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

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

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

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

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

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

1. Monitoring → <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
     group_interval: 5m
     repeat_interval: 12h
     receiver: default
     routes:
     - match:
         alertname: Watchdog
       repeat_interval: 5m
       receiver: watchdog
     - match:
         service: <your_service> 1
       routes:
       - match:
           <your_matching_rules> 2
         receiver: <receiver> 3
   receivers:
   - name: default
   - name: watchdog
   - name: <receiver>
   #  <receiver_configuration>

   1

   service は、アラートを発生させるサービスを指定します。

   2

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

   3

   receiver は、アラートに使用する受信手段を指定します。

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

   global:
     resolve_timeout: 5m
   route:
     group_wait: 30s
     group_interval: 5m
     repeat_interval: 12h
     receiver: default
     routes:
     - match:
         alertname: Watchdog
       repeat_interval: 5m
       receiver: watchdog
     - match: service: example-app routes: - match: 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 → Global Configuration → Alertmanager → YAML ページに移動します。
2. YAML 設定ファイルを変更します。
3. Save を選択します。

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブで、Monitoring → Dashboards に移動します。
2. Dashboard 一覧でダッシュボードを選択します。etcd や Prometheus ダッシュボードなどの一部のダッシュボードは、選択時に追加のサブメニューを生成します。
3. 必要に応じて、Time Range 一覧でグラフの時間範囲を選択します。
4. オプション: Refresh Interval を選択します。
5. 特定の項目についての詳細情報を表示するには、ダッシュボードの各グラフにカーソルを合わせます。

手順

1. OpenShift Container Platform Web コンソールの Developer パースペクティブで、Monitoring → Dashboard に移動します。
2. Project: 一覧でプロジェクトを選択します。
3. All Workloads 一覧でワークロードを選択します。
4. 必要に応じて、Time Range 一覧でグラフの時間範囲を選択します。
5. オプション: Refresh Interval を選択します。
6. 特定の項目についての詳細情報を表示するには、ダッシュボードの各グラフにカーソルを合わせます。

手順

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

   注記

   Developer パースペクティブから、サードパーティーの Alertmanager、Grafana、Prometheus、および Thanos Querier UI にアクセスすることはできません。代わりに Developer パースペクティブの Metrics UI リンクを使用します。これには、選択したプロジェクトの事前に定義された CPU、メモリー、帯域幅、およびネットワークパケットのクエリーが含まれます。

2. Project: 一覧で openshift-monitoring プロジェクトを選択します。

3. サードパーティーのモニタリング UI にアクセスします。

   • alertmanager-main 行の URL を選択し、Alertmanager UI のログインページを開きます。
   • grafana 行の URL を選択し、Grafana UI のログインページを開きます。
   • prometheus-k8s 行の URL を選択し、Prometheus UI のログインページを開きます。
   • thanos-querier 行の URL を選択し、Thanos Querier UI のログインページを開きます。
4. Log in with OpenShift を選択し、OpenShift Container Platform 認証情報を使用してログインします。

手順

1. 以下を実行して、openshift-monitoring プロジェクトのルートを一覧表示します。

   $ oc -n openshift-monitoring get routes

   出力例

   NAME                HOST/PORT                                                     ...
   alertmanager-main   alertmanager-main-openshift-monitoring.apps._url_.openshift.com ...
   grafana             grafana-openshift-monitoring.apps._url_.openshift.com           ...
   prometheus-k8s      prometheus-k8s-openshift-monitoring.apps._url_.openshift.com    ...
   thanos-querier      thanos-querier-openshift-monitoring.apps._url_.openshift.com    ...

2. Web ブラウザーを使用して HOST/PORT ルートに移動します。
3. Log in with OpenShift を選択し、OpenShift 認証情報を使用してログインします。

手順

1. 設定の YAML ファイルを作成します。この例では、これは deploy.yaml というファイルになります。

2. prometheus-adapter のサービスアカウント、必要なロールおよびロールバインディングを作成するための設定の詳細を追加します。

   kind: ServiceAccount
   apiVersion: v1
   metadata:
     name: custom-metrics-apiserver
     namespace: custom-prometheus
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: custom-metrics-server-resources
   rules:
   - apiGroups:
     - custom.metrics.k8s.io
     resources: ["*"]
     verbs: ["*"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: custom-metrics-resource-reader
   rules:
   - apiGroups:
     - ""
     resources:
     - namespaces
     - pods
     - services
     verbs:
     - get
     - list
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: custom-metrics:system:auth-delegator
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: system:auth-delegator
   subjects:
   - kind: ServiceAccount
     name: custom-metrics-apiserver
     namespace: custom-prometheus
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: custom-metrics-auth-reader
     namespace: kube-system
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: extension-apiserver-authentication-reader
   subjects:
   - kind: ServiceAccount
     name: custom-metrics-apiserver
     namespace: custom-prometheus
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: custom-metrics-resource-reader
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: custom-metrics-resource-reader
   subjects:
   - kind: ServiceAccount
     name: custom-metrics-apiserver
     namespace: custom-prometheus
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: hpa-controller-custom-metrics
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: custom-metrics-server-resources
   subjects:
   - kind: ServiceAccount
     name: horizontal-pod-autoscaler
     namespace: kube-system
   ---

3. prometheus-adapter のカスタムメトリクスの設定の詳細を追加します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: adapter-config
     namespace: custom-prometheus
   data:
     config.yaml: |
       rules:
       - seriesQuery: 'http_requests_total{namespace!="",pod!=""}' 1
         resources:
           overrides:
             namespace: {resource: "namespace"}
             pod: {resource: "pod"}
             service: {resource: "service"}
         name:
           matches: "^(.*)_total"
           as: "${1}_per_second" 2
         metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'
   ---

   1

   選択したメトリクスが HTTP 要求の数になるように指定します。

   2

   メトリクスの頻度を指定します。

4. prometheus-adapter を API サービスとして登録するための設定の詳細を追加します。

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       service.beta.openshift.io/serving-cert-secret-name: prometheus-adapter-tls
     labels:
       name: prometheus-adapter
     name: prometheus-adapter
     namespace: custom-prometheus
   spec:
     ports:
     - name: https
       port: 443
       targetPort: 6443
     selector:
       app: prometheus-adapter
     type: ClusterIP
   ---
   apiVersion: apiregistration.k8s.io/v1beta1
   kind: APIService
   metadata:
     name: v1beta1.custom.metrics.k8s.io
   spec:
     service:
       name: prometheus-adapter
       namespace: custom-prometheus
     group: custom.metrics.k8s.io
     version: v1beta1
     insecureSkipTLSVerify: true
     groupPriorityMinimum: 100
     versionPriority: 100
   ---

5. Prometheus アダプターイメージを一覧表示します。

   $ oc get -n openshift-monitoring deploy/prometheus-adapter -o jsonpath="{..image}"

6. prometheus-adapter をデプロイするための設定の詳細を追加します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app: prometheus-adapter
     name: prometheus-adapter
     namespace: custom-prometheus
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: prometheus-adapter
     template:
       metadata:
         labels:
           app: prometheus-adapter
         name: prometheus-adapter
       spec:
         serviceAccountName: custom-metrics-apiserver
         containers:
         - name: prometheus-adapter
           image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:a46915a206cd7d97f240687c618dd59e8848fcc3a0f51e281f3384153a12c3e0 1
           args:
           - --secure-port=6443
           - --tls-cert-file=/var/run/serving-cert/tls.crt
           - --tls-private-key-file=/var/run/serving-cert/tls.key
           - --logtostderr=true
           - --prometheus-url=http://prometheus-operated.default.svc:9090/
           - --metrics-relist-interval=1m
           - --v=4
           - --config=/etc/adapter/config.yaml
           ports:
           - containerPort: 6443
           volumeMounts:
           - mountPath: /var/run/serving-cert
             name: volume-serving-cert
             readOnly: true
           - mountPath: /etc/adapter/
             name: config
             readOnly: true
           - mountPath: /tmp
             name: tmp-vol
         volumes:
         - name: volume-serving-cert
           secret:
             secretName: prometheus-adapter-tls
         - name: config
           configMap:
             name: adapter-config
         - name: tmp-vol
           emptyDir: {}

   1

   直前の手順にある Prometheus Adapter イメージを指定します。

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

   $ oc apply -f deploy.yaml

   出力例

   serviceaccount/custom-metrics-apiserver created
   clusterrole.rbac.authorization.k8s.io/custom-metrics-server-resources created
   clusterrole.rbac.authorization.k8s.io/custom-metrics-resource-reader created
   clusterrolebinding.rbac.authorization.k8s.io/custom-metrics:system:auth-delegator created
   rolebinding.rbac.authorization.k8s.io/custom-metrics-auth-reader created
   clusterrolebinding.rbac.authorization.k8s.io/custom-metrics-resource-reader created
   clusterrolebinding.rbac.authorization.k8s.io/hpa-controller-custom-metrics created
   configmap/adapter-config created
   service/prometheus-adapter created
   apiservice.apiregistration.k8s.io/v1.custom.metrics.k8s.io created
   deployment.apps/prometheus-adapter created

8. ユーザー定義プロジェクトの prometheus-adapter Pod が Running 状態にあることを確認します。この例では、プロジェクトは custom-prometheus です。

   $ oc -n custom-prometheus get pods prometheus-adapter-<string>

9. アプリケーションのメトリクスが公開され、Horizontal Pod Autoscaling を設定するために使用できます。

手順

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

      出力例

      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. Prometheus UI でプロジェクトのターゲットステータスを直接確認します。

   1. openshift-user-workload-monitoring プロジェクトで Prometheus インスタンスへのポート転送を確立します。

      $ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090

   2. Web ブラウザーで http://localhost:9090/targets を開き、 Prometheus UI でプロジェクトのターゲットのステータスを直接確認します。ターゲットに関連するエラーメッセージがあるかどうかを確認します。

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 パースペクティブで、Monitoring → 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 UI で TSDB ステータスを確認します。

   1. Administrator パースペクティブで、Networking → Routes に移動します。
   2. Project: 一覧で openshift-monitoring プロジェクトを選択します。
   3. prometheus-k8s 行の URL を選択し、Prometheus UI のログインページを開きます。
   4. Log in with OpenShift を選択し、OpenShift Container Platform 認証情報を使用してログインします。
   5. Prometheus UI で、Status → TSDB Status に移動します。