最近几周老冯都在忙一件事，准备 Pigsty v4.0 —— 最主要的工作就是将 Prometheus 和 Loki 换为 Victoria 全家桶。Victoria 是朴实无华的强悍 ——效果非常炸裂。这一部分已经完工，发布一个 Beta 版本让有需要的朋友先耍一耍。
VictoriaMetrics 初体验#
你可能没听说过 VictoriaMetrics，但肯定听说过 Prometheus —— 监控领域的事实标准。VictoriaMetrics 就是 Prometheus 的上位替代品。由白俄罗斯大神程序员 Aliaksandr Valialkin 单枪匹马搞出来，吊打业界的神器。
老冯还记得五年前在探探的时候，那时候我们的监控系统里有五千万左右的时间序列，用了十二台物理机（64C 256G）跑 Prometheus 集群。后来我把 Prometheus 换成了三节点的分布式 VictoriaMetrics，结果轻松扛下来了。后来我还试过，**一台顶配物理机也能扛住，这实在是太惊人了！**那时候我测试下来，VM 的内存/磁盘使用量是 Prometheus 的 1/4 ，查询性能则是 4x 左右，着实让我印象深刻。
业界有很多性能对比（Benchmark），VM 基本都吊打 InfluxDB 、Prometheus、TimescaleDB 的。不管是写入吞吐量还是高基数查询（High Cardinality），VM 都是碾压级的存在。
在 Pigsty 里面，我之前一直用 Prometheus，而 VM 作为专业版可选模块。不过最近有个契机，让我感觉有必要给 Pigsty 的监控基建也翻新一下了 —— 第一是原本使用的日志方案 Grafana Loki 和 Promtail 要淘汰了，想来想去还是得上 VictoriaLogs。第二是正好有个客户 —— 影视飓风 要部署生产级别的 VictoriaMetrics，我就干脆一起搞了。
VictoriaMetrics 其实是一个全家桶，不仅仅可以替代 Prometheus，而且还有 VictoriaLogs 用于存储日志，VictoriaTraces 存储链路追踪，我想着干脆都一起上了吧。于是就在 Pigsty v4 中对 Infra 模块整个进行重写。
为什么要 Vicotira 全家桶？#
在聊性能之前，老冯想先聊聊 VictoriaMetrics 背后的男人 —— Aliaksandr Valialkin（@valyala）。这哥们是白俄罗斯人，在搞 VictoriaMetrics 之前，他是一家广告技术公司 VertaMedia 的 CTO。
在 Go 语言社区里，他早就是个传奇人物了。他写的 fasthttp 库有 2.3 万 Star，性能是标准库 net/http 的 10 倍， 150 万并发连接，每秒 20 万请求。他的 quicktemplate 模板引擎比 html/template 快 20 倍，fastjson 解析器比 encoding/json 快 15 倍。
这些库有个共同的特点：热路径零内存分配。这也是 VictoriaMetrics 为什么这么猛的核心秘密 —— 同样的设计哲学贯穿始终。valyala 的代码风格就是两个字：硬核。不依赖第三方库，极致的内存管理，不仅算法牛逼，工程实现更是变态。所以 VM 继承了 ClickHouse 的衣钵：快，省，稳。它就像是数据库界的 AK-47，结构简单，皮实耐造，但火力极其凶猛。
valyala 这哥们还贼有个性，一个人单枪匹马搞出来的东西吊打业界，放群嘲 AOE ，关键他还是太有实力，直接贴脸用 Benchmark 噎的别人说不出话来。用实力说话就是这么带劲。老冯感觉和他很对脾气，惺惺相惜，经常在 X 上互赞
Victoria 有多强#
言归正传，简单来说，这次我弄了 10 个节点作为测试环境，收集所有的指标和日志。Pigsty v4.0 使用 VictoriaMetrics + VictoriaLogs，一天的数据量，12 万个时间序列用了 600 兆内存，11 亿个数据点占了 440MB 存储；50 万行日志占了 6MB 不到的存储。
也就是说，整个监控基础设施，在充分监控十台物理机和数据库应用的情况下，（还要加上 Grafana，Alertmanager 这些）大概使用了 0.2 个 vCPU / 1GB 的资源。可谓是非常经济实惠了！
作为对比，我又运行 Pigsty v3.7 10 节点环境，使用原本的 Prometheus + Loki ，跑了才 10 个小时。资源使用情况如下。基本上已经接近/超过 VictoriaMetrics 全家桶了，主要是数据量太小，弄几百个节点这个差距会更明显。
当然，要是说只是省点内存磁盘 CPU 啥的，我倒也没那么大兴趣去换。主要是查询响应时间也快了很多，这就不一样了，特别是 VictoriaLogs 相比 Loki，简直就是碾压式的降维打击。面板加载的速度肉眼可见的快了许多，那种上百个 Panel 的 Dashboard 也是瞬间全出，这个感觉实在是太爽了！
老冯自己的测试毕竟规模有限，业界三方数据更有说服力。下面是 Claude 汇总的一些测试用例。不是百分之几十几十的提升，都是几倍几倍的提升，朴实无华的强力。
Victoria 如何替代 Prometheus#
有很多人问，VictoriaMetrics 运维复杂不复杂，从 Prometheus 迁移麻烦吗？老冯可以说，基本上是 “原位替代” —— 就是说，你把 VM 的二进制改个名字顶替掉 prometheus，它也能跑起来。
当然这么说其实是有点夸张了，毕竟还是有一点点小小的区别 —— 比如告警规则（Alert Rules）和预计算规则（Record Rules）其实是由一个单独的组件 VMAlert 来负责的，除此之外，它基本和 Prometheus 一模一样。你可以用一样的配置文件，用同样的 PromQL 查询 —— 当然有个别参数其实也有细微的区别，但都很简单。就一个二进制走天下，但也有分布式的集群版本。
有人说，啊这个分布式集群的架构看上去好复杂。相信我，第一，其实也没啥复杂的，第二，你的量绝对用不上分布式 —— 如果你真有那个量，你现在应该已经早就在用 VictoriaMetrics 了。我们 5000 万时间序列单机搞定，你也没必要去折腾分布式的版本，想要冗余，简单的跑两个独立副本去抓就够了。
当然，VictoriaMetrics 有自己的查询语言 MetricsQL，但也兼容 PromQL。这个老冯就真的懒得改了 —— 那么多个 Dashboard 里面的查询语句，我可没兴趣改写。但好处就是，VictoriaMetrics 可以完美扮演一个 Prometheus，你的 Grafana 只需要简单改一个端口，就可以切换到 VictoriaMetrics。
VictoriaLogs：从拖拉机到法拉利#
如果说 VictoriaMetrics 替换 Prometheus 是 “很不错”，那么 VictoriaLogs 替换 Loki 就属于 —— 从拖拉机到法拉利。我唯一后悔的是为啥没早点把 Loki 给下掉。当然，和 Loki 一起下掉的还有 Loki 配套的日志 Agent Promtail，这个日志收集组件烂尾了，2026 年弃用，这也是老冯这次升级的主要原因 —— 然后用 vector 给替换掉了。
为什么我看这 Loki 不爽很久了？
Loki 的设计哲学是“不索引全文，只索引标签”。听起来很美好，但在大规模日志检索时，它本质上就是个分布式的 Grep。你要查几个关键字，它得把原本的数据块拉出来暴力扫描。数据量一上来，查询慢得让人怀疑人生，动不动就超时或者 OOM（内存溢出）。有时候日志面板时间范围拉大一点，就直接报错了。
而 VictoriaLogs 采用了类似 ClickHouse 的列存和 Bloom Filter 技术。它虽然也不搞全文索引（那样太费空间），但在过滤和定位数据块上做得极极极其高效。不仅快的一批，而且稳如老狗。10x 的性能力大砖飞，大力出奇迹。
虽然 VLogs 不兼容 LogQL，使用的是自己的 LogsQL，但这一次，我把 Loki 的查询语句 LogQL 全部丢进了垃圾桶。LogsQL 明显要优雅，简洁的多：
最爽的是，LogsQL 里 Stream Selector 是可选的。你可以直接写 "error" "timeout" 来全局搜索，不用像 LogQL 那样必须先指定标签。这在排查问题的时候太实用了 —— 很多时候你根本不知道错误会出现在哪个服务里。
如果你还在用 ELK 或者 Loki 这类古早日志方案，真的不如试一试力大砖飞的 VictoriaLogs。说不定连 ClickHouse 的活儿都能干掉一部分了。
VictoriaTraces#
可观测性三剑客，除了指标与日志，还有一个链路追踪（Traces）。老实说，老冯在基础设施和数据库监控里面基本上用不到 Traces。但反正就是加双筷子的事情， 也就顺手弄进来了。你就把他当成一个 Jaeger 用就好了。但这个项目是刚刚从 VictoriaLogs 里分支出来的，成熟度还有待观察，老冯自己也没场景验证。
除此之外，还有一些周边的工具，比如专门用来计算告警的 vmalert，可以独立使用的抓取组件 vmagent，日志收集组件 vlagent，还有备份恢复，auth，之类的各种工具，做的非常的细。企业版里还有降采样，异常检测之类的功能。不过企业版老冯就没啥兴趣折腾了，想要用，自己去下载买 license 吧，反正我觉得开源版够够的了。
我应该如何上手？#
为了帮助用户上手 Victoria 全家桶，老冯还是为用户准备了不少好东西，第一个好东西是 APT / DNF 仓库，里面提供了 Victoria 全家桶的 RPM/DEB 包。单机版，集群版，工具包，Agent，Grafana 数据源，全都打包好了。免去你自己去 GitHub 上扒拉 Tarball，可以直接 yum / dnf install 完成安装。
虽然 Pigsty v4 才正式切换到 Victoria 全家桶，但是 Pigsty Infra 仓库里面维护这些RPM/DEB 包已经很长时间了，久经生产考验。当然也顺便一提，这里面还有其他好东西，比如 Grafana / Prometheus / 对象存储全家桶。（包括 MinIO 不再发布二进制后，老冯还打了 2025-12 修完 CVE 的 RPM/DEB 包）
当然，即使是打好了包，从零开始部署 VM 全家桶还是需要不少工作的，设计目录，参考文档进行配置，接入 Grafana ，开发 Dashboard，Nginx 对接，证书申请，有很多很多脏活累活 —— 就算你用容器也一样省不了。所以老冯的 Pigsty 还有一个妙用，就是一键在 Linux 裸机上帮你拉起这套全家桶。
如你所见，所有服务都被 nginx 封装好了 （又省掉了一个 VMAuth 组件哈哈），统一通过 80/443 端口的 i.pigsty 服务对外暴露。 Nginx + Grafana + VMetrics + VLogs + Vtraces + VMALERT + Alertmanager —— 可观测性七件套，As your service! 整整齐齐一家人！
包括这些组件的自监控，也都配置好了。主机监控，Redis，PostgreSQL 这些也都带在里面了。你要把自己的 App 纳入监控，也完全可以很轻松的用添加配置文件的方式，将其加入进来。
从某种意义上来说，现在的 Pigsty 不仅仅是一个 PostgreSQL 数据库发行版了，还是一个 Observability 可观测性发行版！
快速上手#
Pigsty v4 新增了一个配置文件，infra.yml ，这个模板里只会安装纯粹的 Victoria 全家桶，没有 PostgreSQL / ETCD 这些东西。如果你只是需要一个纯粹的 Vicotira 全家桶，只需要一键就可以在主流 Linux 上交付：
curl https://repo.pigsty.cc/beta | bash
./configure -c infra
./infra.yml
使用的配置文件如下，你可以加更多节点，部署更多副本。
然后所有的东西都会自动为你设置好：
比如三个节点就是这个样子，三个都是独立副本可以独立使用。
Pigsty v4 目前还在 Beta 阶段，但 Victoria 这一部分已经非常稳了，剩下的主要是 Dashboard 优化和文档编写。如果你想要尝鲜 Victoria 全家桶，这也许是最简单的方式。
Pigsty v4.0 正式版预计在 2026 年1月发布，届时会有更完整的文档和更多新特性介绍。有兴趣尝鲜的朋友可以先玩玩，有问题欢迎反馈。后续的版本中，也会添加 Victoria 原生分布式的支持。
写在最后#
这次升级到 Victoria 全家桶，老冯自己也是受益者。每次打开 Grafana 看监控，那种丝滑的感觉，真的会让人心情愉悦。以前那种点一下要等好几秒的日志查询体验，现在回想起来简直是折磨。
VictoriaMetrics 这个项目，代表了开源软件一种很纯粹的形态 —— 一个技术大神凭借极致的工程能力，做出了吊打行业巨头的产品，然后用最宽松的许可证分享给全世界。没有风投压力，不玩 License 变脸，就是踏踏实实做产品，用实力吊打所有友商。这种项目，值得被更多人知道和使用。
