ストレージ

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

ローカルストレージ

Prometheusのローカル時系列データベースは、独自の非常に効率的なフォーマットでデータをローカルストレージに保存します。

ディスク上のレイアウト

取り込まれたサンプルは、2時間ごとのブロックにグループ化されます。各2時間ブロックは、その時間枠のすべての時系列サンプルを含む`chunks`サブディレクトリ、メタデータファイル、およびインデックスファイル（メトリック名とラベルを`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同期（通常は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-mappedチャンクは合計サイズにカウントされます。したがって、ディスクの最小要件は、`wal` (WALとチェックポイント) と`chunks_head` (m-mappedヘッドチャンク) ディレクトリを合わせたピークスペースです (2時間ごとにピークになります)。
--storage.tsdb.wal-compression: 先行書き込みログ (WAL) の圧縮を有効にします。データによっては、WAL サイズが半分になり、CPU 負荷はほとんど増えないと予想できます。このフラグは 2.11.0 で導入され、2.20.0 でデフォルトで有効になりました。一度有効にすると、Prometheus を 2.11.0 より前のバージョンにダウングレードするには WAL を削除する必要があることに注意してください。

Prometheus は、1サンプルあたり平均わずか1〜2バイトを保存します。したがって、Prometheus サーバーの容量を計画するには、おおよその式を使用できます。

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

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

Prometheus が起動しないほどローカルストレージが破損した場合は、ストレージディレクトリをバックアップし、バックアップから破損したブロックディレクトリを復元することをお勧めします。バックアップがない場合の最終手段は、破損したファイルを削除することです。たとえば、個々のブロックディレクトリまたは先行書き込みログ (wal) ファイルを削除してみてください。これは、これらのブロックまたは wal がカバーする期間のデータを失うことを意味することに注意してください。

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

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

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

適切な保持サイズの選択

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

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

リモートストレージ統合

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

概要

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

Prometheus は、取り込んだサンプルをリモート書き込み形式でリモート URL に書き込むことができます。
Prometheus は、他のクライアントからリモート書き込み形式でサンプルを受け取ることができます。
Prometheusは、リモート読み取り形式でリモート URL からサンプルデータを読み取る（戻す）ことができます。
Prometheus は、クライアントから要求されたサンプルデータをリモート読み取り形式で返すことができます。

Remote read and write architecture

リモート読み書きプロトコルはどちらも、HTTP 上で snappy 圧縮されたプロトコルバッファエンコーディングを使用します。読み取りプロトコルはまだ安定した API とはみなされていません。

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

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

読み取りパスでは、Prometheus はリモート側からラベルセレクターと時間範囲のセットに対して生の時系列データのみをフェッチすることに注意してください。生データに対するすべての PromQL 評価は、Prometheus 自体で行われます。これは、必要なすべてのデータが最初にクエリを実行する Prometheus サーバーにロードされ、そこで処理される必要があるため、リモート読み取りクエリにはスケーラビリティの限界があることを意味します。ただし、PromQL の完全に分散された評価をサポートすることは、当面は不可能であると判断されました。

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

既存の統合

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

OpenMetrics形式からのバックフィル

概要

ユーザーがOpenMetrics形式のデータからTSDBにブロックを作成したい場合、バックフィルを使用できます。ただし、最後の3時間（現在のヘッドブロック）のデータをバックフィルするのは安全ではないことに注意が必要です。この時間範囲は、Prometheusがまだ変更中の現在のヘッドブロックと重複する可能性があるためです。バックフィルは新しいTSDBブロックを作成し、それぞれに2時間分のメトリックデータが含まれます。これにより、ブロック作成のメモリ要件が制限されます。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 APIからアクセスできるように、依存データをPrometheusサーバーのデータディレクトリに移動する）ことです。

このページの内容