*作者：智真*

> 基於 Prometheus 的監控實踐中，尤其是在規模較大時，時序資料的儲存與查詢是其中非常關鍵，而且問題點較多的一環。如何應對大資料量下的長週期查詢，原生的 Prometheus 體系並未能給出一個令人滿意的答案。對此，ARMS Prometheus 近期上線了降取樣功能，為解決這個問題做出了新的嘗試。

## 前言

### 問題背景

Prometheus 與 K8s 作為雲原生時代的一對黃金搭檔，是目前許多企業執行環境的標準配置。然而，為了適應業務規模和微服務的發展演進，被監控物件的數量會一路增長；為了更完整的體現系統或應用的狀態細節，指標粒度劃分越來越細緻，指標數量越來越多；為了發現更長週期的趨勢變化，指標資料的保留週期勢必也要更長。所有這些變化最終都會導致監控資料量的爆炸性增長，給觀測產品的儲存、查詢、計算帶來非常大的壓力。

我們可以透過一個簡單的場景，來更直觀的感受下這種資料爆炸的後果。假如我們需要查詢近一個月中我的叢集各個節點上 CPU 用量的變化情況，而我的叢集是一個 30 個物理節點的小規模叢集，每個節點上平均執行了 50 個需要採集指標的 POD，按照預設的 30 秒採集間隔，我們需要處理的採集 target 共有 30*50 = 1500 個，而每個取樣點每天會被抓取 60*60*24/30 = 2880 次，在一個月的週期裡，共有 1500 * 2880 * 30 = 1.3 億次指標抓取，以 Node exporter 為例，一臺裸機一次抓取吐出的 sample 數量約為500，那麼一個月內這個叢集產生的取樣點約有 1.3 億 * 500 = 650 億個！而在現實的業務系統中，情況往往不會這麼理想，實際的取樣點數量往往會超過千億。

面對這種情況，我們必須要有一些技術手段，在儘可能保證資料準確性的前提下，對儲存/查詢/計算的成本和效率做最佳化提升。降取樣（DownSampling）就是其中一種代表性的思路。

### 什麼是降取樣

降取樣基於這樣一個前提：資料的處理符合結合律，多個取樣點的值的合併，並不會影響最終計算結果，正巧 Prometheus 的時序資料就符合這樣的特點。降取樣換句話說就是降低資料的解析度，其思路非常直接，如果將一定時間間隔內的資料點，基於一定規則，聚合為一個或一組值，從而達到降低取樣點數，減少資料量，減輕儲存查詢計算的壓力。所以我們需要兩個輸入項：時間間隔，聚合規則。

對於降取樣的時間間隔，基於經驗分析，我們劃定了兩種不同的降取樣時間間隔：五分鐘和一小時，再加上原始資料，會得到三種不同 resolution 的資料，根據查詢條件自動將查詢請求路由到不同 resolution 的資料。隨著後續 ARMS Prometheus 提供更長的儲存時長選擇，我們可能還會增加新的時間間隔選項。

對於聚合規則，透過對 Prometheus 的運算元函式的分析，各種運算元函式最終都可以歸納到六種型別的數值計算上：

-   max，用於計算 vector 內最大值，典型運算元如 max_over_time；
-   min，用於計算 vector 內的最小值，典型運算元如 min_over_time；
-   sum，用於計算 vector 內的和值，典型運算元如 sum_over_time；
-   count，用於統計 ventor 內的點數，典型運算元如 count_over_time；
-   counter，用於計算變化率，典型運算元如 rate，increase 等；
-   avg，取時間間隔內的各個點的平均值；

由此可見，對於時間區間內的一系列取樣點，我們只需要計算出如上六種型別的聚合特徵值，在查詢時返回相應時間區間聚合值即可。如果預設的 scrape interval 為 30 秒，五分鐘的降取樣會將十個點聚合成一個點；一小時的降取樣，會將 120 個點聚合成一個點，同樣查詢涉及到的取樣點數，會有數量級的下降，如果 scrape interval 更小，那麼取樣點縮減的效果會更顯著。取樣點數的縮減一方面減輕了 TSDB 讀取壓力，另一方面查詢引擎的計算壓力也將同步減小，進而有效減少查詢耗時。

## 如何實現降取樣

### 他山之石

其他開源/商業的時序資料儲存實現上，有一些也透過降取樣功能，對長時間跨度查詢做了最佳化提升，我們也一起了解一下。

-   **Prometheus**

開源 Prometheus 的儲存能力，一直是比較讓人詬病的一點，開源的 Prometheus 本身並未直接提供降取樣的能力，但提供了 Recording Rule 能力，使用者可以使用 Recording Rule 來自行實現 DownSampling，但這樣會產生新的時間線，在高基數場景下，反而進一步加劇了儲存壓力。

-   **Thanos**

作為知名的 Prometheus 高可用儲存方案，Thanos 提供了較為完善的降取樣方案。Thanos 中執行 downsmpling 功能的元件是 compactor，他會：

-   定期從 ojbect storage 中拉取 block（原始的 Prometheus Block，2 小時時間跨度），進行 compaction和downsampling，downsampling 的狀態會記錄到 block metadata。
-   壓縮和降取樣的結果，生成新的 block，寫入到 object storage。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e8d5a5a6002348f880b9b08c081e24e2~tplv-k3u1fbpfcp-zoom-1.image "1.png")

Downsampling 之後的特徵值包括 sum/count/max/min/counter，寫到特殊的 aggrChunks 資料塊裡。在做查詢時：

-   原始的聚合運算元和函式會轉換成特殊的 AggrFunc，對應用於讀取 aggrChunks 資料塊資料
-   讀取的 block 按照時間排序，優先讀取最大 Resolution 的 block

-   **M3**

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/59ec1743b9ac41a988b44e7e288973d5~tplv-k3u1fbpfcp-zoom-1.image "2.png")

M3 Aggregator 負責在指標儲存到 M3DB 前，流式聚合指標，並且根據 storagePolicy 指定指標儲存時長和計算視窗的取樣間隔。

M3 支援的資料間隔更加靈活，特徵值更多，包括 histogram quantile 函式。

-   **InfluxDB/Victoria Metric/Context**

Victoria Metrics 目前只在商業版本上線了降取樣功能，開源版本並未透出。InfluxDB 的開源版本（v2.0 之前）透過類似 Recording Rule 的方式，對已經落盤了的原始資料在儲存介質外執行 continuous query 來實現降取樣。Context 目前尚不支援降取樣。

### 我們怎麼做

市面上的降取樣方案各有千秋，我們簡單總結了他們的使用成本等使用者比較關注的點，比對如下：

![3.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/760fa6968756458884976ac3712c1013~tplv-k3u1fbpfcp-zoom-1.image "3.jpeg")

ARMS Prometheus 採用了處理 TSDB 儲存塊的方式，由後臺自動將原始資料塊處理為降取樣資料塊，一方面能取得一個較好的處理效能，另一方面對於終端使用者來說，不需要關心引數配置規則維護等等，儘可能的減輕使用者運維負擔。

此功能已經在阿里雲部分 region 上線，並開始定向邀請體驗。在即將推出的 ARMS Prometheus 高階版中，將預設整合並提供此功能。

## 降取樣對查詢的影響

在我們完成了取樣點層面的降取樣之後，長時間跨度的查詢問題就迎刃而解了麼？顯然不是的，TSDB 中儲存的只是最原始的物料，而使用者看到的曲線，還需要經過查詢引擎的計算處理，而在計算處理的過程中，我們至少面臨這麼兩個問題：

-   Q1：什麼情況下讀取降取樣資料？是不是降取樣後就無法使用原始資料了？
-   Q2：降取樣後資料點密度更小，資料更“稀疏”，其查詢表現會和原始資料一致麼？需要使用者調整 PromQL 麼？

對於第一個問題，ARMS Prometheus 會根據使用者的查詢語句及過濾條件，智慧選擇適合的時間顆粒度，在資料細節和查詢效能之間做出恰當的均衡。

對於第二個問題，首先可以說結論：**採集點的密度對結果計算有很大影響，但 ARMS Prometheus 在查詢引擎層面遮蔽了差異，使用者無需調整 PromQL。** 這個影響主要體現在三個方面：與查詢語句 duration 間的影響，與查詢請求的 step 間的影響，以及對運算元本身的影響，下面我們將詳細說明這三方面的影響，以及 ARMS Prometheus 在這三方面做的工作。

### duration 與降取樣計算結果

我們知道，PromQL 中區間向量（Range Vector）查詢時，都會帶上一個時間區間引數（time duration），用於框定一個時間範圍，用於計算結果。比如查詢語句http_requests_total{job="prometheus"}[2m]中，指定的 duration 即為兩分鐘，計算結果時，會將查詢到的 time series 以兩分鐘為單位，分割成若干個 vector，傳遞給 function 做計算，並分別返回結果。duration 直接決定了 function 計算時能拿到的入參長度，對結果的影響顯而易見。

一般情況下，採集點的間隔是 30s 或者更短，只要 time duration 大於這個值，我們就可以確定每個分割出來的 vector 中，都會有若干 samples，用於計算結果。當降取樣處理之後，資料點間隔會變大（五分鐘甚至一小時），這時候可能就會出現 vector 中沒有值的情形，這就導致 function 計算結果出現斷斷續續的情況。對於這種情況 ARMS Prometheus 會自動調整運算元的 time duration 引數來應對，保證 duration 不小於降取樣的 resolution，即保證每個 ventor 中都會有采樣點，保證計算結果的準確性。

### step 與降取樣計算結果

duration 引數決定了 PromQL 計算時的 vector 的”長度“，而 step 引數決定了 vector 的”步進“。如果使用者是在 grafana 上查詢，step 引數實際上是由 grafana 根據頁面寬度和查詢時間跨度來計算的，以我個人電腦為例，時間跨度 15 天時預設的 step 是 10 分鐘。對於某些運算元，因為取樣點密度下降，step 也可能引起計算結果的跳變，下面以 increase 為例簡單分析一下。

正常情況下（取樣點均勻，無 counter 重置），increase 的計算公式可以簡化為（尾值 - 首值）x duration /（尾時間戳 - 首時間戳），對於一般的場景來說，首/尾點與起/止時間的間隔，不會超過 scrape interval，如果 duration 比 scrape interval 大很多，結果約等於（尾值 - 首值）。假設有一組降取樣後的 counter 資料點，如下：

```
sample1:    t = 00:00:01   v=1 
sample2:    t = 00:59:31   v=1    
sample3:    t = 01:00:01   v=30  
sample4:    t = 01:59:31   v=31 
sample5:    t = 02:00:01   v=31 
sample6:    t = 02:59:31   v=32
...
```

假設查詢 duration 為兩小時，step 為 10 分鐘，那麼我們將會得到分割後的 vector，如下：

```
slice 1:  起止時間 00:00:00 / 02:00:00  [sample1 ...  sample4] 
slice 2:  起止時間 00:10:00 / 02:10:00  [sample2 ...  sample5] 
slice 3:  起止時間 00:20:00 / 02:20:00  [sample2 ...  sample5]
...
```

原始資料中，首尾點與起止時間的間隔，不會超過 scrape interval，而降取樣之後的資料，首尾點與起止時間的間隔最大可以達到（duration - step）。如果取樣點值變化比較平緩，那麼降取樣後的計算結果與原始資料計算結果不會有較大差別，但是如果某個 slice 區間中值的變化比較劇烈，那麼按照上述計算公式（尾值 - 首值）x duration /（尾時間戳 - 首時間戳），會將這種變動等比放大，**讓** **最終展示的曲線起伏更劇烈**。這種結果我們認為是正常情況，同時在指標變動劇烈（fast-moving counter）的場景下，irate 會更適用一些，這也和官方文件的建議是一致的。

### 運算元與降取樣計算結果

有些運算元的計算結果與 samples 數量直接相關，最典型的是 count_over_time ，統計時間區間內 samples 數量，而降取樣本身就是要縮減時間區間內的點數，所以這種情況需要在 Prometheus engine 中做特殊處理，當發現取用的是降取樣資料時，走新的計算邏輯來保證結果的正確。

## 降取樣效果對比

對於使用者來說，最終感受到的就是查詢速度的提升，但這個提升幅度有多大，我們也透過兩個查詢實地驗證對比下。

測試叢集有 55 個 node，共有 pod 6000+，每天上報取樣點總數約 100 億，資料儲存週期 15 天。

### 第一輪比對：查詢效率

查詢語句：

sum(irate(node_network_receive_bytes_total{}[5m])*8) by (instance)

即查詢叢集內各個 node 接收到的網路流量情況，查詢週期為 15 天。

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/751121079edd4c6a99516e6fe6e261c2~tplv-k3u1fbpfcp-zoom-1.image "4.png")

圖 1：降取樣資料查詢，時間跨度十五天，查詢耗時 3.12 秒

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/baa38c2dc0474a58bda676abbd20badf~tplv-k3u1fbpfcp-zoom-1.image "5.png")

圖 2：原始資料查詢，時間跨度十五天，查詢超時（超時時間 30 秒）

原始資料因為資料量過大計算超時，未能返回。降取樣查詢在效率上至少是原始查詢的十倍以上。

### 第二輪比對：結果準確性

查詢語句：

max(irate(node_network_receive_bytes_total{}[5m])*8) by (instance)

即查詢各 node 上，接收資料量最大的網路卡的流量資料。

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/838840c5a1cb4075b0ff67d3c9647832~tplv-k3u1fbpfcp-zoom-1.image "6.png")

圖 3：降取樣查詢，時間跨度兩天

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e9ced84678184e269072e1eb226852f5~tplv-k3u1fbpfcp-zoom-1.image "7.png")

圖 4：原始資料查詢，時間跨度兩天

最終我們將查詢時間跨度縮短到兩天，原始資料查詢也能較快的返回。對比降取樣查詢結果（上圖）和原始資料查詢結果（下圖）可見，二者時間線數量和總體趨勢完全一致，資料變動比較劇烈的點也能很好的契合上，完全能夠滿足長時間週期查詢的需求。

## 結語

阿里雲於 6 月 22 日正式釋出阿里雲可觀測套件（Alibaba Cloud Observability Suite，ACOS）。阿里雲可觀測套件圍繞 Prometheus 服務、Grafana 服務和鏈路追蹤服務， 形成指標儲存分析、鏈路儲存分析、異構構資料來源整合的可觀測資料層，同時透過標準的 PromQL 和 SQL，提供資料大盤展示，告警和資料探索能力。為IT成本管理、企業風險治理、智慧運維、業務連續性保障等不同場景賦予資料價值，讓可觀測資料真正做到不止於觀測。

其中，**阿里雲 Prometheus 監控針對多例項、大資料量、高時間線基數、長時間跨度、複雜查詢等極端場景，逐步推出了全域性聚合查詢，流式查詢，降取樣，預聚合等多種針對性措施。

**目前提供 15 天免費試用、Prometheus 監控容器叢集基礎指標費用減免等促銷活動！**

點選[此處](https://common-buy.aliyun.com/?spm=5176.18083541.J_3817677460.3.672e45938UsEMn&commodityCode=arms#/open)，開通服務~

可觀測｜時序資料降取樣在Prometheus實踐覆盤

相關文章