Thanos 與 VictoriaMetrics，誰纔是打造大型 Prometheus 監控系統的王者？

更多精彩內容歡迎訂閱個人博客：https://fuckcloudnative.io/node

Thanos ^[1] 和 VictoriaMetrics ^[2] 都是用來做爲 Prometheus 長期存儲的成熟方案，其中 VictoriaMetrics 也開源了其集羣版本 ^[3] ，功能更增強大。這兩種解決方案都提供瞭如下功能：

長期存儲，能夠保留任意時間的監控數據。
對多個 Prometheus 實例採集的數據進行全局聚合查詢。
可水平擴展。

本文就來對比一下這兩種方案的差別性和優缺點，主要從寫入和讀取這兩個方面來比較，每個方面的比較都包含如下幾個角度：git

配置和操做的複雜度
可靠性和可用性
數據一致性
性能
可擴展性

先來看一下這兩種方案的架構。github

1. 架構

Thanos

Thanos^[4] 包含如下幾個核心組件：web

Sidecar ^[5] : 每一個 Prometheus 實例都包含一個 Sidecar，它與 Prometheus 實例運行在同一個 Pod 中。它有兩個做用：1) 將本地超過 2 小時的監控數據上傳到對象存儲，如 Amazon S3 或 Google 雲存儲。2) 將本地監控數據（小於 2 小時）提供給 Thanos Query 查詢。api
Store^[6] Gateway : 將對象存儲的數據提供給 Thanos Query 查詢。安全
Query^[7] : 實現了 Prometheus 的查詢 API^[8]，將 Sidecar 和對象存儲提供的數據進行聚合最終返回給查詢數據的客戶端（如 Grafana）。微信
Compact^[9] : 默認狀況下，Sidecar 以 2 小時爲單位將監控數據上傳到對象存儲中。Compactor 會逐漸將這些數據塊合併成更大的數據塊，以提升查詢效率，減小所需的存儲大小。網絡
Ruler^[10] : 經過查詢 Query 獲取全局數據，而後對監控數據評估記錄規則^[11]和告警規則，決定是否發起告警。還能夠根據規則配置計算新指標並存儲，同時也經過 Store API 將數據暴露給 Query，一樣還能夠將數據上傳到對象存儲以供長期保存。因爲 Query 和底層組件的可靠性較低，Ruler 組件一般故障率較高^[12]：架構

Ruler 組件在架構上作了一些權衡取捨，強依賴查詢的可靠性，這可能對大多數場景都不利。對於 Prometheus 來講，都是直接從本地讀取告警規則和記錄規則，因此不太可能出現失敗的狀況。而對於 Ruler 來講，規則的讀取來源是分佈式的，最有可能直接查詢 Thanos Query，而 Thanos Query 是從遠程 Store APIs 獲取數據的，因此就有可能遇到查詢失敗的狀況。app
Receiver^[13] : 這是一個實驗性組件，適配了 Prometheus 的 remote write API，也就是全部 Prometheus 實例能夠實時將數據 push 到 Receiver。在 Thanos v0.5.0 時，該組件尚未正式發佈。

最後再來看一眼 Thanos 的總體架構圖：

VictoriaMetrics

VictoriaMetrics 集羣版包含如下幾個核心組件：

vmstorage : 存儲數據。
vminsert : 經過 remote write API ^[14] 接收來自 Prometheus 的數據並將其分佈在可用的 vmstorage 節點上。
vmselect : 從 vmstorage 節點獲取並聚合所需數據，返回給查詢數據的客戶端（如 Grafana）。

每一個組件可使用最合適的硬件配置獨立擴展到多個節點。

總體架構圖以下：

圖中的 VictoriaMetrics 集羣和 Load balancer 均可以經過 helm^[15] 部署在 Kubernetes 中。對於大部分中小型集羣來講，不須要水平擴展的功能，能夠直接使用單機版的 VictoriaMetrics。更多信息請參考垂直擴展基準^[16]。

瞭解這兩種方案的架構後，開始進入對比環節。

注意：下文提到的 VictoriaMetrics 如沒有特殊說明，均指的是集羣版。

2. 寫入對比

配置和操做的複雜度

Thanos 須要經過如下步驟來創建寫入過程：

禁用每一個 Prometheus 實例的本地數據壓縮。具體作法是將 --storage.tsdb.min-block-duration 和 --storage.tsdb.max-block-duration 這兩個參數的值設置爲相同的值。

Thanos 要求關閉壓縮是由於 Prometheus 默認會以 2, 25, 25*5 的週期進行壓縮，若是不關閉，可能會致使 Thanos 剛要上傳一個 block，這個 block 卻被壓縮中，致使上傳失敗。更多詳情請參考這個 issue^[17]。若是 --storage.tsdb.retainer.time 參數的值遠遠高於 2 小時，禁用數據壓縮可能會影響 Prometheus 的查詢性能。
在全部的 Prometheus 實例中插入 Sidecar，這樣 Sidecar 就能夠將監控數據上傳到對象存儲。
設置 Sidecar 監控。
爲每一個對象存儲的 bucket 配置壓縮器，即 Compact^[18] 組件。

VictoriaMetrics 須要在 Prometheus 中添加遠程存儲的配置^[19]，以將採集到的樣本數據經過 Remote Write 的方式寫入遠程存儲 VictoriaMetrics 中，不須要在 Prometheus 中插入 Sidecar，也不須要禁用本地數據壓縮。詳情請參考官方文檔^[20]。

可靠性和可用性

Thanos Sidecar 以 2 小時爲單位將本地監控數據上傳到分佈式對象存儲，這就意味着若是本地磁盤損壞或者數據被意外刪除，就有可能會丟失每一個 Prometheus 實例上最近 2 小時添加的數據。

從查詢組件到 Sidecar 的查詢可能會對 Sidecar 數據的上傳產生負面影響，由於響應查詢和上傳的任務都是在同一個 Sidecar 進程中執行的。但理論上能夠將負責響應查詢的任務和上傳的任務分別運行在不一樣的 Sidecar 中。

對於 VictoriaMetrics 來講，每一個 Prometheus 實例都會實時經過 remote_write API 將全部監控數據複製到遠程存儲 VictoriaMetrics。在抓取數據和將數據寫入遠程存儲之間可能會有幾秒鐘的延遲，因此若是本地磁盤損壞或者數據被意外刪除，只會丟失每一個 Prometheus 實例上最近幾秒鐘添加的數據。

從 Prometheus v2.8.0+ 開始，Prometheus 會直接從預寫日誌（WAL，write-ahead log）中複製數據到遠程存儲，因此不會由於與遠程存儲的臨時鏈接錯誤或遠程存儲臨時不可用而丟失數據。具體的原理是，若是與遠程存儲的鏈接出現問題，Prometheus 會自動中止在預寫日誌（WAL）的位置，並嘗試從新發送失敗的那一批樣本數據，從而避免了數據丟失的風險。同時，因爲出現問題時 Prometheus 不會繼續往下讀取預寫日誌（WAL），因此不會消耗更多的內存。

數據一致性

Thanos 的 Compactor 和 Store Gateway 存在競爭關係，可能會致使數據不一致或查詢失敗。例如：

若是 Thanos sidecar 或 compactor 在上傳數據的過程當中崩潰了，如何確保讀取數據的客戶端（如 Compactor 和 Store Gateway）都可以優雅地處理這個問題？
分佈式對象存儲對於一個新上傳的對象提供 寫後讀寫一致性（read-after-write consistency）；對於已存在對象的複寫提供 最終讀寫一致性（eventual consistency）。舉個例子，假設咱們有一個嶄新的文件，PUT 以後立刻 GET ，OK，沒有問題，這就是寫後讀寫一致性；假設咱們上傳了一個文件，以後再 PUT 一個和這個文件的 key 同樣，可是內容不一樣的新文件，以後再 GET。這個時候 GET 請求的結果極可能仍是舊的文件。對於 Thanos compactor 來講，它會上傳壓縮的數據塊，刪除源數據塊，那麼在下一次同步迭代後，它可能會獲取不到更新的數據塊（最終讀寫一致性），從而又從新壓縮了一次數據塊並上傳，出現數據重疊的現象。
對於 Store Gateway 來講，它每 3 分鐘同步一次數據，查詢組件可能會試圖獲取刪除的源數據塊，從而失敗。

更多詳情請參考 Read-Write coordination free operational contract for object storage^[21]。

VictoriaMetrics 能夠保持數據的強一致性，詳情可參考它的存儲架構^[22]。

性能

Thanos 的寫入性能不錯，由於 Sidecar 只是將 Prometheus 建立的本地數據塊上傳到對象存儲中。其中 Query 組件的重度查詢可能會影響 Sidecar 數據上傳的速度。對於 Compactor 組件來講，若是新上傳的數據塊超出了 Compactor 的性能，可能會對對象存儲 bucket 帶來不利。

而 VictoriaMetrics 使用的是遠程存儲的方式，Prometheus 會使用額外的 CPU 時間來將本地數據複製到遠程存儲，這與 Prometheus 執行的其餘任務（如抓取數據、規則評估等）所消耗的 CPU 時間相比，能夠忽略不計。同時，在遠程存儲數據接收端，VictoriaMetrics 能夠按需分配合理的 CPU 時間，足以保障性能。參考 Measuring vertical scalability for time series databases in Google Cloud^[23]。

可擴展性

Thanos Sidecar 在數據塊上傳過程當中依賴於對象存儲的可擴展性。S3 和 GCS 的擴展性都很強。

VictoriaMetrics 的擴展只須要增長 vminsert 和 vmstorage 的容量便可，容量的增長能夠經過增長新的節點或者更換性能更強的硬件來實現。

3. 讀取對比

配置和操做的複雜度

Thanos 須要經過如下步驟來創建讀取過程：

Sidecar ^[24] 爲每一個 Prometheus 實例啓用 Store API，以將本地監控數據（小於 2 小時）提供給 Thanos Query 查詢。
Store ^[25] Gateway 將對象存儲的數據暴露出來提供給 Thanos Query 查詢。
Query ^[26] 組件的查詢動做會覆蓋到全部的 Sidecar 和 Store Gateway，以便利用 Prometheues 的查詢 API ^[27] 實現全局查詢。若是 Query 組件和 Sidecar 組件位於不一樣數據中心，在它們之間創建安全可靠鏈接可能會很困難。

VictoriaMetrics 提供了開箱即用的 Prometheues 查詢 API^[28]，因此不須要在 VictoriaMetrics 集羣外設置任何額外的組件。只須要將 `Grafana` 中的數據源指向 VictoriaMetrics^[29] 便可。

可靠性和可用性

Thanos 的 Query 組件須要和全部的 Sidecar 和 Store Gateway 創建鏈接，從而爲客戶端（如 Grafana）的查詢請求計算完整的數據。若是 Prometheus 實例跨多個數據中心，可能會嚴重影響查詢的可靠性。

若是對象存儲中存在容量很大的 bucket，Store Gateway 的啓動時間會很長，由於它須要在啓動前從 bucket 中加載全部元數據，詳情能夠參考這個 issue^[30]。若是 Thanos 須要升級版本，這個問題帶來的負面影響會很是明顯。

VictoriaMetrics 的查詢過程只涉及到集羣內部的 vmselect 和 vmstorage 之間的本地鏈接，與 Thanos 相比，這種本地鏈接具備更高的可靠性和可用性。

VictoriaMetrics 全部組件的啓動時間都很短，所以能夠快速升級。

數據一致性

Thanos 默認狀況下^[31]容許在部分 Sidecar 或 Store Gateway 不可用時只返回部分查詢結果^[32]。

VictoriaMetrics 也能夠在部分 vmstorage 節點不可用時只返回部分查詢結果，從而優先考慮可用性而不是一致性。具體的作法是啓用 -search.denyPartialResponse 選項。

總的來講，VictoriaMetrics 返回部分查詢結果的可能性更低，由於它的可用性更高。

性能

Thanos Query 組件的查詢性能取決於查詢性能最差的 Sidecar 或 Store Gateway 組件，由於 Query 組件返回查詢結果以前會等待全部 Sidecar 和 Store Gateway 組件的響應。

一般 Sidecar 或 Store Gateway 組件的查詢性能不是均衡的，這取決於不少因素：

每一個 Promnetheus 實例抓取的數據容量。
Store Gateway 背後每一個對象存儲 bucket 的容量。
每一個 Prometheus + Sidecar 和 Store Gateway 的硬件配置。
Query 組件和 Sidecar 或 Store Gateway 之間的網絡延遲。若是 Query 和 Sidecar 位於不一樣的數據中心，延遲可能會至關高。
對象存儲的操做延遲。一般對象存儲延遲（ S3、 GCS）比塊存儲延遲（ GCE 磁盤、 EBS）高得多。

VictoriaMetrics 的查詢性能受到 vmselect 和 vmstorage 的實例數量及其資源配額的限制。只需增長實例數，或者分配更多的資源配額，便可擴展查詢性能。vminsert 會將 Prometheus 寫入的數據均勻地分佈到可用的 vmstorage 實例中，因此 vmstorage 的性能是均衡的。VictoriaMetrics 針對查詢速度作了優化^[33]，因此與 Thanos 相比，它應該會提供更好的查詢性能。

可擴展性

Thanos 的 Query 組件是無狀態服務，可用經過水平擴展來分擔查詢負載。Store Gateway 也支持多副本水平擴展，對每個對象存儲 bucket 而言，多個 Store Gateway 副本也能夠分擔查詢負載。可是要擴展 Sidecar 後面的單個 Prometheus 實例的性能是至關困難的，因此 Thanos 的查詢性能受到性能最差的 Prometheus + Sidecar 的限制。

VictoriaMetrics 在查詢方面提供了更好的擴展性，由於 vmselect 和 vmstorage 組件的實例能夠獨立擴展到任何數量。集羣內的網絡帶寬可能會成爲限制擴展性的因素，VictoriaMetrics 針對低網絡帶寬的使用進行了優化，以減小這一限制因素。

4. 高可用對比

Thanos 須要在不一樣的數據中心（或可用區）運行多個 Query 組件，若是某個區域不可用，那麼另外一個區域的 Query 組件將會繼續負責響應查詢。固然，這種狀況下基本上只能返回部分查詢結果，由於部分 Sidecar 或 Store Gateway 組件頗有可能就位於不可用區。

VictoriaMetrics 能夠在不一樣的數據中心（或可用區）運行多個集羣，同時能夠配置 Prometheus 將數據複製到全部集羣，具體能夠參考官方文檔的示例^[34]。若是某個區域不可用，那麼另外一個區域的 VictoriaMetrics 仍然繼續接收新數據，並能返回全部的查詢結果。

5. 託管成本對比

Thanos 選擇將數據存放到對象存儲中，最經常使用的 GCS 和 S3 的每個月計費狀況以下：

GCS : 價格區間位於 $4/TB 的 coldline storage 和 $36/TB 的標準存儲之間。此外，對於出口網絡：內部流量 $10/TB，外部流量 $80-$230/TB。對於存儲 API 的調用（讀寫）：每百萬次調用 10。具體參考價格詳情 ^[35]。
S3 : 價格區間位於 $4/TB 的 glacier storage 和 $23/TB 的標準存儲之間。此外，對於出口網絡：內部流量 $2-$10/TB，外部流量 $50-$90/TB。對於存儲 API 的調用（讀寫）：每百萬次調用 100。具體參考價格詳情 ^[36]。

整體看下來，Thanos 的託管成本不只取決於數據大小，還取決於出口流量和 API 調用的數量。

VictoriaMetrics 只須要將數據存放到塊存儲，最經常使用的 GCE 和 EBS 的每個月計費狀況以下：

GCE 磁盤 : 價格區間位於 $40/TB 的 HDD 和 $240/TB 的 SSD。具體參考價格詳情 ^[37]。
EBS : 價格區間位於 $45/TB 的 HDD 和 $125/TB 的 SSD。具體參考價格詳情 ^[38]。

VictoriaMetrics 針對 HDD 作了優化，因此基本上不必使用昂貴的 SSD。VictoriaMetrics 採用高性能的數據壓縮方式，使存入存儲的數據量比 Thanos 多達 10x，詳情參考這篇文章^[39]。這就意味着與 Thanos 相比，VictoriaMetrics 須要更少的磁盤空間，存儲相同容量數據的成本更低。

總結

Thanos 和 VictoriaMetrics 分別使用了不一樣的方法來提供長期存儲、聚合查詢和水平擴展性。

VictoriaMetrics 經過標準的 remote_write API ^[40] 接收來自 Prometheus 實例寫入的數據，而後將其持久化（如 GCE HDD 磁盤 ^[41]、 Amazon EBS ^[42] 或其餘磁盤）。而 Thanos 則須要禁用每一個 Prometheus 實例的本地數據壓縮，並使用非標準的 Sidecar 將數據上傳至 S3 或 GCS。同時還須要設置 Compactor，用於將對象存儲 bucket 上的小數據塊合併成大數據塊。
VictoriaMetrics 開箱即實現了全局查詢視圖的 Prometheus query API ^[43]。因爲 Prometheus 會實時將抓取到的數據複製到遠程存儲，因此它不須要在集羣外創建任何外部鏈接來實現全局查詢。 Thanos 須要設置 Store Gateway、 SIdecar 和 Query 組件才能實現全局查詢。對於大型的 Thanos 集羣來講，在 Query 組件和位於不一樣數據中心（可用區域）的 Sidecar 之間提供可靠安全的鏈接是至關困難的。 Query 組件的性能會受到性能最差的 Sidecar 或 Store Gateway 的影響。
VictoriaMetrics 集羣能夠快速部署到 Kubernetes 中，由於它的架構很是簡單 ^[44]。而 Thanos 在 Kubernetes 中的部署和配置很是複雜。

本文由 VictoriaMetrics 核心開發者所著，因此可能會更傾向於 VictoriaMetrics，但做者儘可能作到了公平對比。若是你有任何疑問，歡迎找原做者交流（si bi）。

原文連接：https://medium.com/faun/comparing-thanos-to-victoriametrics-cluster-b193bea1683

參考資料

[1]

Thanos: https://github.com/improbable-eng/thanos

[2]

VictoriaMetrics: https://github.com/VictoriaMetrics/VictoriaMetrics

[3]

集羣版本: https://github.com/VictoriaMetrics/VictoriaMetrics/tree/cluster

[4]

Thanos: https://github.com/improbable-eng/thanos

[5]

Sidecar : https://thanos.io/tip/components/sidecar/

[6]

Store: https://thanos.io/tip/components/store/

[7]

Query: https://thanos.io/tip/components/query/

[8]

Prometheus 的查詢 API: https://prometheus.io/docs/prometheus/latest/querying/api/

[9]

Compact: https://thanos.io/tip/components/compact/

[10]

Ruler: https://thanos.io/tip/components/rule/

[11]

記錄規則: https://prometheus.io/docs/prometheus/latest/configuration/recording_rules/

[12]

Ruler 組件一般故障率較高: https://thanos.io/tip/components/rule/#risk

[13]

Receiver: https://thanos.io/proposals/201812_thanos-remote-receive/

[14]

remote write API: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write

[15]

helm: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/README.md#helm

[16]

垂直擴展基準: https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae

[17]

這個 issue: https://github.com/improbable-eng/thanos/issues/206

[18]

Compact: https://thanos.io/tip/components/compact/

[19]

遠程存儲的配置: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write

[20]

官方文檔: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/README.md#prometheus-setup

[21]

Read-Write coordination free operational contract for object storage: https://thanos.io/tip/proposals/201901-read-write-operations-bucket/

[22]

存儲架構: https://medium.com/@valyala/how-victoriametrics-makes-instant-snapshots-for-multi-terabyte-time-series-data-e1f3fb0e0282

[23]

Measuring vertical scalability for time series databases in Google Cloud: https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae

[24]

Sidecar : https://thanos.io/tip/components/sidecar/

[25]

Store: https://thanos.io/tip/components/store/

[26]

Query: https://thanos.io/tip/components/query/

[27]

Prometheues 的查詢 API: https://prometheus.io/docs/prometheus/latest/querying/api/

[28]

Prometheues 查詢 API: https://prometheus.io/docs/prometheus/latest/querying/api/

[29]

將 Grafana 中的數據源指向 VictoriaMetrics: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/README.md#grafana-setup

[30]

這個 issue: https://github.com/improbable-eng/thanos/issues/814

[31]

默認狀況下: https://github.com/improbable-eng/thanos/blob/37f89adfd678c0e263a136da34aafe213e88bc24/cmd/thanos/query.go#L93

[32]

只返回部分查詢結果: https://thanos.io/tip/components/query/#partial-response

[33]

VictoriaMetrics 針對查詢速度作了優化: https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae

[34]

官方文檔的示例: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/README.md#high-availability

[35]

價格詳情: https://cloud.google.com/storage/pricing

[36]

價格詳情: https://aws.amazon.com/s3/pricing/

[37]

價格詳情: https://cloud.google.com/compute/pricing#persistentdisk

[38]

價格詳情: https://aws.amazon.com/ebs/pricing/

[39]

這篇文章: https://medium.com/faun/victoriametrics-achieving-better-compression-for-time-series-data-than-gorilla-317bc1f95932

[40]

remote_write API: https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write

[41]

GCE HDD 磁盤: https://cloud.google.com/compute/docs/disks/#pdspecs

[42]

Amazon EBS: https://aws.amazon.com/ebs/

[43]

Prometheus query API: https://prometheus.io/docs/prometheus/latest/querying/api/

[44]

架構很是簡單: https://github.com/VictoriaMetrics/VictoriaMetrics/blob/cluster/README.md#architecture-overview

你可能還喜歡

點擊下方圖片便可閱讀

Awesome Kubernetes 系列：第一期

雲原生是一種信仰 🤘

掃碼關注公衆號

後臺回覆◉k8s◉獲取史上最方便快捷的 Kubernetes 高可用部署工具，只需一條命令，連 ssh 都不須要！

點擊 "閱讀原文" 獲取更好的閱讀體驗！

          
 
           
            
             
              
               
                
                ❤️ 
                給個 
                「在看」 
                ，是對我最大的支持❤️

本文分享自微信公衆號 - 雲原生實驗室（cloud_native_yang）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。