検索
サポートコンソール開発者トライアルの開始お問い合わせ

2.10. Configuring persistent storage

download PDF

クラスターモニタリングを永続ストレージと共に実行すると、メトリクスは永続ボリューム (PV) に保存され、Pod の再起動または再作成後も維持されます。これは、メトリックデータまたはアラートデータをデータ損失から保護する必要がある場合に適しています。実稼働環境では、永続ストレージを設定することを強く推奨します。IO デマンドが高いため、ローカルストレージを使用することが有利になります。

2.10.1. 永続ストレージの前提条件

  • ディスクが一杯にならないように、十分なローカル永続ストレージを確保します。必要な永続ストレージは Pod 数によって異なります。
  • 永続ボリューム要求 (PVC) で要求される永続ボリューム (PV) が利用できる状態にあることを確認する必要があります。各レプリカに 1 つの PV が必要です。Prometheus と Alertmanager の両方に 2 つのレプリカがあるため、モニタリングスタック全体をサポートするには 4 つの PV が必要です。PV はローカルストレージ Operator から入手できますが、動的にプロビジョニングされるストレージが有効にされている場合は利用できません。

  • 永続ボリュームを設定する際に、volumeMode パラメーターのストレージタイプ値として Filesystem を使用します。

    注記

    永続ストレージにローカルボリュームを使用する場合は、LocalVolume オブジェクトの volumeMode: Block で記述される raw ブロックボリュームを使用しないでください。Prometheus は raw ブロックボリュームを使用できません。

    重要

    Prometheus は、POSIX に準拠していないファイルシステムをサポートしません。たとえば、一部の NFS ファイルシステム実装は POSIX に準拠していません。ストレージに NFS ファイルシステムを使用する場合は、NFS 実装が完全に POSIX に準拠していることをベンダーに確認してください。

2.10.2. ローカ永続ボリューム要求 (PVC) の設定

モニタリングコンポーネントが永続ボリューム (PV) を使用できるようにするには、永続ボリューム要求 (PVC) を設定する必要があります。

前提条件

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

    • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできます。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。

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

    • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。

手順

  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>:
      volumeClaimTemplate:
        spec:
          storageClassName: <storage_class>
          resources:
            requests:
              storage: <amount_of_storage>

        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: local-storage
          resources:
            requests:
              storage: 40Gi

        上記の例では、ローカルストレージ Operator によって作成されるストレージクラスは local-storage と呼ばれます。

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

        apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    alertmanagerMain:
      volumeClaimTemplate:
        spec:
          storageClassName: local-storage
          resources:
            requests:
              storage: 10Gi

    • ユーザー定義プロジェクトをモニターするコンポーネントの 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>:
      volumeClaimTemplate:
        spec:
          storageClassName: <storage_class>
          resources:
            requests:
              storage: <amount_of_storage>

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

        以下の例では、ユーザー定義プロジェクトをモニターする Prometheus インスタンスのローカル永続ストレージを要求する PVC を設定します。 

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

        上記の例では、ローカルストレージ Operator によって作成されるストレージクラスは local-storage と呼ばれます。

        以下の例では、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: local-storage
          resources:
            requests:
              storage: 10Gi
        注記

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

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

    注記

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

    警告

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

2.10.3. 永続ストレージボリュームのサイズ変更

OpenShift Container Platform は、使用される基礎となる StorageClass リソースが永続的なボリュームのサイズ変更をサポートしている場合でも、StatefulSet リソースによって使用される既存の永続的なストレージボリュームのサイズ変更をサポートしません。したがって、既存の永続ボリューム要求 (PVC) の storage フィールドをより大きなサイズで更新しても、この設定は関連する永続ボリューム (PV) に反映されません。

ただし、手動プロセスを使用して PV のサイズを変更することは可能です。Prometheus、Thanos Ruler、Alertmanager などのモニタリングコンポーネントの PV のサイズを変更する場合は、コンポーネントが設定されている適切な設定マップを更新できます。次に、PVC にパッチを適用し、Pod を削除して孤立させます。Pod を孤立させると、StatefulSet リソースがすぐに再作成され、Pod にマウントされたボリュームのサイズが新しい PVC 設定で自動的に更新されます。このプロセス中にサービスの中断は発生しません。

前提条件

  • OpenShift CLI (oc) がインストールされている。

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

    • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできます。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。
    • コア OpenShift Container Platform モニタリングコンポーネント用に少なくとも 1 つの PVC を設定しました。

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

    • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
    • ユーザー定義プロジェクトを監視するコンポーネント用に少なくとも 1 つの PVC を設定しました。

手順

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

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

      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:
          storageClassName: <storage_class> 2
          resources:
            requests:
              storage: <amount_of_storage> 3
        1
        コアモニタリングコンポーネントを指定します。
        2
        ストレージクラスを作成します。
        3
        ストレージボリュームの新しいサイズを指定します。

        以下の例では、コア OpenShift Container Platform コンポーネントをモニターする Prometheus インスタンスのローカル永続ストレージを 100 ギガバイトに設定する PVC を設定します。 

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

        次の例では、Alertmanager のローカル永続ストレージを 40 ギガバイトに設定する PVC を設定します。 

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

    • ユーザー定義プロジェクトを監視するコンポーネントの PVC のサイズを変更するには:

      注記

      ユーザー定義のプロジェクトを監視する Thanos Ruler および 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:
          storageClassName: <storage_class> 2
          resources:
            requests:
              storage: <amount_of_storage> 3
        1
        コアモニタリングコンポーネントを指定します。
        2
        ストレージクラスを作成します。
        3
        ストレージボリュームの新しいサイズを指定します。

        次の例では、ユーザー定義のプロジェクトを監視する Prometheus インスタンスの PVC サイズを 100 ギガバイトに設定します。 

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

        次の例では、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:
          storageClassName: local-storage
          resources:
            requests:
              storage: 20Gi
        注記

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

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

    警告

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

  3. 更新されたストレージ要求を使用して、すべての PVC に手動でパッチを適用します。以下の例では、openshift-monitoring namespace の Prometheus コンポーネントのストレージサイズを 100Gi に変更します。 

    $ for p in $(oc -n openshift-monitoring get pvc -l app.kubernetes.io/name=prometheus -o jsonpath='{range .items[*]}{.metadata.name} {end}'); do \
  oc -n openshift-monitoring patch pvc/${p} --patch '{"spec": {"resources": {"requests": {"storage":"100Gi"}}}}'; \
  done

  4. --cascade=orphan パラメーターを使用して、基になる StatefulSet を削除します。 

    $ oc delete statefulset -l app.kubernetes.io/name=prometheus --cascade=orphan

2.10.4. Prometheus メトリックデータの保持期間およびサイズの変更

デフォルトでは、Prometheus は 15 日間メトリックデータを自動的に保持します。retention フィールドに time 値を指定すると、保持期間を変更し、データの削除方法を変更できます。retentionSize フィールドにサイズの値を指定することで、保持されたメトリックデータが使用する最大ディスク領域を設定することもできます。データがこのサイズ制限に達すると、使用するディスク領域が上限を下回るまで、Prometheus は最も古いデータを削除します。

これらのデータ保持設定は、以下の挙動に注意してください。

  • サイズベースのリテンションポリシーは、/prometheus ディレクトリー内のすべてのデータブロックディレクトリーに適用され、永続ブロック、ライトアヘッドログ (WAL) データ、および m-mapped チャンクも含まれます。
  • wal と /head_chunks ディレクトリーのデータは保持サイズ制限にカウントされますが、Prometheus はサイズまたは時間ベースの保持ポリシーに基づいてこれらのディレクトリーからデータをパージすることはありません。したがって、/wal ディレクトリーおよび /head_chunks ディレクトリーに設定された最大サイズよりも低い保持サイズ制限を設定すると、/prometheus データディレクトリーにデータブロックを保持しないようにシステムを設定している。
  • サイズベースの保持ポリシーは、Prometheus が新規データブロックをカットする場合にのみ適用されます。これは、WAL に少なくとも 3 時間のデータが含まれてから 2 時間ごとに実行されます。
  • retention または retentionSize のいずれかの値を明示的に定義しない場合、保持時間はデフォルトで 15 日に設定され、保持サイズは設定されません。
  • retention および retentionSize の両方に値を定義すると、両方の値が適用されます。データブロックが定義された保持時間または定義されたサイズ制限を超える場合、Prometheus はこれらのデータブロックをパージします。
  • retentionSize の値を定義して retention を定義しない場合、 retentionSize 値のみが適用されます。
  • retentionSize の値を定義しておらず、p retention の値のみを定義する場合、retention 値のみが適用されます。

前提条件

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

    • cluster-admin クラスターロールを持つユーザーとしてクラスターにアクセスできます。
    • cluster-monitoring-configConfigMap オブジェクトを作成している。

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

    • クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
    • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
    • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
  • OpenShift CLI (oc) がインストールされている。
警告

監視設定マップの変更を保存すると、監視プロセスが再起動し、関連プロジェクトの 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:
      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 は自動的に再起動します。

2.10.5. Thanos Ruler メトリックデータの保持期間の変更

デフォルトでは、ユーザー定義のプロジェクトでは、Thanos Ruler は 24 時間にわたりメトリックデータを自動的に保持します。openshift-user-workload-monitoring namespace の user-workload-monitoring-config の Config Map に時間の値を指定して、このデータの保持期間を変更できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
  • cluster-admin クラスターロールを持つユーザーとして、または openshift-user-workload-monitoring プロジェクトの user-workload-monitoring-config-edit ロールを持つユーザーとして、クラスターにアクセスできる。
  • user-workload-monitoring-config ConfigMap オブジェクトを作成している。
警告

監視設定マップの変更を保存すると、監視プロセスが再起動し、関連プロジェクトの 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 は自動的に再起動します。

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.