> ## 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.

# Verifying the agent

> Confirm zero-code telemetry is actually arriving — and rule out the failure where the agent holds every capability, reports healthy and collects nothing.

A running agent is not a working agent. This page is the difference.

<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>

<Warning>
  **The failure you are ruling out is silent.** With `perf_event_paranoid`
  above 1, the agent starts, holds every capability it asked for, passes its
  own internal checks, logs nothing alarming — and collects nothing at all.

  Every check below exists because "the process is up" does not answer the
  question.
</Warning>

## The four checks, in order

<Steps>
  <Step title="The process is running">
    ```bash theme={null}
    systemctl status aiaxoniq-zerocode          # Linux
    docker logs -f <container>                  # Docker
    kubectl -n aiaxoniq get pods                # Kubernetes
    ```

    If it is not, the reason is almost always a missing capability, and the
    startup message names exactly which. See
    [Troubleshooting](/zero-code/troubleshooting).
  </Step>

  <Step title="Probes actually attached">
    ```bash theme={null}
    cat /proc/sys/kernel/perf_event_paranoid    # must be <= 1 for profiles B and C
    journalctl -u aiaxoniq-zerocode | grep -i "perf event"
    ```

    On Kubernetes:

    ```bash theme={null}
    kubectl -n aiaxoniq logs -l app.kubernetes.io/name=opentelemetry-ebpf-instrumentation \
      | grep -i "perf event"
    ```

    A line reading `opening perf event: permission denied` confirms the silent
    failure. Fix it on the host or node:

    ```bash theme={null}
    sudo sysctl -w kernel.perf_event_paranoid=1
    echo 'kernel.perf_event_paranoid=1' | sudo tee /etc/sysctl.d/99-aiaxoniq.conf
    ```
  </Step>

  <Step title="The agent can see other processes">
    If it discovered only itself, it has no shared PID namespace: `--pid=host`
    under Docker, `pid: host` in Compose, `hostPID: true` on Kubernetes (the
    chart sets it).

    The symptom is a service inventory that did not grow.
  </Step>

  <Step title="aiAxonIQ accepted the data">
    Open **Get Started** in the dashboard. The ingest step lights up on the
    first accepted batch, and **Services Discovered** fills in.

    A rejected license key shows as `401` in the agent log — see
    [Troubleshooting](/zero-code/troubleshooting).
  </Step>
</Steps>

## What you should see in the product

Nothing in aiAxonIQ was changed to accommodate the agent, so verification uses
the ordinary surfaces. Within a minute or two of the agent attaching:

| Where           | What to look for                                                     |
| :-------------- | :------------------------------------------------------------------- |
| **Get Started** | The ingest step satisfied, and a non-zero service count              |
| **Services**    | Services you never instrumented, discovered from observed traffic    |
| **Traces**      | Server spans with a method, a route pattern, a status and a duration |
| **Metrics**     | Request duration and count series per service and route              |
| **Service map** | Edges between services that actually call each other                 |

<Note>
  **The agent's telemetry is indistinguishable from SDK telemetry**, because it
  is ordinary OTLP. Verification reads the same key-usage timestamp, the same
  overview counters and the same span-derived service names it always did —
  none of which know or care what produced the batch.

  That is the design, not a shortcut: it is why there is no separate "is the
  agent working" page in the product to keep in sync with reality.
</Note>

## Confirm the privilege you actually got

Intent and reality diverge quietly — a chart default that moved, an upgrade
that regenerated a unit, a flag that was not accepted. The audit tool reports
what the **running** agent actually holds:

```bash theme={null}
./bin/oiq-zerocode-audit
```

Run it after every install and every upgrade. "We deployed profile B" is a
belief until this has been run once.

## When something is missing

The most common outcome is not "nothing" but "some services". That is a
different problem with different causes — TLS library coverage, discovery
scope, or a protocol the agent does not decode. See
[Only some services appear](/zero-code/troubleshooting#only-some-services-appear).

## Collecting diagnostics

If you need to hand something to support:

```bash theme={null}
./bin/oiq-zerocode-support-bundle
```

It collects configuration, versions, capability state, host facts and recent
logs into an archive, with the license key and other credentials **redacted**.
If redaction cannot be completed the bundle deletes itself rather than write a
file that leaks.

## Next

<CardGroup cols={3}>
  <Card title="Troubleshooting" icon="triangle-exclamation" href="/zero-code/troubleshooting">
    Symptom to cause to fix, in likelihood order.
  </Card>

  <Card title="Performance" icon="gauge-high" href="/zero-code/performance">
    What drives overhead and how to measure it on your own hosts.
  </Card>

  <Card title="Known limitations" icon="circle-minus" href="/zero-code/limitations">
    What is missing on purpose.
  </Card>
</CardGroup>