Send OpenTelemetry Traces to Sazabi

Last verified on Nov 8, 2026.

Sazabi stores each OpenTelemetry span as a searchable record, and each exception a span records becomes an error record of its own. That means a trace is something you can query with the same search you use for logs.

What each span record keeps

A trace is the path of one request through your system, and it is made of spans. Every span has a trace ID, a span ID and, unless it is the root span, a parent span ID. Sazabi keeps all three, so one trace ID finds every span of a request and the log lines written during it.

Each record also keeps the span name, kind, status and status message, start time and duration, the span attributes, the resource attributes and service.name. Two filters help when you search: span records carry telemetry.type = span and exception records carry telemetry.type = span_event.

Spans with an error status are stored as errors. Every other span is stored as info.

How exceptions become records

OpenTelemetry records an exception as a span event named exception with the attributes exception.type and exception.message. Sazabi turns each of those events into an error record that carries the span's trace and span IDs along with exception.type, exception.message and exception.stacktrace. The record message reads <type>: <message>.

One failing request can therefore produce two records: the span, with an error status, and the exception, with the stack trace.

Example: one failed request, two records

This example shows the layout for a failed checkout request. The values are illustrative.

telemetry.type = span
service.name   = checkout-api
trace ID       = 5b8aa5a2d2c872e8321cf37308d69df2
status         = error
duration       = 842 ms

telemetry.type    = span_event
service.name      = checkout-api
trace ID          = 5b8aa5a2d2c872e8321cf37308d69df2
message           = TimeoutError: payment gateway did not answer in 800 ms
exception.type    = TimeoutError
exception.message = payment gateway did not answer in 800 ms

To debug it, search by that trace ID. You get the failed span, the exception with its stack trace and any application logs written during the request, in one result. If the logs came from a service that also exports through the general OpenTelemetry source, they share the trace ID and line up.

Configure the exporter

Add or enable the tracing SDK in your app, with its OTLP trace exporter, and initialize it before the rest of your code so early spans are not dropped. Then set these where the process starts:

OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=<your intake URL>
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf

Use the full intake URL from the setup screen. It ends in /v1/traces and has your public key embedded in it. OpenTelemetry treats a per-signal endpoint as a literal URL, so nothing is appended for you.

If spans pass through a Collector first, add an otlphttp exporter to its traces pipeline and set traces_endpoint to an environment variable that holds the URL. The Collector page shows the full pipeline layout.

Read a trace from the root down

The root span is the one with no parent span ID. Its children carry that span ID as their parent ID, and so on down the request. When you search by trace ID, start from the root, then follow the slowest child. OpenTelemetry also labels each span with a kind, such as server, client or internal, which tells you whether a span is handling an inbound request or calling another service.

For a failed request, check the status first. A client span with an error status under a server span that returned successfully often means the caller retried or fell back to a default. That is worth knowing before you spend time on the error itself. Create the source from the CLI with sazabi log-sources create otel_traces --mode manual if you want the URL without the dashboard.

Keep metrics and logs apart

Logs sent to the same host with the /v1/logs path are stored as logs. Metrics are not stored by this source, and they have their own intake in the metrics source.

If you want logs and traces on one base URL and don't need separate exception records, the general OpenTelemetry source does that.

Make exceptions visible

Auto-instrumentation records many failures for you, but code that catches an error and returns a 500 often skips the span. Record the exception in the catch block, and set the span status to error. Those two lines are the difference between a trace that explains a failure and a trace that only shows it was slow.