Introduction
OpenTelemetry is the escape hatch, and it is a good one. Any runtime that can export OTLP spans can send traces to UnifyApps — no SDK, no supported-framework list, no waiting for an integration. The product's own description of it is exact: send traces from any OpenTelemetry-compatible runtime, no UnifyApps SDK required.
Where to find it
Register the agent, then open its Setup tab and follow the SDK steps. Configure your OpenTelemetry exporter with the endpoint and key shown there: UNIFYAPPS_COLLECTOR_ENDPOINT and UNIFYAPPS_API_KEY.
Note: The endpoint is per agent, and this page deliberately does not print it. It carries your host and the agent's own identifier, and the endpoint shape is still settling. Copy it from the panel; anything transcribed here would be wrong for your tenant and possibly wrong outright.
When OTLP is the right choice
Use OTLP when | Use a platform SDK when |
Your framework is not in the picker | It is, and setup instructions exist |
You already run OpenTelemetry | You do not, and would be adopting it just for this |
You built the agent yourself | It runs on a vendor platform |
You want one tracing approach across services | Only this agent needs tracing |
The first row is the common case, and it is the reason this path exists. A framework absent from the picker is not an agent you cannot govern — it is an agent you instrument this way.
The flow
Register the agent first — The endpoint is bound to a registry record, so the record has to exist before there is anywhere to send to.
Point your exporter at the endpoint on the panel — Standard OTLP configuration — the same environment variable your runtime already understands.
Send a test span — The panel includes a verification call that confirms ingest accepted it. Do this before wiring the real agent; it separates "my exporter is misconfigured" from "my agent is not producing spans".
Run the agent — Status moves to
Activeon the first real trace.
What you send determines what you can govern
This is the trade with OTLP. A platform SDK knows what an agent is and captures the right spans by default. With OTLP you are in control, which means you can under-instrument without noticing.
If you emit | You get | You lose |
Model calls only | Cost, latency, volume | Everything about tool use — and every tool-surface control |
Model calls + tool calls | The full governance picture | — |
A single span per run | The run happened | Any ability to see inside it |
"A control on Tool input cannot fire if you never emit a tool span. Under-instrumenting does not produce warnings — it produces a clean dashboard."
Emit tool calls as spans. It is the single decision that determines whether four of the shipped ISO 42001 controls can do anything at all — see the ISO 42001 pack.
Authentication
Where the endpoint expects a key, the panel mints one and shows it inside the snippet. Treat it as a credential: it is what lets something write traces against your agent's record.
Two practical notes:
The key belongs to the agent. Reusing one agent's key from another service files that service's traces under the wrong record — the most common cause of "my traces went somewhere else".
Set it where the agent runs. Exporter configuration read from a developer machine will not apply in production, and OTLP exporters fail quietly.
Troubleshooting
Symptom | Check |
Verification call fails | Reachability first, then auth. The endpoint has to be reachable from the network the agent runs on |
Verification passes, no traces | Your agent is not exporting. The exporter is configured but nothing is instrumented to use it |
Traces arrive under the wrong agent | The endpoint or key belongs to a different record |
Traces have no cost | Token usage is not on the spans. Cost is derived from what you emit |
Spans arrive but the timeline is flat | Parent-child relationships are missing. Without them there is no run shape to read |