Skip to main content
Overhead is dominated by your traffic, not by a fixed property of the agent — which is why this page tells you how to measure it rather than quoting a number at you.
Availability. The zero-code agent is an early-access distribution. It is installable, upgradable and tested, and it is not yet an integrated part of the product: there is no dashboard page for it, no in-product installer and no self-service download. Ask your account contact for access.Its telemetry, once flowing, is ordinary OTLP and needs nothing special — it appears in Services, Traces and Metrics exactly like SDK telemetry does. That is the design rather than a shortcut.

​
No published figure, and why

We do not publish an overhead percentage.The benchmark tool exists and works. On the host it has been run against, probes did not attach — because that host’s perf_event_paranoid setting prevented it — so the only numbers available describe an idle process doing no instrumentation at all.The tool detects this and declines to present numbers rather than reporting a flattering figure that means nothing. Publishing “under 1%” on that basis would be a number with no measurement behind it, and you would reasonably plan capacity against it.A representative measurement is a known gap. Until it exists, the honest answer is: measure it on your hardware, with your traffic.
This is deliberately the only page in this section without a table of numbers. Every vendor in this category publishes one; not all of them measured it.

​
What drives overhead

Overhead is not a single property of the agent — it is dominated by what your traffic looks like. In rough order of impact:
The probe cost is per observed request. A host serving 50,000 requests per second pays 50,000 times whatever one costs; an idle host pays nothing. This is the term that dominates every other one.
Discovery and attachment are per process. A node running 200 containers attaches far more probes than one running three.
Distinct route patterns drive the size of in-memory aggregation state. Explicit route patterns reduce this as well as reducing your ingest bill — see Troubleshooting.
Profile A watches a socket filter. Profile B attaches uprobes to TLS functions and kprobes, which is more work per request. Profile C adds outbound injection on top.
Userspace aggregation and export are a smaller term than probe cost, and the batching is already tuned for a fleet. Dropped health-check traffic reduces this directly.

​
Measuring it on your hardware

The benchmark refuses to mislead you. If it detects that probes did not attach, it says so and declines to report — which is exactly what happened on the host referenced above. A number from this tool means probes were attached.
For a measurement you can act on:
1

Use a host that passes preflight for your chosen profile

Specifically, confirm perf_event_paranoid is 1 or lower. A run on a host where probes cannot attach measures nothing.
2

Establish a baseline under representative load

Your real traffic shape, not a synthetic loop. Record CPU, memory and your own application’s latency percentiles.
3

Install the agent and hold the load constant

Change one thing.
4

Compare the same percentiles

p50 will move less than p99. p99 is the number that matters, and the one a headline percentage always hides.

​
Reducing overhead

The same levers that reduce your ingest bill:

​
Resource footprint

The agent is one process per host regardless of how many services it observes — so its footprint does not scale with your service count the way a per-service sidecar does. It scales with request rate and process count.
Plan a staged rollout. Validation to date is single-node; there is no fleet-scale soak test. Start with a subset of nodes, measure, then widen. That is good practice for anything holding kernel capabilities, and here it is also how you get the number for your own environment.

​
Next

Known limitations

Everything absent by design, including this gap.

Capability profiles

The profile choice, which is also a cost choice.

Verification

Confirm probes attached before measuring anything.