3.7. 永続ストレージの設定
永続ストレージを使用してクラスターモニタリングを実行すると、次の利点が得られます。
- メトリクスとアラートデータを永続ボリューム (PV) に保存することで、データ損失から保護します。その結果、Pod が再起動または再作成されても存続できます。
- Alertmanager Pod が再起動したときに、重複した通知を受信したり、アラートの無音が失われたりすることを回避します。
実稼働環境では、永続ストレージを設定することを強く推奨します。
マルチノードクラスターでは、高可用性を実現するために、Prometheus、Alertmanager、および Thanos Ruler の永続ストレージを設定する必要があります。
3.7.1. 永続ストレージの前提条件
- ストレージのブロックタイプを使用します。
3.7.2. 永続ボリューム要求の設定
コンポーネントの監視に永続ボリューム (PV) を使用するには、永続ボリューム要求 (PVC) を設定する必要があります。
前提条件
-
dedicated-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
user-workload-monitoring-configConfigMapオブジェクトが存在します。このオブジェクトは、クラスターの作成時にデフォルトで作成されます。 -
OpenShift CLI (
oc) がインストールされている。
手順
ConfigMapオブジェクトを編集します。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>: 1 volumeClaimTemplate: spec: storageClassName: <storage_class> 2 resources: requests: storage: <amount_of_storage> 3volumeClaimTemplateの指定方法は、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コンポーネントのストレージ要件は、評価されルールの数や、各ルールが生成するサンプル数により異なります。
変更を適用するためにファイルを保存します。新しい設定の影響を受ける Pod は自動的に再デプロイされ、新しいストレージ設定が適用されます。
警告PVC 設定で config map を更新すると、影響を受ける
StatefulSetオブジェクトが再作成され、一時的なサービス停止が発生します。
3.7.3. Prometheus メトリクスデータの保持期間およびサイズの変更
デフォルトで、Prometheus がメトリクスデータを保持する期間のデフォルトは以下のとおりです。
- コアプラットフォームのモニタリング: 15 日間
- ユーザー定義プロジェクトの監視: 24 時間
データを削除するタイミングを変更するために、ユーザー定義のプロジェクトをモニターする Prometheus インスタンスの保持時間を変更できます。保持されるメトリクスデータが使用するディスク容量の最大量を設定することもできます。データがこのサイズ制限に達すると、使用するディスク領域が上限を下回るまで、Prometheus は最も古いデータを削除します。
これらのデータ保持設定は、以下の挙動に注意してください。
-
サイズベースのリテンションポリシーは、
/prometheusディレクトリー内のすべてのデータブロックディレクトリーに適用され、永続ブロック、ライトアヘッドログ (WAL) データ、および m-mapped チャンクも含まれます。 -
walと/head_chunksディレクトリーのデータは保持サイズ制限にカウントされますが、Prometheus はサイズまたは時間ベースの保持ポリシーに基づいてこれらのディレクトリーからデータをパージすることはありません。したがって、/walディレクトリーおよび/head_chunksディレクトリーに設定された最大サイズよりも低い保持サイズ制限を設定すると、/prometheusデータディレクトリーにデータブロックを保持しないようにシステムを設定している。 - サイズベースの保持ポリシーは、Prometheus が新規データブロックをカットする場合にのみ適用されます。これは、WAL に少なくとも 3 時間のデータが含まれてから 2 時間ごとに実行されます。
-
retentionまたはretentionSizeの値を明示的に定義しない場合、保持期間のデフォルトは、コアプラットフォームの監視は 15 日間、ユーザー定義プロジェクトの監視は 24 時間です。保持サイズは設定されていません。 -
retentionおよびretentionSizeの両方に値を定義すると、両方の値が適用されます。データブロックが定義された保持時間または定義されたサイズ制限を超える場合、Prometheus はこれらのデータブロックをパージします。 -
retentionSizeの値を定義してretentionを定義しない場合、retentionSize値のみが適用されます。 -
retentionSizeの値を定義しておらず、pretentionの値のみを定義する場合、retention値のみが適用されます。 -
retentionSizeまたはretentionの値を0に設定すると、デフォルト設定が適用されます。保持期間のデフォルト設定は、コアプラットフォームの監視の場合は 15 日間、ユーザー定義プロジェクトの監視の場合は 24 時間です。デフォルトでは、保持サイズは設定されていません。
データコンパクションは 2 時間ごとに実行されます。そのため、コンパクションが実行される前に永続ボリューム (PV) がいっぱいになり、retentionSize 制限を超える可能性があります。その場合、PV 上のスペースが retentionSize 制限を下回るまで、KubePersistentVolumeFillingUp アラートが発生します。
前提条件
-
dedicated-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
user-workload-monitoring-configConfigMapオブジェクトが存在します。このオブジェクトは、クラスターの作成時にデフォルトで作成されます。 -
OpenShift CLI (
oc) がインストールされている。
手順
ConfigMapオブジェクトを編集します。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 は自動的に再デプロイされます。
3.7.4. Thanos Ruler メトリクスデータの保持期間の変更
デフォルトでは、ユーザー定義のプロジェクトでは、Thanos Ruler は 24 時間にわたりメトリクスデータを自動的に保持します。openshift-user-workload-monitoring namespace の user-workload-monitoring-config の config map に時間の値を指定して、このデータの保持期間を変更できます。
前提条件
-
dedicated-adminロールを持つユーザーとしてクラスターにアクセスできる。 -
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 は自動的に再デプロイされます。
関連情報
