ストレージ

Prometheus にはローカルのディスク上時系列データベースが含まれていますが、リモートストレージシステムとの統合もオプションで提供されています。

ローカルストレージ

Prometheus のローカル時系列データベースは、カスタムで非常に効率的な形式でローカルストレージにデータを保存します。

ディスク上のレイアウト

取り込まれたサンプルは2時間ごとのブロックにグループ化されます。各2時間ブロックは、その期間のすべての時系列サンプルの `chunks` サブディレクトリ、メタデータファイル、およびインデックスファイル（メトリック名とラベルをチャンクディレクトリ内の時系列にインデックス付けする）を含むディレクトリで構成されます。`chunks` ディレクトリ内のサンプルは、デフォルトで最大512MBの1つ以上のセグメントファイルにグループ化されます。API経由でシリーズが削除されると、削除レコードはチャンクセグメントからのデータ削除の代わりに、別の墓石ファイルに保存されます。

着信サンプルの現在のブロックはメモリ内に保持され、完全に永続化されません。これは、Prometheus サーバーの再起動時に再生できるライトアヘッドログ（WAL）によってクラッシュから保護されています。ライトアヘッドログファイルは `wal` ディレクトリに128MBセグメントで格納されます。これらのファイルには、まだコンパクト化されていない生のデータが含まれているため、通常のブロックファイルよりも大幅に大きくなります。Prometheus は最低3つのライトアヘッドログファイルを保持します。高トラフィックサーバーは、少なくとも2時間の生のデータを保持するために、3つ以上のWALファイルを保持する場合があります。

Prometheus サーバーのデータディレクトリは、次のような構造になります。

./data
├── 01BKGV7JBM69T2G1BGBGM6KB12
│   └── meta.json
├── 01BKGTZQ1SYQJTR4PB43C8PD98
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K
│   └── meta.json
├── 01BKGV7JC0RY8A6MACW02A2PJD
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
├── chunks_head
│   └── 000001
└── wal
    ├── 000000002
    └── checkpoint.00000001
        └── 00000000

ローカルストレージの制限として、クラスタリングやレプリケーションが行われていないことに注意してください。したがって、ドライブやノードの障害に際して、任意のスケーラビリティや耐久性があるわけではなく、他の単一ノードデータベースと同様に管理する必要があります。

スナップショットがバックアップのために推奨されます。スナップショットなしで行われたバックアップは、最後のWAL同期以降に記録されたデータを失うリスクがあります。WAL同期は通常2時間ごとに発生します。適切なアーキテクチャがあれば、ローカルストレージで数年間のデータを保持することが可能です。

あるいは、リモート読み書きAPI を介して外部ストレージを使用できます。これらのシステムは、耐久性、パフォーマンス、効率性が大きく異なるため、注意深い評価が必要です。

ファイルフォーマットの詳細については、TSDB フォーマットを参照してください。

コンパクト化

最初の2時間ブロックは、バックグラウンドでより長いブロックに最終的にコンパクト化されます。

コンパクト化により、保持期間の10%または31日（いずれか短い方）にわたるより大きなブロックが作成されます。

運用上の側面

Prometheus にはローカルストレージを設定するためのいくつかのフラグがあります。最も重要なのは次のとおりです。

--storage.tsdb.path: Prometheus がデータベースを書き込む場所。デフォルトは data/ です。
--storage.tsdb.retention.time: ストレージにサンプルを保持する期間。このフラグまたは storage.tsdb.retention.size のいずれも設定されていない場合、保持期間はデフォルトで 15d になります。サポートされる単位：y、w、d、h、m、s、ms。
--storage.tsdb.retention.size: 保持するストレージブロックの最大バイト数。最も古いデータが最初に削除されます。デフォルトは 0 または無効です。サポートされる単位：B、KB、MB、GB、TB、PB、EB。例：「512MB」。2のべき乗に基づいているため、1KBは1024Bです。永続化されたブロックのみがこの保持を尊重するために削除されますが、WALおよびmマップされたチャンクは合計サイズに含まれます。したがって、ディスクの最小要件は、wal（WALとチェックポイント）およびchunks_head（mマップされたHeadチャンク）ディレクトリの合計ピークスペース（2時間ごと）です。
--storage.tsdb.wal-compression: ライトアヘッドログ（WAL）の圧縮を有効にします。データによっては、CPU負荷をほとんどかけずにWALサイズを半分にできると期待できます。このフラグは2.11.0で導入され、2.20.0ではデフォルトで有効になりました。有効にすると、Prometheus を2.11.0未満のバージョンにダウングレードするには、WALを削除する必要があることに注意してください。

Prometheus サーバーは、サンプルあたり平均1〜2バイトしか格納しません。したがって、Prometheus サーバーの容量を計画するには、次の概算式を使用できます。

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

取り込みサンプルのレートを下げるには、スクレイピングする時系列の数を減らす（ターゲットを少なくするか、ターゲットあたりのシリーズを少なくする）、またはスクレイプ間隔を長くすることができます。ただし、シリーズ内のサンプルの圧縮により、シリーズ数を減らす方が効果的である可能性が高いです。

ローカルストレージが破損して Prometheus が起動しなくなった場合、ストレージディレクトリをバックアップし、破損したブロックディレクトリをバックアップから復元することをお勧めします。バックアップがない場合は、最後の手段として破損したファイルを削除します。たとえば、個々のブロックディレクトリまたはライトアヘッドログ（WAL）ファイルを削除してみてください。これは、それらのブロックまたはWALがカバーする期間のデータを失うことを意味します。

注意復旧不能な破損が発生する可能性があるため、POSIXに準拠しないファイルシステムは Prometheus のローカルストレージではサポートされていません。NFS ファイルシステム（AWS の EFS を含む）はサポートされていません。NFS は POSIX に準拠している可能性がありますが、ほとんどの実装は準拠していません。信頼性のためにローカルファイルシステムの使用を強く推奨します。

時間とサイズの保持ポリシーの両方が指定されている場合、最初にトリガーされた方が使用されます。

期限切れブロックのクリーンアップはバックグラウンドで行われます。期限切れブロックの削除には最大2時間かかる場合があります。ブロックは削除される前に完全に期限切れである必要があります。

保持サイズの適正化

storage.tsdb.retention.size を使用してサイズ制限を設定している場合は、この値の適切なサイズを Prometheus に割り当てたストレージに対して考慮する必要があります。保持サイズを減らしてバッファを提供することは賢明です。これにより、割り当てられた Prometheus ストレージがいっぱいになる前に、古いエントリが削除される可能性が高まります。

現在、保持サイズを割り当てられた Prometheus ディスクスペースの最大80〜85%に設定することをお勧めします。これにより、ディスク制限に達する前に古いエントリが削除される可能性が高まります。

リモートストレージ統合

Prometheus のローカルストレージは、単一ノードのスケーラビリティと耐久性に限定されます。Prometheus 自体でクラスタリングストレージを解決しようとするのではなく、Prometheus はリモートストレージシステムとの統合を可能にする一連のインターフェースを提供します。

概要

Prometheus は4つの方法でリモートストレージシステムと統合します。

Prometheus は、取り込んだサンプルを Remote Write フォーマットでリモートURLに書き込むことができます。
Prometheus は、Remote Write フォーマットで他のクライアントからサンプルを受信できます。
Prometheus は、Remote Read フォーマットでリモートURLからサンプルデータを読み取ることができます（バックフィル）。
Prometheus は、Remote Read フォーマットでクライアントから要求されたサンプルデータを返すことができます。

Remote read and write architecture

リモート読み書きプロトコルは両方とも、HTTP経由でスナッピー圧縮されたプロトコルバッファエンコーディングを使用します。読み取りプロトコルはまだ安定したAPIとは見なされていません。

書き込みプロトコルには、Prometheus サーバーでサポートされている、バージョン1.0の安定した仕様とバージョン2.0の実験的な仕様があります。

Prometheus でクライアントとしてリモートストレージ統合を設定する方法については、Prometheus 設定ドキュメントのリモート書き込みおよびリモート読み取りセクションを参照してください。

読み取りパスでは、Prometheus はラベルセレクターと時間範囲のセットの生のシリーズデータのみをリモートエンドから取得することに注意してください。すべてのPromQL評価は、生のデータに対してPrometheus自体で行われます。これは、リモート読み取りクエリにはスケーラビリティの限界があることを意味します。なぜなら、必要なすべてのデータをまずクエリしているPrometheusサーバーにロードしてから、そこで処理する必要があるからです。ただし、PromQLの完全に分散された評価のサポートは、現時点では非現実的と見なされています。

Prometheus は両方のプロトコルも提供します。組み込みのリモート書き込みレシーバーは、--web.enable-remote-write-receiver コマンドラインフラグを設定することで有効にできます。有効にすると、リモート書き込みレシーバーエンドポイントは /api/v1/write になります。リモート読み取りエンドポイントは /api/v1/read で利用可能です。

既存の統合

リモートストレージシステムとの既存の統合についてさらに詳しく知るには、統合ドキュメントを参照してください。

OpenMetrics フォーマットからのバックフィル

概要

ユーザーが OpenMetrics フォーマットのデータを TSDB にブロックとして作成したい場合、バックフィルを使用して行うことができます。ただし、注意が必要で、最後の3時間（現在のヘッドブロック）からのデータのバックフィルは安全ではないことに注意してください。この期間は、Prometheus がまだ変更中の現在のヘッドブロックと重複する可能性があるためです。バックフィルは、2時間分のメトリックデータを含む新しい TSDB ブロックを作成します。これにより、ブロック作成のメモリ要件が制限されます。2時間ブロックをより大きなブロックにコンパクト化することは、後で Prometheus サーバー自体によって行われます。

典型的なユースケースは、異なる監視システムまたは時系列データベースから Prometheus にメトリックデータを移行することです。これを行うには、ユーザーはまずソースデータを OpenMetrics フォーマットに変換する必要があります。これは、以下で説明するバックフィルの入力フォーマットです。

ネイティブヒストグラムとステールネスマーカーは、OpenMetrics フォーマットで表現できないため、この手順ではサポートされていないことに注意してください。

使用方法

バックフィルは `promtool` コマンドラインから使用できます。`promtool` はブロックをディレクトリに書き込みます。デフォルトではこの出力ディレクトリは `./data/` ですが、サブコマンドのオプション引数として目的の出力ディレクトリ名を指定することで変更できます。

promtool tsdb create-blocks-from openmetrics <input file> [<output directory>]

ブロック作成後、Prometheus のデータディレクトリに移動してください。既存の Prometheus ブロックと重複がある場合、Prometheus バージョン v2.38 以前では `--storage.tsdb.allow-overlapping-blocks` フラグを設定する必要があります。バックフィルされたデータは、Prometheus サーバーで設定された保持期間（時間またはサイズ）の対象となることに注意してください。

より長いブロック期間

デフォルトでは、promtool はブロックにデフォルトのブロック期間（2時間）を使用します。この動作は最も一般的で正確です。ただし、長期間のデータをバックフィルする場合、バックフィルを高速化し、後で TSDB による追加のコンパクト化を防ぐために、ブロック期間に大きな値を使用すると有利な場合があります。

--max-block-duration フラグにより、ユーザーはブロックの最大期間を設定できます。バックフィルツールはこの値以下の適切なブロック期間を選択します。

より大きなブロックは大量のデータセットのバックフィルのパフォーマンスを向上させる可能性がありますが、欠点もあります。時間ベースの保持ポリシーでは、（潜在的に大きな）ブロックのサンプルが1つでも保持ポリシー内にある場合、ブロック全体を保持する必要があります。逆に、サイズベースの保持ポリシーでは、TSDB がサイズ制限をわずかに超えた場合でも、ブロック全体を削除します。

したがって、少数のブロックでバックフィル（つまり、より大きなブロック期間を選択）することは慎重に行う必要があり、本番環境インスタンスには推奨されません。

記録ルールのバックフィル

概要

新しい記録ルールが作成されると、そのルールには履歴データがありません。記録ルールのデータは作成時間以降のみ存在します。promtool は、履歴記録ルールデータを作成することを可能にします。

使用方法

すべてのオプションを表示するには、次を使用します: $ promtool tsdb create-blocks-from rules --help。

使用例

$ promtool tsdb create-blocks-from rules \
    --start 1617079873 \
    --end 1617097873 \
    --url http://mypromserver.com:9090 \
    rules.yaml rules2.yaml

提供される記録ルールファイルは、通常のPrometheus ルールファイルである必要があります。

promtool tsdb create-blocks-from rules コマンドの出力は、記録ルールファイル内のすべてのルールの履歴ルールデータを含むブロックを含むディレクトリです。デフォルトでは、出力ディレクトリは data/ です。この新しいブロックデータを使用するには、ブロックを実行中の Prometheus インスタンスのデータディレクトリ storage.tsdb.path に移動する必要があります（Prometheus バージョン v2.38 以前では、--storage.tsdb.allow-overlapping-blocks フラグを有効にする必要があります）。移動後、次のコンパクト化が実行されるときに、新しいブロックは既存のブロックとマージされます。

制限事項

ルールバックフィラーを重複する開始/終了時刻で複数回実行すると、同じデータを含むブロックがルールバックフィラーの実行ごとに作成されます。
記録ルールファイル内のすべてのルールが評価されます。
記録ルールファイルに interval が設定されている場合、これはルールバックフィルコマンドの eval-interval フラグよりも優先されます。
現在、記録ルールファイルにあるアラートは無視されます。
同じグループ内のルールは、以前のルールの結果を参照できません。つまり、バックフィルされている他のルールを参照するルールはサポートされていません。回避策として、複数回バックフィルして、まず依存データを作成し（依存データを Prometheus サーバーのデータディレクトリに移動して Prometheus API からアクセスできるようにする）、依存データを作成します。

このページの内容