モニタリング

手順

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

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

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

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

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

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

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

手順

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

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

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

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

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

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

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

      注記

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

手順

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

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

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

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

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

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

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

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

        1

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

        2

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

        3

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

        注記

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

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

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

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

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

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

        1

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

        2

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

        3

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

        注記

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

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

手順

1. コアプラットフォームモニタリングコンポーネントを設定するには、openshift-monitoring namespace の cluster-monitoring-config config map オブジェクトを編集します。

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

2. 値を追加して、設定する各コアプラットフォームモニタリングコンポーネントのリソース制限と要求を定義します。

   重要

   制限に設定された値が、常に要求に設定された値よりも大きいことを確認してください。そうでない場合、エラーが発生し、コンテナーは実行されません。

   例

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |
       alertmanagerMain:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       prometheusK8s:
         resources:
           limits:
             cpu: 500m
             memory: 3Gi
           requests:
             cpu: 200m
             memory: 500Mi
       prometheusOperator:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       k8sPrometheusAdapter:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       kubeStateMetrics:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       telemeterClient:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       openshiftStateMetrics:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       thanosQuerier:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       nodeExporter:
         resources:
           limits:
             cpu: 50m
             memory: 150Mi
           requests:
             cpu: 20m
             memory: 50Mi
       monitoringPlugin:
         resources:
           limits:
             cpu: 500m
             memory: 1Gi
           requests:
             cpu: 200m
             memory: 500Mi
       prometheusOperatorAdmissionWebhook:
         resources:
           limits:
             cpu: 50m
             memory: 100Mi
           requests:
             cpu: 20m
             memory: 50Mi

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

手順

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

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

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

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

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

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

        1

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

        2

        既存のストレージクラスを指定します。ストレージクラスが指定されていない場合、デフォルトのストレージクラスが使用されます。

        3

        必要なストレージの量を指定します。

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

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

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

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

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

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

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

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

        1

        PVC を設定するユーザー定義の監視のコンポーネントを指定します。

        2

        既存のストレージクラスを指定します。ストレージクラスが指定されていない場合、デフォルトのストレージクラスが使用されます。

        3

        必要なストレージの量を指定します。

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

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

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

        注記

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

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

   警告

   PVC 設定で config map を更新すると、影響を受ける StatefulSet オブジェクトが再作成され、一時的なサービス停止が発生します。

手順

1. 更新されたストレージ要求を使用して PVC を手動で拡張します。詳細は、永続ボリュームの拡張 の「ファイルシステムを使用した永続ボリューム要求 (PVC) の拡張」を参照してください。

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

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

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

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

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

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

        1

        ストレージサイズを変更するコンポーネント。

        2

        ストレージボリュームの新しいサイズを指定します。前の値より大きくなければなりません。

        次の例では、コア OpenShift Container Platform コンポーネントを監視する Prometheus インスタンスの新しい PVC 要求を 100 ギガバイトに設定します。

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

   • ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:

     注記

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

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

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

     2. data/config.yaml 下のモニタリングコンポーネントの PVC 設定を更新します。

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

        1

        ストレージサイズを変更するコンポーネント。

        2

        ストレージボリュームの新しいサイズを指定します。前の値より大きくなければなりません。

        次の例では、Thanos Ruler の新しい PVC 要求を 20 ギガバイトに設定します。

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

        注記

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

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

   警告

   新しいストレージサイズで config map を更新すると、影響を受ける StatefulSet オブジェクトが再作成され、サービスが一時的に停止します。

手順

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

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

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

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

     2. 保持期間およびサイズ設定を data/config.yaml に追加します。

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

        1

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

        2

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

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

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

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

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

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

     2. 保持期間およびサイズ設定を data/config.yaml に追加します。

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

        1

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

        2

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

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

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

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

手順

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

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

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

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

   1

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

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

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

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

手順

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

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

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

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

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

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

        1

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

        2

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

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

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

        1

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

        2

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

        3

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

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

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

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

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

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

        1

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

        2

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

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

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

        1

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

        2

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

        3

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

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

手順

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

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

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

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

   1

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

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

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

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

手順

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

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

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

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

   1

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

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

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

   1

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

   2

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

   3

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

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

手順

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

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

   1

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

   2

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

   3

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

   4

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

   5

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

   6

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

   7

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

   8

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

   9

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

   10

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

   11

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

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

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

手順

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

4. Namespace フィールドで、アクセスを許可するプロジェクトを選択します。

   重要

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

5. Role Name リストからモニタリングロールまたはクラスターロールを選択します。
6. Subject セクションで、User を選択します。
7. Subject Name フィールドにユーザーの名前を入力します。
8. Create を選択して、ロールバインディングを適用します。

手順

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

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

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

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

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

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

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

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

   $ oc -n ns1 get pod

   出力例

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

手順

1. example-app-service-monitor.yaml という名前の新しい YAML 設定ファイルを作成します。

2. ServiceMonitor リソースを YAML ファイルに追加します。以下の例では、prometheus-example-monitor という名前のサービスモニターを作成し、ns1 namespace の prometheus-example-app サービスによって公開されるメトリクスを収集します。

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

   1

   サービスが実行されるユーザー定義の namespace を指定します。

   2

   Prometheus によってスクレープされるエンドポイントポートを指定します。

   3

   メタデータラベルに基づいてサービスに一致するようにセレクターを設定します。

   注記

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

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

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

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

4. ServiceMonitor リソースが実行されていることを確認します。

   $ oc -n <namespace> get servicemonitor

   出力例

   NAME                         AGE
   prometheus-example-monitor   81m

手順

1. OpenShift Container Platform Web コンソールの Administrator パースペクティブから、Observe → Metrics を選択します。

2. 1 つ以上のクエリーを追加するには、次のいずれかを実行します。

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

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

   注記

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

   注記

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

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

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

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

手順

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

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

   注記

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

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

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

1. OpenShift Container Platform Web コンソールで、Observe → Alerting → Alerts に移動します。
2. サイレントにしたいアラートに対して、 をクリックし、Silence alert を選択して、選択したアラートのデフォルト設定を含む Silence alert ページを開きます。

3. オプション: サイレントのデフォルト設定の詳細を変更します。

   注記

   サイレンスを保存する前にコメントを追加する必要があります。

4. サイレントを保存するには、Silence をクリックします。

1. OpenShift Container Platform Web コンソールで、Observe → <project_name> → Alerts に移動します。
2. 必要に応じて、アラート名の横にある大なり記号 (>) を選択し、アラートの詳細を展開します。
3. 展開されたビューでアラートメッセージをクリックすると、そのアラートの Alert details ページが開きます。
4. Silence alert をクリックして、アラートのデフォルト設定を含む Silence alert ページを開きます。

5. オプション: サイレントのデフォルト設定の詳細を変更します。

   注記

   サイレンスを保存する前にコメントを追加する必要があります。

6. サイレントを保存するには、Silence をクリックします。

1. OpenShift Container Platform Web コンソールで、Observe → Alerting → Silences に移動します。
2. Create silence をクリックします。

3. Create silence フォームで、アラートのスケジュール、期間、およびラベルの詳細を設定します。

   注記

   サイレンスを保存する前にコメントを追加する必要があります。

4. 入力したラベルと一致するアラートのサイレンスを作成するには、Silence をクリックします。

1. OpenShift Container Platform Web コンソールで、Observe → <project_name> → Silences に移動します。
2. Create silence をクリックします。

3. Create silence ページで、アラートの期間とラベルの詳細を設定します。

   注記

   サイレンスを保存する前にコメントを追加する必要があります。

4. 入力したラベルと一致するアラートのサイレンスを作成するには、Silence をクリックします。

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

2. 変更するサイレンスの をクリックして Edit silence を選択します。

   または、Actions をクリックし、サイレンスの Silence details ページで Edit silence を選択することもできます。

3. Edit silence ページで変更を加え、Silence をクリックします。これにより、既存のサイレンスが期限切れになり、更新された設定でサイレンスが作成されます。

1. Observe → <project_name> → Silences に移動します。

2. 変更するサイレンスの をクリックして Edit silence を選択します。

   または、Actions をクリックし、サイレンスの Silence details ページで Edit silence を選択することもできます。

3. Edit silence ページで変更を加え、Silence をクリックします。これにより、既存のサイレンスが期限切れになり、更新された設定でサイレンスが作成されます。

1. Observe → Alerting → Silences に移動します。
2. 期限切れにするサイレンスについては、対応する行のチェックボックスを選択します。

3. Expire 1 silence をクリックして選択した 1 つのサイレンスを期限切れにするか、Expire <n> silences をクリックして複数の沈黙を期限切れにします (<n> は選択した沈黙の数になります)。

   または、単一の沈黙を期限切れにするには、Actions をクリックし、サイレンスのSilence details ページで Expire silence を選択します。

1. Observe → <project_name> → Silences に移動します。
2. 期限切れにするサイレンスについては、対応する行のチェックボックスを選択します。

3. Expire 1 silence をクリックして選択した 1 つのサイレンスを期限切れにするか、Expire <n> silences をクリックして複数の沈黙を期限切れにします (<n> は選択した沈黙の数になります)。

   または、単一の沈黙を期限切れにするには、Actions をクリックし、サイレンスのSilence details ページで Expire silence を選択します。

手順

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

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

   apiVersion: monitoring.openshift.io/v1
   kind: AlertingRule
   metadata:
     name: example
     namespace: openshift-monitoring 1
   spec:
     groups:
     - name: example-rules
       rules:
       - alert: ExampleAlert 2
         for: 1m 3
         expr: vector(1) 4
         labels:
           severity: warning 5
         annotations:
           message: This is an example alert. 6

   1

   namespace が openshift-monitoring であることを確認します。

   2

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

   3

   アラートが発せられる前に条件が真である必要がある期間。

   4

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

   5

   アラートルールがアラートに割り当てる重大度。

   6

   アラートに関連付けられたメッセージ。

   重要

   openshift-monitoring namespace に AlertingRule オブジェクトを作成する必要があります。それ以外の場合は、アラートルールが受け入れられません。

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

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

手順

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

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

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

   1

   namespace が openshift-monitoring であることを確認します。

   2

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

   3

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

   4

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

   5

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

   6

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

   重要

   openshift-monitoring namespace に AlertRelabelConfig オブジェクトを作成する必要があります。それ以外の場合は、アラートラベルが変更しません。

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

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

手順

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

2. アラートルール設定を YAML ファイルに追加します。以下の例では、example-alert という名前の新規アラートルールを作成します。アラートルールは、サンプルサービスによって公開される version メトリクスが 0 になるとアラートを実行します。

   apiVersion: monitoring.coreos.com/v1
   kind: PrometheusRule
   metadata:
     name: example-alert
     namespace: ns1
   spec:
     groups:
     - name: example
       rules:
       - alert: VersionAlert 1
         for: 1m 2
         expr: version{job="prometheus-example-app"} == 0 3
         labels:
           severity: warning 4
         annotations:
           message: This is an example alert. 5

   1

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

   2

   アラートが発せられる前に条件が真である必要がある期間。

   3

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

   4

   アラートルールがアラートに割り当てる重大度。

   5

   アラートに関連付けられたメッセージ。

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

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

手順

1. <project> でアラートルールを一覧表示するには、以下を実行します。

   $ oc -n <project> get prometheusrule

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

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

手順

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

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

   注記

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

手順

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

   注記

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

2. ページの Receivers セクションで、Create Receiver をクリックします。
3. Create Receiver フォームで、Receiver name を追加し、リストから Receiver type を選択します。

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

   • PagerDuty receiver の場合:

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

   • Webhook receiver の場合:

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

   • メール receiver の場合:

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

   • Slack receiver の場合:

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

5. デフォルトでは、すべてのセレクターに一致するラベルを持つ Firing アラートが receiver に送信されます。receiver に送信する前に、Firing アラートのラベル値を完全に一致させる場合は、次の手順を実行します。

   1. フォームの Routing Labels セクションに、ルーティングラベルの名前と値を追加します。
   2. Add label を選択して、さらにルーティングラベルを追加します。
6. Create をクリックしてレシーバーを作成します。

手順

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

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

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

   注記

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

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

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

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

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

手順

1. Alertmanager の YAML 設定ファイルを開きます。

   • CLI から Alertmanager 設定を開くには、以下を実行します。

     1. 現在アクティブな Alertmanager 設定を、alertmanager-main シークレットから alertmanager.yaml ファイルに出力します。

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

     2. alertmanager.yaml ファイルを開きます。

   • OpenShift Container Platform Web コンソールから Alertmanager 設定を開くには、以下を実行します。

     1. Web コンソールの Administration → Cluster Settings → Configuration → Alertmanager → YAML ページに移動します。

2. YAML 内のパラメーターを更新して、Alertmanager 設定を編集します。

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

   1

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

   2

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

   3

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

   4

   アラートを発生させるサービスの名前を指定します。

   5

   アラートに一致するラベルを指定します。

   6

   アラートに使用するレシーバーの名前を指定します。

   7

   レシーバーの設定を指定します。

   重要
   • 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 レシーバーを介して送信されます。通常、この種のアラートは、個人または緊急対応チームに通知します。

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

   • CLI から変更を適用するには、次のコマンドを実行します。

     $ 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=-

   • OpenShift Container Platform Web コンソールから変更を適用するには、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> 3

   1

   アラートに一致するラベルを指定します。この例では、service="prometheus-example-monitor" ラベルを持つすべてのアラートを対象とします。

   2

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

   3

   レシーバーの設定を指定します。

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