Prometheus logo

Prometheus

文件下載社群支援與培訓部落格

Ctrl + K

GitHub Logo

特性標誌

以下是預設停用的特性列表，因為它們屬於破壞性變更或被認為是實驗性的。它們的行為在未來的版本中可能會發生變化，屆時將透過 釋出變更日誌  進行說明。

您可以使用 --enable-feature 標誌並傳入以逗號分隔的特性列表來啟用它們。在未來的版本中，它們可能會被預設啟用。

Exemplars 儲存

--enable-feature=exemplar-storage

OpenMetrics  引入了抓取目標向某些指標新增 exemplar 的功能。Exemplar 是對 MetricSet 之外資料的引用。常見的使用場景是程式追蹤（trace）的 ID。

Exemplar 儲存被實現為一個固定大小的環形緩衝區，用於在記憶體中儲存所有序列的 exemplar。啟用此特性將允許儲存由 Prometheus 抓取的 exemplar。配置檔案塊 storage/exemplars 可用於透過 exemplar 數量來控制環形緩衝區的大小。一個僅包含 trace_id=<jaeger-trace-id> 的 exemplar 在記憶體儲存中大約佔用 100 位元組的記憶體。如果啟用了 exemplar 儲存，我們還會將 exemplar 追加到 WAL 中以進行本地持久化（在 WAL 保留時間內）。

關閉時記憶體快照

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

這將在關閉時對記憶體中的資料塊（chunk）以及序列資訊進行快照並將其儲存到磁碟中。這將縮短啟動時間，因為現在可以透過此快照和記憶體對映（m-map）的資料塊來恢復記憶體狀態，而磁碟上的 WAL 重放僅對不屬於快照部分的 WAL 進行。

額外的抓取指標

--enable-feature=extra-scrape-metrics

注意：此特性標誌已棄用。請改用 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 / totalQueryableSamplesPerStep：查詢期間載入的樣本總數。對於在多個步驟中進行評估的範圍向量函式（例如 rate、sum_over_time），每一步都會計算整個時間視窗（同一個點可能會在多個步驟中被重複計算）。
  • samplesRead / samplesReadPerStep：讀取（I/O）的樣本總數。對於範圍查詢中的範圍向量函式，每步僅計算新的點（第 0 步：完整時間視窗；後續步驟：在前一步中未見過的點）。對於其他查詢型別，這等於 totalQueryableSamples。
  • peakSamples：評估期間記憶體中樣本數量的峰值（用於 query.max-samples 限制）。

Prometheus 服務端公開了兩個用於可觀測性的計數器：prometheus_engine_query_samples_total（已載入樣本數，每步完整時間視窗）和 prometheus_engine_query_samples_read_total（已讀取樣本數，範圍向量的每步增量）。

如果在引擎或查詢中停用，則根本不會計算每步統計資訊。

實驗性 PromQL 函式

--enable-feature=promql-experimental-functions

啟用被認為是實驗性的 PromQL 函式。這些函式可能會更改其名稱、語法或語義，也有可能被完全刪除。

開始（建立）時間戳零值注入

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

注意為了保持一致性，CreatedTimestamp 特性已重新命名為 StartTimestamp。為保證穩定性，上述標誌仍使用舊名稱。

啟用開始時間戳的攝取。在適當的時候，開始時間戳會被注入為值為 0 的樣本。有關詳細資訊，請參閱 PromCon 演講 。

目前，Prometheus 支援在以下協議中使用開始時間戳：

  • PrometheusProto
  • OpenMetrics1.0.0

在上述協議中，Prometheus 推薦使用 PrometheusProto。這是因為 OpenMetrics 1.0 的開始時間戳資訊是作為 <metric>_created 指標共享的，解析這些指標容易出錯且代價高昂（因此會增加開銷）。您還需要注意不要讓額外的 _created 指標汙染您的 Prometheus。

因此，當啟用 created-timestamp-zero-ingestion 時，Prometheus 會將全域性 scrape_protocols 預設配置選項更改為 [ PrometheusProto, OpenMetricsText1.0.0, OpenMetricsText0.0.1, PrometheusText0.0.4 ]，從而優先協商 Prometheus Protobuf 協議（除非顯式將 scrape_protocols 選項設定為其他值）。

除了在 Prometheus 中啟用此特性外，還需要被抓取的應用程式暴露開始時間戳。

開始時間戳（ST）原生儲存

--enable-feature=st-storage

啟用透過 WAL、TSDB/Agent 和 Remote-Write 2.0 儲存每個樣本的開始時間戳（ST）。此選項允許保留抓取和接收協議中所呈現的準確 ST 值。在未來，此特性旨在替代注入虛擬 0 樣本的 created-timestamp-zero-ingestion。

目前，Prometheus 支援在以下協議中使用開始時間戳：

  • PrometheusProto
  • OpenMetrics1.0.0

由於 ST 傳遞的效率高，推薦使用 PrometheusProto。

除了在 Prometheus 中啟用此特性外，還需要被抓取的應用程式暴露開始時間戳。

注意這是一項實驗性特性，在完全實現之前存在已知的侷限性。
  • 它引入了新的 WAL 記錄型別（SamplesV2），該型別只能在 Prometheus 3.11 或更高版本中進行重放。
  • 對於持久化儲存支援（TSDB 塊），您需要手動啟用 XOR2 資料塊格式（xor2-encoding 標誌）。當 st-storage 處於活動狀態時，浮點資料塊編碼必須解析為 XOR2，因為 XOR 資料塊不儲存開始時間戳。如果解析後的編碼為 XOR（即未設定 --enable-feature=xor2-encoding 且未配置 chunk_encoding.floats: xor2），Prometheus 將拒絕啟動並報錯，導致配置驗證失敗，而不會繼續執行。同樣地，在 st-storage 處於活動狀態時，在配置檔案中顯式設定 chunk_encoding.floats: xor 將在配置重新載入時被拒絕。一旦我們完成了 XOR2 的實驗階段，這在以後可能會發生改變。
  • 原生直方圖和 NHCB 的 ST 尚未實現（請參閱 #18315 ）。
  • 在 PromQL 中使用 ST 超出了本特性的範圍。

在 PromQL 函式中使用開始時間戳（ST）

--enable-feature=use-start-timestamps

允許在 rate()、irate() 和 increase() 等 PromQL 函式中使用開始時間戳（ST）。該特性目前不適用於擴充套件範圍選擇器（promql-extended-range-selectors）。

開始時間戳（ST）合成

--enable-feature=st-synthesis

當源未提供開始時間戳（ST）時，啟用為累積指標（計數器、經典直方圖、原生直方圖）合成 ST 的功能。類似於 官方的 OpenTelemetry metricstarttimeprocessor ，它透過跟蹤先前的值來檢測重置，並減去初始參考點，從而從第一個樣本中合成一個基於零的時間線。

注意這是一個實驗性特性。
  • 開啟此特性時，會丟棄第一個樣本以建立開始時間戳參考點。因此，如果一個序列只上報了一個單點，開啟此特性可能會導致該序列沒有點被攝取。
  • 合成在保持準確的計數器速率的同時，能產生準確的開始時間戳。然而，原始計數器值將與抓取的值不同。這是因為丟棄了第一個點，並將其時間戳用作所有後續點的開始時間戳。所有後續點都針對該丟棄的點進行歸一化（即減去它）。實際上，合成會使用原始資料中已知的開始時間戳來建立新的計數器流。
  • 合成僅適用於抓取的資料（尚未實現 RW 和 Otel 接收器）。
  • 合成需要有序的樣本。因此，儘管有 tsdb.out_of_order_time_window 設定，不帶 ST 且亂序的累積樣本仍將被拒絕。
  • 如果某個序列的追加失敗（例如，由於亂序樣本被拒絕），則該序列的合成狀態將被清除。因此，在失敗後收到的下一個樣本將再次被視為第一個樣本，並被丟棄以建立新的參考點。

併發評估獨立規則

--enable-feature=concurrent-rule-eval

預設情況下，規則組是併發執行的，但規則組內的規則是順序執行的；這是因為後面的規則可能會將前一個規則的輸出作為其輸入。但是，如果規則之間沒有可檢測到的關聯，則沒有理由按順序執行它們。啟用 concurrent-rule-eval 特性標誌後，規則組內與任何其他規則均無依賴關係的規則將被併發評估。這有可能縮短規則組評估的延遲並提高資源利用率，但代價是會增加併發查詢負載。

併發規則評估的數量可以透過 --rules.max-concurrent-rule-evals 進行配置，預設設定為 4。

服務舊版 Prometheus UI

回退到服務舊版（Prometheus 2.x）Web UI，而不是新版 UI。作為 Prometheus 3.0 的一部分發布的新 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__ 標籤，並有助於防止“向量不能包含具有相同標籤集的指標”（vector cannot contain metrics with the same labelset）錯誤，該錯誤在使用正則表示式匹配 __name__ 標籤時可能會發生。

請注意，分別評估查詢的各個部分仍會觸發標籤集衝突。這在手動或使用 PromLens 之類的工具分析查詢的中間結果時經常發生。

如果查詢引用了已被移除的 __name__ 標籤，則在設定此特性標誌時，其行為可能會發生變化。（例如：sum by (__name__) (rate({foo="bar"}[5m]))，請參閱 GitHub 上的詳細資訊 。）此類查詢很少出現，且易於修復。（在上述示例中，在沒有該特性標誌的情況下移除 by (__name__) 不會改變任何內容，而有了該特性標誌後，移除它則可以解決可能出現的問題。）

可以構建一個透過 __name__ 進行聚合的查詢，並將帶有和不帶有延遲名稱移除的樣本放入同一個組中。在這種情況下，名稱將從受影響的組中移除。請注意，在滿足實際用途的查詢中幾乎不會出現這種情況。

OTLP 增量轉換

--enable-feature=otlp-deltatocumulative

啟用後，Prometheus 將把 OTLP 指標從增量時效性（delta temporality）轉換為其等效的累積值（cumulative equivalent），而不是直接丟棄它們。這不能與 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

在將偏移量（offset）與持續時間表達式結合使用時，必須將表示式括在括號中。如果不帶括號，則在偏移量計算中僅使用第一個持續時間值。

step() 可用於持續時間表達式。對於範圍查詢，它解析為範圍查詢的步長。對於瞬時查詢，它解析為 0s。

range() 可用於持續時間表達式。對於範圍查詢，它解析為查詢的完整時間範圍（結束時間 - 開始時間）。對於瞬時查詢，它解析為 0s。這在與 @end() 結合使用以回顧整個查詢範圍時特別有用，例如 max_over_time(metric[range()] @ end())。

min_of(<duration>, <duration>) 和 max_of(<duration>, <duration>) 在兩個持續時間表達式之間進行選擇。min_of 返回兩者中較小的一個，這對於將持續時間限制在最大值以內非常有用。max_of 返回兩者中較大的一個，這對於強制設定最小值非常有用。例如，max_of(step(), 5s) 確保持續時間永遠不短於 5s，而 min_of(range(), 1h) 將持續時間限制在 1h 以內。

注意：@ 時間戳運算子中不支援持續時間表達式。

支援以下運算子

  • + - 加法
  • - - 減法
  • * - 乘法
  • / - 除法
  • % - 取模
  • ^ - 冪運算

等效持續時間示例

  • 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 等同於查詢步長增加 1s。
  • max_of(step(), 5s) 等同於查詢步長和 5s 之間的較大值。
  • min_of(2 * step() + 5s, 5m) 等同於查詢步長兩倍加上 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>：計算增量指標的每秒速率。

如果 <range> 不是指標收集間隔的倍數，這些方法可能無法很好地工作。例如，如果您進行 sum_over_time(delta_metric[1m]) / 1m 範圍查詢（步長為 1m），但指標的收集間隔為 10m，則圖表將每 10 分鐘顯示一個具有高速率值的單點，而不是 10 個具有較低、恆定值的點。

注意事項

  • 如果增量指標透過 聯邦 公開，如果攝取間隔與聯邦端點的抓取間隔不同，資料可能會被錯誤地收集。

  • 由於指標名稱或標籤中沒有時效性的指示，因此很難弄清楚一個指標是具有增量時效性還是累積時效性。目前，如果您正在攝取混合的增量和累積指標，我們建議您顯式新增自己的標籤來區分它們。在未來，我們計劃引入型別標籤來一致地識別指標型別，並可能讓 PromQL 函式具備型別感知能力（例如，當在增量指標上使用僅限累積的函式時提供警告）。

  • 如果在同一時間戳攝取了多個樣本，則僅保留其中一個點 - 樣本不會相加（這通常是 Prometheus 的工作方式 - 重複的時間戳樣本會被拒絕）。任何聚合都必須在將樣本傳送到 Prometheus 之前完成。

型別和單位標籤

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

啟用後，Prometheus 將開始注入額外的保留標籤 __type__ 和 __unit__，正如在 PROM-39 提案  中所設計的那樣。

這些標籤來源於現有抓取和攝取格式的元資料結構，如 OpenMetrics Text、Prometheus Text、Prometheus Proto、Remote Write 2 和 OTLP。所有使用者提供的 __type__ 和 __unit__ 標籤都將被覆蓋。

PromQL 層將以處理 __name__ 的相同方式處理這些標籤，例如在某些操作（如 - 或 +）中將其丟棄，並受 promql-delayed-name-removal 特性的影響。

該特性使得重要的元資料資訊可以直接透過樣本和 PromQL 層進行訪問。

這對於符合以下情況的使用者特別有用：

  • 希望能夠根據型別或單位來篩選指標。
  • 希望處理具有相同指標名稱但具有不同型別和單位的序列。例如原生直方圖遷移，或來自 OTLP 端點且無需轉換的 OpenTelemetry 指標。

在未來，計劃開展更多工作  將依賴於此，例如豐富的 PromQL 使用者體驗（當在錯誤的函式上使用錯誤的型別時提供幫助）、自動重新命名、增量型別等。

元資料記錄的行為

當啟用此特性且元資料 WAL 記錄存在時，在極少數情況下如果這二者之間的型別或單位不一致，Prometheus 的輸出傾向於首選 __type__ 和 __unit__ 標籤值。例如，在 Remote Write 2.0 上，如果元資料記錄由於某種原因（例如由於 Bug）顯示為 "counter"，但 __type__="gauge"，則遠端時間序列將被設定為 gauge。

使用無快取的 IO

--enable-feature=use-uncached-io

實驗性特性，且僅在 Linux 上可用。

啟用後，它使資料塊（chunk）寫入繞過頁面快取（page cache）。其主要目標是減少對頁面快取行為的混淆，並防止因誤導性的快取增長而導致記憶體過度分配。

目前這是使用直接 I/O（direct I/O）實現的。

有關更多詳細資訊，請參閱提案 。

XOR2 資料塊編碼

--enable-feature=xor2-encoding

警告：這是高度實驗性且帶有風險的設定

  • 使用 XOR2 編碼的資料塊無法被不支援該編碼的舊版 Prometheus 讀取。一旦啟用並寫入了資料，您需要手動從磁碟中刪除這些塊，否則 Prometheus 將在所有查詢中返回錯誤。
  • 我們仍在對最終編碼進行實驗。目前，此編碼可能會在任何 Prometheus 版本中發生變化。版本升級可能會導致您丟失所有持久化的塊資料。
  • 此編碼是全新的，這意味著下游工具和長期支援（LTS）系統可能尚不支援它（例如 Thanos sidecar 上傳的塊）。

此設定啟用了針對浮點樣本的新 XOR2 資料塊編碼，在典型的 Prometheus 工作負載中，它比預設的 XOR 編碼提供了更好的磁碟壓縮。此格式還允許儲存開始時間戳（ST）。

該編碼還可以透過配置檔案中 storage.tsdb 部分的 chunk_encoding.floats 欄位在每次配置重新載入時進行控制。即使設定了 --enable-feature=xor2-encoding，將 chunk_encoding.floats: xor 設定為 xor 也會強制使用標準的 XOR 編碼；而將 chunk_encoding.floats: xor2 設定為 xor2 則需要啟用 --enable-feature=xor2-encoding。

在沒有啟用 st-storage 的情況下，XOR 和 XOR2 是相容的編碼，因此透過 chunk_encoding.floats 更改編碼不會分割當前資料塊；新編碼將在當前資料塊因任何原因（大小、時間範圍或樣本數）下一次被分割時生效。當同時啟用 st-storage 時，XOR 和 XOR2 是不相容的，因為 XOR 資料塊不儲存開始時間戳，因此在編碼更改後進行下一次追加時，進行中的資料塊將被分割。

請注意，--enable-feature=st-storage 不會自動啟用 XOR2 編碼。然而，當 st-storage 處於活動狀態時，在配置重新載入時將 chunk_encoding.floats: xor 設定為 xor 將被拒絕，因為 XOR 資料塊不儲存開始時間戳。

擴充套件範圍選擇器

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

為 PromQL 區間選擇器和瞬時選擇器啟用實驗性的 anchored 和 smoothed 修飾符。這些修飾符提供了對 rate 和 increase 等函式中如何處理區間邊界的更多控制，特別是在資料缺失或不規則的情況下。

擴充套件區間選擇器尚不支援原生直方圖（Native Histograms）。

anchored

在區間的起點，使用最近的樣本（在回溯增量內）；如果回溯增量內沒有樣本，則使用區間內的第一個樣本。在區間的終點，也使用區間內的最後一個樣本。不應用任何外推或插值，因此這對於獲取樣本值之間的直接差值非常有用。

錨定區間選擇器適用於：resets、changes、rate、increase 和 delta。

示例查詢：increase(http_requests_total[5m] anchored)

注意：當在 increase 函式中使用 anchored 修飾符時，返回的結果為整數。

smoothed

在區間選擇器中，線性插值區間邊界處的值，使用邊界前後的樣本值進行更好的估算，從而對不規則的抓取和缺失的樣本具有魯棒性。但是，它需要評估區間之後的樣本才能正常工作，請參見下面的說明。

對於瞬時選擇器，使用緊鄰評估時間戳之前和之後的樣本在評估時間戳處進行線性插值。

平滑區間選擇器適用於：rate、increase 和 delta。

示例查詢：rate(http_requests_total[step()] smoothed)

關於告警和記錄規則的注意事項： smoothed 修飾符需要評估區間之後的樣本，因此直接在告警或記錄規則中使用它通常會低估結果，因為在評估時無法獲取未來的樣本。要在規則中安全地使用 smoothed，您必須在規則組中應用 query_offset（參見文件），以確保計算視窗完全處於過去，且所有必需的樣本都可用。對於關鍵的告警，請將偏移量設定為至少一個抓取間隔；對於不太關鍵或更具彈性的用例，可以考慮設定更大的偏移量（多個抓取間隔）以容忍抓取丟失。

欲瞭解更多詳情，請參閱設計文件 。

注意：子查詢不支援擴充套件區間選擇器。

二元運算子填充修飾符

--enable-feature=promql-binop-fill-modifiers

為 PromQL 二元運算子啟用實驗性的 fill()、fill_left() 和 fill_right() 修飾符。這些修飾符允許在二元運算的任一側使用提供的預設樣本值來填充缺失的匹配項。

示例查詢

  rate(successful_requests[5m])
+ fill(0)
  rate(failed_requests[5m])

詳情和示例請參閱填充修飾符文件。

搜尋 API

--enable-feature=search-api

啟用實驗性的搜尋 API 端點，支援透過模糊匹配和過濾來發現指標名稱、標籤名稱和標籤值。詳情請參閱搜尋 API 文件。

--web.search.max-limit 標誌（預設值為 10000）限制了搜尋端點接受的 limit 查詢引數。limit 超過此限制的請求將被拒絕，並返回 HTTP 400。預設的響應限制（100）會被靜默限制在此最大值內，因此管理員設定較小的上限並不會破壞不帶 limit 的請求。將該標誌設定為 0 會完全停用上限；對於暴露在受信網路之外的端點，不建議這樣做，因為單個客戶端可以透過一次響應請求整個索引。

本頁內容