Send OpenTelemetry Collector Data to Sazabi

Last verified on Nov 8, 2026.

The OpenTelemetry Collector is the usual place to add a second destination without touching application code. You add one exporter, list it in a pipeline and the Collector sends every batch to Sazabi as well as to whatever you run today.

Why the Collector is a good place to start

OpenTelemetry's own guidance is to run a Collector alongside your service, because the service can hand data off quickly and the Collector takes care of retries, batching, encryption and filtering of sensitive data. That same placement helps here. One config change covers every service that already sends to the Collector.

Sazabi acts as an additional OTLP/HTTP destination. Nothing about your existing exporters changes, and nobody has to redeploy an application.

What reaches Sazabi

This source stores logs and traces. A logs pipeline might read Kubernetes pod files with the filelog receiver. A traces pipeline might take OTLP from your services or spans from a Jaeger receiver. Any receiver in the Collector ecosystem works, as long as the pipeline ends in the Sazabi exporter.

Metrics are not stored by this source. If you collect host or application metrics in the same Collector, give that pipeline its own exporter and follow the OpenTelemetry metrics setup. Spans carry more detail than log lines do, so read the trace source page before you decide how much to send.

Example: the exporter and two pipelines

This is an example otelcol.yaml fragment. The exporter name otlphttp/sazabi follows the type/name identifier format the Collector uses, and the endpoint comes from an environment variable so the intake URL stays out of version control.

exporters:
  otlphttp/sazabi:
    endpoint: ${env:SAZABI_INTAKE_URL}

service:
  pipelines:
    logs:
      receivers: [filelog]
      exporters: [otlphttp/sazabi]
    traces:
      receivers: [otlp]
      exporters: [otlphttp/sazabi]

Use the complete intake URL from the log source setup screen, including https://. The hostname alone is not enough. The URL is also your credential, so keep it in a secret store.

Check the result

Restart or redeploy the Collector after you change its config. Then open the Intake page in Sazabi and look for the OpenTelemetry Collector source. Records should show up within a minute or two.

You can also count lines per service from the CLI:

sazabi logs ask "how many log lines did each service send in the last 24 hours"

A service that sends traces but no logs, or the reverse, points at a pipeline that is missing the exporter. A pipeline sends only to the exporters in its own list, so each pipeline needs the Sazabi exporter.

Register the source from the CLI

You can mint the intake URL without opening the dashboard. Run this from a machine with the Sazabi CLI installed and signed in:

sazabi log-sources create otel_collector --mode manual

The command prints the intake URL for the new source. Run sazabi log-sources get <log-source-id> to print it again, or sazabi log-sources list to see every source in the project.

If the Collector config lives in a repository, commit only configuration that references the environment variable. Put the URL itself in your secret store. The Collector reads ${env:SAZABI_INTAKE_URL} at startup, so rotating the URL means updating the secret and restarting the Collector, with no config edit.

Common problems

• Nothing arrives after a redeploy. Check the Collector's own logs for TLS, DNS or authentication errors on the Sazabi exporter, and confirm the URL is the full one.
• Traces are missing. The exporter is in the logs pipeline but not in traces.
• Metrics are missing. Expected. This source does not store them.

Where this fits

The Collector is one of several ways to get telemetry in. If your services can export directly, the OpenTelemetry SDK path skips the extra hop. If you already run a different shipper, compare Vector, Fluent Bit and Grafana Alloy in the telemetry pipelines overview.