Skip to main content
Stated plainly, so an evaluation does not spend a week discovering these one at a time. Each says what to use instead.
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 in-process detail

This is the boundary of the technique, not a gap to be closed in a later version. eBPF observes syscalls and library calls. It has no view inside your functions, so it cannot produce:
  • custom spans around your own operations
  • business attributes — order id, customer tier, feature flag
  • exception types and stack traces
  • anything about work that never crosses a socket
Use instead: the OpenTelemetry SDK, in the services where you need it. The two compose — the agent reads an incoming traceparent and joins the same trace. See Zero-code and the SDK together.

​
Linux only

eBPF is a Linux kernel facility. No Windows, no macOS, and no serverless platform where there is no node to install on. Use instead: the OpenTelemetry SDK, or a Collector you run somewhere you do control. See Compatibility.

​
Profile A is unavailable on Kubernetes

The upstream Helm chart hardcodes a six-capability floor for unprivileged mode and ignores the security context when the container is not privileged, so a three-capability profile cannot be expressed through it without forking — which would cost more than the profile is worth. Both the generator and the chart refuse it by name rather than widening the grant to six and still calling it “network only”. Use instead: profile B on Kubernetes; profile A remains available on Linux and Docker. See Capability profiles.

​
TLS library coverage is unmeasured

The agent hooks OpenSSL. Statically linked TLS, BoringSSL, rustls, GnuTLS and NSS are each a potential gap, and the full matrix has not been measured.
This is the largest untested claim surface in the product. Node.js bundles its own OpenSSL; Rust’s rustls is not OpenSSL. Both are known risks rather than known failures.It presents as “some services are missing” and never as an error — which makes it easy to misdiagnose as a broken install. If a service you expected is absent while its neighbours are present, suspect this first.
Use instead: the OpenTelemetry SDK in the affected services.

​
One release per namespace

The agent ConfigMap has a fixed name, because the upstream chart consumes it as a plain value rather than a template. Two releases in one namespace collide, and Helm fails loudly. This is a constraint you would want regardless: two DaemonSets both instrumenting every process on every node would double the overhead and the telemetry.

​
perf_event_paranoid must be 1 or lower

Above that, the kernel denies perf-event access even with the right capability, and the agent starts, holds every capability, reports healthy and collects nothing. Preflight treats it as a blocking failure. On managed Kubernetes it is a node-level change, and on OpenShift a machine-config one — arrange it before the rollout rather than after. See How eBPF works.

​
No published overhead figure

We do not publish an overhead number, because one has not been measured on a representative host. The benchmark tool exists, and it refuses to present numbers when it detects that probes did not attach — so the only figures currently available describe an idle process, and publishing them would be worse than publishing nothing.Use instead: measure on your own hardware. See Performance.

​
No external security review

The agent holds kernel capabilities on every node it runs on. The distribution ships least-privilege defaults, an automated audit tool and a security document written for a reviewer — and nobody outside the team that built it has reviewed the result. If your process requires third-party assurance before granting kernel capabilities in production, that requirement is not met today. See Security model.

​
Validated at single-node scale only

Behaviour has been exercised on a real cluster, Docker, Compose and Helm — but not across a large fleet and not under a soak test. Large rollouts should be staged.

​
Not integrated with the product

There is no dashboard page for the agent, no in-product installer, no onboarding step and no self-service download. Its telemetry appears in the ordinary surfaces because it is ordinary OTLP, and everything else about operating it happens outside the product.

​
Coexistence with the AI-agent eBPF agent is unmeasured

aiAxonIQ also has an eBPF agent for LLM and AI-agent observability. Both attach probes to the same TLS library symbols, and the zero-code agent additionally decodes several GenAI APIs natively — a real overlap.
Running both on one host is untested and not recommended until the convergence decision is made. If you are evaluating both, run them on separate hosts. Talk to your account contact.

​
Next

Frequently asked

The questions an evaluation actually asks.

Performance

What drives overhead, and measuring it yourself.

Compatibility

Where it runs, and where it never will.