Send traces
Send OpenTelemetry traces to Sazabi over OTLP, where spans are stored as searchable records the agent can correlate with your logs, and confirm they arrive.
Sazabi ingests traces over OTLP and stores them as searchable records the agent can correlate with your logs by trace context. For most setups, export OpenTelemetry traces to your project's OTLP intake. By the end you will have traces arriving and confirmed. Setup takes a few minutes plus a redeploy.
How Sazabi handles traces
Traces arrive over the standard OTLP intake and each span is stored as a record, with its trace and span IDs, name, kind, status, duration, and attributes; spans with an error status are stored as errors. Each exception a span records becomes an error record of its own, carrying the exception's type, message, and stack trace. Because every record carries trace context, the agent can line up a trace with the logs emitted during the same request — including browser events when the browser SDK propagates trace context to your backend.
Send OpenTelemetry traces
Get your traces intake URL. In the dashboard, add the OpenTelemetry Traces source under Settings > Log streams and copy the Intake URL from the source's setup screen — your public key is embedded in it, so you copy the whole URL. An agent can do the same with the CLI: sazabi log-sources create otel_traces --mode manual mints a keyed traces endpoint and prints its intake URL. See CLI reference for install and auth.
Enable the OpenTelemetry tracing SDK in your app, or configure the OTLP trace exporter on your Collector.
Set the OTLP traces environment. OTEL_EXPORTER_OTLP_TRACES_ENDPOINT is
the intake URL you copied, which already ends in /v1/traces. Use the
protobuf protocol:
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=<your intake URL>
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobufRestart or redeploy so the new configuration takes effect.
For the full source page, including Collector configuration, see OpenTelemetry Traces.
Query traces in a thread
Traces are stored as records, so you query them the way you query logs: open a thread and ask the agent about a request, or search your logs by trace id to pull the spans and correlated log lines together.
Verify
Confirm a trace reaches your project.
- Configure the trace exporter and redeploy as above.
- Exercise a code path that produces a trace (for example, make a request that flows through instrumented services).
- Search for records from the traced service, or by the trace id if you have it. In a thread, ask the Sazabi agent for those records, or run
sazabi logs ask "records from <service or trace id>" --since 1h. - You should see span records for that request, and an error record for each exception it recorded. Allow a short delay — up to about a minute — for export and ingestion.
If nothing appears, confirm you copied the full intake URL for this project, that the path ends in /v1/traces, and that the exporter uses the http/protobuf protocol.