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

# 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](https://docs.sazabi.com/catalogs/integrations/opentelemetry)

## 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](https://docs.sazabi.com/catalogs/log-sources/send-to-an-endpoint/opentelemetry.md) 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

**Step 1**

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

**Step 2**

### Point the trace exporter at Sazabi

Set these environment variables where the process starts:

```bash theme={"system"}
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:

```yaml theme={"system"}
exporters:
  otlphttp/sazabi:
    traces_endpoint: ${env:SAZABI_TRACES_ENDPOINT}

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

**Step 3**

### Redeploy

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

**Step 4**

### 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](https://docs.sazabi.com/reference/cli.md) (installed and authenticated — see [CLI reference](https://docs.sazabi.com/reference/cli/log-sources.md)).

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

```bash theme={"system"}
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](https://docs.sazabi.com/guides/instrument/intake.md) 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](https://docs.sazabi.com/catalogs/log-sources/send-to-an-endpoint/opentelemetry-metrics.md) instead.

## Further reading

> [card] [Send traces](https://docs.sazabi.com/guides/instrument/traces.md)
>
> How Sazabi stores and correlates traces.

> [card] [Intake](https://docs.sazabi.com/guides/instrument/intake.md)
>
> See per-source ingestion volume and health in the Intake page.


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