Prometheus logo

Prometheus

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

Ctrl + K

GitHub Logo

機能フラグ

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

これらは、--enable-featureフラグと、コンマで区切られた機能のリストを使用して有効にできます。将来のバージョンではデフォルトで有効になる場合があります。

Exemplars storage

--enable-feature=exemplar-storage

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

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

シャットダウン時のメモリ・スナップショット

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

これは、シャットダウン時にメモリ内のチャンクと時系列情報のスナップショットを取得し、ディスクに保存します。これにより、メモリの状態をこのスナップショットとm-mappedチャンクで復元できるため、起動時間が短縮されます。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の講演を参照してください。

現在、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の提供

新しいUIの代わりに古い（Prometheus 2.x）ウェブUIの提供にフォールバックします。Prometheus 3.0の一部としてリリースされた新しいUIは完全に書き直され、よりクリーンで、すっきりしていて、よりモダンな内部を目指しています。しかし、まだ完全に機能が完成しておらず、実戦でテストされていないため、一部のユーザーはまだ古いUIの使用を好むかもしれません。

--enable-feature=old-ui

メタデータWALレコード

--enable-feature=metadata-wal-records

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

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

圧縮開始時間の遅延

--enable-feature=delayed-compaction

Headの圧縮開始時間には、チャンクレインジの最大10%のランダムなオフセットが追加されます。これにより、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）クリアされます。

これを有効にすると、インメモリの状態がミューテックスで保護されるため、パフォーマンスに悪影響を及ぼす_可能性_があります。累積のみの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

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

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

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

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

同等の期間の例

  • 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 と同等です

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[]): 指定された時間範囲でのデルタ値の合計を計算します。
  • sum_over_time(delta_metric[]) / : デルタメトリックの1秒あたりのレートを計算します。

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

現在の落とし穴

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

  • メトリック名やラベルにテンポラリティの表示がないため、メトリックがデルタまたは累積テンポラリティを持つかどうかを把握することは困難です。今のところ、デルタメトリックと累積メトリックを混在させて取り込む場合は、それらを区別するために独自のラベルを明示的に追加することをお勧めします。将来的には、メトリックタイプを一貫して区別するためにタイプラベルを導入し、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、自動名前変更、デルタ型など、この機能に依存するさらなる作業が計画されています。

キャッシュされていないI/Oの使用

--enable-feature=use-uncached-io

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

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

これは現在、直接I/Oを使用して実装されています。

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

このページの内容