OpenTelemetry Traces

Set OTEL_EXPORTER_OTLP_TRACES_ENDPOINT to your Sazabi intake URL to store every OpenTelemetry span, and every exception a span records, as a searchable log record.

All OpenTelemetry integration capabilities

About

Send OpenTelemetry traces to Sazabi and search them alongside your logs. Sazabi stores each span as a log record, and each exception a span records as an error record of its own, so the Sazabi agent, search, and patterns work on your traces the same way they work on your logs.

Each span record keeps:

the trace ID, span ID, and parent span ID, so a trace ID finds every span of a request and the logs written during it;
the span's name, kind, status and status message, start time, and duration;
the span's attributes, its resource attributes, and service.name.

Spans with an error status are stored as errors; every other span is stored as info. An exception event becomes an error record carrying the span's trace and span IDs and the exception's exception.type, exception.message, and exception.stacktrace; its message reads <type>: <message>.

Span records carry telemetry.type = span and exception records telemetry.type = span_event, so you can filter for them.

To send OpenTelemetry logs and traces to one base URL without separate exception records, use the OpenTelemetry source instead.

Prerequisites

An application instrumented with an OpenTelemetry tracing SDK, or an OpenTelemetry Collector that receives your spans
Your Sazabi intake URL, shown above. Open the log source and copy the Intake URL from its setup screen; it ends in /v1/traces and has the public key embedded in it.

Set up in the dashboard

Enable the OpenTelemetry tracing SDK

Add or enable the OpenTelemetry tracing SDK in your application, with its OTLP trace exporter. Initialize it before the rest of your application code so early spans are not dropped.

Point the trace exporter at Sazabi

Set these environment variables where the process starts:

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

Use the full intake URL shown above, including /v1/traces. Sazabi accepts OTLP over HTTP (protobuf or JSON).

If your spans go through an OpenTelemetry Collector instead, add an otlphttp exporter to its traces pipeline, and set SAZABI_TRACES_ENDPOINT to your intake URL in the Collector's environment or secret store:

exporters:
  otlphttp/sazabi:
    traces_endpoint: ${env:SAZABI_TRACES_ENDPOINT}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/sazabi]

Redeploy

Restart or redeploy the application or Collector so it picks up the new configuration.

Hand off the change

If this configuration is version-controlled, commit it on a new branch, push it, and open a pull request. Otherwise apply it directly. Keep the intake URL in environment variables or a secret store, and commit only configuration that references it.

Set up with the CLI

You can also register the OpenTelemetry Traces log source with the Sazabi CLI (installed and authenticated — see CLI reference).

Registering the source mints the same intake URL the dashboard shows above (the public key is embedded in its hostname):

sazabi log-sources create otel_traces --mode manual

The command prints the intake URL for the new source — copy the whole URL and point your exporter at it using the configuration shown above. Run sazabi log-sources get <log-source-id> at any time to reprint the endpoint, or sazabi log-sources list to see every log source in the project.

Verify

Make a request your instrumented service handles. Within a minute or two, its spans appear on the Intake page under the OpenTelemetry Traces source.

Start a thread in the dashboard and ask about the service's recent requests, or search your logs by a trace ID to pull its spans, their exceptions, and the logs written during the request together.

Troubleshooting

No spans after redeploying — Confirm OTEL_EXPORTER_OTLP_TRACES_ENDPOINT is set in the process that runs your application and that it ends in /v1/traces. Sazabi accepts OTLP over HTTP (protobuf or JSON), so set OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf if your SDK defaults to another protocol.

Spans arrive but no exception records — Exception records come from exception span events. Confirm your instrumentation records exceptions on the span (for example span.recordException(error) in Node.js or span.record_exception(e) in Python).

Metrics or logs sent to the same URL — Logs sent to the same host with the /v1/logs path are stored as logs. Metrics are not stored by this source; use OpenTelemetry Metrics instead.