Skip to main content
The questions that come up in a real evaluation, answered directly — including the ones where the answer is “no”. Each links to the page that goes deeper.
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.

​
Getting started

No. No dependency, no import, no initialisation, no rebuild, no restart. You install one agent per host and it observes processes that are already running — including ones that start later.
It is language-agnostic, because it observes the socket and TLS boundary rather than your runtime. Go gets the most depth; Java, .NET, Node.js, Python, Ruby, C, C++ and Rust all produce protocol-level spans and RED metrics.The caveat is TLS libraries rather than languages — see Which services will it miss? below.
Minutes. Install the agent, generate some traffic, and services appear in the inventory. There is no configuration step between installing and seeing data — see Verification.
Yes, and you should. Preflight is read-only and safe to run anywhere. Then install on one non-production host and compare what appears against what you expected.Docker Desktop on macOS or Windows will run it, but observes only what runs inside its Linux VM — fine for a first look, misleading as a basis for planning.

​
Privilege and security

Not required. It runs with an explicit Linux capability set — a named profile. On Kubernetes the container is not privileged: capabilities are dropped entirely and exactly the profile’s set added back.
No. It is in no profile. It is refused outright on the lower two profiles and needs an explicit opt-in flag on the highest.Watch for one trap: upstream documents CAP_SYS_ADMIN as the workaround on AKS and EKS. Setting kernel.perf_event_paranoid=1 on your nodes is the correct fix, and avoids granting near-root cluster-wide. See Security model.
eBPF programs are checked by the in-kernel verifier before loading. A program that could crash, loop unbounded or read out of bounds is rejected and never runs. This is the fundamental difference from kernel-module agents.
It hooks TLS read and write functions, so at that boundary it observes plaintext — including Authorization headers, cookies, bodies and SQL text.It does not send them. Payload capture is off, URL paths are reduced to route patterns before export, and only metadata leaves the host. There is no supported way to enable payload capture in this distribution.This deserves verification rather than trust: the configuration is a plain file and the audit tool reports the running agent’s effective settings. See Security model.
No. Exactly one outbound destination — your configured endpoint, over TLS. No analytics, no usage telemetry, no update check. It opens no inbound listeners.The exception is install time on Linux, which downloads and checksum-verifies upstream artefacts once.
Not externally. It ships least-privilege defaults, an automated audit tool and a security document written for a reviewer — but no third party has reviewed the result.If your process requires that before granting kernel capabilities in production, raise it with your account contact rather than inferring an answer. See What has not been reviewed.
Nothing in the kernel. eBPF programs and their maps are released when the process exits — no module to unload, no reboot. The Linux uninstaller optionally removes the configuration and credential file too.

​
Coverage

Three categories, in likelihood order:
  1. Services whose TLS library it does not hook. It hooks OpenSSL. Statically linked TLS, BoringSSL, rustls, GnuTLS and NSS are potential gaps — Node.js bundles its own OpenSSL and rustls is not OpenSSL, both known risks rather than known failures. The full matrix is unmeasured.
  2. Services it cannot see, because host PID access is missing.
  3. Bespoke binary protocols it cannot decode — you get connection-level information but no request-level spans.
All three present as “that service is missing”, never as an error.
No — not at any privilege level, and not in a future version. eBPF observes the boundary, not your logic. Custom spans, business attributes and exception stack traces require the OpenTelemetry SDK in that service.The two compose cleanly. See Use both.
On the default profile, the agent reads an incoming traceparent and joins that trace, but does not inject one on outbound calls.If your services already propagate traceparent — most modern frameworks do, even without an observability SDK — you get joined traces on the default profile. If nothing propagates, you get excellent per-service telemetry and disjoint traces, and profile C is what closes that at the cost of CAP_NET_ADMIN on every node.Check one request path before planning around this; it is usually the first case.
No. A container has no kernel of its own, so the requirements apply to the host. Distroless, Alpine and full distribution images are equally observable.
No. There is no node to install on and no kernel access. Use the OpenTelemetry SDK, or a sidecar Collector. The rule is simple: if you control the node, the agent works.

​
Operating it

We do not publish a figure, because one has not been measured on a representative host — and the benchmark tool refuses to report numbers when probes did not attach.Overhead is dominated by request rate through instrumented processes, not by a fixed property of the agent. Measure it on your hardware. See Performance.
In order: perf_event_paranoid above 1 (the agent reports healthy and collects nothing), then missing host PID access (it sees only itself), then a rejected license key showing as 401.Each has a confirming command on Troubleshooting.
Re-run the installer, or helm upgrade. Your configuration is preserved unless you explicitly force it to be overwritten. The systemd unit is always regenerated, because it encodes the capability profile — so run the audit tool afterwards to confirm the privilege you actually have.
Yes, and most estates should. The Collector gathers host, container and infrastructure metrics that the agent does not produce; the agent produces application spans and RED metrics the Collector cannot see. They overlap almost not at all.
Not recommended today. Both attach probes to the same TLS symbols, and the zero-code agent also decodes several GenAI APIs natively. Running both on one host is untested. Use separate hosts while evaluating, and talk to your account contact.

​
Commercial

No, and this is testable rather than a claim. The agent is upstream OpenTelemetry eBPF Instrumentation, unmodified. Change the endpoint and credential and it exports to any OpenTelemetry backend.If you are comparing vendors, run that experiment against each of them — most agents in this category are proprietary binaries that emit OpenTelemetry, which is a different thing. See OpenTelemetry OBI.
Through your account contact. It is an early-access distribution: there is no self-service download, no in-product installer and no dashboard page for it yet.
Its telemetry counts toward your plan like any other telemetry, because it is ordinary telemetry. A fleet-wide rollout can be a significant step up in volume — health and metrics endpoints are excluded by default partly for that reason. See Plan limits.

​
Next

Capability profiles

The decision that shapes everything else.

Compatibility

Whether your hosts can run it.

Security model

The document to forward to a reviewer.