Skip to main content
Zero-code instrumentation observes your services from inside the Linux kernel. You install one agent per host. It sees the traffic your processes send and receive, and turns it into spans and metrics — without you adding a library, changing a line of code, rebuilding an image or restarting a process.
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.

​
What you get

RED metrics

Rate, errors and duration for every HTTP, gRPC and database call each service makes and serves.

Server and client spans

One span per inbound request and per outbound call, with method, route pattern, status and peer.

A service inventory you did not write

Every service that talks on the network appears — including the ones nobody remembered were running.

Kubernetes context

Pod, namespace, node and workload attached to every record, resolved from the cluster.

​
What it cannot give you

This is the honest boundary, and knowing it up front saves an evaluation.
eBPF sees the boundary, not your logic. The agent observes syscalls and library calls. It has no view inside your functions, so there is no way for it to 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
For those you need the OpenTelemetry SDK in that service. The two compose cleanly: run the agent everywhere for coverage, and add the SDK to the handful of services where you need depth. See Zero-code and the SDK together.
It is also Linux only, and it needs a kernel you control. No Windows, no macOS, and no serverless platform where there is no node to install on. See Compatibility.

​
How it differs from the other ways to send data

Most estates end up with all three: the Collector for infrastructure, the agent for breadth, the SDK for depth where it earns its cost.

​
Nothing here is a fork

The agent is upstream OpenTelemetry eBPF Instrumentation (OBI), shipped unmodified. What aiAxonIQ adds sits around it: a configuration with the cardinality and privilege decisions already made, three named capability profiles, a preflight checker, packaging for systemd, Docker, Compose, Helm and OpenShift, and diagnostic tooling. That matters beyond principle. Because the binary is genuinely upstream’s, the telemetry it produces is standard OTLP and you can point it at any OpenTelemetry backend. Nothing about adopting it is a decision you cannot reverse. See OpenTelemetry OBI.

​
Where to go next

1

Understand the trade-off

Why zero-code — what it replaces, what it does not, and when the SDK is still the right answer.
2

Check your hosts can run it

Compatibility — kernel, distribution, cloud and runtime support, stated as validated or expected rather than blurred together.
3

Choose a privilege level

Capability profiles — three levels. Most people should use B, and the page says why.
4

Install

Linux · Docker · Docker Compose · Kubernetes · OpenShift
5

Confirm it is working

Verification — including the failure mode where the agent reports healthy and collects nothing.
Handing this to a security team? Security model is written for exactly that: what the agent can see, what it sends, what privilege it holds and why, and what it never does.