> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aiaxoniq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Zero-code instrumentation

> Get traces and RED metrics from services you have not instrumented, using eBPF, with no code change, no SDK and no restart. What it is and what it cannot do.

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.

<Warning>
  **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.
</Warning>

## What you get

<CardGroup cols={2}>
  <Card title="RED metrics" icon="chart-line">
    Rate, errors and duration for every HTTP, gRPC and database call each
    service makes and serves.
  </Card>

  <Card title="Server and client spans" icon="share-nodes">
    One span per inbound request and per outbound call, with method, route
    pattern, status and peer.
  </Card>

  <Card title="A service inventory you did not write" icon="magnifying-glass">
    Every service that talks on the network appears — including the ones nobody
    remembered were running.
  </Card>

  <Card title="Kubernetes context" icon="dharmachakra">
    Pod, namespace, node and workload attached to every record, resolved from
    the cluster.
  </Card>
</CardGroup>

## What it cannot give you

This is the honest boundary, and knowing it up front saves an evaluation.

<Warning>
  **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](/zero-code/why#use-both).
</Warning>

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](/zero-code/compatibility).

## How it differs from the other ways to send data

|                                            | Zero-code agent                  | OpenTelemetry SDK               | Collector alone |
| :----------------------------------------- | :------------------------------- | :------------------------------ | :-------------- |
| Code change                                | None                             | Add a dependency and initialise | None            |
| Restart required                           | No                               | Yes                             | No              |
| Covers services you cannot rebuild         | **Yes**                          | No                              | No              |
| Custom spans and business attributes       | No                               | **Yes**                         | No              |
| Exception stack traces                     | No                               | **Yes**                         | No              |
| Host, container and infrastructure metrics | No                               | No                              | **Yes**         |
| Works on Windows or macOS                  | No                               | **Yes**                         | **Yes**         |
| Privilege required                         | Kernel capabilities on each host | None                            | None            |

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](/zero-code/obi).

## Where to go next

<Steps>
  <Step title="Understand the trade-off">
    [Why zero-code](/zero-code/why) — what it replaces, what it does not, and
    when the SDK is still the right answer.
  </Step>

  <Step title="Check your hosts can run it">
    [Compatibility](/zero-code/compatibility) — kernel, distribution, cloud and
    runtime support, stated as *validated* or *expected* rather than blurred
    together.
  </Step>

  <Step title="Choose a privilege level">
    [Capability profiles](/zero-code/profiles) — three levels. Most people
    should use B, and the page says why.
  </Step>

  <Step title="Install">
    [Linux](/zero-code/linux) · [Docker](/zero-code/docker) ·
    [Docker Compose](/zero-code/docker-compose) ·
    [Kubernetes](/zero-code/kubernetes) · [OpenShift](/zero-code/openshift)
  </Step>

  <Step title="Confirm it is working">
    [Verification](/zero-code/verification) — including the failure mode where
    the agent reports healthy and collects nothing.
  </Step>
</Steps>

<Info>
  **Handing this to a security team?** [Security model](/zero-code/security) is
  written for exactly that: what the agent can see, what it sends, what
  privilege it holds and why, and what it never does.
</Info>