3.2. モニタリングスタックの設定

手順

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

   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 リソース要求を定義します。

2. ファイルを保存して、変更を ConfigMap オブジェクトに適用します。

   警告

   ConfigMap オブジェクトの設定変更によって、結果も異なります。

   • Pod は再デプロイされません。したがって、サービスの停止はありません。

   • 変更された Pod が再デプロイされます。

     • 単一ノードクラスターの場合、一時的なサービスが停止します。
     • マルチノードクラスターの場合、高可用性であるため、影響を受ける Pod は徐々にロールアウトされ、モニタリングスタックは引き続き利用可能です。
     • 永続ボリュームの設定およびサイズ変更を行うと、高可用性であるかどうかに関係なく、常にサービスが停止します。

   config map の変更を必要とする手順にはそれぞれ、想定される結果が含まれます。