本文讓我們一起來看看PromQL查詢解析。雖然PromQL有操作符、函數、選擇器等，但我們無需被本篇文章中的這些細節所困擾。讓我們來看看查詢的總體性質：PromQL查詢是如何結構化和類型化的？隨著時間的推移它們是如何評估的？

讓我們來看一下PromQL的查詢結構。PromQL有操作符、函數、選擇器等等，但是我們不要被本篇文章中的細節所困擾。相反，讓我們看看查詢的整體：PromQL查詢是如何構造和輸入的，以及隨著時間的推移它們是如何被評估的？

這篇文章將假設您對PromQL查詢和Prometheus數據模型有大概粗略的了解。

讓我們開始吧！

1.PromQL是一種嵌套的函數式語言

不像SQL或其他一些更傾向于命令式的查詢語言(SELECT * FROM...)，PromQL是一種嵌套的函數式語言。這意味著您將所尋找的數據描述為一組嵌套表達式，每個表達式都計算出一個中間值(沒有副作用)。每個中間值都用作它周圍表達式的參數或操作數，而查詢的最外層表達式表示您在表、圖或類似用例中看到的最終返回值。

查詢示例如下所示：

#Rootofthequery,finalresult,approximatesaquantile.
histogram_quantile(
#1stargumenttohistogram_quantile(),thetargetquantile.
0.9,
#2ndargumenttohistogram_quantile(),anaggregatedhistogram.
sumby(le,method,path)(
#Argumenttosum(),theper-secondincreaseofahistogramover5m.
rate(
#Argumenttorate(),therawhistogramseriesoverthelast5m.
demo_api_request_duration_seconds_bucket{job="demo"}[5m]
)
)
)

PromQL表達式不僅是整個查詢，而且是查詢的任何嵌套部分(如上面的rate(…)部分)，可以單獨作為查詢運行。在上面的例子中，每個注釋行代表一個表達式。

當你在PromLabs的PromLens查詢可視化工具中分析相同的查詢時，包含子表達式的嵌套表達式結構會變得特別清晰：

在PromLens中，您可以單擊每個樹節點來分別評估其子表達式，以了解您在嵌套表達式樹的每個部分中處理的數據。

2.輸入的表達式，可能不像你想的那樣

Prometheus中有兩個“類型”的概念：

• 由抓取目標所報告的度量類型：計數器、儀表、直方圖、摘要或無類型。
• PromQL表達式的類型：字符串、標量、瞬時向量或范圍向量。

PromQL完全忽略度量類型，只關心表達式類型：每個表達式都有一個類型，每個函數、操作符或其他類型的操作都要求其參數是某種表達式類型。例如，rate()函數要求其參數是一個范圍向量，但rate()本身的計算結果是一個瞬時向量。因此，rate()的結果只能用于期望瞬時向量的地方。

PromQL中可能的表達式類型有：

• 字符串：類似 "I am a string!". 這些只作為某些函數(如label_join())的參數出現，在PromQL中并不常用。
• 標量：沒有標注尺寸的單個數值，如 1.234。您將看到這些函數的數值參數，如histogram_quantile(0.9，…)或topk(3，…)，以及算術運算。
• 瞬時向量：一組帶標簽的時間序列，每個序列有一個樣本，所有樣本都有相同的時間戳。瞬時向量可以直接來自TSDB時間序列選擇器，如node_cpu_seconds_total，也可以來自返回它們的任何函數或其他轉換。

node_cpu_seconds_total{cpu="0",mode="idle"}→19165078.75@timestamp_1
node_cpu_seconds_total{cpu="0",mode="system"}→381598.72@timestamp_1
node_cpu_seconds_total{cpu="0",mode="user"}→23211630.97@timestamp_1

• 范圍向量：一組帶標簽的時間序列，每個序列都有一段時間的樣本范圍。在PromQL中只有兩種方法產生范圍向量:在查詢中使用文字范圍向量選擇器(如node_cpu_seconds_total[5m])，或者使用子查詢(如[5m:10s])。當您想要聚合指定時間窗口內的一系列行為時，范圍向量非常有用，就像您使用rate(node_cpu_seconds_total[5m])計算node_cpu_seconds_total在過去5分鐘內的平均每秒增長率一樣。

node_cpu_seconds_total{cpu="0",mode="idle"}→19165078.75@timestamp_1,19165136.3@timestamp_2,19165167.72@timestamp_3
node_cpu_seconds_total{cpu="0",mode="system"}→381598.72@timestamp_1,381599.98@timestamp_2,381600.58@timestamp_3
node_cpu_seconds_total{cpu="0",mode="user"}→23211630.97@timestamp_1,23211711.34@timestamp_2,23211748.64@timestamp_3

但是指標類型呢？如果您已經使用過PromQL，您可能知道某些函數只適用于特定類型的指標！例如，histogram_quantile()函數只適用于直方圖指標，rate()只適用于計數器指標，而deriv()只適用于儀表。但是PromQL實際上并不檢查您是否傳入了正確類型的指標——這些函數通常會順利地運行，并為錯誤類型的輸入指標返回一些無意義的東西，并且由用戶決定是否傳入符合某些假設的時間序列(比如在直方圖的情況下有一個敏感的le標簽，或者在計數器的情況下單調增加)。然而，將來我們很可能會看到像PromLens這樣的用戶界面試圖警告你，如果你把一個不兼容的指標類型傳遞給一個函數。

3.時間是怎么進來的？范圍和即時查詢！

您可能已經注意到，PromQL查詢中對時間的唯一引用是相對引用(例如[5m]，向后看5分鐘)。那么，如何指定絕對圖形時間范圍，或者在表中顯示查詢結果的時間戳呢？在PromQL中，這樣的時間參數與表達式分開發送給Prometheus查詢API，確切的時間參數取決于您發送的查詢類型。Prometheus有兩種類型的PromQL查詢：即時查詢和范圍查詢。

3.1即時查詢

即時查詢用于類似表格的視圖，在這些視圖中，您希望顯示PromQL查詢在單個時間點的結果。

即時查詢的參數包括：

• PromQL表達式。

• 評估時間戳

表達式在計算時間戳時進行計算，查詢中的任何數據選擇器都可以選擇從該時間戳回溯到過去的數據(foo[1h]選擇foo系列的最后一個小時的數據)，但不能選擇未來的數據(foo[-1h]是無效的PromQL)。訪問過去數據的窗口通常有助于計算一段時間內的比率或平均值等總量。

即時查詢可以返回任何有效的PromQL表達式類型(字符串、標量、即時和范圍瞬時和范圍向量)。

例如即時查詢：

讓我們看一個即時查詢的例子，看看它是如何工作的。想象一下使用表達式http_requests_total查詢給定的時間戳數據。http_requests_total是一個瞬時向量選擇器，它使用指標名稱http_requests_total為任何時間序列選擇最新的樣本。更具體地說，相對于評估時間戳，“latest”意味著“最多5分鐘以前的并且不是陳舊的”。因此，該選擇器將只為在評估時間戳之前最多5分鐘有一個樣本的序列產生一個結果，并且評估時間戳之前的最后一個樣本不是一個陳舊的標記(一種將序列標記為在Prometheus TSDB中的某個時間終止的顯式方法)。

如果我們在有最近樣本的時間戳上運行此查詢，結果將包含兩個序列，每個序列只有一個樣本：

注意，每個返回樣本的輸出時間戳不再是原始樣本時間戳，而是被設置為評估時間戳。

想象一下，在一個時間戳上執行同樣的查詢，在該時間戳之前有>5m的數據間隔:

在這種情況下，查詢將返回一個空結果，因為所有匹配的樣本都太舊而無法包含。

3.2范圍查詢

范圍查詢主要用于圖形，其中您希望顯示給定時間范圍內的PromQL表達式。范圍查詢的工作方式完全類似于許多完全獨立的即時查詢，這些查詢在給定時間范圍內的后續時間步驟中進行評估。當然，這是經過高度優化的，在這種情況下，Prometheus實際上并沒有運行很多獨立的即時查詢。

范圍查詢包含以下參數：

• PromQL表達式。
• 開始時間。
• 結束時間。
• 解析步驟。

在開始時間和結束時間之間的每個解析步驟對表達式求值后，單獨求值的時間片被拼接到單個范圍向量中。范圍查詢允許傳入瞬時向量類型或標量類型的表達式，但總是返回一個范圍向量(標量或瞬時向量在一段時間內計算的結果)。

范圍查詢示例：

如果我們將上面的示例表達式評估為一個范圍查詢，它將如下所示：

請注意，每個評估步驟的行為完全類似于獨立的即時查詢，并且每個獨立的即時查詢對查詢的整體范圍沒有概念。這種情況下的最終結果將是一個范圍向量，它包含一個時間范圍內兩個選定序列的樣本，但也包含某些時間步長的序列數據中的間隙。

最后

希望這篇博客文章讓您對PromQL查詢的整體結構、正在進行的類型檢查(或缺少的類型檢查)以及查詢的解析評估有了更好的了解。

審核編輯 ：李倩