14.3 万条/秒！VictoriaMetrics 亲自“开考”，把 8 大主流日志采集器按在地上摩擦

本文永久链接 – https://tonybai.com/2026/08/21/victoriametrics-vlagent-log-collectors-benchmark-2026

大家好，我是Tony Bai。

【导读】

K8s 里每天产生的海量日志，最先经过的那个“搬运工”——日志采集器，性能差距到底有多大？VictoriaMetrics 联合创始人在最新演讲中公布了一份耗时数月的压测报告：在完全相同的 1 核 1GB 资源限制、零调优的条件下，自家新品 vlagent 单节点吞吐量冲到 14.3 万条/秒，是排名第二的 Fluent Bit 的 4.5 倍，是老牌选手 Fluentd 的 28 倍。更值得警惕的是，测试中还揪出了 Fluent Bit 和 Vector 在日志文件轮转时“偷偷丢字段”、Vector 默认配置下会“悄悄漏日志”等一系列容易被忽视的正确性问题。

【文章要点】

• 严格受控的公开测试：测试涵盖 vlagent、Fluent Bit、Vector、OTel Collector 等 9 款主流采集器，在统一的 1 核 1GB 内存、零调优、同节点资源抢占的真实 K8s 环境下进行，测试代码与配置完全开源可复现。
• 吞吐量断层领先：在 100 个 Pod 高并发写入场景下，vlagent 单节点吞吐量冲到 14.3 万条/秒，达到第二名 Fluent Bit 的 4.5 倍，老牌选手 Fluentd 的 28 倍，且吞吐量随负载保持线性扩展。
• 极低的资源消耗：在 1 万条/秒日常负载下，vlagent 仅占用 0.062 核 CPU 与 27.9 MiB 内存，资源效率全场最优；而 Fluent Bit 和 Filebeat 在高压下因内存突破 1GiB 被 OOM Killer 强制杀死。
• 曝光两大主流工具的正确性缺陷：
  • 日志轮转“断句”：Fluent Bit 与 Vector 在日志文件轮转时未拼接上下文，将完整日志切碎成残缺记录转发；
  • Vector 默认配置隐患：默认 60 秒扫描冷却导致新 Pod 启动前期的日志静默丢失，并伴随高负载下的文件描述符泄漏与 Pod 元数据丢失。
• vlagent 适用边界与短板：对 Kubernetes JSON 结构化日志开箱即用且保证不丢数据，但目前尚不支持跨行日志（如 Java 堆栈）合并与非 JSON 自定义正则解析。

如果你的团队在 Kubernetes 上跑着 Fluent Bit、Vector 或者 Filebeat 采集日志，这篇文章可能会让你重新审视一下资源配置表里那几行不起眼的 CPU、内存 request。

时序数据库领域的知名玩家 VictoriaMetrics，最近把目光从“存储日志”转向了“采集日志”这一环。他们开源了一个新的日志采集器 vlagent，并且没有止步于自卖自夸，而是拉来了市面上几乎所有叫得上名字的日志采集器，在同一个测试环境里“真刀真枪”打了一场。测试代码、配置全部开源，任何人都可以自行复现验证。

这篇文章更像一份行业体检报告——它顺带揭出了几个连许多资深 SRE 都没意识到的坑。

日志采集器，为什么突然成了性能焦点

在可观测性的“三驾马车”（Metrics、Logs、Traces）里，日志一直是数据量最大、结构最杂的一块。而日志采集器（log collector）作为整条链路的第一环，承担着从容器标准输出中“抢救”日志、解析、打标签、转发的重任。

一旦采集器扛不住高吞吐，后果通常是两种：丢日志，或者把宿主机的 CPU / 内存资源吃干抹净，反过来影响同节点上正在跑的业务 Pod。在生产环境里，日志采集器往往和业务容器抢同一批资源，这个“隐形税”常年被低估。

VictoriaMetrics 这次测试想回答的问题很直接：在完全相同的资源限制下，谁能扛住更大的日志洪峰，谁的资源效率更高，谁又会在压力下悄悄“作弊”（丢日志、丢字段）？

测试是怎么设计的

整套测试系统由四个部分组成：

• log-generator（日志生成器）：以 Pod 为单位并发写入 JSON 格式的日志，每条记录带有严格自增的 sequence_id，用于后续校验是否丢包；
• 待测采集器：从 /var/log/pods 或 /var/log/containers 里 tail 日志，解析后按各自协议（JSON Lines、Loki、Elasticsearch Bulk、OpenTelemetry）转发出去；
• log-verifier（校验器）：兼容以上所有协议，记录每个采集器实际收到的日志条数和最大 sequence_id，两者之差就是丢失的日志数量，同时统计端到端延迟；
• VictoriaMetrics + Grafana：采集并可视化整个测试过程中的 CPU、内存等资源指标。

下面示意图还原了整体架构：

测试环境非常“抠门”：一台 Google Cloud n2-highcpu-32（32 核、32GB 内存、本地 SSD）虚拟机，跑着一个单节点 kind 集群，所有 9 款采集器同时运行、共享同一个节点，模拟生产环境里资源被其他工作负载抢占的真实场景。每个采集器都通过官方 Helm Chart 部署，限制死 1 核 CPU、1GiB 内存，并且不做任何调优——不改缓冲区大小，不改批量提交参数，不改 GC 参数，全部用官方默认值。

这个设定很关键：这不是“各自跑在专属机器上飙分”的理想化测试，而是模拟了绝大多数团队实际部署时“没空调优、资源有限”的真实处境。

吞吐量硬碰硬：14.3 万条/秒 是什么概念

测试选用 100 个日志生成 Pod 并发写日志作为主要对比场景——这个数字并非随意选取，Kubernetes 官方建议单节点 Pod 数量上限为 110，100 个 Pod 已经是单节点部署下具有代表性的压力上限。

上图展示了 vlagent（蓝线）冲到约 14.3 万条/秒峰值，其余采集器均在 5k–40k 区间见顶。

具体100 个 Pod 场景下各采集器的最大吞吐量如下表：

从曲线上可以看出一个更值得关注的细节：vlagent 的吞吐量随负载几乎呈线性增长，而其他采集器普遍在某个阈值之后就“撞墙”了——不是慢慢爬升到极限，而是很快触顶，即使继续加压也无法再提升。这意味着在真实的日志突发流量（比如故障排查时应用疯狂打印堆栈）场景下，非 vlagent 的采集器更容易率先出现积压甚至丢日志。

CPU 与内存效率：差距不止在峰值

峰值吞吐固然亮眼，但更能反映“日常性价比”的，是在同样负载下谁用的资源更少。测试选取了 10k 条/秒（2 个 Pod、各 5000 条/秒）这个所有采集器（除已经开始丢日志的 Filebeat 和 Fluentd）都还能正常工作的负载点，来对比 CPU 和内存消耗。

10k 条/秒下的 CPU 占用：

10k 条/秒下的内存占用：

一个值得关注的细节是：Fluent Bit 和 Filebeat 在高负载下的内存峰值超过了 1GiB 限制，导致容器被 OOM Killer 强制杀死，这也是它们在压力图中出现断档的原因。换句话说，如果你的生产环境给日志采集器分配的内存不够宽裕，Fluent Bit 和 Filebeat 存在被系统“物理超度”的风险。

比跑分更吓人的：正确性翻车现场

性能测试打分固然直观，但这份报告最有价值的部分，其实是它顺带揪出的几个正确性 bug——这些问题在常规的吞吐量测试里几乎不会被发现，却可能在生产环境里悄无声息地污染你的日志数据。

日志轮转时的“断句”问题

容器日志文件会定期轮转（rotate）。在高吞吐场景下，containerd 有可能在写入过程中恰好触发轮转，导致一条完整的日志记录被“腰斩”——前半段写入旧文件，后半段写入新文件。

理论上，任何采集器在自身 CPU 不足、来不及跟上写入速度时都可能撞上这个时机差，vlagent 也不例外。但测试中发现了一个反常现象：

Fluent Bit 和 Vector 即便在 CPU 占用很低、完全没有性能压力的情况下，也会产生断句记录——原因是它们没有把轮转前后两个文件里的片段重新拼接成完整记录，而是直接把两个残缺片段分别当作两条独立日志转发了出去。在 1 小时、10k 条/秒的相同压力测试下，Fluent Bit 产生了 34 条残缺记录，Vector 产生了 2 条；而测试中其余采集器（包括 vlagent）在多次数小时的重复测试里从未出现过这个问题。

如果你的日志处理管道依赖某些字段做路由、过滤或告警，这种“看起来正常收到了、内容却是坏的”记录，排查起来会格外头疼。VictoriaMetrics 团队已经把这个问题分别提交给了 Fluent Bit 和 Vector 官方仓库。

Vector 默认配置里的隐藏地雷

除了断句问题，测试还专门给 Vector 列了一节“默认配置踩坑指南”：

新 Pod 日志静默丢失：Vector 有一个 glob_minimum_cooldown_ms 参数，控制它多久重新扫描一次文件系统来发现新的日志文件，默认值是 60 秒。这意味着一个新起的 Pod 在头 60 秒内产生的日志，很可能在 Vector 反应过来之前就已经丢失，而且是静默丢失，没有任何报错。作为对比，Fluent Bit 的同类参数默认只有 10 秒，因此不会踩到这个坑。测试中把该参数调到 10 秒后问题消失——但这也说明，默认配置本身是有陷阱的。

文件描述符泄漏：高负载下，Vector 打开日志文件的速度比处理速度快，导致文件描述符数量持续增长。由于文件被进程持有着无法真正删除，轮转后的旧日志文件会在磁盘上不断堆积，极端情况下可能把节点磁盘空间撑爆。

如果负载回落，Vector 最终会追上积压、把日志全部投递完；但如果磁盘先被撑满，或者 Vector 在积压过程中重启，文件描述符会被释放、文件被系统删除，这部分日志就永久丢失了。Vector 提供了 rotate_wait_secs 参数来控制持有轮转文件句柄的时长，但调低它意味着用“可能丢日志”换取“不占满磁盘”——本质上是一个两难权衡，而不是真正的解法。

Pod 元数据丢失：如果一个 Pod 在 Vector 还有它的日志积压未处理完时就被删除了，Vector 会丢失这个 Pod 的标签、注解等 Kubernetes 元数据。日志本身最终还是会被投递，但元数据没了，下游依赖标签做过滤路由的规则可能因此失效。

这三个问题共同指向一个道理：日志采集器的“默认配置”未必是为高负载场景准备的，直接拿官方默认值上生产，本身就是一种未被充分评估的风险。

vlagent 现在能直接换吗？

报告最后也很坦诚地列出了 vlagent 目前的短板：

• 不支持多行日志合并：比如 Java 的异常堆栈这种跨多行的日志，vlagent 暂时无法把它们拼成一条完整记录；
• 不支持自定义格式解析：比如 Nginx access log 这类非 JSON 结构的日志，需要自定义 grok 或正则解析规则的场景，vlagent 目前还不支持。

如果你的管道强依赖这两个能力，现阶段还是应该继续用更成熟、配置更灵活的采集器。VictoriaMetrics 团队表示相关功能正在开发中，计划基于自家的 LogsQL 查询语言实现。

但如果你的诉求相对“朴素”——稳定采集 K8s 里的 JSON 结构化日志、不丢数据、资源占用可控，vlagent 已经具备了几个开箱即用的能力：

• 自动解析 JSON 日志和 Kubernetes 系统日志（无需任何配置）；
• 自动发现并采集集群内所有容器的日志（配套 Helm Chart，开箱即用）；
• 基于 LogsQL 语法，按 Pod / Node 标签或注解过滤日志，噪音日志可以在到达后端前就被丢弃；
• 后端不可用时支持本地磁盘缓冲，连接恢复后自动补发，不需要额外引入 Kafka 之类的消息队列；
• 支持同时向多个目的地复制日志，且每个目的地独立缓冲；
• 官方承诺的"至少一次投递"，即不丢日志。

值得一提的是，vlagent 并不绑定 VictoriaLogs——它同样支持把日志转发给 Fluent Bit、Vector、ClickHouse 等下游系统，也可以和现有采集器并行部署，逐步替换，不需要"推倒重来"。

给 K8s 工程师的几条实践建议

不管你最终选择哪款采集器，这份报告里有几条建议是通用的：

1. 不要迷信默认配置：像 Vector 的 glob_minimum_cooldown_ms 这种参数，默认值可能是为了通用场景做的保守选择，未必适合你的吞吐量级别，上线前最好逐项核对。
2. 给采集器留够资源余量：一个有闲余 CPU / 内存的采集器，才能在日志突发时跟上写入速度、避免错过轮转窗口。资源限制卡得太死，等于主动放弃了抗压能力。
3. 在源头限流：应用一旦开始疯狂重复打印同一条错误日志，最好的做法是尽早在采集器层面按容器或日志流做限速 / 采样，把资源留给真正有价值的日志。
4. 增大轮转前的单文件大小：文件越大，采集器能读取的窗口时间越长，越不容易撞上轮转分割的时机。
5. 如果你的场景是纯 JSON 结构化日志、且对丢日志零容忍，vlagent 值得拿到自己的环境里试跑一轮——测试代码和配置全部开源，复现成本不高。

小结

日志采集器这个组件长期处在可观测性体系里“没人关心”的位置——大家更愿意讨论后端存储怎么选、怎么建索引，却很少有人认真算过采集这一环到底吃了多少 CPU、多少内存，更别说去验证它有没有偷偷丢数据。这次 VictoriaMetrics 的测试，某种程度上是把这个长期被忽视的问题摆到了台面上：性能差距可以是数量级的，而正确性问题往往比性能问题更难被察觉。

如果你的团队正在规划或者重新评估 K8s 上的日志采集方案，不妨去把测试代码拉下来，在自己的环境里跑一遍，比看任何一篇文章都更有说服力。

参考资料：

• 测试代码仓库：https://github.com/VictoriaMetrics/log-collectors-benchmark
• 原文报告：https://victoriametrics.com/blog/log-collectors-benchmark-2026/
• vlagent 文档：https://docs.victoriametrics.com/victorialogs/vlagent/
• Victoriametrics联合创始人的演讲，聊了云原生log收集器的性能 https://www.youtube.com/watch?v=MaRbIfIzeQc

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。