The Oligo sensor runs on the host operating system using eBPF. It observes what your applications actually execute. No code changes, no sidecar, no kernel module, no reboot.
Less than 2% impact on CPU, memory, and I/O. These are production numbers from a live fleet, not a lab bench.
Measured sample 4,000+ nodes
Source: Oligo Sensor Performance Benchmarks, September 2026
Averages across the measured sample. Percentile spread is shown in each chart below.
The Oligo sensor is an eBPF program that loads into the host kernel. It watches what runs and reports what actually executed.
The sensor is not a library you import. It is not a sidecar container. It is not a kernel module. Your application code does not change. Your build does not change. Your Dockerfile does not change.
It runs on the operating system, underneath everything you deploy. That position is why one sensor covers every process on the node, including the software you didn’t write.
These are averages across the full range of Oligo deployments. Every environment is different. Available hardware, workload density, and the applications being scanned all move these figures. We publish the averages so you can check your own against them.
Most monitoring agents pay a tax on every single observation. Data gets collected in the kernel, copied out to user space, and processed there. Every one of those hops costs a mode transition and a copy, and that is where agent overhead actually accumulates.
The Oligo sensor does the filtering and aggregation in the kernel. eBPF programs are JIT compiled into native machine code, so they run at close to native speed. Only the results cross into user space.
The key shift is where the work happens. Fewer transitions, less copying, lower cost.
Traditional endpoint agents load a kernel module. A kernel module runs with full kernel privileges, which means a bug in that module can panic the machine.
eBPF is built differently. Every eBPF program is verified by the kernel before it loads. The verifier rejects programs that can loop forever, read out of bounds, or touch memory they do not own. The program then runs inside a sandbox the kernel itself enforces.
That is the difference between trusting a vendor’s code review and having your own kernel check the code first.
The first few hours cost more than steady state.
The sensor profiles every process on the node when it first comes up. Resource usage runs higher during that window, then settles. Oligo’s team monitors this closely during deployment.
There are hard ceilings.
The sensor enforces strict CPU and memory thresholds and throttles itself as it approaches them.
It loads and unloads without a reboot.
eBPF programs attach and detach dynamically. Rolling out the sensor does not mean rolling your nodes. Removing it does not either.
It tunes to the environment.
The sensor is built to be configured and tuned for the environment it runs in. Dynamic, resource-conscious optimization is included with every Oligo platform license.
What lands on the node, what it needs from you, and how it comes off.
One eBPF program per node, loaded into the host kernel. Nothing is added to your application image.
None. No code change, no rebuild, no sidecar, no kernel module.
None. eBPF programs attach and detach dynamically, so rolling out the sensor does not mean rolling your nodes.
Strict CPU and memory thresholds, enforced by the sensor. It throttles itself as it approaches them.
Detaches the same way it attached. No reboot, no rollback window.
Methodology and benchmark log
Many of the world’s largest and most innovative organizations trust Oligo to secure their applications. This includes members of the Fortune 100. It looks deeper, operates in real time and can halt an attack in less than a second. Oligo could do the same for your organisation, book a demo today.
