2.10. Configuring persistent storage
クラスターモニタリングを永続ストレージと共に実行すると、メトリクスは永続ボリューム (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-configConfigMapオブジェクトを作成している。
-
-
OpenShift CLI (
oc) がインストールされている。
手順
ConfigMapオブジェクトを編集します。OpenShift Container Platform のコアプロジェクトをモニターするコンポーネントの PVC を設定するには、以下を実行します。
openshift-monitoringプロジェクトでcluster-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
コンポーネントの 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 を設定するには、以下を実行します。
openshift-user-workload-monitoringプロジェクトでuser-workload-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
コンポーネントの 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コンポーネントのストレージ要件は、評価されルールの数や、各ルールが生成するサンプル数により異なります。
変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動され、新規ストレージ設定が適用されます。
注記user-workload-monitoring-configConfigMapオブジェクトに適用される設定は、クラスター管理者がユーザー定義プロジェクトのモニタリングを有効にしない限りアクティブにされません。
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-configConfigMapオブジェクトを作成している。 - ユーザー定義プロジェクトを監視するコンポーネント用に少なくとも 1 つの PVC を設定しました。
-
手順
ConfigMapオブジェクトを編集します。OpenShift Container Platform のコアプロジェクトをモニターするコンポーネントの PVC サイズを変更するには、以下を実行します。
openshift-monitoringプロジェクトでcluster-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
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以下の例では、コア 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 インスタンスのボリュームサイズを変更できます。
openshift-user-workload-monitoringプロジェクトでuser-workload-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
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次の例では、ユーザー定義のプロジェクトを監視する 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コンポーネントのストレージ要件は、評価されルールの数や、各ルールが生成するサンプル数により異なります。
変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動します。
警告monitoring config map への変更を保存すると、関連プロジェクトの Pod およびその他のリソースが再デプロイされる場合があります。そのプロジェクトで実行している監視プロセスも再開される可能性があります。
更新されたストレージ要求を使用して、すべての PVC に手動でパッチを適用します。以下の例では、
openshift-monitoringnamespace の 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--cascade=orphanパラメーターを使用して、基になる StatefulSet を削除します。$ oc delete statefulset -l app.kubernetes.io/name=prometheus --cascade=orphan
2.10.4. Prometheus メトリクスデータの保持期間およびサイズの変更
デフォルトでは、Prometheus は 15 日間メトリクスデータを自動的に保持します。Prometheus の保持時間を変更して、データが削除されるまでの時間を変更できます。保持されるメトリクスデータが使用するディスク容量の最大量を設定することもできます。データがこのサイズ制限に達すると、使用するディスク領域が上限を下回るまで、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の値を定義しておらず、pretentionの値のみを定義する場合、retention値のみが適用されます。
前提条件
OpenShift Container Platform のコアモニタリングコンポーネントを設定する場合、以下を実行します。
-
cluster-adminクラスターロールを持つユーザーとしてクラスターにアクセスできます。 -
cluster-monitoring-configConfigMapオブジェクトを作成している。
-
ユーザー定義のプロジェクトをモニターするコンポーネントを設定する場合:
- クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
-
cluster-adminクラスターロールを持つユーザーとして、またはopenshift-user-workload-monitoringプロジェクトのuser-workload-monitoring-config-editロールを持つユーザーとして、クラスターにアクセスできる。 -
user-workload-monitoring-configConfigMapオブジェクトを作成している。
-
OpenShift CLI (
oc) がインストールされている。
手順
ConfigMapオブジェクトを編集します。OpenShift Container Platform のコアプロジェクトをモニターする Prometheus インスタンスの保持時間とサイズを変更するに は、以下を実行します。
openshift-monitoringプロジェクトでcluster-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-monitoring edit configmap cluster-monitoring-config
保持期間およびサイズ設定を
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以下の例では、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 インスタンスの保持時間とサイズを変更するには、以下を実行します。
openshift-user-workload-monitoringプロジェクトでuser-workload-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
保持期間およびサイズ設定を
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次の例では、ユーザー定義プロジェクトを監視する 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
変更を適用するためにファイルを保存します。新規設定の影響を受けた Pod は自動的に再起動します。
警告変更がモニタリング設定マップに保存されると、関連するプロジェクトの Pod およびその他のリソースが再デプロイされる可能性があります。該当するプロジェクトの実行中のモニタリングプロセスも再起動する可能性があります。
2.10.5. Thanos Ruler メトリクスデータの保持期間の変更
デフォルトでは、ユーザー定義のプロジェクトでは、Thanos Ruler は 24 時間にわたりメトリクスデータを自動的に保持します。openshift-user-workload-monitoring namespace の user-workload-monitoring-config の Config Map に時間の値を指定して、このデータの保持期間を変更できます。
前提条件
-
cluster-adminクラスターロールを持つユーザーとして、またはopenshift-user-workload-monitoringプロジェクトのuser-workload-monitoring-config-editロールを持つユーザーとして、クラスターにアクセスできる。 - クラスター管理者は、ユーザー定義プロジェクトのモニタリングを有効にしている。
-
user-workload-monitoring-configConfigMapオブジェクトを作成している。 -
OpenShift CLI (
oc) がインストールされている。
手順
openshift-user-workload-monitoringプロジェクトでuser-workload-monitoring-configConfigMapオブジェクトを編集します。$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
保持期間の設定を
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変更を適用するためにファイルを保存します。新規設定が加えられた Pod は自動的に再起動します。
警告監視設定マップの変更を保存すると、監視プロセスが再起動し、関連プロジェクトの Pod やその他のリソースが再デプロイされる場合があります。そのプロジェクトで実行中のモニタリングプロセスも再起動する場合があります。