> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sazabi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](https://docs.sazabi.com/guides/instrument/frontend.md) when the browser SDK propagates trace context to your backend.

## Send OpenTelemetry traces

**Step 1**

Get your traces intake URL. In the dashboard, add the OpenTelemetry Traces source under [**Settings > Log streams**](https://app.sazabi.com/settings/log-source-providers) 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](https://docs.sazabi.com/reference/cli.md) for install and auth.

**Step 2**

Enable the OpenTelemetry tracing SDK in your app, or configure the OTLP
trace exporter on your Collector.

**Step 3**

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:

```bash title="Environment" theme={"system"}
OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=<your intake URL>
OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
```

**Step 4**

Restart or redeploy so the new configuration takes effect.

For the full source page, including Collector configuration, see [OpenTelemetry Traces](https://docs.sazabi.com/catalogs/log-sources/send-to-an-endpoint/opentelemetry-traces.md).

## 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.

1. Configure the trace exporter and redeploy as above.
2. Exercise a code path that produces a trace (for example, make a request that flows through instrumented services).
3. 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`.
4. 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.

## Further reading

> [card] [OpenTelemetry Traces source](https://docs.sazabi.com/catalogs/log-sources/send-to-an-endpoint/opentelemetry-traces.md)
>
> The per-vendor setup page.

> [card] [Browser SDK](https://docs.sazabi.com/guides/instrument/frontend.md)
>
> Correlate browser events with backend traces.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.