Skip to main content
Instrumenting an estate with an SDK is not technically hard. It is hard to coordinate, and that is a different problem with a different solution.
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.

​
The problem it solves

Adding the OpenTelemetry SDK to one service is an afternoon. Adding it to eighty is a programme, because each one needs a team with capacity, a dependency bump, a code review, a test cycle and a deployment window. Some of those services will not get one:
  • Nobody owns it. It runs, it is important, and the team that wrote it has moved on.
  • You cannot rebuild it. A vendor binary, a legacy container image, a language nobody left uses.
  • Change is expensive. A regulated deployment path where a dependency bump means a re-certification.
  • It is not worth an afternoon each. Forty small services, individually unremarkable, collectively the whole of your dependency graph.
The result is familiar: excellent telemetry from the services that were easy, nothing from the rest, and a service map with holes exactly where incidents turn out to live.
The agent’s value is coverage, not depth. One install per host, and every process on it becomes visible at once. It is the fastest way to answer “what is actually running and what talks to what” — and it does not need anyone’s roadmap.

​
When it is the wrong tool

Do not choose zero-code when the question you need answered is inside your code. eBPF observes the boundary. If your open questions are “which customer tier is affected”, “which feature flag was on”, “what did the exception say” or “how long did the internal cache lookup take”, the agent cannot answer any of them, at any privilege level, ever. That is not a limitation to be lifted in a later version — it is where the technique sits.
It is also the wrong tool when:
  • You do not control the kernel. Serverless platforms, gVisor, Firecracker and managed runtimes with no node access are out. See Compatibility.
  • Your teams are already instrumenting. If SDK adoption is happening anyway, the agent adds cost and overlap rather than coverage.
  • Granting kernel capabilities is not approvable. Some security teams will not, and that is a legitimate answer. Capability profiles exists to make that decision on evidence.

​
Use both

Zero-code and the SDK are not competing choices, and treating them as one is the most common mistake in evaluating this.
1

Install the agent everywhere

You get a complete service inventory, a real dependency graph, and RED metrics on every service — including the ones that were never going to be instrumented. This is your floor, and it arrives in an afternoon.
2

Add the SDK where depth pays

The five or ten services where incidents actually get diagnosed. Custom spans, business attributes, exception detail.
3

They join up on their own

The agent reads an incoming W3C traceparent and joins that trace. So a request entering an SDK-instrumented service and passing through an agent-only one produces one trace, not two.
The join works because both speak OpenTelemetry. There is no correlation feature to enable and no vendor glue in the middle — it is the standard context-propagation header doing what it was designed to do.

​
What it replaces, honestly

​
The claim worth checking

Vendors describe agents like this as “100% OpenTelemetry”. For most, the agent is a proprietary binary that emits OpenTelemetry. Here the agent is upstream OpenTelemetry eBPF Instrumentation, unmodified and version-pinned. The practical test is portability: point it at a different OpenTelemetry backend and it works, because there is nothing aiAxonIQ-specific inside it. If you are comparing products, that is the question to ask each of them. See OpenTelemetry OBI.

​
Next

How eBPF works

Enough kernel detail to answer a security question, and no more.

Capability profiles

Three privilege levels and how to choose between them.

Compatibility

Whether your hosts can run it, stated per kernel and platform.