時序數(shù)據(jù)庫有很多，比如Prometheus、M3DB、TimescaleDB、OpenTSDB、InfluxDB等等。Prometheus與VictoriaMetrics都是開源的時間序列數(shù)據(jù)庫，它們都提供了強大的監(jiān)控和告警解決方案。本文我們分析下Prometheus和VictoriaMetrics之間的差異以及優(yōu)缺點，從而來為用戶提供最合適的解決方案。

Prometheus

Prometheus最初是 SoundCloud 中的一個項目，是一個功能強大的監(jiān)控和警報工具包，專門用于處理多維環(huán)境中的時間序列數(shù)據(jù)。由于其對多維數(shù)據(jù)收集、查詢和警報生成的本機支持，它在 SRE 和 DevOps 社區(qū)中變得非常受歡迎。

Prometheus 是在云原生計算基金會 (CNCF) 下開發(fā)的。Prometheus 服務(wù)器、客戶端庫、Alertmanager 和其他相關(guān)組件可以在 Prometheus GitHub 組織中找到。主要存儲庫是：https://github.com/prometheus/prometheus

VictoriaMetrics

VictoriaMetrics則是一個高性能、高性價比、可擴展的時間序列數(shù)據(jù)庫，可以作為Prometheus的長期遠程存儲。它擁有超強的數(shù)據(jù)壓縮和高速數(shù)據(jù)攝取能力，使其成為大規(guī)模監(jiān)控任務(wù)的有吸引力的替代方案。VictoriaMetrics源代碼可以在以下位置找到：https://github.com/VictoriaMetrics/VictoriaMetrics

性能比較

VictoriaMetrics 與 Prometheus 之間的數(shù)據(jù)攝取和查詢率性能基于使用指標的基準node_exporter`測試。內(nèi)存和磁盤空間使用情況數(shù)據(jù)適用于單個 Prometheus 或 VictoriaMetrics 服務(wù)器。

可擴展性和集成性比較

Prometheus使用基于PUll模型來收集指標，可以處理多達數(shù)百萬個活動時間序列。該架構(gòu)雖然簡化了監(jiān)控服務(wù)方的操作。但是也有一定的弊端，比如多個實例抓取的是相同的監(jiān)控指標，不能保證采集的數(shù)據(jù)值為一致的，并且在實際的使用中可能遇到網(wǎng)絡(luò)延遲問題，所以會產(chǎn)生數(shù)據(jù)不一致的問題，不過對于監(jiān)控報警這個場景來說，一般不會要求數(shù)據(jù)的強一致性，所以從業(yè)務(wù)上來說是可以接受，因為這種數(shù)據(jù)不一致性影響基本上沒什么影響。這種場景適合監(jiān)控規(guī)模不大，只需要保存短周期監(jiān)控數(shù)據(jù)的場景。

圖片

而 VictoriaMetrics支持pull模型和Push模型。它能夠處理大量數(shù)據(jù)和更廣泛的網(wǎng)絡(luò)場景（得益于其推送模型支持），使其具有可擴展性和靈活性。

Prometheus架構(gòu)

圖片

Prometheus的架構(gòu)由四個主要組件組成：

1. Prometheus Server ：Prometheus Server是Prometheus的核心組件，主要負責從各個目標（target）中收集指標（metrics）數(shù)據(jù)，并對這些數(shù)據(jù)進行存儲、聚合和查詢。
2. Client Libraries ：Prometheus提供了多種客戶端庫，用于在應(yīng)用程序中嵌入Prometheus的指標收集功能。
3. Exporters ：Exporters是用于將第三方系統(tǒng)的監(jiān)控數(shù)據(jù)導出為Prometheus格式的組件。Prometheus支持多種Exporters，例如Node Exporter、MySQL Exporter、HAProxy Exporter等。
4. Alertmanager：Alertmanager是Prometheus的告警組件，用于根據(jù)用戶定義的規(guī)則對監(jiān)控數(shù)據(jù)進行告警。
5. 服務(wù)發(fā)現(xiàn)：Prometheus 支持各種服務(wù)發(fā)現(xiàn)機制，幫助它找到應(yīng)該抓取的目標。
6. PromQL：這是 Prometheus 內(nèi)置的靈活查詢語言，用于數(shù)據(jù)探索和儀表板，與 SQL 不同。

VictoriaMetrics架構(gòu)

VictoriaMetrics 提供單機版和集群版。如果您的每秒寫入數(shù)據(jù)點數(shù)小于100萬（這個數(shù)量是個什么概念呢，如果只是做機器設(shè)備的監(jiān)控，每個機器差不多采集200個指標，采集頻率是10秒的話每臺機器每秒采集20個指標左右，100萬/20=5萬臺機器），VictoriaMetrics 官方默認推薦您使用單機版，單機版可以通過增加服務(wù)器的CPU核心數(shù)，增加內(nèi)存，增加IOPS來獲得線性的性能提升。且單機版易于配置和運維。

下面這是一個集群版的架構(gòu)圖

圖片

VictoriaMetrics在保持更簡單的架構(gòu)的同時，還包括幾個核心組件：

• vmstorage：數(shù)據(jù)存儲以及查詢結(jié)果返回，默認端口為 8482
• vminsert：數(shù)據(jù)錄入，可實現(xiàn)類似分片、副本功能，默認端口 8480
• vmselect：數(shù)據(jù)查詢，匯總和數(shù)據(jù)去重，默認端口 8481
• vmagent：數(shù)據(jù)指標抓取，支持多種后端存儲，會占用本地磁盤緩存，默認端口 8429
• vmalert：報警相關(guān)組件，如果不需要告警功能可以不使用該組件，默認端口為 8880

數(shù)據(jù)壓縮和存儲效率

Prometheus擁有高效的存儲系統(tǒng)，但在長期數(shù)據(jù)存儲后端和檢索效率方面不如VictoriaMetrics。

VictoriaMetrics 相對于 Prometheus 的主要優(yōu)勢之一是其數(shù)據(jù)壓縮功能。它的數(shù)據(jù)壓縮算法，可顯著降低存儲要求。VictoriaMetrics 聲稱提供比 Prometheus 高出 10 倍的數(shù)據(jù)壓縮，這是長期數(shù)據(jù)保留和成本優(yōu)化的關(guān)鍵優(yōu)勢。

Prometheus

1. 內(nèi)存存儲：Prometheus利用內(nèi)存存儲來訪問最近的時間序列數(shù)據(jù)。數(shù)據(jù)庫中的這個部分被稱為head block。
2. 磁盤存儲：當數(shù)據(jù)達到一定的年齡或大小后，位于"head block"中的數(shù)據(jù)會被移動到磁盤中，這個過程稱為checkpointing。這個數(shù)據(jù)庫由長期存儲的"persistent blocks"組成。

VictoriaMetrics

1.內(nèi)存存儲：與 Prometheus 類似，VictoriaMetrics 使用內(nèi)存存儲在傳入數(shù)據(jù)寫入磁盤之前進行緩沖。這種方法有助于優(yōu)化寫入性能。同時還緩存經(jīng)常訪問的數(shù)據(jù)以加快檢索速度。

2.磁盤存儲：VictoriaMetrics 中的大部分數(shù)據(jù)存儲在磁盤上。它使用一種高效的存儲格式，可以實現(xiàn)大幅度地進行數(shù)據(jù)壓縮。

查詢語言

PromQL

Prometheus使用PromQL。PromQL 允許實時選擇和聚合時間序列數(shù)據(jù)。它使我們能夠高度靈活地使用指標。通過 PromQL，用戶可以過濾和聚合指標，計算比率、比率、平均值和百分位數(shù)等指標。

MetricsQL

VictoriaMetrics向后兼容 PromQL。我們都可以按照理解的 PromQL 語法來進行查詢。但是，它還引入了 PromQL 的擴展，稱為MetricsQL。MetricsQL 增強了 PromQL 提供的查詢功能。它引入了新函數(shù)、運算符和語法糖。簡化并改善了用戶體驗，特別是對于復雜的查詢和聚合。

攝取率

Prometheus

• Prometheus定期從監(jiān)控目標中獲取指標。這些獲取的頻率的調(diào)整可以控制數(shù)據(jù)攝取速率。
• Prometheus實際上能夠攝取數(shù)據(jù)的速率取決于許多因素，包括運行的硬件性能、被獲取的指標的復雜性以及存儲層的效率。
• 如果Prometheus無法跟上傳入數(shù)據(jù)量，可能會丟棄樣本或增加延遲。

VictoriaMetrics

• VictoriaMetrics則比Prometheus更加高效利用資源。它聲稱在相同的數(shù)據(jù)量下，能夠更高效地攝取數(shù)據(jù)，使用更少的CPU、內(nèi)存和磁盤空間。
• 這種效率使得VictoriaMetrics在相同硬件上能夠比Prometheus更快地攝取數(shù)據(jù)。
• 在架構(gòu)設(shè)計方面，VictoriaMetrics可以通過拉?。ㄅcPrometheus類似）和推送模式來攝取數(shù)據(jù)。推送模式對于高基數(shù)數(shù)據(jù)和攝取速率是有幫助的。

高可用性和可靠性

Prometheus 本身并不支持集群，這意味著它不提供原生高可用性。高可用性可以通過運行重復實例來實現(xiàn)，或者thanos架構(gòu)，當然也可以整合VictoriaMetrics。

來源：vivo容器監(jiān)控系統(tǒng)架構(gòu)

而VictoriaMetrics 在設(shè)計時就考慮到了高可用性。它使用復制和集群來確保在實例發(fā)生故障時數(shù)據(jù)不會丟失，從而成為了很多大廠的選擇。

API接口

Prometheus和VictoriaMetrics都提供了基于 Http的 API接口，以滿足客戶端調(diào)用需求

Prometheus API

• 查詢：Prometheus提供了PromQL查詢語言，用戶可以使用該語言通過HTTP API查詢指標數(shù)據(jù)。
• 元數(shù)據(jù)：API endpoint提供對 Prometheus 服務(wù)器中關(guān)系列和標簽的元數(shù)據(jù)的訪問。
• 管理：某些管理任務(wù)，例如刪除系列、快照等，也可以通過 API 執(zhí)行。

VictoriaMetrics API

VictoriaMetrics提供了一個全面的HTTP API，根據(jù)功能分為幾個部分：

• 適用于Prometheus的指標API：此API與Prometheus的HTTP API兼容，這意味著可以將VictoriaMetrics作為Prometheus的替代品。
• InfluxDB API：VictoriaMetrics還提供與InfluxDB的寫入和查詢API兼容的API。這使得從InfluxDB切換到VictoriaMetrics也很容易。
• Graphite API：VictoriaMetrics還為Graphite的API提供了一個兼容層。
• MetricsQL和PromQL API：這些API用于查詢存儲在VictoriaMetrics中的指標數(shù)據(jù)。MetricsQL是VictoriaMetrics特定的PromQL擴展，提供了PromQL中不可用的額外功能。

與 Grafana 集成

由于 VictoriaMetrics兼容Prometheus，所以在 在 Grafana 進行可視化配置時，可以使用“Prometheus”數(shù)據(jù)源，并將 Url 設(shè)置為VictoriaMetrics Server 地址即可。

總結(jié)

以上我們總結(jié)Prometheus與VictoriaMetrics的各個方面的對比，雖然VictoriaMetrics在某些方面可能比Prometheus更強大，比如在處理大規(guī)模數(shù)據(jù)和高并發(fā)負載時的性能表現(xiàn)，完全可以替換Prometheus，但它相對來說是相對較新的項目，尚未達到Prometheus在用戶社區(qū)和廣泛采用方面的水平。此外，Prometheus的發(fā)展時間更早，是CNCF第二個畢業(yè)的項目，已經(jīng)得到了大量用戶的驗證，并且有更多的文檔、教程和案例可供參考。

此外，技術(shù)的流行和廣泛采用并不僅僅取決于技術(shù)本身的性能，還受到多個因素的影響，包括市場宣傳、社區(qū)支持、用戶體驗和可用性等。Prometheus在這些方面都做得相對較好，因此在監(jiān)控領(lǐng)域更為流行和廣泛采用。

參考

https://last9.io/blog/prometheus-vs-victoriametrics/

https://www.qikqiak.com/post/victoriametrics-usage/