OpenTelemetry-native AI observability.
If you already emit OpenTelemetry, you already emit to Obsivara. Point your OTLP/HTTP exporter at Obsivara's collector and your LLM and agent spans map automatically via GenAI semantic conventions — then get the operations layer OTEL doesn't give you: cost intelligence, health scoring, and predictive failure alerts.
OpenTelemetry, fully observable.
Standards-based ingestion
Use any OTEL SDK in any language. No proprietary agent — Obsivara consumes standard OTLP/HTTP.
GenAI semantic conventions
LLM spans with model, tokens, and cost map automatically to Obsivara's data model following the OpenTelemetry GenAI conventions.
The operations layer on top
Beyond raw spans: per-model/agent/workflow cost, health scoring, waste detection, and predictive failure alerts.
Vendor-neutral
Keep your existing OTEL pipeline. Fan out to Obsivara alongside any other backend — no lock-in.
Three steps. No code changes.
Add an OTLP exporter
Configure your OpenTelemetry SDK's OTLP/HTTP exporter to send to Obsivara's collector endpoint with your ingest key.
Emit GenAI spans
Instrument LLM and tool calls following the GenAI semantic conventions (most GenAI OTEL instrumentations already do).
See it in Obsivara
Spans arrive as runs and traces with cost and health applied — no schema mapping on your side.
Signals tracked out of the box.
- →OTLP run and span traces
- →GenAI model, tokens, and cost
- →Latency and error rates
- →Health score and predictive alerts
- →Cross-language AI telemetry
Common questions.
Which languages are supported?
Any language with an OpenTelemetry SDK and an OTLP/HTTP exporter — Python, JavaScript/TypeScript, Go, Java, and more.
Do I need to change my existing OTEL setup?
No — Obsivara is just another OTLP destination. Keep your current pipeline and add Obsivara as an exporter target.
Does Obsivara export via OpenTelemetry too?
Obsivara ingests OTLP. It's a destination for your GenAI telemetry, not an OTEL exporter itself.