以下は、破壊的な変更であるか、実験的と見なされるため、デフォルトで無効になっている機能のリストです。これらの動作は今後のリリースで変更される可能性があり、その際はリリース変更履歴を通じて告知されます。
これらの機能を有効にするには、コンマ区切りの機能リストと共に --enable-feature フラグを使用します。今後のバージョンではデフォルトで有効になる可能性があります。
--enable-feature=expand-external-labels
external_labels 値の ${var} または $var を、現在の環境変数の値に従って置き換えます。未定義の変数への参照は空の文字列に置き換えられます。$ 文字は $$ を使用してエスケープできます。
--enable-feature=remote-write-receiver
リモート書き込みレシーバーを使用すると、Prometheus は他の Prometheus サーバーからのリモート書き込みリクエストを受け入れることができます。詳細についてはこちらを参照してください。
機能フラグを介したリモート書き込みレシーバーの有効化は非推奨です。代わりに --web.enable-remote-write-receiver を使用してください。この機能フラグは、今後のバージョンの Prometheus では無視されます。
--enable-feature=exemplar-storage
OpenMetrics は、スクレイプターゲットが特定のメトリクスに Exemplar を追加する機能を紹介しています。Exemplar は、MetricSet の外部のデータへの参照です。一般的なユースケースは、プログラムトレースの ID です。
Exemplar ストレージは、すべての系列の Exemplar をメモリに格納する固定サイズの循環バッファとして実装されています。この機能を有効にすると、Prometheus によってスクレイプされた Exemplar のストレージが有効になります。構成ファイルブロックの storage/exemplars を使用して、Exemplar の数で循環バッファのサイズを制御できます。trace_id=<jaeger-trace-id> だけを持つ Exemplar は、インメモリの Exemplar ストレージを介して約 100 バイトのメモリを使用します。Exemplar ストレージが有効になっている場合、ローカル永続化のために Exemplar を WAL (WAL 期間) にも追加します。
--enable-feature=memory-snapshot-on-shutdown
シャットダウン時にメモリ内にあるチャンクのスナップショットを系列情報とともに取得し、ディスクに保存します。これにより、メモリ状態をこのスナップショットと m-mapped チャンクで復元でき、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=new-service-discovery-manager
有効にすると、Prometheus は、再読み込み時に変更されていないディスカバリを再起動しない新しいサービスディスカバリマネージャーを使用します。これにより、再読み込みが高速になり、サービスディスカバリのソースへの負荷が軽減されます。
ユーザーは新しいサービスディスカバリマネージャーをテストし、問題を上流に報告することが推奨されます。
今後のリリースでは、この新しいサービスディスカバリマネージャーがデフォルトになり、この機能フラグは無視されます。
--enable-feature=agent
有効にすると、Prometheus はエージェントモードで実行されます。エージェントモードは、ディスカバリ、スクレイプ、およびリモート書き込みに限定されます。
これは、Prometheus データをローカルでクエリする必要がなく、中央のリモートエンドポイントからのみクエリする場合に便利です。
--enable-feature=promql-per-step-stats
有効にすると、クエリリクエストで stats=all を渡すと、ステップごとの統計が返されます。現在、これは totalQueryableSamples に限定されています。
エンジンまたはクエリのいずれかで無効になっている場合、ステップごとの統計はまったく計算されません。
--enable-feature=auto-gomaxprocs
有効にすると、GOMAXPROCS 変数は Linux コンテナの CPU クォータに合わせて自動的に設定されます。
--enable-feature=auto-gomemlimit
有効にすると、GOMEMLIMIT 変数は Linux コンテナのメモリ制限に合わせて自動的に設定されます。コンテナ制限がない場合、またはプロセスがコンテナ外で実行されている場合は、システムの総メモリが使用されます。
また、Prometheus に使用するメモリ量を制御できる追加のチューニングフラグ --auto-gomemlimit.ratio もあります。残りはプロセス外のメモリ用に予約されます。たとえば、カーネルページキャッシュです。ページキャッシュは、Prometheus TSDB クエリのパフォーマンスにとって重要です。デフォルトは 0.9 であり、これはメモリ制限の 90% が Prometheus に使用されることを意味します。
--enable-feature=no-default-scrape-port
有効にすると、デフォルトの動作とは異なり、HTTP (:80) または HTTPS (:443) のデフォルトポートは、ターゲットのスクレイプに使用されるアドレス (__address__ ラベルの値) には追加されません。さらに、静的構成またはサービスディスカバリメカニズムのいずれかですでにデフォルトの HTTP または HTTPS ポートが追加されており、それぞれのスキームが指定されている (http または https) 場合、そのポートは削除されます。
--enable-feature=native-histograms
有効にすると、Prometheus はネイティブヒストグラム (以前はスパースヒストグラムまたは高解像度ヒストグラムとしても知られていました) を取り込みます。ネイティブヒストグラムは、まだ非常に実験的です。(TSDB が読み取り不能になるものを含む) 破壊的な変更が発生することが予想されます。
ネイティブヒストグラムは現在、従来のPrometheus protobuf形式でのみサポートされています。したがって、この機能フラグは、すべてのメトリクス（つまり、ネイティブヒストグラムだけでなく）を取り込むための新しい（そして実験的な）protobufパーサーも有効にします。Prometheusは最初にprotobuf形式でのネゴシエーションを試みます。計測されたターゲットもprotobuf形式をサポートし、かつネイティブヒストグラムを公開する必要があります。protobuf形式では、従来のヒストグラムとネイティブヒストグラムを並行して公開できます。この機能フラグが無効の場合、Prometheusは従来のヒストグラム（ただしテキスト形式経由）を解析し続けます。このフラグが有効になっている場合でも、Prometheusは対応するネイティブヒストグラムがない従来のヒストグラムを取り込みます。ただし、ネイティブヒストグラムが存在する場合、Prometheusは対応する従来のヒストグラムを無視します。ただし、常に取り込まれるエクゼンプラーは例外です。従来のヒストグラムも保持するには、スクレイプジョブでscrape_classic_histogramsを有効にしてください。
leおよびquantileラベル値の形式に関する注意点
特定の状況では、protobuf解析により、従来のヒストグラムのleラベルとサマリーのquantileラベルの数値形式が変更されます。通常、これは、スクレイプされたターゲットがclient_golangで計測されている場合で、かつpromhttp.HandlerOpts.EnableOpenMetricsがfalseに設定されている場合に発生します。このような場合、整数ラベル値はテキスト形式で、例えばquantile="1"またはle="2"のように表現されます。ただし、protobuf解析では、（OpenMetrics仕様に従って）表現が浮動小数点のようなものに変更されるため、上記の例はPrometheusに取り込まれた後、quantile="1.0"およびle="2.0"になり、テキスト形式で以前に取り込まれたものと比較して、メトリクスの識別子が変更されます。
この変更の影響として、le="1"のような整数としてラベル値を直接参照するアラート、記録ルール、およびダッシュボードが動作しなくなります。
古い形式と新しい形式を含むベクトルのleおよびquantileラベルによる集計は、予期しない結果につながり、異なる形式間の移行にまたがる範囲ベクトルには追加の系列が含まれます。両方の最も一般的なユースケースは、histogram_quantileによる量子化計算です。例えば、histogram_quantile(0.95, sum by (le) (rate(histogram_bucket[10m])))です。histogram_quantile関数はすでに影響をある程度軽減しようとしていますが、特に少数のサンプルしかカバーしない短い範囲では、不正確さが生じます。
この変更にグローバルまたはメトリクスごとに対応する方法
le、quantileラベル値への参照を修正しますが、それ以外は何もしないで、移行時間にまたがる一部のクエリが不正確な結果または予期しない結果を生成することを許容します。これは、一貫して正規化されたラベル値を取得するための推奨されるソリューションです。また、Prometheus 3.0ではこれらのラベル値の正規化が強制される予定です。metric_relabel_configを使用します。これは、現在そのようなラベルを生成しているメトリクスにのみ適用する必要があります。 metric_relabel_configs:
- source_labels:
- quantile
target_label: quantile
regex: (\d+)\.0+
- source_labels:
- le
- __name__
target_label: le
regex: (\d+)\.0+;.*_bucket
--enable-feature=otlp-write-receiver
OTLPレシーバーを使用すると、PrometheusはOpenTelemetryメトリクスの書き込みを受け入れることができます。Prometheusはプルベースのシステムとして使用するのが最適であり、古さ、upメトリクス、およびその他のプルが有効な機能は、OTLPメトリクスをプッシュすると機能しません。
--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に設定されています。
--enable-feature=metadata-wal-records
有効にすると、Prometheusはメタデータをメモリに保存し、系列ごとにメタデータ変更をWALレコードとして追跡します。
WALからのみメタデータを収集するため、リモート書き込み2.0も使用している場合は、これを使用する必要があります。
このドキュメントはオープンソースです。問題やプルリクエストを提出して、改善にご協力ください。