Benchmarking Kubernetes Log Collectors: Vector, Fluent Bit, OpenTelemetry(victoriametrics.com)
victoriametrics.com
Benchmarking Kubernetes Log Collectors: Vector, Fluent Bit, OpenTelemetry
https://victoriametrics.com/blog/log-collectors-benchmark-2026/index.html
6 comments
Disclaimer: I am affiliated with VictoriaMetrics.
> The test setup is divergent from the real world (single node k8s cluster)
The setup was chosen to simplify the suite, so it can be easily run anywhere. In real world, log collectors are mostly deployed as deamonsets and this is what was tested during the benchmark. The vlagent was initially developed to run as a deployment, though. So I don't think changing setup will affect its performance.
> Their product is #1 in every metric they measured, but is also missing features from those compared against. Will those features change the results?
Depending on what features will be involved into the testing. In the benchmark, all collectors are doing the same job: collecting logs, parsing JSONs, shipping log records. So they are even in used features. Of course, the #1 product is missing features for log transformations, but these features aren't used during testing and shouldn't affect performance of other log collectors.
The bottom line of the post has "Should I switch" section explaining what's missing yet in product #1 for transparency.
> The test setup is divergent from the real world (single node k8s cluster)
The setup was chosen to simplify the suite, so it can be easily run anywhere. In real world, log collectors are mostly deployed as deamonsets and this is what was tested during the benchmark. The vlagent was initially developed to run as a deployment, though. So I don't think changing setup will affect its performance.
> Their product is #1 in every metric they measured, but is also missing features from those compared against. Will those features change the results?
Depending on what features will be involved into the testing. In the benchmark, all collectors are doing the same job: collecting logs, parsing JSONs, shipping log records. So they are even in used features. Of course, the #1 product is missing features for log transformations, but these features aren't used during testing and shouldn't affect performance of other log collectors.
The bottom line of the post has "Should I switch" section explaining what's missing yet in product #1 for transparency.
Using a single node cluster is not representative, full stop.
Meh, I don't get it—what's stopping you from running the same benchmark on a Kubernetes cluster and sharing your own benchmark results, instead of just claiming that this benchmark is crap?
The company selling a product and trying to convince me with benchmarks should be the one putting in the honest effort. The point is to nudge them towards doing this themselves, because people who know about things (how to run distributed system benchmarks) will silently close the tab. HN gives feedback to each other so we can improve. Do you have a problem with that?
Another thing we try to do here is avoid comments that lower the level of discourse, it's in the guidelines.
It seems you are biased to OP, your comment does more harm than good to their effort. (why would I want to use this project if the people around it make snide remarks)
https://news.ycombinator.com/item?id=44680602
Another thing we try to do here is avoid comments that lower the level of discourse, it's in the guidelines.
It seems you are biased to OP, your comment does more harm than good to their effort. (why would I want to use this project if the people around it make snide remarks)
https://news.ycombinator.com/item?id=44680602
The benchmark suite is available here: https://github.com/VictoriaMetrics/log-collectors-benchmark
1. The test setup is divergent from the real world (single node k8s cluster)
2. Their product is #1 in every metric they measured, but is also missing features from those compared against. Will those features change the results?