モニタリング

手順

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

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

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

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

        Copy to Clipboard Toggle word wrap

     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>

        Copy to Clipboard Toggle word wrap

        <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

        Copy to Clipboard Toggle word wrap

        1

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

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

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

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

        Copy to Clipboard Toggle word wrap

     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>

        Copy to Clipboard Toggle word wrap

        <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

        Copy to Clipboard Toggle word wrap

        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

        Copy to Clipboard Toggle word wrap

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

        Copy to Clipboard Toggle word wrap

        <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

        Copy to Clipboard Toggle word wrap

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

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

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

        Copy to Clipboard Toggle word wrap

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

        Copy to Clipboard Toggle word wrap

        <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

        Copy to Clipboard Toggle word wrap

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

        Copy to Clipboard Toggle word wrap

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

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

        Copy to Clipboard Toggle word wrap

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

        Copy to Clipboard Toggle word wrap

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

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

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

        Copy to Clipboard Toggle word wrap

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

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

        Copy to Clipboard Toggle word wrap

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

        Copy to Clipboard Toggle word wrap

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

        Copy to Clipboard Toggle word wrap

     2. data/config.yaml の下にすべてのメトリクスについて追加する必要のあるラベルのマップを定義します。

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

        1

        Copy to Clipboard Toggle word wrap

        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

        Copy to Clipboard Toggle word wrap

   • カスタムラベルを、ユーザー定義のプロジェクトをモニターする Prometheus インスタンスから出るすべての時系列およびアラートに割り当てるには、以下を実行します。

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

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

        Copy to Clipboard Toggle word wrap

     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

        Copy to Clipboard Toggle word wrap

        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

        Copy to Clipboard Toggle word wrap

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

        Copy to Clipboard Toggle word wrap

     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

        Copy to Clipboard Toggle word wrap

        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

        Copy to Clipboard Toggle word wrap

     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

        Copy to Clipboard Toggle word wrap

        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"

   Copy to Clipboard Toggle word wrap

   出力例

           - --log-level=debug

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap
   注記

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

手順

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

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

   Copy to Clipboard Toggle word wrap

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

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

   1

   Copy to Clipboard Toggle word wrap

   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

   Copy to Clipboard Toggle word wrap

   出力例

   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

   Copy to Clipboard Toggle word wrap

手順

1. トークンを展開して Prometheus に接続します。

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

2. ルートホストを展開します。

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

   Copy to Clipboard Toggle word wrap

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

   $ NAMESPACE=ns1

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   出力には、アプリケーション 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"]}]}}

   Copy to Clipboard Toggle word wrap

手順

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

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

   Copy to Clipboard Toggle word wrap

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

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

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

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

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

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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>

   Copy to Clipboard Toggle word wrap

   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"

   Copy to Clipboard Toggle word wrap

   この設定では、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=-

   Copy to Clipboard Toggle word wrap