Prometheus logo

Prometheus

ドキュメントダウンロードコミュニティサポート & トレーニングブログ

Ctrl + K

GitHub Logo

フィーチャーフラグ

以下は、破壊的な変更であったり、実験的な機能と見なされるため、デフォルトで無効になっている機能のリストです。これらの動作は将来のリリースで変更される可能性があり、その場合はリリース変更ログで通知されます。

--enable-featureフラグにカンマ区切りの機能リストを指定して有効にできます。将来のバージョンではデフォルトで有効になる可能性があります。

Exemplars storage

--enable-feature=exemplar-storage

OpenMetrics は、スキャンターゲットが特定のメトリックにエグザンプラーを追加できる機能を提供します。エグザンプラーは、MetricSet 外のデータへの参照です。一般的なユースケースは、プログラムトレースの ID です。

Exemplar storage は、すべてのシリーズのエグザンプラーをメモリに保存する固定サイズの円形バッファとして実装されています。この機能を有効にすると、Prometheus によってスキャンされたエグザンプラーの保存が有効になります。設定ファイルブロックの storage/exemplars を使用して、円形バッファのサイズをエグザンプラーの数で制御できます。trace_id=<jaeger-trace-id> のみを持つエグザンプラーは、インメモリのエグザンプラーストレージを介して約 100 バイトのメモリを使用します。エグザンプラーストレージが有効な場合、ローカル永続化のためにエグザンプラーを WAL に追加します（WAL 期間中）。

メモリのスナップショットをシャットダウン時に取得

--enable-feature=memory-snapshot-on-shutdown

これは、シャットダウン時にメモリ内にあるチャンクとシリーズ情報をスナップショットし、ディスクに保存します。これにより、メモリ状態がこのスナップショットと mmapped チャンクで復元できるため、起動時間が短縮され、ディスクからの WAL 再利用はスナップショットに含まれていない WAL の部分に対してのみ必要になります。

追加スキャンメトリック

--enable-feature=extra-scrape-metrics

有効にすると、各インスタンスのスキャンごとに、Prometheus は次の追加時系列にサンプルを保存します。

  • scrape_timeout_seconds。ターゲットの構成済み scrape_timeout。これにより、各ターゲットを測定して、タイムアウトまでの時間（scrape_duration_seconds / scrape_timeout_seconds）を把握できます。
  • scrape_sample_limit。ターゲットの構成済み sample_limit。これにより、各ターゲットを測定して、制限までの時間（scrape_samples_post_metric_relabeling / scrape_sample_limit）を把握できます。scrape_sample_limit は、制限が構成されていない場合はゼロになる可能性があることに注意してください。つまり、上記のクエリは制限のないターゲットに対して +Inf を返す可能性があります（ゼロで割っているため）。サンプル制限があるターゲットのみをクエリしたい場合は、次のクエリを使用してください：scrape_samples_post_metric_relabeling / (scrape_sample_limit > 0)。
  • scrape_body_size_bytes。成功した場合の最新のスキャン応答の非圧縮サイズ。body_size_limit を超えたために失敗したスキャンは -1 を報告し、その他のスキャン失敗は 0 を報告します。

ステップごとの統計情報

--enable-feature=promql-per-step-stats

有効にすると、クエリ要求に stats=all を渡すと、ステップごとの統計情報が返されます。現在、これは totalQueryableSamples に限定されています。

エンジンまたはクエリで無効にすると、ステップごとの統計情報は一切計算されません。

ネイティブヒストグラム

--enable-feature=native-histograms

有効にすると、Prometheus はネイティブヒストグラム（以前はスパースヒストグラムまたは高解像度ヒストグラムとも呼ばれていました）を取り込みます。ネイティブヒストグラムは依然として高度に実験的です。破壊的な変更が発生する可能性があります（TSDB が読み取れなくなるものを含む）。

ネイティブヒストグラムは現在、従来の Prometheus プロトコル バッファ（protobuf）エンコーディング形式のみをサポートしています。したがって、このフィーチャーフラグは、新しい（および同様に実験的な）protobuf パーサーも有効にします。このパーサーを通じて、すべてのメトリックが取り込まれます（つまり、ネイティブヒストグラムだけでなく）。Prometheus は、protobuf 形式を最初にネゴシエートしようとします。インストルメント化されたターゲットも protobuf 形式をサポートする必要があります。さらに、ネイティブヒストグラムを公開する必要があります。protobuf 形式では、従来のヒストグラムとネイティブヒストグラムを並べて公開できます。このフィーチャーフラグが無効な場合、Prometheus は（テキスト形式を介して）従来のヒストグラムを引き続き解析します。このフラグが有効な場合、Prometheus は、対応するネイティブヒストグラムが付属していない従来のヒストグラムも引き続き取り込みます。ただし、ネイティブヒストグラムが存在する場合、Prometheus は対応する従来のヒストグラムを無視します。ただし、エグザンプラーは例外であり、常に取り込まれます。従来のヒストグラムも保持するには、スキャンジョブで always_scrape_classic_histograms を有効にしてください。

実験的な PromQL 関数

--enable-feature=promql-experimental-functions

実験的と見なされる PromQL 関数を有効にします。これらの関数は、名前、構文、またはセマンティクスを変更する可能性があります。また、完全に削除される可能性もあります。

作成タイムスタンプゼロ注入

--enable-feature=created-timestamp-zero-ingestion

作成タイムスタンプの取り込みを有効にします。作成タイムスタンプは、適切な場合に 0 値のサンプルとして注入されます。詳細については、PromCon talk を参照してください。

現在、Prometheus は作成タイムスタンプを従来の Prometheus プロトコル バッファ（protobuf）プロトコルでのみサポートしています（他のプロトコルについては WIP）。したがって、この機能を有効にすると、Prometheus の protobuf スキャンプロトコルが優先されます（詳細については、scrape_config.scrape_protocols 設定を参照してください）。

Prometheus でこの機能を有効にするだけでなく、スキャンされるアプリケーションで作成タイムスタンプを公開する必要があります。

独立したルールの並行評価

--enable-feature=concurrent-rule-eval

デフォルトでは、ルールグループは並行して実行されますが、グループ内のルールは逐次実行されます。これは、ルールが前のルールの出力を入力として使用できるためです。ただし、ルール間に検出可能な関係がない場合は、逐次実行する必要はありません。concurrent-rule-eval フィーチャーフラグが有効になっている場合、ルールグループ内の他のルールに依存関係のないルールは並行して評価されます。これにより、より多くの並行クエリ負荷を追加する代償として、ルールグループの評価レイテンシとリソース使用率が向上する可能性があります。

並行ルール評価の数は、--rules.max-concurrent-rule-evals で構成でき、デフォルトは 4 です。

古い Prometheus UI を提供する

Prometheus 3.0 の一部としてリリースされた新しい UI ではなく、古い（Prometheus 2.x）Web UI を提供するフォールバック。新しい UI は完全な再作成であり、よりクリーンで、散らかりがなく、内部的に最新であることを目指しています。しかし、まだ完全に機能が充実しておらず、実証もされていないため、一部のユーザーは古い UI を使用することを好むかもしれません。

--enable-feature=old-ui

メタデータ WAL レコード

--enable-feature=metadata-wal-records

有効にすると、Prometheus はメタデータをメモリに格納し、シリーズごとにメタデータの変更を WAL レコードとして追跡します。

新しいリモート書き込み 2.0 を使用してメタデータを送信したい場合は、これを使用する必要があります。

コンパイル開始時間の遅延

--enable-feature=delayed-compaction

チャンク範囲の 10% までのランダムオフセットが、Head コンパイルの開始時間に加算されます。これにより、Prometheus インスタンスが同時にコンパイルすることを避け、共有リソースへの負荷を軽減できます。

自動 Head コンパイルのみ、およびそれらに直接起因する操作のみが、この遅延の対象となります。

連続する複数の Head コンパイルが可能な場合、最初のコンパイルのみがこの遅延を経験します。

この遅延中も、Head はサービス提供やシリーズの追加など、通常の操作を継続することに注意してください。

コンパイルが遅延しても、生成されるブロックは、遅延がない場合と同様の方法で時間的に整列されます。

PromQL エンジンの `__name__` ラベル削除の遅延

--enable-feature=promql-delayed-name-removal

有効にすると、Prometheus は PromQL クエリ結果から __name__ ラベルが削除される方法を変更します（派生メトリックを作成する式または関数の場合）。具体的には、式または関数が評価されるたびに削除するのではなく、クエリ評価の最後のステップまで削除を遅延させます。

これにより、label_replace および label_join 関数を介してオプションで __name__ ラベルを保持できるようになり、__name__ ラベルに正規表現マッチを適用した場合に発生する可能性のある「ベクトルは同じラベルセットを持つメトリックを含めることはできません」というエラーを防ぐのに役立ちます。

クエリの一部を個別に評価すると、依然としてラベルセットの衝突が発生することに注意してください。これは、中間結果を手動で、または PromLens のようなツールで分析する場合に一般的に発生します。

既に削除された __name__ ラベルを参照するクエリの場合、このフィーチャーフラグが設定されている間、その動作が変更される可能性があります。（例：sum by (__name__) (rate({foo="bar"}[5m]))、GitHub での詳細 を参照してください。）これらのクエリは発生頻度が低く、修正も容易です。（上記の例では、フィーチャーフラグなしで by (__name__) を削除しても何も変わりませんが、フィーチャーフラグの問題は解決されます。）

自動リロード設定

--enable-feature=auto-reload-config

有効にすると、Prometheus は指定された間隔で設定ファイルを自動的にリロードします。間隔は --config.auto-reload-interval フラグで定義され、デフォルトは 30s です。

設定のリロードは、メイン設定ファイルまたはルール設定やスキャン設定などの参照ファイルの内容のチェックサムの変更を検出することによってトリガーされます。一貫性を確保し、リロード中の問題を回避するために、これらのファイルをアトミックに更新することをお勧めします。

OTLP デルタ変換

--enable-feature=otlp-deltatocumulative

有効にすると、Prometheus は OTLP メトリックをデルタ一時性から累積一時性に変換します。ドロップしません。これは otlp-native-delta-ingestion とは同時に有効にできません。

これは、OTel コレクターの deltatocumulative を、デフォルト設定で使用します。

デルタ変換は、デルタ変更を時間とともに集計するためにインメモリ状態を保持します。Prometheus が再起動すると、この状態は失われ、集計はゼロから再度開始されます。これにより、累積シリーズのカウンターリセットが発生します。

この状態は、非アクティブなシリーズから定期的に（max_stale）クリアされます。

これを有効にすると、インメモリ状態は mutex で保護されているため、パフォーマンスに悪影響を与える可能性があります。累積のみの OTLP 要求には影響しません。

時間間隔での PromQL 算術式

--enable-feature=promql-duration-expr

このフラグを使用すると、範囲クエリの時間間隔やオフセット期間で算術式を使用できます。

範囲クエリでの

rate(http_requests_total[5m * 2])  # 10 minute range
rate(http_requests_total[(5+2) * 1m])  # 7 minute range

オフセット期間での

http_requests_total offset (1h / 2)  # 30 minute offset
http_requests_total offset ((2 ^ 3) * 1m)  # 8 minute offset

オフセットに期間式を使用する場合、式を括弧で囲む必要があります。括弧がない場合、オフセット計算では最初の期間値のみが使用されます。

step() は期間式で使用できます。範囲クエリの場合、範囲クエリのステップ幅に解決されます。インスタントクエリの場合、0s に解決されます。

min(<duration>, <duration>) および max(<duration>, <duration>) を使用して、2 つの期間式の最小値または最大値を見つけることができます。

注：期間式は @ タイムスタンプ演算子ではサポートされていません。

次の演算子がサポートされています。

  • + - 加算
  • - - 減算
  • * - 乗算
  • / - 除算
  • % - モジュロ
  • ^ - 指数

等価な期間の例

  • 5m * 2 は 10m または 600s と同等です。
  • 10m - 1m は 9m または 540s と同等です。
  • (5+2) * 1m は 7m または 420s と同等です。
  • 1h / 2 は 30m または 1800s と同等です。
  • 4h % 3h は 1h または 3600s と同等です。
  • (2 ^ 3) * 1m は 8m または 480s と同等です。
  • step() + 1 は、クエリステップ幅に 1 秒加算されたものと同等です。
  • max(step(), 5s) は、クエリステップ幅と 5s のうち大きい方と同等です。
  • min(2 * step() + 5s, 5m) は、クエリステップを 2 倍して 5s を加算したものと 5m のうち小さい方と同等です。

OTLP ネイティブデルタサポート

--enable-feature=otlp-native-delta-ingestion

有効にすると、デルタ OTLP メトリックのネイティブ取り込みが可能になり、変換せずに生のサンプル値を保存します。これは otlp-deltatocumulative とは同時に有効にできません。

現在、StartTimeUnixNano フィールドは無視され、デルタは不明なメトリックメタデータタイプとして扱われます。

デルタサポートは開発の非常に初期段階にあり、取り込みおよびクエリプロセスは時間とともに変更される可能性があります。オープンな提案については、prometheus/proposals#48 を参照してください。

クエリ

デルタを試して、既存の PromQL 関数を試すことをお勧めします。フィードバックを収集し、デルタのクエリエクスペリエンスを向上させる機能を作成する予定です。

rate() や increase() のような標準的な PromQL カウンター関数は累積メトリック用に設計されており、デルタメトリックで使用すると不正確な結果を生成することに注意してください。これは将来変更される可能性がありますが、現時点では、デルタメトリックで同様の結果を得るには sum_over_time() が必要です。

  • sum_over_time(delta_metric[<range>])：指定された時間範囲にわたるデルタ値の合計を計算します。
  • sum_over_time(delta_metric[<range>]) / <range>：デルタメトリックの 1 秒あたりのレートを計算します。

これらは、<range> がメトリックの収集間隔の倍数でない場合、うまく機能しない可能性があります。たとえば、sum_over_time(delta_metric[1m]) / 1m の範囲クエリ（1 分のステップ）を実行し、メトリックの収集間隔が 10 分の場合、グラフは 10 分ごとに 1 つのポイントを表示し、高いレート値が表示されます。10 ポイントで低く一定の値が表示されるのではなく。

現在の注意点

  • デルタメトリックが フェデレーション を介して公開される場合、取り込み間隔がフェデレーションエンドポイントのスキャン間隔と同じでないと、データが不正確に収集される可能性があります。

  • メトリック名やラベルに一時性の表示がないため、メトリックがデルタ一時性か累積一時性かを判断することは困難です。現時点では、デルタと累積メトリックの混合を ingesting している場合は、それらを区別するために独自のラベルを明示的に追加することをお勧めします。将来的には、メトリックタイプを一貫して区別するためのタイプラベルを導入し、（累積専用関数がデルタメトリックで使用された場合の警告を提供するなど）PromQL 関数をタイプ認識可能にする予定です。

  • 同じタイムスタンプで複数のサンプルが取り込まれる場合、1 つのポイントのみが保持されます。サンプルは合計されません（これは Prometheus の一般的な動作です。重複したタイムスタンプサンプルは拒否されます）。集計は、サンプルを Prometheus に送信する前に行う必要があります。

タイプとユニットのラベル

--enable-feature=type-and-unit-labels

有効にすると、Prometheus は PROM-39 提案 で設計された、追加の予約済み __type__ および __unit__ ラベルの注入を開始します。

これらのラベルは、OpenMetrics Text、Prometheus Text、Prometheus Proto、Remote Write 2、および OTLP のような既存のスキャンおよび取り込み形式のメタデータ構造から取得されます。__type__ および __unit__ を持つユーザー提供のすべてのラベルは上書きされます。

PromQLレイヤーは、これらのラベルをnameと同じように扱います。例えば、-または+のような特定の操作でドロップされたり、promql-delayed-name-removal機能の影響を受けたりします。

この機能により、重要なメタデータ情報をサンプルおよびPromQLレイヤーで直接利用できるようになります。

特に、以下のようなユーザーに役立ちます。

  • タイプまたは単位に基づいてメトリクスを選択できるようにしたい。
  • 同じメトリクス名で異なるタイプと単位を持つシリーズのケースを扱いたい。例：ネイティブヒストグラムの移行や、OTLPエンドポイントからのOpenTelemetryメトリクス（変換なし）。

将来的には、これに依存するさらなる作業が計画されており、例えば、誤った関数に誤ったタイプが使用された場合に役立つリッチなPromQL UX、自動リネーム、デルタタイプなどが追加される予定です。

キャッシュなしIOの使用

--enable-feature=use-uncached-io

実験的であり、Linuxでのみ利用可能です。

有効にすると、チャンクの書き込みがページキャッシュをバイパスします。その主な目的は、ページキャッシュの動作に関する混乱を減らし、誤解を招くキャッシュの成長に対応するメモリの過剰割り当てを防ぐことです。

これは現在、ダイレクトI/Oを使用して実装されています。

詳細については、提案を参照してください。

拡張レンジセレクター

--enable-feature=promql-extended-range-selectors

PromQLのレンジセレクターとインスタントセレクターに、実験的なanchoredおよびsmoothedモディファイアを有効にします。これらのモディファイアは、特に欠損または不規則なデータにおいて、rateやincreaseのような関数でレンジの境界をどのように処理するかをより細かく制御できます。

ネイティブヒストグラムは、拡張レンジセレクターではまだサポートされていません。

anchored

レンジの開始時点（ルックバックデルタ内）の最も最近のサンプル、またはルックバックデルタ内にサンプルがない場合はレンジ内の最初のサンプルを使用します。レンジ内の最後のサンプルも終了時点で使用されます。外挿や補間は適用されないため、サンプル値の直接的な差を取得するのに役立ちます。

アンカードレンジセレクターは、resets、changes、rate、increase、およびdeltaと連携します。

クエリ例：increase(http_requests_total[5m] anchored)

注意：increase関数でアンカードモディファイアを使用すると、返される結果は整数になります。

smoothed

レンジセレクターでは、境界線の前後にあるサンプル値を使用して、境界線で値を線形補間し、不規則なスクレイプや欠損サンプルに対してロバストな推定値を改善します。ただし、正しく機能するには境界線の後のサンプルが必要になります。以下の注意を参照してください。

インスタントセレクターでは、評価タイムスタンプの前後にあるサンプルを使用して、評価タイムスタンプで値を線形補間します。

スムージングレンジセレクターは、rate、increase、およびdeltaと連携します。

クエリ例：rate(http_requests_total[step()] smoothed)

アラートおよびレコーディングルールに関する注意：smoothedモディファイアは評価間隔より後のサンプルを必要とするため、アラートまたはレコーディングルールで直接使用すると、通常は結果が過小評価されます。これは、評価時に将来のサンプルが利用できないためです。ルールでsmoothedを安全に使用するには、ルールグループにquery_offsetを適用して（ドキュメントを参照）、計算ウィンドウが完全に過去にあり、必要なすべてのサンプルが利用可能であることを確認する必要があります。
クリティカルなアラートの場合、オフセットを少なくとも1つのスクレイプ間隔に設定します。それほどクリティカルでない、またはより耐性のあるユースケースの場合は、見逃したスクレイプを許容するために、より大きなオフセット（複数のスクレイプ間隔）を検討してください。

詳細については、設計ドキュメントを参照してください。

注意：拡張レンジセレクターはサブクエリではサポートされていません。

このページの内容