OpenTelemetry Collector vs Datadog Agent: What a Fair, Matched-Load Benchmark Actually Shows
Every observability vendor says its tooling is efficient. Very few publish a number you can check yourself.
That's a problem for anyone choosing between the Datadog Agent and the OpenTelemetry Collector, or deciding how to run both. Most comparisons online are opinions, marketing claims or tests where one tool is under load and the other is sitting idle.
Enterprise buyers have stopped accepting that. The question they ask now isn't "do you say your tooling is efficient?" It's "can you show me working, live, and can I reproduce your numbers?"
So Fusionpact's DevOps team built a way to answer it. This post covers what we built, how we made the comparison fair, what the numbers showed, and what they do and don't mean for your stack.
Why Most Observability Benchmarks Can't Be Trusted
Before getting to results, it's worth saying why so many benchmarks fail.
The busy-vs-idle trap
The most common mistake is comparing a tool handling real traffic against one doing almost nothing. The idle tool looks far more efficient, but the test measured the traffic, not the tool.
We nearly made this mistake ourselves. An early version of our benchmark had exactly this flaw. We caught it internally before publishing anything, threw out the results and rebuilt the test.
No raw data, no reproducibility
A single headline number with no configuration, raw samples or capture method can't be checked. If you can't reproduce it, you're being asked to take it on faith.
Hidden scope differences
Two agents with "default" settings may be doing very different jobs. A fair benchmark has to say exactly what each tool was doing during the test.
Want the full methodology and raw results? Download "The Proof Dividend" benchmark report. It covers the matched-load method, every result, the scope caveats and the guardrail pattern for cost-safe load testing.
How We Built a Fair Observability Benchmark
The test runs on observability-in-a-box, a one-command reference environment built by Fusionpact's DevOps team. It's a realistic multi-service application with a frontend, a backend and a worker, real calls between services and real failure conditions. It deploys with Docker Compose.
The benchmark data and method are in the companion repository, otel-vs-dd-benchmarks.
Matched load: same requests, same moment, both tools
The core rule is that every service reports to both tools for every request. Each of the three services sends a span to the Datadog Agent and to the OpenTelemetry Collector at the same time. Neither tool sits idle while the other works.
The five-step method
Instrument: frontend, backend and worker each emit a span to Datadog and to OpenTelemetry for every request.
Generate load: a controllable load generator drives real traffic at a set requests-per-second rate.
Vary the level: runs are repeated at 10, 50 and 100 requests per second to see whether the gap changes with load.
Capture: container-level CPU, memory and network are sampled every 30 seconds, with 10 samples per run.
Publish raw data: every sample, the exact configuration and the capture script are committed to the repository so anyone can reproduce the results.
Guardrails before load
Generating synthetic telemetry inside a live Datadog account costs real money, so cost controls went in before any load was generated:
A dedicated log index with 15-day retention keeps test data fully separate from any client data.
A hard daily ingestion cap of 1,000,000 events acts as an always-on stop on runaway cost.
A tested kill switch tears down the entire environment and leaves zero processes running.
The same guardrail pattern is worth reusing anywhere you run load tests against a paid observability platform.
The Results: Datadog Agent vs OpenTelemetry Collector CPU Overhead
Here's the CPU usage of each tool under identical, matched load:
Load level | Datadog Agent CPU | OpenTelemetry Collector CPU |
10 requests/sec | 6.1% | 0.30% |
50 requests/sec | 3.85% | 0.25% |
100 requests/sec | 3.47% | 0.44% |
(Tip for Wix: recreate this as a bar chart image. Visual results get shared far more than tables.)
What the numbers show
The OpenTelemetry Collector stayed under 0.5% CPU at every load level.
The Datadog Agent stayed in a 3.5%–6.1% band and didn't rise with a 10x increase in traffic. It actually used the most CPU at the lowest traffic level.
What this means, and what it doesn't
It would be easy to read this as "OpenTelemetry is cheaper". That isn't quite what the data says, and the difference matters.
Most of the Datadog Agent's CPU use comes from fixed background work: disk, network, container and telemetry checks that run on their own schedule, whatever the trace volume. Its overhead is largely fixed. The OpenTelemetry Collector's overhead is proportional to the work it does, and it stayed consistently lower at every level we tested.
The scope caveat, stated plainly: in this test the Datadog Agent was also running its default infrastructure checks, and the OpenTelemetry Collector wasn't configured to do the same work. These results show each tool's out-of-the-box footprint in this stack. They aren't an isolated "traces only" cost for either tool. That's why every configuration file is published, so you can change the scope and rerun the test yourself.
For platform teams, the practical takeaway is that agent overhead depends heavily on what's switched on, not just how much traffic flows through it. Before assuming either tool is "lightweight", measure it in your own configuration.
Curious how your agents perform? Book a free benchmark review. We'll help you run the same matched-load method against your own stack and configuration.
Measured, Not Assumed: A 90% Log Volume Reduction with Vector
The second finding is about log sampling, and about a habit worth breaking.
Most teams quote their configured sampling rate as their savings: "We sample at 10%, so we cut log volume by 90%." But configuration and reality don't always match. Filters, routing rules and transforms can all change what actually gets through.
So we didn't rely on the configuration. After sending real traffic through the full service chain, we queried Vector's own internal telemetry to count events going into the sampling step and events coming out:
Events received: 7,244
Events passed through: 725
Measured pass-through rate: 725 ÷ 7,244 = 10.01%, which means about a 90% reduction in indexed log volume
Since log indexing is generally priced by volume, a measured 90% cut in indexed volume points to a roughly proportional cut in log-indexing spend. You can defend that number in a budget review because it comes from the pipeline itself, not from a config file.
The lesson for any team: don't report the savings you configured. Report the savings your pipeline shows you.
Conclusion: Evidence You Can Check Beats Claims You Can't
The observability market is full of efficiency claims. What's rare is evidence you can watch working and numbers you can reproduce.
That's what this work delivers:
A live reference environment that shows full-stack, dual-instrumented telemetry working in real time.
A reproducible benchmark comparing the Datadog Agent and the OpenTelemetry Collector across three load levels, with every raw sample published.
A measured log-reduction result read from the pipeline's own telemetry, not estimated.
A reusable guardrail pattern for running cost-safe load tests against paid observability platforms.
If you're choosing between Datadog and OpenTelemetry, running both, or trying to prove that your log sampling really saves money, start with evidence rather than assumptions.
Once your telemetry is flowing, the next question is what it costs. See our Datadog cost optimization guide for a safe, read-only way to find waste.
See it live, with your own questions. Book a demo of observability-in-a-box with Fusionpact's DevOps team. We'll walk through the benchmark, show you how to reproduce it, and talk through what it means for your Datadog or OpenTelemetry setup. Book your live demo →
Datadog is a trademark of Datadog, Inc. OpenTelemetry is a trademark of The Linux Foundation. This article is published independently by Fusionpact Technologies and is not affiliated with, sponsored or endorsed by Datadog, Inc. or the OpenTelemetry project. Results reflect this stack's specific configuration and instrumentation scope.
Comments