最近幾周老馮都在忙一件事，準備 Pigsty v4.0 —— 最主要的工作就是將 Prometheus 和 Loki 換為 Victoria 全家桶。效果非常炸裂，Victoria 是樸實無華的強悍——效果非常炸裂，。這一部分已經完工，發(fā)布一個 Beta 版本讓有需要的朋友先耍一耍。

VictoriaMetrics 初體驗

你可能沒聽說過 VictoriaMetrics，但肯定聽說過 Prometheus —— 監(jiān)控領域的事實標準。VictoriaMetrics 就是 Prometheus 的上位替代品。由白俄羅斯大神程序員 Aliaksandr Valialkin 單槍匹馬搞出來，吊打業(yè)界的神器。

老馮還記得五年前在探探的時候，那時候我們的監(jiān)控系統(tǒng)里有五千萬左右的時間序列，用了十二臺物理機（64C 256G）跑 Prometheus 集群。后來我把 Prometheus 換成了三節(jié)點的分布式 VictoriaMetrics，結果輕松扛下來了。后來我還試過，一臺頂配物理機也能扛住，這實在是太驚人了！那時候我測試下來，VM 的內存/磁盤使用量是 Prometheus 的 1/4 ，查詢性能則是 4x 左右，著實讓我印象深刻。

業(yè)界有很多性能對比（Benchmark），VM 基本都是吊打 InfluxDB 、Prometheus、TimescaleDB 的。不管是寫入吞吐量還是高基數查詢（High Cardinality），VM 都是碾壓級的存在。

在 Pigsty 里面，我之前一直用Prometheus，主要是懶得換，而且公眾認知成本低，而 VM 作為專業(yè)版可選模塊。不過最近有個契機，讓我感覺有必要給 Pigsty 的監(jiān)控基建也翻新一下了 —— 第一是原本使用的日志方案 Grafana Loki 和 Promtail 要淘汰了，想來想去還是得上 VictoriaLogs。第二是正好有個客戶 ——影視颶風要部署生產級別的 VictoriaMetrics，我就干脆一起搞了。

VictoriaMetrics 其實是一個全家桶，不僅僅可以替代 Prometheus，而且還有 VictoriaLogs 用于存儲日志，VictoriaTraces 存儲鏈路追蹤，我想著干脆都一起上了吧。于是就在 Pigsty v4 中對 Infra 模塊整個進行重寫。

為什么要 Vicotira 全家桶？

在聊性能之前，老馮想先聊聊 VictoriaMetrics 背后的男人 —— Aliaksandr Valialkin（@valyala）。這哥們是白俄羅斯人，在搞 VictoriaMetrics 之前，他是一家廣告技術公司 VertaMedia 的 CTO。

在 Go 語言社區(qū)里，他早就是個傳奇人物了。他寫的fasthttp庫有 2.3 萬 Star，性能是標準庫 net/http 的10 倍，能用 150 萬并發(fā)連接扛住每秒 20 萬請求。他的quicktemplate模板引擎比 html/template 快20 倍，fastjson解析器比 encoding/json 快15 倍。

這些庫有個共同的特點：熱路徑零內存分配。這也是 VictoriaMetrics 為什么這么猛的核心秘密 —— 同樣的設計哲學貫穿始終。valyala 的代碼風格就是兩個字：硬核。不依賴第三方庫，極致的內存管理，不僅算法牛逼，工程實現(xiàn)更是變態(tài)。所以 VM 繼承了 ClickHouse 的衣缽：快，省，穩(wěn)。它就像是數據庫界的 AK-47，結構簡單，皮實耐造，但火力極其兇猛。

valyala 這哥們還賊有個性，一個人單槍匹馬搞出來的東西吊打業(yè)界，放群嘲 AOE ，關鍵他還是太有實力了，直接貼臉用 Benchmark 噎的別人說不出話來。用實力說話，就是這么帶勁。老馮感覺和他很對脾氣，惺惺相惜，經常在 X 上互贊

Victoria 有多強

言歸正傳，簡單來說，這次我弄了 10 個節(jié)點作為測試環(huán)境，收集所有的指標和日志。Pigsty v4.0 使用 VictoriaMetrics + VictoriaLogs，一天的數據量，12 萬個時間序列用了 600 兆內存，11 億個數據點占了 440MB 存儲；50 萬行日志占了 6MB 不到的存儲。

也就是說，整個監(jiān)控基礎設施，在充分監(jiān)控十臺物理機和數據庫應用的情況下，（還要加上 Grafana，Alertmanager 這些）大概使用了 0.2 個 vCPU / 1GB 的資源。可謂是非常經濟實惠了?。?/p>

作為對比，我又運行 Pigsty v3.7 10 節(jié)點環(huán)境，使用原本的 Prometheus + Loki ，跑了才 10 個小時。資源使用情況如下。基本上已經接近/超過 VictoriaMetrics 全家桶了，主要是數據量太小，弄幾百個節(jié)點這個差距會更明顯。

當然，要是說只是省點內存磁盤 CPU 啥的，我倒也沒那么大興趣去換。主要是查詢響應時間也快了很多，這就不一樣了，特別是 VictoriaLogs 相比 Loki，簡直就是碾壓式的降維打擊。面板加載的速度肉眼可見的快了許多，那種上百個 Panel 的 Dashboard 也是瞬間全出，這個感覺實在是太爽了！

老馮自己的測試畢竟規(guī)模有限，業(yè)界三方數據更有說服力。下面是 Claude 匯總的一些測試用例。不是百分之幾十幾十的提升，都是幾倍幾倍的提升，樸實無華的強力。

Victoria 如何替代 Prometheus

有很多人問，VictoriaMetrics 運維復雜不復雜，從 Prometheus 遷移麻煩嗎？老馮可以說，基本上是 "原位替代" —— 就是說，你把 VM 的二進制改個名字頂替掉 prometheus，它也能跑起來。

當然這么說其實是有點夸張了，畢竟還是有一點點小小的區(qū)別 —— 比如告警規(guī)則（Alert Rules）和預計算規(guī)則（Record Rules）其實是由一個單獨的組件 VMAlert 來負責的，除此之外，它基本和 Prometheus 一模一樣。你可以用一樣的配置文件，用同樣的 PromQL 查詢 —— 當然有個別參數其實也有細微的區(qū)別，但都很簡單。

有人說，啊這個分布式集群的架構看上去好復雜。相信我，第一，其實也沒啥復雜的，第二，你的量絕對用不上分布式 —— 如果你真有那個量，你現(xiàn)在應該已經早就在用 VictoriaMetrics 了。我們 5000 萬時間序列單機搞定，你也沒必要去折騰分布式的版本，想要冗余，簡單的跑兩個獨立副本去抓就夠了。

當然，VictoriaMetrics 有自己的查詢語言 MetricsQL，但也兼容 PromQL。這個老馮就真的懶得改了 —— 那么多個 Dashboard 里面的查詢語句，我可沒興趣改寫。但好處就是，VictoriaMetrics 可以完美扮演一個 Prometheus，你的 Grafana 只需要簡單改一個端口，就可以切換到 VictoriaMetrics。

VictoriaLogs：從拖拉機到法拉利

如果說 VictoriaMetrics 替換 Prometheus 是 “很不錯”，那么 VictoriaLogs 替換 Loki 就屬于 ——牛逼大發(fā)了，堪稱從拖拉機到法拉利。我唯一后悔的是為啥沒早點把 Loki 給下掉。當然，和 Loki 一起下掉的還有 Loki 配套的日志 Agent Promtail，這個日志收集組件爛尾了，2026 年棄用，這也是老馮這次升級的主要原因 —— 然后用 vector 給替換掉了。

為什么我看這 Loki 不爽很久了？

Loki 的設計哲學是“不索引全文，只索引標簽”。聽起來很美好，但在大規(guī)模日志檢索時，它本質上就是個分布式的 Grep。你要查幾個關鍵字，它得把原本的數據塊拉出來暴力掃描。數據量一上來，查詢慢得讓人懷疑人生，動不動就超時或者 OOM（內存溢出）。有時候日志面板時間范圍拉大一點，就直接報錯了。

而 VictoriaLogs 采用了類似 ClickHouse 的列存和 Bloom Filter 技術。它雖然也不搞全文索引（那樣太費空間），但在過濾和定位數據塊上做得極極極其高效。不僅快的一批，而且穩(wěn)如老狗。10x 的性能力大磚飛，大力出奇跡。

雖然 VLogs 不兼容 LogQL，使用的是自己的LogsQL，但這一次，我把 Loki 的查詢語句LogQL全部丟進了垃圾桶。LogsQL 明顯要優(yōu)雅，簡潔的多：

最爽的是，LogsQL 里 Stream Selector 是可選的。你可以直接寫"error" "timeout"來全局搜索，不用像 LogQL 那樣必須先指定標簽。這在排查問題的時候太實用了 —— 很多時候你根本不知道錯誤會出現(xiàn)在哪個服務里。

如果你還在用 ELK 或者 Loki 這類古早日志方案，真的不如試一試力大磚飛的 VictoriaMetrics。說不定連 ClickHouse 的活兒都能干掉一部分了。

VictoriaTraces

可觀測性三劍客，除了指標與日志，還有一個鏈路追蹤（Traces）。老實說，老馮在基礎設施和數據庫監(jiān)控里面基本上用不到 Traces。但反正就是加雙筷子的事情， 也就順手弄進來了。你就把他當成一個 Jaeger 用就好了。

除此之外，還有一些周邊的工具，比如專門用來計算告警的 vmalert，可以獨立使用的抓取組件 vmagent，日志收集組件 vlagent，還有備份恢復，auth，之類的各種工具，做的非常的細。企業(yè)版里還有降采樣，異常檢測之類的功能。不過企業(yè)版老馮就沒啥興趣折騰了，想要用，自己去下載買 license 吧，反正我覺得開源版夠夠的了。

我應該如何上手？

為了幫助用戶上手 Victoria 全家桶，老馮還是為用戶準備了不少好東西，第一個好東西是 APT / DNF 倉庫，里面提供了 Victoria 全家桶的 RPM/DEB 包。單機版，集群版，工具包，Agent，Grafana 數據源，全都打包好了。免去你自己去 GitHub 上扒拉 Tarball，可以直接 yum / dnf install 完成安裝。

雖然 Pigsty v4 才正式切換到 Victoria 全家桶，但是 Pigsty Infra 倉庫里面維護這些RPM/DEB 包已經很長時間了，久經生產考驗。當然也順便一提，這里面還有其他好東西，比如 Grafana / Prometheus / 對象存儲全家桶。（，老馮還打了 2025-12 修完 CVE 的 RPM/DEB 包）

當然，即使是打好了包，從零開始部署 VM 全家桶還是需要不少工作的，設計目錄，參考文檔進行配置，接入 Grafana ，開發(fā) Dashboard，Nginx 對接，證書申請，有很多很多臟活累活 —— 就算你用容器也一樣省不了。所以老馮的 Pigsty 還有一個妙用，就是一鍵在 Linux 裸機上幫你拉起這套全家桶。

如你所見，所有服務都被 nginx 封裝好了 （又省掉了一個 VMAuth 組件哈哈），統(tǒng)一通過 80/443 端口的 i.pigsty 服務對外暴露。 Nginx + Grafana + VMetrics + VLogs + Vtraces + VMALERT + Alertmanager —— 可觀測性七件套，As your service! 整整齊齊一家人！

包括這些組件的自監(jiān)控，也都配置好了。主機監(jiān)控，Redis，PostgreSQL 這些也都帶在里面了。你要把自己的 App 納入監(jiān)控，也完全可以很輕松的用添加配置文件的方式，將其加入進來。

從某種意義上來說，現(xiàn)在的 Pigsty 不僅僅是一個 PostgreSQL 數據庫發(fā)行版了，還是一個 Observability 可觀測性發(fā)行版！

快速上手

Pigsty v4 新增了一個配置文件，infra.yml ，這個模板里只會安裝純粹的 Victoria 全家桶，沒有 PostgreSQL / ETCD 這些東西。如果你只是需要一個純粹的 Vicotira 全家桶，只需要一鍵就可以在主流 Linux 上交付：

curl https://repo.pigsty.cc/beta | bash
./configure -c infra
./infra.yml

使用的配置文件如下，你可以加更多節(jié)點，部署更多的副本。

然后所有的東西都會自動為你設置好：

比如三個節(jié)點就是這個樣子，三個都是獨立副本可以獨立使用。

Pigsty v4 目前還在 Beta 階段，但 Victoria 這一部分已經非常穩(wěn)了，剩下的主要是 Dashboard 優(yōu)化和文檔編寫。如果你想要嘗鮮 Victoria 全家桶，這也許是最簡單的方式。

Pigsty v4.0 正式版預計在 2026 年1月發(fā)布，屆時會有更完整的文檔和更多新特性介紹。有興趣嘗鮮的朋友可以先玩玩，有問題歡迎反饋。后續(xù)的版本中，也會添加 Victoria 原生分布式的支持。

這次升級到 Victoria 全家桶，老馮自己也是受益者。每次打開 Grafana 看監(jiān)控，那種絲滑的感覺，真的會讓人心情愉悅。以前那種點一下要等好幾秒的日志查詢體驗，現(xiàn)在回想起來簡直是折磨。

VictoriaMetrics 這個項目，代表了開源軟件一種很純粹的形態(tài) —— 一個技術大神憑借極致的工程能力，做出了吊打行業(yè)巨頭的產品，然后用最寬松的許可證分享給全世界。沒有風投壓力，不玩 License 變臉，就是踏踏實實做產品，用實力吊打所有友商。這種項目，值得被更多人知道和使用。